Представлен (https://blog.golang.org/go1.12) релиз языка программирования Go 1.12 (http://golang.org), который развивается компанией Google при участии сообщества как гибридное решение, сочетающее высокую производительность компилируемых языков с такими достоинствами скриптовых языков, как лёгкость написания кода, быстрота разработки и защищённость от ошибок. Код проекта распространяется (https://golang.org/dl/) под лицензией BSD.Синтаксис Go основан на привычных элементах языка Си с отдельными заимствованиями из языка Python. Язык достаточно лаконичен, но при этом код легко читается и воспринимается. Код на языке Go компилируется в обособленные бинарные исполняемые файлы, выполняемые нативно без использования виртуальной машины (модули профилирования, отладки и другие подсистемы выявления проблем на этапе выполнения интегрируются в виде runtime-компонентов (http://golang.org/pkg/runtime/)), что позволяет добиться производительности, сопоставимой с программами на языке Си.
Проект изначально разрабатывается с оглядкой на многопоточное программирование и эффективную работу на многоядерных системах, в том числе предоставляя реализованные на уровне операторов средства для организации параллельных вычислений и взаимодействия между параллельно выполняемыми методами. Язык также предоставляет встроенные средства защиты от выхода за допустимые области выделенных блоков памяти и обеспечивает возможность использования сборщика мусора.
Основные новшества (http://golang.org/doc/go1.12), представленные в выпуске Go 1.12:- В пакет crypto/tls добавлена реализация протокола TLS 1.3 (https://www.opennet.dev/opennews/art.shtml?num=49126).
В реализации пока отсутствует поддержка режима 0-RTT, применяемого для устранения задержек при возобновлении ранее установленных защищённых соединений. Поддержка TLS 1.3 отключена по умолчанию и для включения требует установки опции "tls13=1" в переменной окружения GODEBUG. Включение TLS 1.3 по умолчанию ожидается в следующем выпуске;- Продолжена работа по усовершенствованию новой системы модулей, которую можно применять в качестве альтернативы GOPATH. Система модулей отличается интегрированной поддержкой версионирования, средствами доставки пакетов и улучшенной системой управления зависимостями. При помощи модулей разработчики больше не привязаны к работе внутри дерева GOPATH, могут явно определять зависимости с учётом версий и создавать повторяемые сборки. Из улучшений по сравнению с прошлым выпуском отмечается реализация поддержки параллельного выполнения операций загрузки и извлечения модулей при помощи команды go. Директива "go" внутри файла go.mod теперь учитывает версию языка Go, используемую в коде модуля (по умолчанию используется текущий релиз).
По умолчанию систему модулей планируется предложить в выпуске Go 1.13. До этого требуется явная активация системы модулей через переменную GO111MODULE=on или использование контекста, в котором модули применяются автоматически (например, когда команда go выполняется не в каталоге GOPATH/src и когда в корне текущего каталога присутствует файл go.mod). Начиная с текущего выпуска система модулей также автоматически используется при выполнении команд подобных "go run x.go" или "go get rsc.io/2fa@v1.1.0" без явного указания файла go.mod;- В компиляторе улучшен анализ изменения переменных (live variable analysis (https://en.wikipedia.org/wiki/Live_variable_analysis)). Расширен спектр функций для которых по умолчанию применяется inline-развёртывание кода, в том числе данная оптимизация теперь применима для функций, работа которых ограничивается вызовом других функций.
Добавлен новый флаг "-lang" позволяющий выбрать конкретную версию языка, например, в процессе компиляции будет выведена ошибка, если запустить компилятор с флагом "-lang=go1.8" для программы, в которой используется функциональность более новых версий Go.
Улучшена генерация отладочной информации в формате DWARF, в том числе добавлены сведения о выводимых аргументах и местоположении переменных.- Значительно увеличена производительность сборки мусора в ситуациях, когда большая часть кучи остаётся активной, что позволяет уменьшить время выделения памяти сразу после сборки мусора. В Go runtime улучшена масштабируемость кода таймеров (timer и deadline) на системах с большим числом CPU;
Обеспечен более агрессивный возврат освобождённой памяти обратно операционной системе. Для возвращения неиспользуемой памяти в Linux в задействован флаг MADV_FREE, который только помечает блок доступным для освобождения, но не освобождает сразу, что позволяет вернуть его без генерации "page fault", если обращение произошло до его фактического использования ядром.- В переменной окружения GODEBUG добавлена поддержка флага "cpu.extension=off", отключающего использования расширенных инструкций CPU в коде стандартной библиотеки и в runtime;
- Утилита godoc теперь не предоставляет интерфейс командной строки, а доступна только в форме web-сервера для просмотра документации через браузер. Для вывода подсказки в командной строке следует использовать команду "go doc". В "go doc" добавлена новая опция "-all" для вывода всех экспортируемых API и документации по ним;
- Детектор состояний гонки (race detector) портирован для платформы linux/arm64;- Прекращена поддержка команды "go tool vet", вместо которой рекомендуется использовать "go vet" с определением поддержки внешних анализаторов кода через модуль analysis (https://golang.org/x/tools/go/analysis);
- Добавлена поддержка ОС AIX 7.2 и более новых выпусков на системах с архитектурой POWER8 (aix/ppc64);
- Добавлена поддержка платформы Windows на системах с архитектурой ARM, например, Go теперь можно использовать на платах Raspberry Pi 3 с ОС Windows 10 IoT Core;- Для совместимости с будущими выпусками macOS и iOS задействована библиотека libSystem, выступающая прослойкой для выполнения специфичных для платформы Darwin системных вызовов;
Начиная с версии Go 1.13 будет прекращена поддержка macOS 10.10 "Yosemite", в качестве минимально поддерживаемой версии macOS станет 10.11 "El Capitan". В следующем выпуске также планируется прекратить поддержку ветки FreeBSD 10.x.
URL: https://blog.golang.org/go1.12
Новость: https://www.opennet.dev/opennews/art.shtml?num=50210
> Начиная с версии Go 1.13 будет прекращена поддержка macOS 10.10 "Yosemite", в качестве минимально поддерживаемой версии macOS станет 10.11 "El Capitan". В следующем выпуске также планируется прекратить поддержку ветки FreeBSD 10.x.ну теперь можно переключатся обратно на использование perl
там хоть работать будет вечно
Это косается только рефиренсной реализации компилятора.
Есть еще gccgo. Если нужно поддерживать legacy то это как раз тот вариант который будет работать вечно.И никто же не жалуется что новый x-code не работает в 10.10.
А кстати, как заставить собираться проекты, которые требуют Google Go посредством gccgo?
> И никто же не жалуется что новый x-code не работает в 10.10.Я жалуюсь. Доколе?!
Кажется еще вчера обновлялся на Йосемити, а оно уже скоро все...
> Утилита godoc теперь не предоставляет интерфейс командной строки, а доступна только в форме web-сервера для просмотра документации через браузерШёл 2019 год...
>> Утилита godoc теперь не предоставляет интерфейс командной строки, а доступна только в форме web-сервера для просмотра документации через браузер
>
> Шёл 2019 год...Для альтернативно одарённых:
'Для вывода подсказки в командной строке следует использовать команду "go doc"'
GNU/Hurd они добавили в GOOS почему и зачем?
А на go можно dllку создать?
можно, гугли go plugin, но зачем?
go plugin — это крайне вырожденный случай. можно и обычные динамические библиотеки с сишным ABI делать.
А как на Golang сделать обычную DLL с внешним ABI? Что-то я не слышал о такой возможности.
$ go help buildmode
>сочетающее высокую производительность компилируемых языковЧто-то по бенчмарку он даже медленнее Явы:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Интересный ресурс.
И результаты интересные.
Явы он не медленнее, скорее на одном уровне. Но как его можно пихать на замену C/C++?
Я конечно понимаю что RUST не совсем готов и на него пересаживаться сложнее, но вот он реально обеспечивает скорость С/С++
> Интересный ресурс.
> И результаты интересные.Абсолютно ничего интересного, на самом деле. Все бенчмарки сводятся к тому умеет ли язык программирования подцеплять внешние библиотеки или нет. Если не умеет - он будет на дне. Если умеет - то ура, подключаем pcre и мы в топе. То же касается и gmp.
По идее надо установить правила - пользоваться только тем, что идёт для языка из коробки. В си нет регулярок? Ну что ж, выкручивайтесь как хотите, но pcre не подключайте.
Не согласен.
Не надо в коробку тащить все подряд. И переизобретать велосипеды.
Если pcre написан на С, то какая разница из коробки он или нет.
Вот если ввести ограничение на подключение библиотек только на том же языке, это да.
Но ведь это не отменяет факта тормозов GO по сравнению с C/C++
А кому нужна абстрактная быстрота самого языка?
Меряться количеством NOP-инструкций в секунду?Логично сравнивать конкретные возможности, которые язык как инструмент предоставляет. Если встроено в стандартную библиотеку - хорошо, если нет, то из внешней.
Может кому-то нужны именно полностью PCRE-совместимые регулярки. Вот в таком виде надо и ставить задачу. Надо смотреть какие задачи как решаются на разных языках, библиотеках и т.д.А вот если сама задача слишком редкая или узко-специализированная (типа программирование контроллеров и обработка данных датчиков с режиме реального времени), тогда надо так и сказать, мол отлично, но у нас таких задач почти не бывает, а этот синтаксис нам не очень удобен для описания бизнеса продаж в интернет-магазине.
Он не пихается на замену плюсам и, тем более, сям. Он, скорее целится в области применения python-а, предлагая при этом статическую типизацию, компиляцию и более простой ffi в C.
> более простой ffi в CСпорное утверждение: cgo только и умеют что поливать помоями за неудобства, вызванные, насколько я понимаю, слишком умным менеджером памяти в go.
Там проблемы с тем, что у go свой ABI (из-за pascal-строк и, разумеется, своих векторных типов). Из-за чего требуется маршаллинг из C ABI в Go ABI, потому FFI получается небесплатный. Но в использовании довольно удобен.
Вот только на нем пытаются писать системный софт.
Я понимаю демоны написанные на ЯВЕ тоже иногда работают быстро.
Но это скорее исключение чем правило. И Go по сути из той же оперы.
Вот только до Явы он пока не дотягивает, вон модули только сейчас сделали.
А там где не нужна скорость, ну зачем менять скриптовый язык?
Что выигрывается?
> Что выигрывается?Скорость деплоймента: опустим pip install в серную кислоту, а статичный гоферный бинарь в дистилированную воду…
>опустим pip install в серную кислоту, а статичный гоферный бинарь в дистилированную водуолдфаг в треде
И не один. И таки что ?
> А там где не нужна скорость, ну зачем менять скриптовый язык?
> Что выигрывается?Скорость не нужна, когда вы на своей персоналке один прогон сделали и обрадовались, что работает. А когда вас вызывает руководитель и спрашивает, почему новый мощный сервак еле-еле ворочается под числом пользователей в разы меньше того, которое нужно для окупаемости проекта - вот тогда вы будете поминать тихим добрым словом и Ларри Уолла, и Гвидо ван Россума, и Расмуса Лердорфа, и всех остальных создателей скриптовых языков вместе и по отдельности, а заодно и макак из отдела разработки, которые выбрали язык для себя - тот, на котором можно быстро накуячить код и сдать задание в срок, а как оно будет крутиться в продакшоне - это уже не их головная боль.
На нем пытаются писать тот системный софт, который иначе писали бы на питоне. Модули ядра на нем никто не пишет, ясное дело.
И вот цитата
>что позволяет добиться производительности, сопоставимой с программами на языке Си.
А на каких операциях там не говорится :-)
При минимальном использовании heap-а — таки позволяет. Попробуй каким-нибудь декомпилятором, позволяющим представить программу в псевдосишном коде, для интереса посмотреть на go-шную программу и сравнить с исходником.
Медленнее go получается по большей части, когда разработчик размещает данные в куче, для обслуживания которой уже требуется gc. Ну или если бесконтрольно юзает c ffi, что приведет к падению производительности из-за маршаллинга.
> Что-то по бенчмарку он даже медленнее Явы:Разве ж это медленнее? Это примерно на одном уровне.
Вообще-то, если пройтись по списку тестов вот с этой странички: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... в шести тестах (n-body, fannkuch-redux, spectral-norm, mandelbrot, pidigits и fasta) Go выигрывает и по времени выполнения, и по меньшему потреблению памяти (причём в разы, а то и на порядки - 1,472 vs 31,180 в fannkuch-redux, 2,656 vs 33,572 в spectral-norm, 2,620 vs 42,212 в fasta), в трёх (regex-redux, k-nucleotide и binary-trees) Go проигрывает по скорости, но выигрывает по потреблению памяти, и только в reverse-complement Go сливает и по скорости, и по памяти.
Так что иногда ходите по ссылкам, которые постите.
Кичиться тем что язык слегка обогнал жирную Яву в некоторых задачах, когда он заявляет:
"что позволяет добиться производительности, сопоставимой с программами на языке Си" - как-то глупо.
> Кичиться тем что язык слегка обогнал жирную Яву в некоторых задачах, когда
> он заявляет:
> "что позволяет добиться производительности, сопоставимой с программами на языке Си" - как-то
> глупо.А где тут гордость? Комментатору 1.11 просто указали на фактическую ошибку.
> До этого требуется явная активация системы модулей через переменную GO111MODULE=onА почему GO111MODULE, а не GO123MODULE? Или G0000M0DULE?
Go 1.11
GO!!111MODULE
Попробуйте:
https://gocenter.jfrog.com/
https://jfrog.com/blog/go-at-full-speed-with-gocenter/
Go vN+0
> Начиная с версии Go 1.13 будет прекращена поддержка macOS 10.10Что вообще означает - язык не поддерживает ОС? Бред какой-то. Впрочем, укладывается в логику всего, что делает Google.
Версия языка — "1", "1.13" — это версия референсного компилятора.
Потому что когда язык — и его стандартная библиотека — скомпилированы, им приходится вызывать ядро ОС чтобы делать что-либо полезное помимо арифметических вычислений. И вот в этом месте начинается интересное.
И в тех ОС - какой-то неправильный POSIX ?
Go не использует glibc, у них свой велосипед через который они напрямую к ядру обращаются, в этом траблы.
Вот это поворот! И давно?У Go, как бэ, в зависимостях одна glibc и есть... Странно не использовать свою единственную зависимость, КМК.
нет там glibc, может для пары функций опционально. Для линукса одна зависимость: kernel 2.6.23+
oh, rly?
Разве что для какого-то HelloWorld.https://github.com/docker/docker-ce
$ file /usr/bin/dockerd-ce
/usr/bin/dockerd-ce: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=94cd64511d93cf28a4af807f8ce83b78feee5509, not strippedldd /usr/bin/dockerd-ce
linux-vdso.so.1 => (0x00007fff465cf000)
libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f0ad176c000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0accfa8000)
libseccomp.so.2 => /lib/x86_64-linux-gnu/libseccomp.so.2 (0x00007f0accd63000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f0accb5f000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0acc795000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f0acc573000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f0acc36b000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f0acc149000)
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f0acbe68000)
/lib64/ld-linux-x86-64.so.2 (0x00007f0ad15e8000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f0acbbf8000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f0acb9e4000)
Как только подключаете работу с сетью, то сразу сборка становиться зависимой от libc и libpthread, но существует и статическая реализация сети в golang. Просто ее нужно включать флагом -tags netgo.
Внезапно, posix описывает API, но не регламентирует ABI, потому программа, вызывающая напрямую syscall-ы, при смене ABI ядра таки сломается, даже если не использует никакие syscall-ы, кроме определенных в posix (что в реальной жизни невозможно).
Не поддерживает - и хрен с ним. ОС первична, остальное шелуха (кроме C).
Дженерики.
> Дженерики.I'm sorry but the princess is in another castle
Не нужно.
Годный язык, мне прям нравится, тем кто знаком с СИ языком Golang заходит прям на ура. А главное в нем сразу есть большинство того что в СИ так не хватает.
Рекомендую.
CaMeLCaSe что ли?
нафиг нада
> тем кто знаком с СИ языком Golang заходит прям на уране надо за всех говорить
Кто знает когда будет go2 и какие там будут изменения?
А какие изменения вам нужны? Го язык молодой, он сразу был создан как работа над ошибками других языков.
Или вам нужна боль и унижение древнего Python-а?
> По умолчанию систему модулей планируется предложить в выпуске Go 1.13Ага, смешно.
а try-catch то когда подвезут?
например мне лично нужно более удобное общение с JSON. то что есть сейчас полный ужас.
с разбиением на модули то-же проблемы какие то дикие с именами. может что-то еще.в целом язык гораздо интересней тупого питона
Го 2 будет не скоро. Будет 1.13, 1.14, 1.15 с постепенным внедрением фич. Где-то в районе 1.15, можно будет считать, что это 2.0, только об этом не скажут, чтобы не взрывались пукальники
Add your company... https://github.com/golang/go/wiki/GoUsers
дженерики завезли?
Генерики для слабаков.
Проходите не задерживайтесь. Вас много, go один. Следующий.
> В "go doc" добавлена новая опция "-all" для вывода всех экспортируемых API и документации по нимА в PAGER это скармливать оно так и не? Как и zfs команды в случае опечатки и проч.
lol no generics