Вышел Go 1.2

ещё окам вспомни.

у голэнга удобная и прозрачная конкрурентность - есть ноды (императивные) и есть взаимодействие нод(горутины) через стримы/потоки/ченелы

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

есть утиные интерфейсы.

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

печаль в том, что голэнг не достаточно убог для такой судьбы.

Хм, ну как бы в яве для тредов есть все, от простого как табуретка Thread t = new Thread(runnable); t.start(); до различных апишников любой степени абстракции. Со всякими BlockingQueue, parallelStream() и совсем асинхронными и распределенными JMS, а так-же автоматическом выполненнии кода в различных потоках всякими контейнерами. Чего еще не хватает для счастья и где тут непомерная цена?

java to golang as FORTRAN to C

Система типов там не примитивнее ранней Явы (до 1,5).

Но на дворе уже не девяносто мохнатый.

Но на дворе уже не девяносто мохнатый.

Если ты хочешь сказать, что Go устарел еще до релиза, то я согласен.

java to golang as FORTRAN to C

Это деградация, батенька. Один взгяд на программу, написанную на Fortran 90/95 сразу должен привести вас к подобному заключению. Единственным оправданием вашего заключения может служить только то, что вы имели ввиду Fortran 66.

выходящему из моды Руби

а ведь не прошло и пол-года

Кстати, гуру, а киньте в качестве примерf чо-нить на современном фортране. Только на современном. Это ведь уже вполне человеческий ЯП с обобщенными функциями, перегрузкой операторов, с модулями, интерфейсами (по Ц/Цхх - прототипами) функций, и кучей других вкусных плюшек. Правда, насколько я знаю, на нём почти никто не пишет, а если предъявить такой исходник бородатому ветерану ф77, то его сразу инфаркт хватит.

Погуглите реализацию iso_varying_string. Будут там вам интерфейсы и проч. Правда, это довольно специфическая задача.

Ещё есть проект gtk fortran, там на фортране написали обёртку к GTK и даже графопостроитель забахали (на самом деле прикрутили plplot, куажется). Мои собственные проекты сугубо счётные и я использую главным образом возможности Fortran 95, всякими объектами и интерфейсами не увлекаюсь.

Я в последнее время достаточно много использую сабж как си с большой стандартной библиотекой и автоматической системой сборки с зависимостями.

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

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

В общем впечатления вполне положительные.

Go антихипстерский: взять хотя бы стандартизованный кодинг-стайл (go fmt).

var v1 int

Здесь, в объявлении типа, var выглядит ощутимо лишним.

Go антихипстерский: взять хотя бы стандартизованный кодинг-стайл (go fmt).

Ты как маленький, это же цикл моды: самоограничение -> вседозволенность ->самоограничение etc.

Это объявление переменной v1 типа int.

Ну и зря не увлекаетесь. Очень удобная и полезная штука - объявлять, какие типы должны быть переданы в качестве аргументов функции. Правда на фортране она малость вербозной получается. И группирование данных в структуры (в терминологии Ц/Цхх) тоже весьма в жилу даже в сугубо счётных задачах.

А вот и закомплексованный нищеброд в тред пожаловал.

Еще одна хипстерская игрушка на замену выходящему из моды Руби.

o_O

Что у них общего, кроме того, что оба — языки программирования?

Вообще-то во всех нормальных языках, и не только нормальных. Scala, F#, C#, (надо думать есть и в Visual Basic), D, Ada, FreePascal, всё семейство ML, Haskell

О! Т.е. глядя на этот список, можно предположить, что Go, таки, взлетит? :)

Мне куда больше понравилась его работа с пакетами/библиотеками «из коробки» на уровне языка.

Вот что пока не нравится — обязательные блоки даже для одиночного оператора (if ... { приветПерл! } ), невозможность перенести точку при вызове метода в новую строку (что логичнее при цепном вызове), и традиция использовать всюду код возврата вторым аргументом вместо генерации исключений при ошибке. Да и сами исключения (точнее, defer/panic/recover) создают ощущение неуклюжести. Хотя идея просто defer'а нравится :)

В общем и целом больше нравится, но на бочку мёда приходится не ложка, а целый черпак дёгтя, так что ощущения пока сложные :)

код возврата вторым аргументом вместо генерации исключений при ошибке

Это как раз хорошо. Эксепшны - говно. В остальном согласен.

panic

Это чтобы приложение вылетело, его ловить не надо.

Как самый убогий? Может и взлетит.

Нет, как самый лучший.

го это си сегодня.

согласен, про схожесть с сями.

т.е переносимый ассемблер.

вот с этим не совсем согласен, темболее что

однако таких переносимых уже ща пруд пруди асм.жс ; ллвм

Как самый убогий?

откуда столько ненависти? Вот как по-твоему, Го лучше сей или си лучше го? //а если с lisp'ом сравнить?

откуда столько ненависти? Вот как по-твоему, Го лучше сей или си лучше го? //а если с lisp'ом сравнить?

В компании так называемых «новых» компилируемых языков: D, Vala, Go, Rust Go --- самый убогий (в смысле простой, примитивный, не имеющий продвинутых возможностей), это факт. При этом у него самый эзотерический синтаксис.

При этом у него самый эзотерический синтаксис.

в чём его эзотеричность?

в смысле простой, примитивный

это плохо?

не имеющий продвинутых возможностей

не имеет параметрического полиморфизма. Имеет встроеные корутины и каналы. Ещё чего не хватает?

Кстати, товарищи специалисты по Go. А как он разруливает зависимости пакетов? Вот пишу я go get github.com/robfig/revel и он ставит мне до кучи другие зависимости. Это прописывается где-то в репозитории или он анализирует сорцы на предмет

import (
...
    "github.com/streadway/simpleuuid"
...
)

система типов языка Go описывается в категориальной семантике?

http://en.wikipedia.org/wiki/Denotational_semantics

http://en.wikipedia.org/wiki/Domain_theory

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.124.5712

For historical reasons, formal semantics are usually classified as following one of three main approaches:

[...]

Denotational semantics: Meanings are mathematical objects, typically functions from inputs to outputs. This category of semantics explicitly constructs mathematical models of programming languages.

Наверно описывает, просто никто этого не делал.

Превращаем «семантическими скобками» вещи из языка в вещи модели, то есть ставим нотации в соответствие денотацию — типам, допустим, семантические домены, то есть определённого вида множества, программам — математические (семантические) функции определённого вида (http://repository.upenn.edu/cgi/viewcontent.cgi?article=1887&context=cis_... ). Естественно, что такие множества и функции образуют категорию, а семантические эффекты часто даются монадическими построениями на такой категории (http://homepages.inf.ed.ac.uk/gdp/publications/Domains_a4.ps, http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.55.903, http://www.cs.cmu.edu/~crary/819-f09/Moggi91.pdf).

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

А доказать этот факт можно? Удобная система вкладываемых структур, нативная многопоточность, прекрасная система зависимостей со встроенным пакетным менеджером, куча синтаксического сахара, высокая производительность, очень лёгкий стартап. Что из перечисленного — «убогость это факт»? :)

При этом у него самый эзотерический синтаксис.

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

или он анализирует сорцы

вроде так

Это прописывается где-то в репозитории или он анализирует сорцы на предмет

Анализирует сорцы.

Вот как по-твоему, Го лучше сей или си лучше го?

А может ещё с FORTRAN77 сравним?

Ясно. Тогда — совсем хорошо :) Пожалуй, понемногу начну пописывать на нём текущие небольшие задачи.

Правда, обломался сейчас. Хотел GOPATH положить в SparkleShare, чтобы иметь синхронизированную версию на разных машинах, а оно несовместимо: https://github.com/hbons/SparkleShare/issues/1442

А может ещё с FORTRAN77 сравним?

с lisp'ом, с lisp'ом сравните!)

код возврата вторым аргументом вместо генерации исключений при ошибке

Эксепшены удобны только в однопоточных программах.

Подумайте, куда полетит и где ловить этот эксепшен, когда запущены 10000 независимых горутин? Ошибку в виде значения можно передать по каналу и спокойно обработать в другой горутине.

И еще. Чтобы стало легче без привычных эксепшенов, перестаньте думать об ошибках, как об авариях. Это просто альтернативные результаты. Почему этот результат должен куда-то лететь по стеку вызовов сшибая все на своем пути?

Анализирует. Что не очень удобно, если требуется форкнуть проект: придётся переписывать все импорты этого пакета, всех других, которые его используют, и так далее.

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

Так вот именно этот вариант и интересен. Просто передать другой вариант можно и обычным способом. А тут — приходится тонну лишних проверок вводить.

Тем не менее, было бы совсем неплохо уметь ловить ошибку в блоке, а не писать if err != nil { return } сотню раз. В скалке есть Try[] и for-yield, в хаскеле такое можно сделать монадками, а в го такое безобразие.

Я бы не сказал, что она такая уж сама по себе распрекрасная. Вот, например, имеет место быть невозможность привязаться к конкретному ярлыку (tag), ветке (branch) или свершению (commit) в мерзавчике (git). Предположим, хочу заюзать такую-то либу конкретной версии, а не HEAD... А если вдруг появится такая поддержка, то не будет ли конфликта в случае если мой код захочет юзать библиотеку одной версии, а какая-нибудь другая используемая моим кодом библиотека эту же, но с другим API. Прошу разъяснить, если кто в теме.

Кстати, оно чем-нибудь лучше хаскеля помимо «привычного» синтаксиса и (возможно) более лёгкой совместимостью с C?

вот с этим не совсем согласен, темболее что

гоАвторы во многом единомышленики святого Ричи который в свой язык включил проверенные временем решения - такс сказать наименьший общий делитель.

даже указатели(смешивание с массивами) притащены из предков .

у голэнга тоже взяты проверение временем решения и сообранны в одну коробку

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

зы. к деферу лично отношусь положительно.

А доказать этот факт можно? Удобная система вкладываемых структур, нативная многопоточность, прекрасная система зависимостей со встроенным пакетным менеджером, куча синтаксического сахара, высокая производительность, очень лёгкий стартап. Что из перечисленного — «убогость это факт»? :)

Хорошо, давайте по порядку. Я буду на примере D излагать, потому что Rust и Vala мне плохо знакомы.

Итак, давайте посмотрим, что имеет D из крупных вещей и не имеет Go (если я не прав, вы меня поправите):

• ООП: наследование, интерфейсы, множественное наследование интерфейсов.
• Шаблоны.
• Лямбды и всякие там мапы (функциональщина).

Стандартная библиотека D богаче, например, есть такие вещи, как std.algorithm, std.parallel, std.mathspecial, std.numeric, std.regexp, которыми в Go и не пахнет.

Стандартные типы: float, double, real в D с возможностью работы с 80-битною (а на некоторых архитектурах вскоре и 128-битною за счёт эмуляции средствами AVX) арифметикою против float32 и float64 в Go, UTF8, UTF16, UTF32 в D и только один вариант в Go.

Скорость кода, сгенерированного референсным компилятором (dmd vs goc) выше в полтора-два раза. Если говорить о gcc, то здесь разница меньше, но всё равно в пользу gdc против go-gcc.

Теперь по синтаксису. Есть и там и там:

• Автоматические типы.
• Кортежи.
• foreach (который в Go просто for).
• ещё что-то наверняка забыл.

Есть в D и нет в Go:

• D может делать операции над срезами массивов вида:

  A[$/4 .. $/2] = 0.5*B[$/2 .. $] + C[0 .. $/2]*D;
  

  Go не может.
• D может передавать произвольный тип в функцию (фактически это вариант шаблонов):

  auto f(T, S)(T x1, S[] x2) {return x1*std.reduce!"a+b"(x2)}
  

Можно писать дальше, но зачем?

ты оперируешь терминами не понимая (в достаточной полноте) их семантики.

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

по остальным пунктам у тя такой же уровень как и с лямбдами

по остальным пунктам у тя такой же уровень как и с лямбдами

Т.е. по существу вам сказать нечего.

Предположим, хочу заюзать такую-то либу конкретной версии, а не HEAD...

А просто распаковать вручную нужную версию в src? Там же обычный репозиторий git.

Вот, нагугливаются такие рецепты:
http://stackoverflow.com/questions/3559076/git-how-to-get-back-to-most-recent...

Т.е. по существу вам сказать нечего.

Ответ и был по существу.

ООП: наследование, интерфейсы, множественное наследование интерфейсов.

В Go есть вложенность структур, которая может вести себя как ООП (но гибче и шире). В т.ч. поддерживать множественное наследование. В Go есть интерфейсы.

Вот пример: http://play.golang.org/p/g9QZE6a74Z
(Спецов прошу не пинать, это мой второй в жизни код на Go :D)

Лямбды и всякие там мапы (функциональщина).

Это всё в Go есть. Вот мой третий в жизни код на Go:http://play.golang.org/p/lsFnbogw5l

В общем, пока похоже, что Вы Go знаете даже хуже меня (а я его совсем не знаю :D)

Скорость кода, сгенерированного референсным компилятором (dmd vs goc) выше в полтора-два раза.

Кстати, о птичках: https://github.com/Balancer/benchmarks-fib-obj/wiki/Результат-теста:-i3-2.2ГГц

(и, да, это был мой первый код на Go и второй или третий на D ;) )