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 ()

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

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

5.1.2.3:

6. Accesses to volatile objects are evaluated strictly according to the rules of the abstract machine.

Заметь, строгое соответствие обещано только для volatile объектов.

9. EXAMPLE 1 An implementation might define a one-to-one correspondence between abstract and actual semantics: at every sequence point, the values of the actual objects would agree with those specified by the abstract semantics. The keyword volatile would then be redundant.

Да, реализация может всегда обеспечивать полное соответствие.

10. Alternatively, an implementation might perform various optimizations within each translation unit, such that the actual semantics would agree with the abstract semantics only when making function calls across translation unit boundaries.

А может - только между вызовами внешних функций.

6.7.3.7:

An object that has volatile-qualified type may be modified in ways unknown to the implementation or have other unknown side effects. Therefore any expression referring to such an object shall be evaluated strictly according to the rules of the abstract machine, as described in 5.1.2.3. Furthermore, at every sequence point the value last stored in the object shall agree with that prescribed by the abstract machine, except as modified by the unknown factors mentioned previously. What constitutes an access to an object that has volatile-qualified type is implementation-defined.

Опять-таки: значение переменной в точках следования должно быть таким, как задумано, но только при наличии volatile.

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

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

Если честно, непонятно, можно наглядный пример?

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

6. Accesses to volatile objects are evaluated strictly according to the rules of the abstract machine.

...the actual semantics would agree with the abstract semantics only when making function calls across translation unit boundaries.

Спасибо, вопрос снят. В принципе в пределах одного оператора компилятор вправе выполнять вычисления как ему вздумается это известно (i+++++i), так что в целом логично это и на несколько операторов распространить. Давно уже собирался читнуть стандарт, да все никак руки не доходят...

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

Код на С не упадет, в коде на С нужно будет только добавить volatile к декларации g и все будет работать. Атомарность тут ни при чем, сначала выделили память, потом проинициализировали и уже только потом присвоили указателю значение проинициализированной памяти. Вот в таком порядке, как и написано в коде. Но в комментарии разработчиков утверждается что указателю может быть присвоено значение ссылающееся на неинициализированную память.

A-234 ★★★★★ ()
Ответ на: комментарий от eugeno

Мне это кажется нелогичным и некрасивым.

Я так понимаю ты уже заявил комитет стандартизации с++ что

class X: Y нелогичность и надо Y class X или Y X class и тому подобное?:)

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

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

Что такое := и чем оно у них отличается от = интуитивно понятно, но от этого не легче. В Паскале := было всегда присваиванием а = сравнением. Здесь присваиванием является и то и другое. Нахрена спрашивается?

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

Ну по крайней мере в нём есть конкурентность

Зато все остальное заставляет рыдать.

D к стати тоже не нужен.

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

Спасибо, теперь понятно. У меня был синдром C-утёнка.

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

Зато все остальное заставляет рыдать.

Единственное, чего го действительно не хватает — генерики.

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

Для меня вообще идеальный синтаксис — это питоновский. К сожалению, для языков со статической типизацией реализовать красивый и логичный синтаксис намного сложнее.

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

Не передергивай. В Go достаточно библиотек и они довольно быстро развиваются. Gо концептуально чище D и Rust.

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

Одно присваивание, другое — присваивание с определением. Это две большие разницы.

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

У них все переменные, судя по примерам, изначально определены. В чем состоит разница в данном случае?

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

Вообще

a := b
это аналог цппшного
auto a = b

Повторная попытка переопределить вызовет еггог.

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

Единственное, чего го действительно не хватает — генерики.

Он шизанутый. Они поубирали кучу знаков припинания - но добавили новых. Зачем импорты в кавычках? Там есть multiple results вместо таплов. КАкая шиза их покусала с named results? Какую гениальную проблему они решали с var x ,y , z = 1, 2, 3? В цикле for/if сэкономили на скобках, но сделали {} required. Гениально! Какую они проблему решали добавив список инициализации в if? Кому-о оно мешало в outer scope? Очередной специальный синтаксис для массивов вместо обобщения до коллекций. Ага и как следствие keyword range. Ага ну конечно-же изобретем map - встроенный тип - никакой фантазии для обобщения. И конечно же сдедалаем всю эту бодягу частным случаем. То надо создавать с помобщью new а это с помощью make....

можно продолжать до бескончености. Решение проблем которые являются проблемами только под ЛСД, да еще и частными случаями , и отсутствие базовых современных фич. Шиза.

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

Gо концептуально чище

Go концептуально не содержит никаких интересных концепций.

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

Го проектировали написав фломастером на доске что им (в гугле) нужно от языка. Нужны были мапы, добавили мапы. И так далее.

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

Скучный язык для практического применения.

Как раз для практического применения он не годится в связи со всем вышеупомянутым. Как только задачи становятся большими и сложными которые не решить хитрым фором для хитрого мапа - все тут же становиться черезжопным как std::function и прочее. Этот CSP сам по себе не нужен. У меня он совместно с долбонутейшими деревьями которые представляют всякие метрические пространства. И чем мне поможет ваш хитрый аррай и мапа? Для меня синтаксисов нафигации по структуре нету - придеся все ручками.

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

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

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

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

Если задача требует того, что го не может или может плохо, следует использовать что-либо другое.

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

Я когда-то думал что скала достаточно сложна, попахивает «с++». Глядя на поделки типа го я пришел к выводу что скала просто гениально логична при всей своей фичастости.

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

Но это ведь форменный кошмар, присваивание которое на самом деле является декларацией. Кстати, в С auto не используется, ибо смысла в нем ноль. Есть только один случай его использования, типа:

auto i = 5;
Нубов пугать, разве что.

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

auto в C и C++ — две большие разницы.

:= это не оператор присваивания, это декларация. Это другой оператор, отличный от =. Состоит из другого набора символов.

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

Всякие околосерверные дела в нём делаются хорошо. Бложик, сервер онлайн игрушки и подобное.

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

Всякие околосерверные дела в нём делаются хорошо.

Только те которые и на чистом C делаются нормально. Если он предьявляет претензии заменить Си - пускай покажет в чем. В растановке скобок? Смешно.

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

Бложик, сервер онлайн игрушки и подобное.

порыдал. Особенно насчет игрушек.

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

Рыдай дальше. Выше была ссылка на проекты на Go.

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

Go в некоторой ограниченной сфере позиционируется как замена C. Хочеш сказать, что на C мало игрушек написано ?

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

Вот как раз сами по себе игрушки (с графеном и прочим) на го писать не стоит. По скорости не очень, библиотек этого плана мало (по сути есть биндинги к sdl и opengl, ничего более высокоуровневого). Проблемы с кроссплатформенностью (ипады, андроиды, сонсоли).

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

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

По поводу auto спасибо, посмотрел в C++11 что это такое. Не об этом речь конечно, но ведь там auto является лишь названием обобщенного типа а не оператором.

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

Это для сближения с такими языками как питон, где для декларации и присваивания вообще один и тот же оператор используется. Но го в этом плане более строг.

Ну и a = blah() от auto a = blah() в цпп отличается лишь ключевым словом auto, про которое тоже можно забыть и получить либо компилейшн еггог, либо переписать глобальную переменную с тем же именем.

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

Выше была ссылка на проекты на Go.

Есть проекты на чем угодно. Наличие мазохистов не показывает ровным счетом ничего.

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

Зачем импорты в кавычках?

Потому, что это и путь к тому же.

Там есть multiple results вместо таплов.

Лишние типы не нужны.

КАкая шиза их покусала с named results?

Ты даже не представляешь, насколько это удобно. И да, это стиль паскаля, модулы и оберона.

Какую гениальную проблему они решали с var x ,y , z = 1, 2, 3?

Тебя удивляет множественное присваивание?

В цикле for/if сэкономили на скобках, но сделали {} required. Гениально!

В Модула-2 if <условие> then <операторы> end, в го — if <условие> { <операторы> }. Почему бы и нет?

Какую они проблему решали добавив список инициализации в if?

if val, err := SomeFunc(); err == nil, ну ты понял.

Очередной специальный синтаксис для массивов вместо обобщения до коллекций.

Какой специальный синтаксис? Есть массивы, есть срезы, в чём проблема?

Ага и как следствие keyword range

range в случае срезов и массивов — не более, чем синтаксический сахар.

Ага ну конечно-же изобретем map - встроенный тип - никакой фантазии для обобщения.

Выше по треду уже писали, почему в го нет генериков.

которые являются проблемами только под ЛСД

С твоим узким восприятием только ЛСД и поможет.

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

ну-ка расскажи про фичи go, которых нет в D\Rust

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

Go в некоторой ограниченной сфере позиционируется как замена C. Хочеш сказать, что на C мало игрушек написано ?

Хочу сказать что если Go позиционируется как замена С он должен исправлять недостатки, добавлять фичи по сравнению с Си. А он почти ничего не добавил, а изменения относительно Си - это несистематичная борьба со знаками припинания. Например в Скале со знаками припинания поборолись для возможностей создания edsl. То есть вот например:

 val list = 1 :: 6 :: 3 :: 2 :: 5 :: Nil
 var result = from (list) where (_ % 2 == 1) select (_ * 2) orderby self ascending

и вот

  receive {
        case Ping =>
          sender ! Pong
        case Stop =>
          exit()
  }
валидный скальный код. С чем боролись убирая скобки с форов и ифов и добавляя фигурные? В голову стукнуло просто? Уж не говоря о том что они имплементировали те самые грабли которыё везде пытаются исправить - вроде общих фреймворков для коллекций, нормальные генерики, нормальные таплы и т.д. Какие ненужные вещи! Главное список инициализации в if вставить - конечно оптимизатор совсем совсем не может сузить скоуп автоматически - рокет саянс, надо трехэтажные ifы писать для этого.

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

Ну тогда asm просто золотое сечение.

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

что блять? чем сложнее? как сложнее? почему сложнее?

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

Потому, что это и путь к тому же.

В сях это тоже путь. И?

Лишние типы не нужны.

Ага. Их переизобрели тут же во встроенных мапах и т.д. То что нормальные люди делают обобщенной библиотекой там закатали в компилятор. Можно мне реализацию мультимапы на Go? Ну пожалуста - я хочу посмеятся.

Ты даже не представляешь, насколько это удобно.

Это фейспалм полный. Как с точки зрения чтения так и с точки зрения execution flow. А уже оптимизатор наверное вообще вешается.

Тебя удивляет множественное присваивание?

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

Параметриков не сделали - зато решение детских проблем в полный рост.

Почему бы и нет?

Это лозунг го. Не «нужно потому что». А «почему бы и нет».

ну ты понял.

Ага. Главное таплов не изобретать. Лучше if и case поправить. Хочу видеть в цвете например аналог этого:

do
x <- might_return_error(1),
y <- might_return_error(x),
z <- might_return_error(y),
return z

Какой специальный синтаксис? Есть массивы, есть срезы, в чём проблема?

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

range в случае срезов и массивов — не более, чем синтаксический сахар.

Конечно. И как всякие другие люди живут не засовівая такой чуши в компилятор - ума не приложу. Как мне сделать range например по дереву моей собственной реализации? Писать на каком нибудь другом языке?

Выше по треду уже писали, почему в го нет генериков.

Потому что главное было скобки вырезать и кейвордов напихать. Знаем.

С твоим узким восприятием только ЛСД и поможет.

Узким? что там воспринимать? ТАм же нет ничего. И тормозит как жаба.

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

И да, это стиль паскаля, модулы и оберона.

пусть на кладбишче. всё верно.

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