После шести месяцев разработки компания Google представила (http://blog.golang.org/go1.6) релиз языка программирования Go 1.6 (http://golang.org), который позиционируется как гибридное решение, сочетающее высокую производительность компилируемых языков с такими достоинствами скриптовых языков, как лёгкость написания кода, быстрота разработки и защищённость от ошибок. Код проекта распространяется под лицензией BSD.
Синтаксис Go основан на привычных элементах языка Си с отдельными заимствованиями из языка Python. Язык достаточно лаконичен, но при этом код легко читается и воспринимается. Код на языке Go компилируется в обособленные бинарные исполняемые файлы, выполняемые нативно без использования виртуальной машины (модули профилирования, отладки и другие подсистемы выявления проблем на этапе выполнения интегрируются в виде runtime-компонентов (http://golang.org/pkg/runtime/)), что позволяет добиться производительности, сопоставимой с программами на языке Си.Проект изначально разрабатывается с оглядкой на многопоточное программирование и эффективную работу на многоядерных системах, в том числе предоставляя реализованные на уровне операторов средства для организации параллельных вычислений и взаимодействия между параллельно выполняемыми методами. Язык также предоставляет встроенные средства защиты от выхода за допустимые области выделенных блоков памяти и обеспечивает возможность использования сборщика мусора.
Основные новшества (http://golang.org/doc/go1.6), представленные в выпуске Go 1.6:
- В модуль net/http (https://golang.org/pkg/net/http/) добавлена поддержка протокола HTTP/2, которая при использовании HTTPS включена по умолчанию как для клиентов, так и для серверов. Использование новой версии модуля позволит задействовать HTTP/2 в уже существующих проектах на языке Go, в том числе в http-сервере Caddy (https://caddyserver.com/);- Расширены возможности, связанные с использованием шаблонов (модуль text/template (https://golang.org/pkg/text/template/)). Добавлена поддержка чистки пробелов (https://golang.org/pkg/text/template/#hdr-Text_and_spaces) вокруг операций в шаблоне и реализована новая операция "{{block}} (https://golang.org/pkg/text/template/#hdr-Actions)" для создания блочных шаблонов, собираемых из других шаблонов;
- Включена по умолчанию поддержка директории vendor (https://golang.org/s/go15vendor), предназначенной для поставки внешних зависимостей, привязанных к определённому поставщику;
- Проведена оптимизация работы модулей compress/bzip2, compress/gzip, crypto/aes, crypto/elliptic и crypto/ecdsa, производительность которых возросла приблизительно на 10%. Изменён алгоритм сортировки, используемый в sort.Sort, что также позволило поднять производительность примерно на 10%. Cтарый алгоритм сортировки доступен через вызов sort.Stable (https://golang.org/pkg/sort/#Stable) для тех кому требуется полная идентичность порядка вывода;
- Сокращено число пауз, вызванных работой сборщика мусора, что особенно заметно в программах, расходующих большие объемы памяти;
- Добавлены экспериментальные порты для Linux на 64-рядных процессорах MIPS (linux/mips64 и linux/mips64le) и Android on 32-разрядных процессорах x86 (android/386);
- Для сборки порта во FreeBSD в качестве внешнего компилятора по умолчанию задействован Clang вместо GCC;
- В компилятор, систему динамического связывания и команду "go" добавлена новая опция "-msan", доступная только на архитектуре linux/amd64 и включающая режим совместимости с анализатором памяти Clang MemorySanitizer (http://clang.llvm.org/docs/MemorySanitizer.html), который удобно использовать для тестирования приложений, содержащих вставки на C и C++;
- В runtime добавлен легковесный механизм выявления неправомерного одновременного использования ассоциативных массивов (map). Если один goroutine записывает в map, то другой goroutine не может прочитать или записать в map. В случае, когда данное условие нарушено и runtime выявил конфликт, программа будет экстренно завершена с выводом соответствующего сообщения об ошибке. Для выявления подобных проблем на этапе отладки предлагается использовать race-detector (https://blog.golang.org/race-detector);- В runtime изменён метод вывода информации о крахе программы, которая теперь включает только дамп стека для вызвавшего проблему goroutine, а не для всех goroutine как раньше. Изменить данное поведение можно через переменную окружения GOTRACEBACK (https://golang.org/pkg/runtime/#hdr-Environment_Variables) или вызвав функцию debug.SetTraceback (https://golang.org/pkg/runtime/debug/#SetTraceback);
- В Cgo, механизм для организации вызова кода на C/C++ из программ на языке Go, внесены изменения (https://golang.org/doc/go1.6#cgo) в правила совместного доступа к указателям, которые в основном связаны с обеспечение сосуществования кода на языке Си со сборщиком мусора языка Go.URL: https://blog.golang.org/go1.6
Новость: http://www.opennet.ru/opennews/art.shtml?num=43898
Не понял - что такого в том, чтобы в двух goroutine обращаться к одному map? Они ж кооперативные, никаких проблем с локами быть не должно?
map-ы в Go не thread-safe. Читать можно конечно и без всяких lock-ов, но не писать. Удобно поэтому для конкурентного доступа к map использовать sync.RWMutex.
Да, удобно. Но зачем теперь сразу ошибку сегфолтить?
Явное лучше неявного.Словить панику на месте приятнее чем чесать репу разбирая странности потом.
С вашей логикой тогда надо крэшить для всех типов одновременный доступ, например, для int. Одновременная запись в string не вызывает паники, и как бэ "явное неявное" почему-то всех устраивает. Race - все же на совести программиста. Зачем паниковать, тоже не понимаю.Тем более есть прекрасный sync в стандартной либе.
> С вашей логикой тогда надо крэшить для всех типов одновременный доступ, например,
> для int.Было бы неплохо, но сложно реализовать не уничтожив скорость работы и не раздув код
Абзац про гоу-няшное костылестроение с горутином в мужском роде — это пять. Сегодня так ещё не смеялся.
Хороший язык!
Для написания фирмваре?
CS 1.6 - понимаю
CS Go - понимаю
Go 1.6 - не понимаю
¯\_(ツ)_/¯
Отличный язык!
От какого языка отличный?
От других.
Злые языки бають, что от лимбо не отличный. Ату их!
>с такими достоинствами скриптовых языков, как ... защищённость от ошибок.Вы поделили на ноль. Скриптовые языки предоставляют защищённости от ошибок, если только не имеется ввиду, что программа как-нибудь да будет работать даже при наличии кучи ошибок, легко отлавливаемых в статически строго типизированных компилируемых языках.
>Скриптовые языки НЕ предоставляют защищённости от ошибокИсправлено
> легко отлавливаемыхУ низкоуровневых языков есть свои траблы.
Программы с миллиардами (!) пользователей, написанные на C страдают от таких проблем, как переполнение буфера и выход за границу массива. (Пруфы? Открой список CVE за последние пару лет)
И что-то не сильно легко эти баги отлавливаются.
Программы с миллиардами (!) пользователей, написанные на ПХП страдают от таких проблем, как переполнение sql-injection и сравнение нуля с пустой строкой. (Пруфы? Открой новости за последние пару лет)
ПХП же хуже мерзкого бейсика, к чему он тут?
Как бы о защищённости от ошибок динамически типизированных языков.
Обоснуй!
PS: я не про то, что PHP или, упасихоспади, Basic в чем-то хороши. Но вот так PHP равнять с Бейсиком! Не настолько же он плох!!!
Программы с миллиардами (!) пользователей, написанные на ПХП страдают от таких проблем, как переполнение sql-injection и сравнение нуля с пустой строкой
Дык программы на си и этим страдают и перечисленным предыдущим оратором.
То что на php или java можно сделать `rm -rf /` не повод считать их плохими.А вот то, что на си даже крутой программер не может обеспечить 100% отсутствие переполнений - это повод назвать сишечку какашечкой.
> Программы с миллиардами (!) пользователей, написанные на ПХП страдают от таких проблем,
> как переполнение sql-injection и сравнение нуля с пустой строкой
> Дык программы на си и этим страдают и перечисленным предыдущим оратором.
> То что на php или java можно сделать `rm -rf /` не
> повод считать их плохими.
> А вот то, что на си даже крутой программер не может обеспечить
> 100% отсутствие переполнений - это повод назвать сишечку какашечкой.Ща вот прям срыв покровов будет. ПХП написан на C (как, в общем-то, и Java, и даже само небо и сам Аллах). Поэтому:
1. Программы на ПХП имеют кучу проблем, обусловленных ПХП.
2. Программы на ПХП наследуют проблемы С, на котором написан ПХП.
3. Программисты на ПХП не могут поправить косяки программистов С, написавших ПХП, и живут как-то с этим.
Справедливости ради, такие ошибки можно и нужно вылавливать статическими анализаторами типа PVS-Studio (на чем они кстати и пиарятся). То, что это мало кто делает -- вопрос другой.
А вот для языков с динамической типизацией статический анализатор как-то трудно представить
Ваше замечание в целом верно кроме того, что не имеет отношения к моему комментарию. Я не писал про низкоуровневые языки. Перечитайте, у меня написано:>статически строго типизированных компилируемых языках
На всякий случай уточню - это не про Си, ему не хватает строгости.
Переполнение буфера и выход за границу массива - это по большей части проблемы динамического характера и они недостаточно эффективно отлавливаются на этапе статического анализа. То есть, это вообще не о том. Выход за границу массива и в динамически типизированном языке будет выходом за границу массива. Будет ли оно проходить незаметно или будет сопровождаться крахом - это не свойство вида типизации.
> это не свойство вида типизации.Согласен. Мой комментарий был не к месту.
При выходе за границу массива или иной структуры в скриптовых языках не произойдет чтения или перезаписи других данных. С этой точки зрения они защищают(но не предотвращают) от данного класса ошибок.
>При выходе за границу массива или иной структуры в скриптовых языках не произойдет чтения
>или перезаписи других данныхЭто не свойство динамически типизированных языков.
никнейм у тебя правильный, соотвествует уровню комментариев
>Код на языке Go компилируется в обособленные бинарные исполняемые файлы,
>выполняемые нативно без использования виртуальной машины (...), что позволяет
>добиться производительности, сопоставимой с программами на языке СиСопоставимая с Си производительность достигается на том же уровне, что и в Java с обособленной виртуальной машиной и не всегда в пользу Go. А при использовании AOT подходы становяться ещё более похожими.
Хм. Мой опыт использования aptly показал, что это инструмент весьма шустрый.
Раз Вы взялись утверждаеть, что у Go такие же проблемы с производительностью, как и у Java - пожалуйста, подтвердите пруфами.
А у java есть проблемы с производительностью?
java вообще летает, особенно в связке с 100500 мб оперативы и N ядерным процом с тактовой частотой 100500 ГГц.
> java вообще летает, особенно в связке с 100500 мб оперативы и N
> ядерным процом с тактовой частотой 100500 ГГц.Именно так, анонимушка. На большие задачи, которые в любом случае потребуют толстого железа, на си умаешься писать масштабируемый, назовем его обработчик. Или в сишном мире уже появился аналог JavaEE?
На чём написана jvm напомнить? :)
На чём написано си себе напомни.
Внезапно - на С же и написанна :) Но жабофилам этого не понять, мозжечок не вмещает :)
Я не писал о проблемах производительности. Я указал на то, что утверждение:>Код на языке Go компилируется в обособленные бинарные исполняемые файлы,
>выполняемые нативно без использования виртуальной машины (...), что позволяет
>добиться производительности, сопоставимой с программами на языке СиЯвляется ошибочным.
По поводу доказательств. Посмотрите, кто соседствует друг с другом в тестах скорости:
http://benchmarksgame.alioth.debian.org/u64q/which-programs-...
Раньше этот тест был более информативным:
http://web.archive.org/web/20150923053032/http://benchmarksg...Поинтересуйтесь, почему в блоге разработчиков так радуются улучшению производительности сборщика памяти:
https://blog.golang.org/go15gc
Прошу простить мне неграмотность, однако не подскажете ли Вы мне также, что я должен знать, чтобы понимать эти графики? Я нигде не нашёл описания подобного рода графиков, хотя совершенно точно видел их уже не раз. Я боюсь, что читаю их не правильно.1) Что значит жирная линия посередине столбца? Это среднее значение всех программ, участвовавших в тесте?
2) Что означает белый столбец, внутри которого содержится линия? Это разброс всех замеренных результатов?
3) Что означают чёрные палочки под и над столбцом? Это погрешности измерений?
Это графики для визуализации статистических данных. Можете почитать про боксплоты в "Наглядная статистика. Используем R" биолога Шипунова. Если лень - просто ориентируйтесь на жирную горизонтальную линиию - медиану.
Окей, значит я пока понял это дело так. Go процентов на 30% шустрее Java, но оба они примерно в 2 раза медленнее C.
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...Результат, в принципе, интересный. Меня также удивляет, что OCaml оказался позади Java и Scala, хотя на данный момент, как утверждают некоторые товарищи из Inria, он обладает самым быстрым GC, пускай и однопоточным: при столь малых размерах получаемых бинарей программы на Ocaml могут позволить себе форки, и забить на треды.
Ещё такой момент: я не понимаю, каким образом у Java/Scala получаются такие хорошие результаты. Это AOT тому причиной? Я вот чего не знаю наверняка:
1) Jar-ники с jvm-байткодом можно полностью перегнать в нативный код для ускорения программы после старта?
2) В jvm есть gc, но ходят слухи, что работает он так "хорошо", что сжирает вообще все русурсы CPU, и потому его отключают. Вам известно, как дела обстоят на самом деле?По поводу радости разработчиков Go улучшению производительности gc, думаю, тут всё весьма очевидно. Заставить хорошо работать многопоточный gc - та ещё головная боль, ocaml-исты с этой задачей уже собаку съели, но до сих пор не сделали. Если у Go он работает, причём быстро - так это большая победа.
> 1) Jar-ники с jvm-байткодом можно полностью перегнать в нативный код для ускорения программы после старта?Так с этим вроде стало яснее. Был AOT-compiler GCJ из набора, который похоже загнулся, ибо последние обновления датированы 2009-м. Сейчас осталось проприетарное поделие Excelsior JET, которое, впрочем, уже поддерживает восьмёрку.
Я так понял, что они перегоняют набор jar-ников в бинарь. А в самих jar-никах содержится исключительно jvm-байткод. Всегда.
Попровьте меня, если где-то ошибся.
> Окей, значит я пока понял это дело так. Go процентов на 30%
> шустрее Java, но оба они примерно в 2 раза медленнее C.Ты неправ. Во первых задачи бывают разные, я сталкивался с реальными задачами, на которых java быстрее си.
Во вторых, при большой сложности проекта java/c получается деление на ноль, т.к. на си надо бесконечное количество программистов с бесконечно крутыми познаниями на бесконечное время.
Ну, а так, в теории да, "сферическовакуумная сишечка быстрее в 2 раза".
> 2) В jvm есть gc, но ходят слухи, что работает он так
> "хорошо", что сжирает вообще все русурсы CPU, и потому его отключают.
> Вам известно, как дела обстоят на самом деле?Странно иметь какие-то мнение по вопросу вообще не будучи в теме. Сборщик мусора в java-программах часто вообще не запускается.
На очень жирных программах, в духе - системная интеграционная шина огромной организации, которая имеет потребление порядка 20ГБ ОЗУ и лютое количество enterprise java bean-ов ("потоков") может например срабатывать раз в 6-10 часов и тормозить программу на пару-тройку секунд. И что? Кто лучше-то может?
>2) В jvm есть gc, но ходят слухи, что работает он так "хорошо", что сжирает вообще все
>русурсы CPU, и потому его отключаютGC в Oracle JVM работает куда лучше для модели Java чем GC в Go, но разработчики инструментария для Go не стоят на месте.
Потенциально Go предоставляет возможность для большей эффективности при работе с памятью поскольку в отличии от Java позволяет размещать переменные структурного типа статически. На практике это может никак не проявиться, потому что это сложнее, особенно для бывшего Джависта, который тянет в Go патерны из Java. С другой стороны, JVM в ряде случаев способна провести оптимизацию и разместить динамические с точки зрения языка данные статически. Это не говоря уже о AOT, который позволяет провести более глубокую оптимизацию за счёт меньших ограничений на время компиляции. С другой стороны JIT позволяет получить профиль использования программы и делать оптимизацию более предметно.Вообще, в современном мире невменяемо сложных техник компиляторов и процессоров очень сложно разобраться что быстрее чего(обратите внимание, что результаты тестирования довольно существенно отличаются для разных процессоров).
Мне вот интересно, зачем они все эти модули в языке тащат.
Потому как язык изначально для толковых студней создавалася, поэтому, с кучей стандартных либ в Go проще стартануть.Я, конечно, за минимальньное ядро языка (aka runtime) - работа со строками, числами, базовый I/O (сокеты, файлы) - должно быть достаточно.
Потому что это означает, что оно всё будет развиваться в гармсонии с остальными частями языка, и будет какой-то понятный мейнстрим с понятным статусом, а не десяток "стандартов де-факто", тянущих каждый в свою сторону."Batteries included" - это сейчас вообще необходимость для любого нового языка.
Пользователь IDE? :)ЯП = синтаксис, и либы тут немного сбоку. Хороший пример - C/C++ к-ми можно пользоваться без стандартных либ.
Начни с ввода/вывода в консоль без стандартных либ в С/С++.
Ну посмотри как в линукс ядре, например, выводят на консоль. Без стандартных либ.
Дооо - ты напиши корректный printf сначала чмо малолетнее :) Там и зубры тока так зубы ломают :-F
Так в ядре же есть своя libc: klibc. И вот куча функций:
usr/klibc/printf.c
usr/klibc/vfprintf.c
usr/klibc/vsnprintf.c
usr/klibc/stdio/fwrite.c
usr/klibc/SYSCALLS.defПроисходит следующее:
--> printf()
--> vfprintf(stdout,... )
--> vsnprintf()
--> _fwrite(..., stdout)
--> fwrite_noflush()
--> write() (SYSCALL)
Этих модулей нет в языке, они в стандартной библиотеке. Чем это хорошо при должном уровне разработки библиотек - понятно, чем плохо - не понятно.
> что позволяет добиться производительности, сопоставимой с программами на языке Си.а затем:
> Сокращено число пауз, вызванных работой сборщика мусора, что особенно заметно в программах, расходующих большие объемы памяти;Ну и его сраный рантайм, пихаемый прямо в код бинаря, никак не добавляет производительности, сравнимой с Си
Скорость только возрастает, если рантайм встраивается в исполняемый файл. Рантайм есть и у Си, но обычно идёт в виде динамической библиотеки при возможности статической компоновки. Для Go выбрали обратный подход - по умолчанию идёт статическая компоновка, но возможна и динамическая.
CS GO 1.6 вышел?
круто!
>Изменён алгоритм сортировки, используемый в sort.Sort, что также позволило поднять производительность примерно на 10%судя по коммиту, увеличили минимальный размер массива для сортировки вставками, но добавили сортировку Шелла.
Интересно, почему там не используется timsort, как в большинстве современных библиотек. (видимо потому что появился после 1990-го года. Все эти Коксы с Пайками - они такие)
> Интересно, почему там не используется timsort, как в большинстве современных библиотекВ большинстве??? Согласно википедии: питон, а также джава, андроид и октав. Всё.
> (видимо потому что появился после 1990-го года. Все эти Коксы с
> Пайками - они такие)Ну, Роб Пайк, может, и да. Но Рас Кокс - поколение помоложе.
> Добавлены экспериментальные порты для Linux на 64-рядных процессорах MIPS (linux/mips64 и linux/mips64le) и Android on 32-разрядных процессорах x86 (android/386);прошу гугл добавить arm/arm64 и powerpc/powerpc64 - очень хочется докеры
> Cтарый алгоритм сортировки доступен через вызов sort.StableДезинформация. sort.Stable был и до этого, а sort.Sort был отличен от него.
> В Cgo, механизм для организации вызова кода на C/C++ из программ на языке GoА вот этот последний пункт - самая большая головная боль для кучи проектов. Даже если ты передавал opaque указатель, теперь - нельзя! Указатели нужно хранить в map, и передавать можно только "указатели" на эти указатели.
В общем, извращенцы
Вообще, я - за Go! Но, признаю, что это решение выглядит неуклюже. Причина: сборщик мусора. Чтобы ему было удобней, решили пожертвовать удобством для cgo.
Наркоман, что ли? Ничего подобного и близко нет.
Для тех, кто в танке, один из основных разработчиков Go, ответственный за gccgo/cgo:
https://github.com/golang/go/issues/8310#issuecomment-66096613
Привет, мир, пожалуйста, в студию.
Какие браузеры поддерживают язык?
Здравствуй, школьник. В привычном понимании этого слова никакие браузеры не поддерживают этот язык. Тем не менее и как это ни смешно, "привет, мир" можно попробовать прямо из браузера сразу на главной странице официального сайта https://golang.org/
при чем тут браузеры?
версии слишком быстро плодятся. версия gccgo - не поспевает.
Что за версия языка еще? Это, типа, стандарт Go99 или Go14?
> Что за версия языка еще? Это, типа, стандарт Go99 или Go14?Чего https://golang.org/ref/spec (см.внизу: "Build version go1.6."!) непонятого-то? Спецификация - часть билда компилёра, компилёр - референсная (и единственная, надо полагать?) реализация, включённой в него спецификации, и т.д., и т.д -- чтобы понять рекурсию, надо понять: Ленин - Партия, Партия - Ленин.
Версия компилятора все-таки? Вот есть GCC 5.3.1, поддерживающий C++11. 5.3.1 - версия GCC, а C++11 это версия стандарта языка С++. Сабж то какую версию Go поддерживает? И как у языка может быть версия?
> Версия компилятора все-таки?Многие жалуются, что я непонятно пишу, поэтому для тех, кто не понял: я написал "версия и того(компилятора=реализации), и другого(языка=спецификации)".
> C++11 это версия стандарта языка С++
>И как у языка может быть версия?Это Вы так сам с собой разговариваете? Извините, если помешал.
Мне так казалось, что [как бы очевидно, что] язык=спецификация, версия языка=версия "стандарта".
Кто-нибудь Caddy производительность смотрел против nginx?
Я смотрю там reverse-proxy failover check из коробки, чего у nginx нет (есть в Plus версии или надо Lua прикручивать)
https://caddyserver.com/docs/proxyДумаю есть ли смысл только как Load-Balancer Caddy поставить перед nginx?