LINUX.ORG.RU

Go 1.5 Release Notes

 , ,


0

5

Стали доступны release notes Go 1.5 : https://tip.golang.org/doc/go1.5 . Для новости рано - релиз будет в августе, пока же можно оценить степень ненужности.

Из интересного:

  • The compiler and runtime are now written entirely in Go (with a little assembler). C is no longer involved in the implementation [..].

    Казалось бы, хорошее дело, ребята наконец-то осилили bootstrapping, но читаем дальше:

    Builds in Go 1.5 will be slower by a factor of about two. The automatic translation of the compiler and linker from C to Go resulted in unidiomatic Go code that performs poorly compared to well-written Go.

    Оказывается осилили они только костыль, перегнавший им С-код в Go-код, и теперь у них в кодовой базе тонны неподдерживаемого С-кода зачем-то написанного на Go.
  • Independent of but encouraged by the move to Go, the names of the tools have changed. The old names 6g, 8g and so on are gone; instead there is just one binary, accessible as go tool compile, that compiles Go source into binaries suitable for the architecture and operating system specified by $GOARCH and $GOOS

    К 2015 году ребята таки решили закопать начавшее пахнуть наследие Plan9.

    Similarly, there is now one linker (go tool link) and one assembler (go tool asm).

    Но закопать свои нескучные ассемблер и линкер так и не собрались.
  • The garbage collector is now concurrent and provides dramatically lower pause times by running, when possible, in parallel with other goroutines.

    Хорошее дело.

    The «stop the world» phase of the collector will almost always be under 10 milliseconds and usually much less.

    Выглядит неплохо, для большинства use cases Go должно хватить.
  • By default, Go programs run with GOMAXPROCS set to the number of cores available; in prior releases it defaulted to 1.

    Логично, раз GC теперь позволяет нормально масштабироваться.

В целом позитивный релиз, ЯП ориентированный на конкурентность наконец-то получил конкурентный GC и может эффективно использовать многоядерность. Печально, что вместо того, чтобы встраиваться в существующие toolchain-ы, они продолжают тащить свои ассебмлер и линкер. Решение автоматом перегнать С-код в Go-код имхо ошибка, и приведет к сложностям в поддержке. Опять же, одна из рекламируемых фишек Go - быстрая компиляция - теперь не такая уже и быстрая.

писать компилятор на сишечке - моветон

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

Дженериков по-прежнему нет?

и не будет, ибо тормоза

The garbage collector is now concurrent and provides dramatically lower pause times by running, when possible, in parallel with other goroutines.

зато лучший в индустрии gc в наличии

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

и не будет, ибо тормоза

Ты явно что-то путаешь, нормальные компиляторы проводят мономорфизацию полиморфного кода и получается производительно близкая к коду, написанному вручную, что явно быстрее полиморфизма через interface{}. Или ты про тормоза времени компиляции?

лучший в индустрии gc в наличии

Сильно сомневаюсь, у JVM GC 20 лет под продакшен вылизывают. И если ты не осознал, конкурентный GC в нормальных языках стал нормой лет 10 назад, см. тот же Haskell. Но для Go это прорыв, да.

nonimous
() автор топика

Ну наконец-то дженерики!

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

Или ты про тормоза времени компиляции?

про нее, родимую

И если ты не осознал, конкурентный GC в нормальных языках стал нормой лет 10 назад, см. тот же Haskell

Только Haskell? пойду хлебну борща

речь не только о конкуретности, а о low latency https://sourcegraph.com/blog/live/gophercon2015/123574706480

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

Пруф?

не будет Пруфа

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

а тем кто пишет на Go, они не нужны

получается что никогда не будет

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

нету возможности сохранить главный принцип Go - быструю компиляцию

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

nonimous
() автор топика
Ответ на: комментарий от umren

зато лучший в индустрии gc в наличии

А чем он лучший? Паузами меньше 10 мс? Так в G1 есть опция MaxGCPauseMillis и куча других опций, с помощью которых можно затюнить коллектор как тебе нужно.

foror ★★★★★
()

В какой-нибудь IDE есть нормальная поддержка (рефакторинг и интелектуальное автодополнение) сего чуда?

Как по мне плодят энтропию этим своим Go. За место решения проблем ЯП из 20 века, привносят им новые проблемы.

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

Ляжет неподалеку от руби.

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

Рубины пали под «это можно сделать тысячей путей, но очень бы желательно всем использовать одинаковый» + лютая чехарда с версиями, переходами и поддержкой внешней пакетной базы. Задеплоить с наскоку что-то большое на рубях, с кусков, да ели оно еще только выкопано на кладбище - это адский труд и гемор. Порой ради этого нужно переписать половину кодовой базы.

В go негде совершать такие ошибки. Любой известный мне код будет скомпилирован и запущен начиная с версии 1.0, без каких-либо плясок. Плюс переезды больших систем на и вместе с go, если я уже и об этом - это не пересобирание и настройка свежих подходящих сред с костылями и армией симлинков. Как правило это просто переезд бинарников.

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

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

В go негде совершать такие ошибки. Любой известный мне код будет скомпилирован и запущен

А если какой-нибудь репозиторий с гитхаба выпилят?

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

А если какой-нибудь репозиторий с гитхаба выпилят?

Для таких случаев деплой-пакет обычно включает в себя директорию src, из которой можно всё зависимости взять, предварительно накинув на неё ${GOPATH}.

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

А вот это зря. Для поисковых систем плохо.

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