LINUX.ORG.RU

Go 1.9

 


1

6

Команда разработчиков Go представила релиз Go 1.9. Релиз доступен на странице загрузки. В данном релизе имеется много изменений в языке, стандартной библиотеке, среде выполнения и инструментарии. Большая часть усилий разработчиков была положена на усовершенствование среды выполнения и инструментария.

Наиболее важным изменением языка является введение псевдонимов типов. Объявление псевдонима типа выглядит следующим образом:

type T1 = T2

Это объявление вводит псевдоним Т1 для типа Т2, таким же образом, как byte всегда был псевдонимом для uint8. Дизайн-документ псевдонимов типов и статья о рефакторинге объясняют это дополнение более детально.

Новый пакет math/bits предоставляет функции подсчета и обработки битов для целых беззнаковых чисел, которые, когда это возможно, реализуются специальными инструкциями CPU. Например, в системах x86-64 bits.TrailingZeros(x) использует инструкцию BSF.

Пакет sync добавил новый тип Map, безопасный для многопоточного доступа. Важно понимать, что это не общая замена типа Map; обратитесь к документации, чтобы узнать, когда она должна использоваться.

В пакет testing также добавлено дополнение. Новый метод Helper, добавленный к testing.T и testing.B, отмечает вызывающую функцию в качестве тестовой вспомогательной функции. Когда тестовый пакет печатает информацию о файле и строке, он показывает местоположение вызова вспомогательной функции вместо строки в самой вспомогательной функции.

Пакет time теперь прозрачно отслеживает монотонное время в каждом временном значении, делая вычисление длительности между двумя временными значениями безопасной операцией.

Наконец, в рамках усилий, направленных на ускорение работы компилятора, Go 1.9 компилирует функции в пакете одновременно.

Go 1.9 включает в себя еще много дополнений, улучшений и исправлений. Полный список изменений и дополнительную информацию об улучшениях можно найти в примечаниях к выпуску Go 1.9.

Чтобы отпраздновать релиз, группы пользователей Go по всему миру проводят вечеринки.

>>> Подробности



Проверено: Klymedy ()
Последнее исправление: Klymedy (всего исправлений: 3)

Ответ на: комментарий от SuoiCat

Может быть тогда ты предложишь самый доходный вид деятельности, который избавит меня от необходимости зарабатывать на Го?

Запросто. Найти клад. Выиграть в лотерею.

Zenom ★★★
()
Ответ на: комментарий от Legioner

На 3 строчки кода 9 строчек мусорного кода, не добавляющего никакого функционала.

А потом после таких писателей, добавляющих функционал без мусорного кода приходится стектрейсы разгребать, проходили, знаем. Нет уж, явное лучше неявного. Хотя растовский сахар мне нравится больше, код на go мог бы быть и менее многословным, но лучше так, чем unchecked исключения.

feofan ★★★★★
()
Ответ на: комментарий от Virtuos86

Религия заставляет бздяшников статически линковать и ни в коем случае не хранить библиотеки?

NextGenenration ★★
()
Ответ на: комментарий от anonymous

(почти) любой компилируемый язык можно закомпилировать и слинковать в статический бинарь.

mersinvald ★★★★★
()
Ответ на: комментарий от RazrFalcon

Модули - тоже сахар?

А их уже ввели? А то емнип их даже в c++17 не ввели

Или вы предлагаете GC добавить?

Сравни мощь макропроцессора rust и препроцессора c++. Как минимум

NextGenenration ★★
()
Ответ на: комментарий от anonymous

Компилятор Rust копилирует код на Rust в LLVM IR. И он написан полностью на Rust.

А писать свой велосипедный оптимизирующий компилятор с генерацией кода по десятки платформ — идиотизм и пустая трата времени на переизобретение уже готового llvm.

mersinvald ★★★★★
()
Ответ на: комментарий от feofan

А потом после таких писателей, добавляющих функционал без мусорного кода приходится стектрейсы разгребать, проходили, знаем

Нет такого

NextGenenration ★★
()
Ответ на: комментарий от NextGenenration

У тебя что привычка пересобирать программу вместе со всеми зависимыми библиотеками?

Нет. Это — показательный случай сборки порта гишной Qt-программы. Я этим не люблю страдать, поэтому остановился на Gtk2/3-тулките, где такого маразма нет.

iZEN ★★★★★
()
Ответ на: комментарий от NextGenenration

И после этого ты агитируешь за бздю?

Я агитирую за разумность. А то получается такая вещь, как смещение от 80/20% к 98/2%. (В собранной системе 80% кода не используется никогда, 20% используется. У хипстеров 98% не используется никогда и только 2% используется.)

iZEN ★★★★★
()
Ответ на: комментарий от NextGenenration

Я не говорил о том, что Qt нужно пересобирать. Я говорю о том, что для сборки Qt-программы сборщик должен иметь доступ к архиву с исходниками Qt и читать оттуда определённые файлы, чтобы правильно построить Qt-программу.

iZEN ★★★★★
()
Ответ на: комментарий от Davidov

в Rust это появилось не так давно.

Макросы и в частности try! были с самого начала

mersinvald ★★★★★
()
Ответ на: комментарий от iZEN

его можно собрать как в окружении (системного) LLVM/Clang, так и в окружении GCC.

ШОК, Go зависит от компиляторов, написанных на C и C++!!!!

mersinvald ★★★★★
()
Ответ на: комментарий от RazrFalcon

Падение, даже с трейсом, в main - не обработка.

Ещё какая обработка, это просто идеальная обработка. Сразу видно и сообщение об ошибке и её источник.

Legioner ★★★★★
()
Ответ на: комментарий от Davidov

Рекомендую ознакомиться с багом JDK-8043516 (статус won't fix). Даже сама JVM порой не может пережить недостаток памяти.

Ну тут JVM не может стартануть, в чём проблема-то. Как раз таки хорошо видно, что в JVM обработка ошибок выделения прописана. Всё работает как положено. А пытаться угадывать параметры за пользователя — только вредить. У параметров есть значения по умолчанию. Если с ними не получается запуститься, значит падаем. Это и есть правильное поведение.

Что-то я не понял, какую проблему мы решаем. Если системная библиотека вернула ошибку, то стектрейс нужен до вызова, все что в самой библиотеке не имеет значения.

Проблема в том, что на каждую строку вызова стандартной библиотеки надо создавать новый объект ошибки, а не делать return err как нормальные люди.

Если это важно, создать свой тип ошибки, где будет имя файла, см. errors are values.

Угу и оборачивать ошибку от стандартной библиотеки после каждого её вызова. К чему и вернулись — то, что в нормальных языках с исключениями работает из коробки с нулевыми усилиями, в Go надо делать ручками, загромождая код бессмысленными строками, порождая сотни багов в этих строках, которые никогда никем не тестируются.

Legioner ★★★★★
()
Ответ на: комментарий от mersinvald

Рантайм Go19 зависит только от этого:

> ldd /usr/local/go/bin/go
/usr/local/go/bin/go:
	libthr.so.3 => /lib/libthr.so.3 (0x800cbe000)
	libc.so.7 => /lib/libc.so.7 (0x800ee6000)

iZEN ★★★★★
()
Ответ на: комментарий от NextGenenration

Попрошу уточнить язык.

Java, Python, C#. Да любой язык в принципе, я не видел тех, которые не обрабатывали бы исключения.

Как минимум в c# можно случайно забыть перехватить исключения и уронить в рантайме

Ничего ты не уронишь. Отрабатывает обработчик ошибок по умолчанию, который обрабатывает исключения, вылетающие из main.

Legioner ★★★★★
()
Ответ на: комментарий от feofan

А потом после таких писателей, добавляющих функционал без мусорного кода приходится стектрейсы разгребать, проходили, знаем.

Ну да, лучше пыриться на «Error Occured» в логах, чем иметь стектрейс, прямо стрелочкой показывающий, где произошла ошибка. Или вообще ничего не иметь в логах, просто у юзера что-то криво работает и всё.

Нет уж, явное лучше неявного.

Что может быть более явного чем исключения?

лучше так, чем unchecked исключения.

Ничего нет лучше unchecked исключений.

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

Нет ничего более неявного, чем uncheched исключение. Ты понятия не имеешь что и откуда у тебя может прилететь, пока у тебя код не упал в рантайме из-за необработанного исключения.

Падение в мейне со стектрейсом — не обработка ошибки

mersinvald ★★★★★
()
Ответ на: комментарий от mersinvald

Для бутстрапа Go нужен какой-нибудь сишный компилятор, производящий первоначальный код для запуска основной сборки. По-моему, так с любым языком программирования в Unix-системе.

iZEN ★★★★★
()
Ответ на: комментарий от mersinvald

Нет ничего более неявного, чем uncheched исключение. Ты понятия не имеешь что и откуда у тебя может прилететь, пока у тебя код не упал в рантайме из-за необработанного исключения.

Нет ничего, более явного, чем unchecked исключение. В любом вызове функции может прилететь что угодно, некоторые встроенные функции кидают конкретные исключения, вот и всё. Что может быть более явного?

Падение в мейне со стектрейсом — не обработка ошибки

Это отличная обработка ошибки.

Legioner ★★★★★
()
Ответ на: комментарий от mersinvald

И какой смысл разводить срач что больше зависит от C++? Это нелепо.

Сборка Rust мне потянула безальтернативную пересборку уже установленного в системе пакета llvm40-4.0.1 (который, в свою очередь, используется для графической подсистемы X.org Mesa 3D). Он собрался абсолютно с теми же опциями, что и установленный. Это ли не маразм?! Go (и Node.js) такого себе не позволяет.

Rust-1.19 собирается 30 минут. Пересборка LLVM-4.0.1 - 1 час 50 минут. Go-1.4.3/1.9 - 5 минут.

iZEN ★★★★★
()
Последнее исправление: iZEN (всего исправлений: 1)
Ответ на: комментарий от Legioner

Ну да, лучше пыриться на «Error Occured» в логах, чем иметь стектрейс, прямо стрелочкой показывающий, где произошла ошибка. Или вообще ничего не иметь в логах, просто у юзера что-то криво работает и всё.

Стектрейс действительно иногда удобен. Но лучше добавлять в ошибку контекст, необходимый пользователю, чтобы понять, что пошло не так. Стектрейс очень редко для этого необходим. В таких случаях его можно добавить.

Что может быть более явного чем исключения?

Ошибка, отраженная в сигнатуре функции. Я не говорю, что подход го идеален, подход rust мне нравится больше, но подход go явно лучше unchecked исключений.

Ничего нет лучше unchecked исключений.

Видимо, ты просто не ловил падений на проде из-за необработанных исключений.

feofan ★★★★★
()
Ответ на: комментарий от iZEN

И тебе уже написали, что Rust умеет собираться с системным LLVM выше.

mersinvald ★★★★★
()
Ответ на: комментарий от iZEN

В собранной системе 80% кода не используется никогда, 20% используется

Если ты собираешь фокс растом, то значит раст уже используется.

NextGenenration ★★
()
Ответ на: комментарий от iZEN

Я говорю о том, что для сборки Qt-программы сборщик должен иметь доступ к архиву с исходниками Qt и читать оттуда определённые файлы, чтобы правильно построить Qt-программу

Разве с gtk это не так?

NextGenenration ★★
()
Ответ на: комментарий от iZEN

То что код не используется постоянно — не значит что он не нужен. Как только ты откроешь секрет написания надежных систем, реализуя только т.н hot-path, я с тобой соглашусь.

mersinvald ★★★★★
()
Ответ на: комментарий от NextGenenration

С Gtk это не так. После установки Gtk-либ почему-то их исходники больше не требуются ни для чего.

iZEN ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.