LINUX.ORG.RU

Релиз Go 1.1

 ,


2

7

Команда разработчиков рада сообщить о выходе новой версии языка программирования Go — 1.1.

Go — компилируемый многопоточный язык программирования, разработанный компанией Google. Первоначальная разработка Go началась в сентябре 2007 года, а его непосредственным проектированием занимались Роб Пайк и Кен Томпсон.

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

  • оптимизация компилятора и компоновщика;
  • улучшение работы сборщика мусора;
  • многочисленные улучшения в стандартной библиотеке.

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

Кроме того, есть некоторые изменения и в самом языке:

С момента выхода Go 1.0 было внесено 2600 изменений от 161 разработчика за пределами Google.

На данный момент поддержка Go осуществляется для операционных систем FreeBSD, OpenBSD, Linux, Mac OS X, Windows.

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

★★★★★

Проверено: maxcom ()
Последнее исправление: CYB3R (всего исправлений: 2)
Ответ на: комментарий от Reset

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

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

В скале есть исключения и ошибку можно поймать и обработать на любом уровне вложенности, есть блок finally, а в сраном go как в дедовские времена надо проверять коды возвратов и писать портянки if'ов.

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

Прошлый век — это глобальный флаг ошибок (це).

Он похоже имел ввиду signal handlers + setjmp/longjmp. Идея в целом неплоха, но практически неюзабельна в C и абсолютно неюзабельна в C++ при использовании ++.

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

есть блок finally

В Go есть какой-то аналог (defer, кажется).

в сраном go как в дедовские времена надо проверять коды возвратов и писать портянки if'ов.

Да ладно, возвращаются 2 значения, и результирующий код не такой уродливый, как в Си.

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

Да ладно, возвращаются 2 значения, и результирующий код не такой уродливый, как в Си.

Но всё-таки крайне навязчивый. В хаскеле можно по крайней мере сделать монаду и использовать do-синтаксис для случаев, когда от блока требуется сразу вернуть первую из ошибок, в го придётся, в лучшем случае, писать if err != nil { return } после каждого возвращающего ошибку вызова.

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

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

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

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

Только в отличии от скалы в go эквивалент do-notation не напишешь. Даже в чертовом эрланге можно. А в go эти возвраты error только до if - вот именно как в Си.

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

В Go есть какой-то аналог (defer, кажется).

Он очень кривой. В finally есть локальная область этого try finally. Область defer вся функция. Вон я уже спросил выше что сделать если мне надо выполнить что-то после какого либо defer - мне предложили лямбду туда замкнуть - то есть по сути написать вверху то что навернется где-то внизу, да еще применить arcane art если вдруг мне понадобятся какие-то вычисленные ниже значения.

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

если мне надо выполнить что-то после какого либо defer - мне предложили лямбду туда замкнуть

Ну и что? В Rust вообще везде сплошные лямбды с замыканиями и даже Rust-аналог try/catch сделан на замыканиях.

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

Ну если setjmp/longjmp, то, например, возможностью выйти из всех функций ^_^ С exceptions конечно покрасивее получается и понадежнее, зато в плане реализации очень просто - быстрый возврат к нужной точке стека (или состоянию стека).

В сравнении с реализацией exceptions реализация longjmp вообще тривиальная, но нужно предусмотреть заранее, что может быть longjmp. В существующий код (в котором это не предусматривалось заранее) вставить longjmp не получится без потенциальных утечек памяти и нарушения целостности данных. В некоторых случаях это вообще единственный вариант работы с библиотеками (например, некоторые ситуации обработки ошибок в libjpeg и некоторых других библиотек на чистом C). Работает это даже на очень простых контроллерах.

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

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

Ну и что?

Суть в том что область видимости вся функция. То есть defer f.Close() сработает только при завершении скоупа. Я не могу например фигурально выражаясь

f = open_read
try
X = f.read
finally
f.close

modify(X)

f = open_write
try
f.write(x)
finaly
f.close

потмоу что defer первого не закроет до завершения функции. Следовательно если я хочу подобный код - все опять к закатыванию солнца вручную. «Так же придетс ядействовать в любых подобніх обстоятельствах» (C)...

То есть как я уже говорил - благодаря подобным решениям go прямо напрашивается на свой вариант boost который будет кривокосо компенсировать недостатки языка.

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

Да, забыл еще... Можно попробовать сделать SEH на системные ошибки, но это достаточно убого получается. С другой стороны, в unix это кажется единственный вариант сделать так, чтобы при сегфолте программа не просто тихо упала с одним сообщением в stdout/stderr, а попыталась максимально корректно завершить работу или откатится к предыдущему рабочему состоянию или отправить дамп/стектрейс разработчику.

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

Ну, это ерунда.

А по моему совсем не ерунда если нельзя контролировать скоуп различных закрываемых ресурсов типа файлов/соединений/запросов в бд. Особенно это критично в бд будет когда insert/update после select будет конкурировать с этим же select чуть ранее не отпуская его до завершения функции.

Да и вообще - посмотри код работы с бд из их же примеров:

age := 27
rows, err := db.Query("SELECT name FROM users WHERE age=?", age)
if err != nil {
    log.Fatal(err)
}
for rows.Next() {
    var name string
    if err := rows.Scan(&name); err != nil {
        log.Fatal(err)
    }
    fmt.Printf("%s is %d\n", name, age)
}
if err := rows.Err(); err != nil {
    log.Fatal(err)
}
Это же ужас.

Даже на эрланге аналог будет приблизительно таким:

 Age = 27,
 do([error_m || 
      Rows <- db:query(db, "SELECT name FROM users WHERE age=?", Age),
     db:foreach(fun({Name}) -> io:format("~s is ~d\n", [Name, Age]) end, Rows)
 ])

без всего этого бойлерплейта.

Особенно мне нравится что я тут совсем не вижу почему оно прерывает execution. Черная магия log.Fatal?

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

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

Fatal is equivalent to Print() followed by a call to os.Exit(1).

Простенько и со вкусом.

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

Простенько и со вкусом.

Я не против такой семантики per se - пусть бы оно было os.exit(msg, status). Но когда log.Fatal (я надеялся что это логирование с уровне fatal) - делает os.exit.....

«Как завершить программу? Залогируй фаталную ошибку....»

Наркоманы...

тут остается вспомнить только логлевел в андроиде

log.wtf(«go-lang»)....// what a terrible failure...

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

Fatal — губительный, пагубный, смертельный, летальный, смертоносный, вызывающий смерть

Ты бы хоть в словари заглядывал что-ли.

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

Ты бы хоть в словари заглядывал что-ли.

теперь посмотри слово «log».

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