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)

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

высокоуровневый обработчик ошибок

Нет, не будет. Будет много обработчиков там, где это целесообрано. Чем ближе к месту возникновения ошибки — тем лучше. Поймав ошибку в мейне, ты вообще ничего не можешь сделать, кроме как перезапуститься или упасть.

Хотя тебя это, похоже, не смущает совсем.

mersinvald ★★★★★
()

Мне больше интересно когда в ГО появится управление пакетами. А то нагородили лисапедов не понятно что использовать

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

в JVM обработка ошибок выделения прописана. Всё работает как положено.

Ну не совсем, сначала JVM пытается угадать объем памяти исходя из количества памяти в системе, но игнорируя ulimits, потом делает malloc сразу на все и выходит с ошибкой.

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

на каждую строку вызова стандартной библиотеки надо

Не надо. Просто не надо писать на Go как на Java или Rust. Точно так же не надо писать на rust, как на C (на форуме были примеры).

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

Трейсы в логах - это конечно круто, но обычно не нужно, это не Java.

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

А тебе не стыдно потреблять то, что за тебя написали другие?)

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

Он собрался абсолютно с теми же опциями, что и установленный. Это ли не маразм?! Go (и Node.js) такого себе не позволяет.

Маразм в том что системный LLVM полон багов, и если соберешь с ним то тесты не пройдут. В растовом форке около 30 патчей поверх 4.0.1.

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

Сама система собирается только системным LLVM, а вот большинство портов вполне себе могут собираться GCC8-dev и LLVM 4.0.1.

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

Исключение это способ сделать goto в выделенное место для обработки ошибок где-то выше по стеку.

Goto подразумевает знание, куда ты goto. Если эмулировать исключения на языке без оных, будет что-то типа

(result, exception) = foo();
if (exception != null) {
    if (exception instanceof MyException){
       ...
   } 
   else return (null, exception);
}

Но на практике есть ряд ситуаций, с которыми по крайней мере дизайнеры Java не справились

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

Мы пишем интерфейс (или базовый класс). Какие исключения он может бросать? Что если в наследние понадобится бросить другое исключение?

Это общая проблема наследования. Что если одному из потомков понадобятся дополнительные данные? Что если один из потомков вернёт не одно значение, а несколько? Подразумевается, что интерфейс виртуального метода планируется с учётом того, что может потребоваться потомкам.

И да, заворачивать - вполне вариант, если бы в Java был патернматчинг не только в catch, можно было бы обернутое нормально обрабатывать.

Ты правильно говоришь, что есть надёжность, есть удобство. И на практике ни то ни другое не возводится в абсолют

Это мог бы написать и фанат джаваскрипта, типа чё вы до меня докопались, у меня аджайл, сегодня я возвращаю число, а завтра мне понадобится вернуть объект, я лучше в 2х местах проверку типа добавлю чем прототипы всех функций менять. В принципе непроверяемые исключения эмулируются «throws Exception», если не хочется париться, то чем не решение?

khrundel ★★★★
()

А про дженерики уже писали?

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

Мне больше интересно когда в ГО появится управление пакетами. А то нагородили лисапедов не понятно что использовать

Go 1.9 (комментарий)

feofan ★★★★★
()
Последнее исправление: feofan (всего исправлений: 2)
Ответ на: комментарий от SuoiCat

Честно, не знаю языков с ОЧЕНЬ КЛАССНОЙ обработкой ошибок.
с ОЧЕНЬ КЛАССНОЙ обработкой ошибок.
КЛАССНОЙ

Java же! Там всё классы :3

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

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

Если malloc вернёт 0 во время работы, всё будет нормально. 0 во время инициализации это немного другое.

Трейсы в логах - это конечно круто, но обычно не нужно, это не Java.

Не понимаю я этого вашего не нужно. Когда я начал писать код на Go, я в первый же день понял, что так жить нельзя, когда получил непонятное сообщение об ошибке. С pkg/errors жить можно, хоть и грустно, надо постоянно помнить после каждого вызова библиотечной функции, что ошибку надо обернуть, а после своей функции не надо. Лишняя ментальная нагрузка.

На самом деле уверен на 99%, что errors портируют в стандартную библиотеку, когда у них руки дойдут.

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

Goto подразумевает знание, куда ты goto.

Ну это знание есть. Каждый try-catch добавляет адрес на стек, в верхний адрес и делаешь goto.

Если эмулировать исключения на языке без оных, будет что-то типа

Ну это так, хотя это не совсем исключения, скорее так пишется любой нормальный код, что на C, что на Go, что на Rust.

Мы пишем интерфейс (или базовый класс). Какие исключения он может бросать? Что если в наследние понадобится бросить другое исключение?

Это общая проблема наследования. Что если одному из потомков понадобятся дополнительные данные? Что если один из потомков вернёт не одно значение, а несколько? Подразумевается, что интерфейс виртуального метода планируется с учётом того, что может потребоваться потомкам.

А планировать это можно только одним способом — завести отдельный класс исключений для этого интерфейса (или метода) и оборачивать все другие исключения в него (если мы говорим про проверяемые исключения). Так тоже делают, но тогда смысл проверяемых исключений опять же теряется. И весь код превращается в сплошные перезаворачивания. Опять же в Rust такое работает, но потому, что там перезаворачиваются ошибки в макросе с почти нулевыми усилиями. Если бы в Java было подобное, может и проще было бы. Но это уже вилами по воде.

И да, заворачивать - вполне вариант, если бы в Java был патернматчинг не только в catch, можно было бы обернутое нормально обрабатывать.

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

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

Ну фанату джаваскрипта можно показать, что в реальном мире кроме жаваскрипта популярны типизированные языки. Так же как и фанату хаскеля показать на жаваскрипт. Так что тут однозначно сказать нельзя, что лучше. Разным программам и требованиям подходят разные языки. А в случае с исключениями на практике за много последних лет я в популярных жава библиотеках не видел ни одного проверяемого исключения. Максимум — какой-нибудь IOException прокидывают, а то и их оборачивают.

В принципе непроверяемые исключения эмулируются «throws Exception», если не хочется париться, то чем не решение?

Ну как минимум тем, что объявление каждой функции раздувается на 2 токена. Обычно просто все проверяемые исключения по месту вызова оборачиваются в непроверяемые (например UncheckedIOException в стандартной библиотеке, хе-хе). Благо их в реальном коде раз-два и обчёлся, все проверяемые исключения только из старого кода, который уже переделывать никто не будет, в новом коде даже в JDK исключения непроверяемые.

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

Ну это знание есть. Каждый try-catch добавляет адрес на стек, в верхний адрес и делаешь goto.

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

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

В общем случае да, но в некоторых случаях при проектировании может быть известно, например, что в потомках производится чтение файлов, соответственно пропускается ioexception и т.п.

Ну вот Scala продвинутейший язык.

У меня сложилось впечатление, что скала, конечно, продвинута, но не продумана и авторы не ставили себе целью создание надёжного языка. Тем не менее, ловить вложенные исключения там можно: https://scalafiddle.io/sf/W4REsyx/0

Ну как минимум тем, что объявление каждой функции раздувается на 2 токена.

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

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

Даже Oracle в 8 версии практически официально задепрекейтил Checked исключения, введя Unchecked-обёртки.

Можно подробнее?

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

А перехватив ошибку на месте, ты даже понять не сможешь, насколько она фатальна, потому что вся логика процесса находится наверху.

Уровень перехвата ошибок должен быть разным, в зависимости от задачи перехвата. Если это освобождение ресурсов, то внизу. А если с целью логирования или перезапуска, то наверху.

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

Если за 5 лет перевели всего 1% , то я не проживу до 5%

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

Ну что тут скажешь «Шарик! Ты балбес.»

Собери сам себе третьекеды на Расте и пропатчь их до вторых.

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

Собери сам себе

Зачем? Пересборка ценна не сама по себе, а лишь как решение какой-то проблемы. Пересборка в моём случае не решит пожалуй ни одной проблемы, зато потребуется время, память и куча всего другого. Или у тебя карго культ пересборки? Вот ты говорил что тебе нужна повторяемая сборка. Чем ты собираешь компилятор rust? Ты его собирал с самой первой версии и хранишь в архиве или же качаешь его с сайта и им пересобираешь? Ответ на последний вопрос крайне важен и уже укажет на смысл твоего занятия.

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

Так интересно смотреть как гоферы отвечают заготовленными фразами из статей и конференций (иногда прям в слово в слово, аж пугает).

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

PS заметил еще такую фишку, если вы какая-то компания и скажите всем что вот вы используете новый «X» язык (пускай на какой-то второстепенной штуке), вы сразу получите невероятную лояльность от сообщества и сообщество само будет разносить ваш бренд повсюду - это умно и круто.

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

Ну судя по жарким дискуссиям, открыватель америк...

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

Зачем?

Не знаю, что там у тебя. А я экспериментирую со сборкой ПО и восторгаюсь тем, как всё запущено. Ощущение такое, что людям просто заняться нечем и они разрабатывают недоделанные комбайны. Уже собран целый парк недоделанных комбайнов и зернокосилок, но 3D-принтер не хочет останавливаться.

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

Но еще интересно смотреть баталию между Rust и Go. Языки совершенно разного уровня

Rust - это замена С++.

Go - это замена C.

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

Go - это замена C.

Посмеялся. Го — замена python, php, иногда java и c#. Си он может заменить только в тех кусках, где его уже заменили зелёным змием.

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

Что у вас за бардак в голове? С каких пор язык без ГЦ, с указателями (и арифметикой), вообще язык по сути настройка над ассемблером, противопоставляется управляемому языку, в котором вся архитектура крутится поверх сопрограмм?

Я понимаю еще холивар между джавой и го, но си, растом и плюсами?? Насколько надо быть безграмотным, чтобы сопоставлять языки по одному только синтаксису (вероятно наличие слово «структура» как-то у вас ассоциировалось с сями, да?)

wist512
()
Ответ на: комментарий от grossws

Тяжёлый случай - смешались в кучу: интерпретаторы, компиляторы, JIT, АОТ... Вот как с таким мировоззрением тебе жить, а?

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

Go - структурно-ориентированный язык с поддержкой многопоточности. Программы на Go компилируются в нативный код процессора, на котором и выполняются без сопровождения стороннего кода (виртуальной машины, интерпретатора, JIT &tc.) - это его роднит с Си, Паскаль/Ада, Модула - классическими системными языками программирования, на которых написаны операционные системы и системные утилиты.

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

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

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

А я экспериментирую со сборкой ПО и восторгаюсь тем, как всё запущено

В итоге до этой дискуссии ты даже не знал на каком языке написан rust и почему он так долго собирается. Как можно доверять анализ такому диванному эксперту как ты? Я вижу лишь одну причину твоего существования - благодаря тому что тебе отвечают заинтересованные люди могут узнать истину(некий намёк на карго культ)(на половину с сарказмом, на половину без).

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

Ощущение такое что все прислушаются к твоему мнению и будут тратить своё время так как тебе этого захочется.

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

Rust - это замена С++.

Почему rust не способен заменить c?

Go - это замена C.

Замена лучше не придумаешь - толстые бинарники, сборка мусора...

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