Доступен (http://blog.golang.org/go12) значительный релиз языка программирования Go 1.2 (http://golang.org/doc/go1.2), развиваемого компанией Google. При подготовке нового выпуска в кодовую базу проекта внесено более 1600 изменений, внесённых 116 разработчиками, не связанным с компанией Google, что демонстрирует интерес сообщества к проекту и подчёркивает правильность выбора открытого пути развития языка. Код проекта распространяется под лицензией BSD.Язык Go был создан как гибридное решение, сочетающее высокую производительность компилируемых языков с такими достоинствами скриптовых языков, как лёгкость написания кода, быстрота разработки и защищённость от ошибок. Синтаксис Go базируется привычных элементах языка Си с отдельными заимствованиями из языка Python. Язык достаточно лаконичен, но при этом код легко читается и воспринимается. Код на языке Go компилируется в обособленные бинарные исполняемые файлы, выполняемые нативно без использования виртуальной машины (модули профилирвоания, отладки и другие подсистемы выявления проблем на этапе выполнения интегрируются в виде runtime-компонентов (http://golang.org/pkg/runtime/)), что позволяет добиться производительности, сопоставимой с программами на языке Си.
Проект изначально разрабатывается с оглядкой на многопоточное программирование и эффективную работу на многоядерных системах, в том числе предоставляя реализованные на уровне операторов средства для организации параллельных вычислений и взаимодействия между параллельно выполняемыми методами. Язык также предоставляет встроенные средства защиты от выхода за допустимые области выделенных блоков памяти и обеспечивает возможность использования сборщика мусора.Новая версия примечательна переработанным планировщиком (http://golang.org/doc/go1.2#preemption), в котором частично решена проблема с негативным влиянием бесконечно зацикленных нитей на выполнение других подпрограмм в текущем потоке. Планировщик теперь вызывается при входе в фунуцию, т.е. может корректно передать управление другим подпрограммам в условиях вызова функций в цикле, который ранее прожирал все ресурсы (ситуация с inline-циклами не изменилась, но проблема в основном касается конфигураций с одним рабочим потоком, GOMAXPROCS=1). В инструментарий добавлена программа "go tool cover" для сбора и отображения статистики тестового покрытия (Test Coverage) для оценки качества тестирования.
Порция улучшений коснулась непосредственно языка. Изменена логика обработки nil-указателей, при появлении которых отныне выводится ошибка. Добавлена поддержка нового синтаксиса задания слайсов (https://docs.google.com/document/d/1GKKdiGYAghXRxC2BFrSEbHBZ...), оперирующего тремя аргументами - кроме определения непрерывной области в массиве через конструкцию вида array[i:j], теперь можно использовать новый формат array[i:j:k], в котором указывается как размер итогового слайса (j - i), так и его вместимость (k - i), что позволяет разработчику обеспечить доступ только к ограниченной части исходного массива.
Расширено число доступных функций в стандартной библиотеке. Добавлен новые пакеты encoding (http://golang.org/pkg/encoding/) и image/color/palette (http://golang.org/pkg/image/color/palette/). В пакете fmt в строках форматирования Printf обеспечена поддержка проиндексированных аргументов (http://golang.org/doc/go1.2#fmt_indexed_arguments). Расширены возможности пакетов text/template и html/template. Значительно увеличена производительность некоторых пакетов: compress/bzip2 на 30%, crypto/des в 5 раз, encoding/json на 30%. Производительность сетевых функций на платформах Windows и BSD ускорена примерно на 30% (указанные оптимизации были добавлены для Linux и OS X в прошлом выпуске).С 4 до 8KB увеличен минимальный размер стека goroutine, что должно положительно сказаться на производительности некоторых программ. Внесены дополнительные ограничения на размер стека (по умолчанию 1GB для 64-bit и 250MB для 32-bit) и число нитей (по умолчанию 10000), что позволит защитить систему от неконтролируемого потребления ресурсов (для корректировки лимитов следует использовать SetMaxThreads и SetMaxStack в пакете runtime/debug).
URL: http://blog.golang.org/go12
Новость: http://www.opennet.me/opennews/art.shtml?num=38568
Вот оно престанище перловшиков. Надеюсь гугль не забросит его.
там больше синтаксиса питона
Как перловщик говорю - эта ограниченная убогая штуковина не впечатляет совершенно. TIMTOWDI и рядом не лежало. Вот D - этот да, хорош.
Я тоже перловщик, и мне нравится эта штуковина. И чем же по вашему ограничена?
Вероятно у него не получилось приготовить на нём такую привычную и понятную всем перловую кашу.
Чел которому нравится D ... не говори с ним - запачкаешься :-\
Ок, идите туда, где полторы концепции и три оператора - плодите простыни кода. Потому что сложность реашемых проблем - это данность. Она отразится либо в сложность языка либо в сложность библиотек и пользовательского кода. Только вот над языком годами думают, и учить его надо один раз. А бибилотеки и пользовательский код каждый раз новые, и рыться в них каждый раз заново.
Отсутствием метапрограммирования, например, что влечет невозможность сваять аналог дишных ranges. А если более общо - отсутствием "фокусов", которые могут помочь сделать код компактным и выражающим именно то, что хотели.
>Отсутствием метапрограммирования, например, что влечет невозможность сваять аналог дишных ranges.Я не знаю D, но прочитал документацию про ranges и не понимаю, почему их на интерфейсах нельзя сваять.
> А если более общо - отсутствием "фокусов", которые могут помочь
> сделать код компактным и выражающим именно то, что хотели.Use Perl, Luke! C%-@
Я серьёзно - даже рожу вон какую слепил.
И вот в этом D перед перлом как та грелка перед Тузиком ...
Я тоже перловик, никуда валить не собираюсь. Отучайся говорить за всех.
пpиcтaнищe, ёптa
При всех плюсах он пока не умеет линковаться в .so доступные из программ на других языках. Получается он хорош только в написании маленьких приложений. Как только созданные наработки хочется вынести в библиотеку окажется, что никто кроме Go их использовать не сможет.
> При всех плюсах он пока не умеет линковаться в .so доступные изМоно и CIL наше Всё! Да, камрад Мигель?
> окажется, что никто кроме Go их использовать не сможетО боже, Erlang, Lisp (добавите сюда практически любой non-C язык) тоже не умеют!
Да, но они-то скриптовые, а не компилируемые...
> Да, но они-то скриптовые, а не компилируемые...Сам ты скриптовый...
> Да, но они-то скриптовые, а не компилируемые…ты так больше не шути, пожалуйста.
> О боже, Erlang, Lisp (добавите сюда практически любой non-C язык) тоже не умеют!При том это баг, а не фича. Почему этот ретардизм с невозможностью реюза кода считается нормальным? Вот си и держит №1 по популярности. Реюз кода - великая вещь.
> Реюз кода - великая вещь.и код на эрланге отлично можно «реюзать» в другом проекте на эрланге. а код на cl — в другом проекте на cl. я тебе ещё страшней вещь скажу: код на си тоже только в другом проекте на си можно «реюзать». ну, и в c++, если повезёт.
Именно. А вызывать сишные функции из динамически компонуемых библиотек не умеет разве что Brainfuck. Написать сишную обёртку для функции на другом ЯП - тоже посильная задача для простых смертных.
Fortran и FreePascal почему-то умеют.
вроде как благодаря go имеем docker-контейнеры для виртуализации на базе cgroup.
То, что его написали на го, не означает, что его нельзя было написать на чем-то другом. Потому благодарить не за что.
> То, что его написали на го, не означает, что его нельзя было
> написать на чем-то другом. Потому благодарить не за что.Потому что ты жадная шкoлoта. Написать можно много на чём - однако написали на Go.
ну в общем конечно это не та благодарность по сравнению с тем, что если бы контейнеры написали бы на эрланге... Хотя все-равно разнообразие несколько радует...
> вроде как благодаря go имеем docker-контейнеры для виртуализации на базе cgroup.Сами по себе cgroups и LXC - набор системных вызовов и ряда рукояток. То что некто накатал один из управляторов на go - не делает это чем-то эксклюзивным, а основная заслуга идет таки ядру линя, а не этой оболочке от cocиски.
поражаюсь людям пишушим комменты и не разбирающимися в вопросе, ну не позорьтесь.
LXC это тулза в юзерспейсе.
если бы не контейнеры - не интересовался особо этим языком, а так выглядит как язык с системным уклоном и возможностями параллельности, хотя какая может быть параллельность без эрланга...
>какая может быть параллельность без эрланга...такая же как ис эрлангом, только без эрланга.
>>какая может быть параллельность без эрланга...
> такая же как ис эрлангом, только без эрланга.Go красивый и компактный, но не функциональный. А без иммутабельности достичь "прозрачной" параллельности проблематично. Отсюда и проблемы с планировщиком, возможно. Модель акторов как гарант асинхронного взаимодействия в этом языке не упоминается. Но тем не менее язык интересен и корректно с эрлангом его можно сравнивать только по определенным нишам.
GC и производительность Си звучит мягко говоря странно. Отожрав хотя-бы гиг оперативы, от производительности не останется и следа
> GC и производительность Си звучит мягко говоря странно. Отожрав хотя-бы гиг оперативы,
> от производительности не останется и следаОт реализации ГЦ зависит. И, кстати, чем чаще и тщательнее мусор собирается, тем тормозов больше. А аллоцированная память на производительность мало влияет.
Теория говорит о том, что в общем случае тормоза сборщика пропорциональны объёму занятой памяти. Сказки про генерации, инкрементальную сборку и нон-стоп оставьте на закуску теоретикам.
> Теория говорит…
> Сказки … оставьте на закуску теоретикам.молодец, взаимоисключающие параграфы во все поля!
Отожрав 1 гагабайт оперативы из 128 гигабайт. Гугель предлагает Go для написания программ работающих на сервере.
А скорость достигается путем того что программа не ищет свободное место ОП, а использует заранее подготовленную область. Любая крупная программа использует техники автоматизированного управления памятью, так какая разница кто это будет делать пограмист-пейсатель программы или компилятором (виртуальной машиной)?
Очень кстати новость. Только вчера начал знакомиться с языком. Интересен для разработки веб приложений.
> Очень кстати
> языком
> для разработки веб приложений.Написал на awk-е вебсервер. До 4ёх утра писал - взлетело. Массу удовольствия получил! </чистейшая>
Адгбша - вы таки лох :) На вашем любимим баш давно уже есть < пол-кило буков.PS: Да я и сама офигела :)
Всё бы хорошо, но статическая линковка - это виндузятничество. Хотя тому, что гугл - латентные виндузятники, я не удивлён.
> гугл - латентные виндyзятники, я не удивлён.Они б рады, да вот конкурент им MS, опаньки.
> Всё бы хорошо, но статическая линковка - это виндузятничество.нет, это пайковщина: http://harmful.cat-v.org/software/dynamic-linking/ он известный противник shared libraries.
Ты дал ссылку на плохой сайт, необъективный.
Можешь доказать необъективность?
> Можешь доказать необъективность?да чо там — это ж пландевятовцы, где Пайк руку приложил. конечно, необъективны: ну точно же слова Пайка исказили!
>достоинствами скриптовых языков, как лёгкость написания кода, быстрота разработки и защищённость от ошибокЭти "достоинства скриптовых языков" не вытекают из какой-то абстрактной "скриптовости".
> Новая версия примечательна переработанным планировщиком, в котором частично решена проблема с негативным влиянием бесконечно зацикленных нитей на выполнение других подпрограмм в текущем потоке. Планировщик теперь вызывается при входе в фунуцию, т.е. может корректно передать управление другим подпрограммам в условиях вызова функций в цикле, который ранее прожирал все ресурсы (ситуация с inline-циклами не изменилась, но проблема в основном касается конфигураций с одним рабочим потоком, GOMAXPROCS=1).Ээээээпать, расшифруйте чего здесь написано ??? Потоки, нити, подпрограммы...
>> Новая версия примечательна переработанным планировщиком, в котором частично решена проблема с негативным влиянием бесконечно зацикленных нитей на выполнение других подпрограмм в текущем потоке. Планировщик теперь вызывается при входе в фунуцию, т.е. может корректно передать управление другим подпрограммам в условиях вызова функций в цикле, который ранее прожирал все ресурсы (ситуация с inline-циклами не изменилась, но проблема в основном касается конфигураций с одним рабочим потоком, GOMAXPROCS=1).
> Ээээээпать, расшифруйте чего здесь написано ??? Потоки, нити, подпрограммы...Go может запускать несколько потоков через штатные threads уровня ОС. В каждом из потоков внутренним планировщиком может дополнительно обеспечиваться параллельное выполнение нескольких подпрограмм. Если поток только один, и одна подпрограмма зависла, то и остальным подпрограммам становится плохо. Сейчас чуть поправили эту проблему.
Ура!
Хз как все, уже больше года пишу на Go и чем дальше тем больше нравится, уже практически не использую другие языки, причем нравится что могу и для Винды написать, и для Линухов тоже. Согласен что есть маленький косяк, что не делает нормальных dll, so... но извините это 1 версия языка, все еще впереди.
с другой стороны, Go собирает все в один исполняемый файл, что очень удобно для деплоя на сервер
> с другой стороны, Go собирает все в один исполняемый файл, что очень
> удобно для деплоя на серверУдобно?!?!
И при уязвимости - менять все 100500 задеплоеных нетленок?
У врачей это называется шиндовс межушного ганглия.
А что ты делаешь, когда находишь в софте, не написанном на Go, уязвимость? Правильно, то же самое: обновляешь его (или его компоненты) на всех серверах, заменяя уязвимые копии.
> А что ты делаешь, когда находишь в софте, не написанном на Go,
> уязвимость? Правильно, то же самое: обновляешь его (или его компоненты) на
> всех серверах, заменяя уязвимые копии.а если уязвимость в библиотеке? ура-ура, пересобираем всё, что на этом ге было собрано — вместо замены одной библиотеки и перезапуска софта.
И в чем проблема пересобрать? При такой скорости компиляции даже не заметишь.
(вздыхает) да ничего, ничего, просто иди мимо.
Скажите лучше, как вы живёте с rc-кодами?
> Скажите лучше, как вы живёте с rc-кодами?намного комфортней, чем с исключениями.
>> Скажите лучше, как вы живёте с rc-кодами?
> намного комфортней, чем с исключениями.Комфортнее чем? Тем, что при каждом вызове на каждом уровне нужно думать о том, что там внутри могло что-то случиться и это надо как-то обработать?
> Комфортнее чем? Тем, что при каждом вызове на каждом уровне нужно думатьДа, большинству думать некомфортно...
>> Комфортнее чем? Тем, что при каждом вызове на каждом уровне нужно думать
> Да, большинству думать некомфортно...Думать в момент, когда с возникшей проблемой ничего сделать нельзя, опасно для психического здоровья.
> Комфортнее чем?если бы тебя действительно это интересовало, ты бы давно уже прочитал кучу аргументов обеих сторон, и пришёл бы сюда с более-менее конкретными вопросами. но ты пришёл с горящим взором и пустой головой — я это специально проверил своим ответом.
поэтому гуляй, вася. лимит просвещения дураков у меня временно исчерпался.
Дурные оскорбления пропущу мимо ушей. Будем считать, что у Вас день не задался.Аргументы сторон, по крайней мере, некоторые из них, я, естественно читал. Как другой спор тупо- и остроконечников, про Checked/Unchecked Exceptions в Java/Scala. А ещё знаком с методологиями обработки исключительных ситуаций в таких, например, языках как Visual Basic и Rexx'е, где действительно были чётко выделенные fail/recovery секции, и, в целом, при всех известных ограничениях, код они не загрязняли.
Под загрязнением кода я в ввиду примерно такие конструкции, щедро разбросанные по многим Go-шным библиотекам:
defer func() {
if e := recover(); e != nil {
err = e.(error)
}
}()Замечу, что никаких _осмысленных_ действий в этом случае не производится, только борьба с приступами диар^W паники в нижележащем коде, конвертация из одного вида исключительных ситуаций в другой. О котором, кстати, вызывающей стороне ещё и думать надо будет особо, даже если ничего осмысленного она с этой ошибкой сделать не сможет.
Ребята, после такого со скепсисом начинаешь воспринимать критику подхода с исключениями, они-де обрабатываются где попало, а не ровно в том месте, в котором есть хоть какой-то шанс сделать с этим исключением что-то осмысленное.
Поэтому, собственно, и вопрос был: почему лично Вы думаете, что такой способ лучше?
исключения — это fuckin' uncontrollable mess. прежде всего.во-первых, они нарушают execution flow, и в итоге *весь* код должен учитывать наличие исключений, даже если он их не использует. особенно больно надо бить по почкам, если execution flow ломает библиотека: in no fuckin' way any library should go out of control. в итоге получается то же самое, что и без исключений, только if'ы заменяются на catch'и. ну, и компилятор нагружается лишней ерундой.
вообще, всё — от неправильной трактовки исключений. исключение — это «а-а-а-а, паника, спасай что можешь и ползи на кладбище!», а не «упс, файлик не открылся, лови булыжник и пробуй другой». если произошло исключение — никаких catch нет и быть не должно, максимум — быстрый cleanup с вываливанием на диск каких-нибудь потрохов, которые потом будет разбирать recovery system.
а если исключение используется как control flow statement — это полное непонимание того, что такое исключение и использование оного не по назначению. к сожалению, практика черезжопного использования исключений очень распространена, и единственный вариант эффективной борьбы с ней — вообще выкинуть catch.
вообще, это вопрос разных «школ».
большие проекты в итоге приходят к очень строгой политике контроля и битию по голове за библиотеки, которые кидаются своими отрыжками во все стороны. именно потому, что со временем контролировать это всё сложнее и сложнее.
в общем-то, это весьма длинная сказка с элементами BDSM и mind control. и всё равно люди с крепким background в каком-нибудь цпп или жабе обычно излечению не подлежат, потому что категорически не понимают ключевого постулата: «exception is not a control flow statement».
просто в качестве курьёза, не в качестве иллюстрации тезиса: мне доводилось видеть программу, где функции возвращали значение через throw. человек таким образом реализовал механизм ослабления типизации, желая, чтобы функции могли возвращать «всё на свете». и проверял результат в разных catch.
> исключения — это fuckin' uncontrollable mess. прежде всего.:-) Это лозунг. Как "земля - крестьянам, фабрики - рабочим..." В каждом конкретном случае он может быть правдой, может быть неправдой, или может постепенно дрейфовать из одной крайности в другую.
> во-первых, они нарушают execution flow, и в итоге *весь* код должен учитывать
> наличие исключений, даже если он их не использует.Ну, Вы понимаете, что типичное для C и Go программ 'if (rc != 0) { сделайте с этим что-нибудь! }' - это точно такое же нарушение нормального хода выполнения? Да, в Go есть ещё и defer'ы, которые частично ситуацию исправляют, а частично - запутывают её. По сути, в большинстве случаев, defer - это такой аналог вызова деструктора на размотке стека, только явно прописанный. А коли явно, значит, о нём можно забыть, перепутать порядок следования и прочая-прочая-прочая.
> особенно больно надо бить по почкам, если execution flow ломает библиотека:
> in no fuckin' way any library should go out of control.Опять же, если библиотека разумно спроектирована и аккуратно оповещает пользователя о том,
что в ней что-то может пойти не так (а то, что пойти не так может - это, я думаю, неоспариваемо?), то, по большому счёту, выбор метода оповещения - это исключительно вопрос синтаксических средств. За исключением того, что эксепшны - это _единообразный_
способ оповещения, а в Go'шных либах встречается и rc, и паника, там где автор поленился поймать панику на выходах из либы и обернуть её в rc.> в итоге получается то же самое, что и без исключений, только if'ы заменяются на
> catch'и. ну, и компилятор нагружается лишней ерундой.Ну, есть возможность не делать ничего на тех уровнях, где контроль не нужен (== там, где мы ничего осмысленного с этим сделать не можем). О существовании эксепшнов на таких уровнях напоминают только сигнатуры методов. Но за правильностью сигнатур IDE/чекеры отлично следят. Ну а заботиться об удобстве компилятора в ущерб удобству глаз и рук - это, действительно, слегка мазохизм.
> вообще, всё — от неправильной трактовки исключений. исключение — это «а-а-а-а,
> паника, спасай что можешь и ползи на кладбище!»,Нет. Это способ аккуратно передать управление из того места, где жопа случилась, в то место, где с этой жопой можно сделать что-либо осмысленное.
> если произошло исключение — никаких catch нет и быть не должно, максимум — быстрый
> cleanup с вываливанием на диск каких-нибудь потрохов, которые потом будет разбирать
> recovery system.Вы путаете с abort(3)/std::terminate/java.lang.Error(). Там, да, методика обработки именно такая.
> вариант эффективной борьбы с ней — вообще выкинуть catch.
> вообще, это вопрос разных «школ».Ну, мне вот, да, представляется что это скорее педагогический вопрос, а не техническое преимущество. Но запретить, знаете ли, всегда проще, чем научить, как именно этим пользоваться.
> большие проекты в итоге приходят к очень строгой политике контроля и битию
> по голове за библиотеки, которые кидаются своими отрыжками во все стороны.
> именно потому, что со временем контролировать это всё сложнее и сложнее.Ну, у нас есть несколько больших проектов (на Яве), и тщательно продуманное и прописанное полиси, что есть Checked Exception, в каких случаях нужен Unchecked, а в каких обязателен Error (такие случаи тоже есть, хотя их заведомо меньше пальцев на одной руке :)), и где именно обрабатывать. В общем, как-то справляемся :)
> не понимают ключевого постулата: «exception is not a control flow statement».Хех :) На то у нас есть свой постулат, не хуже Вашего ;) Но, подчёркиваю, реальная жизнь она сложнее лозунгов и постулатов.
> просто в качестве курьёза, не в качестве иллюстрации тезиса: мне доводилось видеть
> программу, где функции возвращали значение через throw.Ну а на то есть Gerrit Code Review, прочная металлическая линейка и доска почёта. Хотя, подчёркиваю ещё раз, не поглядев на тот код, а также на условия его написания, я не возьмусь однозначно за линейку.
Вообще, решать проблемы педагогические путём запретов - это всё равно, что своего ребёнка отучать курить, обыскивая его карманы в поисках табачных крошек и жестоко карая за это. Свинья в любом случае грязь найдёт.
В общем, позицию я Вашу, в целом, понял. А вот детали...
а детали — это долго, нудно, безрезультативно и офтопично. всё равно никто никого в итоге не убедит.
>[оверквотинг удален]
> по голове за библиотеки, которые кидаются своими отрыжками во все стороны.
> именно потому, что со временем контролировать это всё сложнее и сложнее.
> в общем-то, это весьма длинная сказка с элементами BDSM и mind control.
> и всё равно люди с крепким background в каком-нибудь цпп или
> жабе обычно излечению не подлежат, потому что категорически не понимают ключевого
> постулата: «exception is not a control flow statement».
> просто в качестве курьёза, не в качестве иллюстрации тезиса: мне доводилось видеть
> программу, где функции возвращали значение через throw. человек таким образом реализовал
> механизм ослабления типизации, желая, чтобы функции могли возвращать «всё на свете».
> и проверял результат в разных catch.let it crash
> let it crashДа, если остальное окружение это позволяет.
let it live? в принципе, вы правы, если позволяет окружение, но чревато неправильной работой.Пример утечки памяти - течет, но пусть работает. Вообще это конечно больше философский вопрос.
есть аналог си-шеых указателец ?
http://bolknote.ru/2011/05/05/~3200#10
Графическую библиотеку к нему прикрутили?
Кстати, для всех интересующихся Go http://4gophers.com/