LINUX.ORG.RU

Go 1.8

 


3

6

Представлен стабильный выпуск Go 1.8. Этот релиз содержит значительные улучшения производительности и изменения в стандартной библиотеке.

Бекенд компилятора, впервые представленный для x86_64 в Go 1.7, теперь применяется на всех архитектурах, что даст ощутимый прирост производительности. Благодаря этому, например, на 32-битных системах ARM программы для измерения производительности затрачивают на 20-30 % меньше процессорного времени. Для 64-битных x86-систем также сделаны некоторые улучшения производительности. Компилятор и компоновщик стали быстрее, по сравнению с Go 1.7 время компиляции должно уменьшиться примерно на 15 %.

Паузы сборки мусора в новом релизе должны стать значительно короче: как правило, ниже 100, и чаще, ниже 10 микросекунд.

Улучшения также коснулись и HTTP-сервера. Добавлена поддержка HTTP/2 Push, что позволит серверам заранее отправлять ответы клиенту и минимизировать задержки в сети. Добавлена поддержка мягкого завершения (graceful shutdown), когда сервер завершает работу после обработки всех своих текущих запросов.

В контекстах добавлен механизм лимитов времени и отмены. В Go 1.8 поддержка контекстов добавлена во многих частях стандартной библиотеки, включая пакеты database/sql и net, и в Server.Shutdown из пакета net/http.

Благодаря новой функции Slice в пакете sort, стало проще сортировать срезы. Например, следующим образом можно отсортировать срез структур по полю Name:

sort.Slice(s, func(i, j int) bool { return s[i].Name < s[j].Name })

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

Пользователи Go по всему миру собираются вместе на этой неделе, чтобы отпраздновать данный выпуск. Это стало доброй традицией в сообществе Go. Если вы не успели отпраздновать в этот раз, впереди ещё будет Go 1.9.

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

★★★★★

Проверено: leave ()
Последнее исправление: sudopacman (всего исправлений: 3)
Ответ на: комментарий от shkolnick-kun

ЯП - инструмент, отношусь я к нему, как к напильнику, отвертке

Не ты ли тут задорно хейтишь раст и кресты?)

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

Аналогичный proposal для Rust: https://github.com/rust-lang/rust/issues/39916

Практически готовое решение, так как нужный инструментарий уже присутствует в LLVM. Как пишет сам автор: We may need to make some LLVM flags available via the Rust frontend, that's it.

dotcoder ★★★★★
() автор топика

Мне нравится Go и D как замена скриптовым языкам со статической типизацией и неявным выводом типов. Про Rust немного почитал, мне он показался перегруженным синтаксисом как C++ и Perl. Языки «для всего» уже были и большинство из них мертво, например, Ada, PL/1. Популярность языков программирования такая же непредсказуемая и подверженная моде штука, как литература. Кроме собственно достоинств языка есть много других факторов - наличие компании, спонсирующей и продвигающей ЯП, популярность и известность автора языка, killer apps на этом ЯП, наличие обширной стандартной библиотеки и активного сообщества. Плюс сетевой эффект при котором победитель получает всё. Мало кто захочет учить Яп с долей меньше 30% на рынке труда.

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

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

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

1. Первое, на что жалуются - отсутствие дженериков

Они практический ненужны.

2. Многословность обработки ошибок (if err != nil { return err }).

Решается созданием одной функции например checkError.

3. Отсутствие развитого общепринятого средства управления зависимостями из коробки

Незаметил необходимости.

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

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

nightuser
()
Ответ на: комментарий от bread

Он хейтит не ЯП, упоротых адептов, при этом являясь фанбоем няшной сишечки.

Религиозная вражда в общем.

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

Вроде как всегда можно было так:


// #include "blablabla.h"
import "C"
anonymous
()
Ответ на: комментарий от AUX

Они практический ненужны

Не то чтобы ненужны, но можно жить без них. Как в старой жабке жили с Object.

no-such-file ★★★★★
()
Ответ на: комментарий от AUX

checkError

Некомильфо, если пишешь не консольную утилитку, которая может паниковать сколько угодно.

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

Пишу микровебсервисы для предприятия которые собирают и визуализируют данные с промыш. оборудования. Работают и не падают, что я делаю не так?

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

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

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

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

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

Насколько я понимаю, в Go используется для многопоточки единственная модель communicating sequential processes (CSP), т.е. корутины, связанные каналами, по которым бегают сообщения. Этот подход довольно простой и подходит для широкого круга задач. Чтобы оставить язык простым, вряд ли в язык станут добавлять другие модели работы с многопоточностью. Так что программировать на Go, как на Java у тебя вряд ли получится. А вот разобраться, как на CSP перенести привычные для тебя алгоритмы работы и реализовать это на Go вполне возможно.

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

Русский можно подтягивать всю жизнь, так что об этом бессмысленно дискутировать, да и некорректно (вам в англоязычных форумах/списках рассылок разве подчёркивают, что вам английский ещё подтягивать надо, прежде чем получить право критики?).

А в расте значит только новые и не обкатанные идеи?

Однозначно не только, раз им LLVM хватило.

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

Мало кто захочет учить Яп с долей меньше 30% на рынке труда.

Ну надо же, какая глубокая экспертная оценка... И кто, по-вашему, будет учить тот же Go?

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

Незаметил необходимости.

Как только ты начнешь (не дай бог) писать большой проект на несколько человек да еще и с third part libs, а не только используя базовую библиотеку (собственно поэтому наверняка у тебе и не было необходимости мучиться с версионированностью, хотя по сути тут версионированность скрыта в релизе языка) на Go это будет ад.

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

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

Если высказывание непонятно - да.

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

Ну надо же, какая глубокая экспертная оценка... И кто, по-вашему, будет учить тот же Go?

Немного преувеличил. Корректнее было бы сказать что ЯП за пределами топ-10 учат только энтузиасты. Хотя нужно еще учитывать предметную область - системное программирование, веб, базы данных и т.п. Go уже достаточно популярен. По рейтингу TIOBE в феврале на 14 месте.

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

По рейтингу TIOBE в феврале на 14 месте.

Второй раз стал языком года на TIOBE).

Из кучи новых языков Crystal, Elixir, Julia и т.д. взлетело только 2. Swift и Go.

И если Swift был официально предложен как замена objective-С (единственный в своей нише), то Go намного сложнее было взлетать (ибо конкурентов у него было намного больше).

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

Плюс, по моим наблюдениям, студенты очень неохотно в большинстве своём учат что-то кроме того что было в вузе - java, c#, python, javascript.

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

Go намного сложнее было взлетать

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

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

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

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

Да ладно, а как яву в своё время Sun раскручивал. Go язык нишевый - для сетей,веб/микросервисов. Для замены python в этой области вполне годится. В конце концов, сам гугл его использует в продакшене.

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

Почему неоднозначный то?

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

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

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

У уважающих себя людей обвинять/оскорблять других, если сам что-то не понял, считается проявлением слабости (у нас же пока наоборот). Если что-то не понял, по какой бы то ни было причине, переспрашивают или просят изложить это подробнее.

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

Неоднозначный. Привычных средств для построения абстракций почти совсем нет. Ни ООП, ни ФП, ни обобщенного программирования. Суровая ретро-императивщина, никакого намека на сахарок даже. Обработка ошибок тоже очень необычна для мейнстрима. И такой язык всеми восторженно принят? Да ну?

bread
()
Ответ на: комментарий от gag

Просто примеры вызовов внешних функций.

А цифры там подозрительные: Luajit заруливает C.

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

Хм, а мне приятно на Rust. Реально очень приятно писать на нём

БДСМщицам тоже приятно когда их по жопе железной плеткой хлещат.

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

Конечно восторженно! ООП там есть, с чего ты взял что там его нет? Обработка ошибок нормальная, не дающая обмазываться try-catch, ломай шаблоны уже!

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

не только, раз им LLVM хватило

Что надо курить, чтобы идеи языка связывать с бэкендом компилятора?

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

var :=

(Голосом Гэндальфа) Я так и думал...

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

каким боком Go к паскалю?

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

bread
()
Ответ на: комментарий от AUX

Согласен, раст ужасен своим синтаксисом.

И не только синтаксисом. Имхо по сравнению с ним С++ получше будет

Siado ★★★★★
()
Ответ на: комментарий от no-such-file

Во-первых ты путаешь теплое с мягким. Во-вторых у npm и mvn есть центральные репозитории куда складываются библиотеки. Что у нас в случае Go ? Zip архив на гитхабе ? И если нет твоего glide (то есть файла glide.yml), то надо руками качать.

И это не говоря уже о том, что Go не умеет в динамические библиотеки, то есть невозможно собрать библиотеку на Go и выложить бинарь где-нибудь, в том же artifactory, а потом подключить ее через систему сборки (кстати чем вцы там собираете ? go build only ?), нужны _обязательно_ сорцы. Это вообще финиш для 21 века.

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