Релиз Go 1.1

Ну по крайней мере в нём есть конкурентность, в отличие от D.

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

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.

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

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

http://golang.org/doc/faq#declarations_backwards

Также http://golang.org/doc/articles/gos_declaration_syntax.html

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), так что в целом логично это и на несколько операторов распространить. Давно уже собирался читнуть стандарт, да все никак руки не доходят...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

По каким примерам? Например вот. В питоне для такого приходится использовать костыль global.

http://play.golang.org/p/SEQDsVxMtV

Вообще

a := b

auto a = b

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

auto i = 5;

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

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

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

Внимание вопрос _зачем_?

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

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

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

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

Внимание вопрос _зачем_?

Потому что они могли.

И вообще, на многие вопросы этого треда уже отвечено в faq.

http://golang.org/doc/faq

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

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

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

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

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

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

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

Японил! Лучше go, чем php!

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

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

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

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

Там есть 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 - встроенный тип - никакой фантазии для обобщения.

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

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

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

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

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

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

В них больше фич, но и мозготраха побольше.

Хоть кто-то правильно понял.

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

которых нет в D

Элементарно: горутины и каналы.

Rust

defer.

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

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

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

Ага. Их переизобрели тут же во встроенных мапах и т.д. То что нормальные люди делают обобщенной библиотекой там закатали в компилятор. Можно мне реализацию мультимапы на 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 например по дереву моей собственной реализации? Писать на каком нибудь другом языке?

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

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

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

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

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

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