Комментарии 146
НЛО прилетело и опубликовало эту надпись здесь
Да, только у тебя
Напрасно минусуете человека, это распространённый вопрос. По ссылочке можно почитать зачем.
А мне больше интересно почему?
if a < b { f() } // Valid
if (a < b) { f() } // Valid
if (a < b) f() // INVALID
for i = 0; i < 10; i++ {} // Valid
for (i = 0; i < 10; i++) {} // INVALID
if x {
}
else { // INVALID
}
А еще больше интересно, почему никто не читает документацию?
Я лично читал документацию.
Go does not require parentheses around the condition of an if statement, or the expressions of a for statement, or the value of a switch statement.
Ели вас не затруднит, поясните.
Go does not require parentheses around the condition of an if statement, or the expressions of a for statement, or the value of a switch statement.
if (a < b) {} // VALID
for (i = 0; i < 10; i++) {} // INVALID
Ели вас не затруднит, поясните.
скобки относятся к выражениям, (a < b) — валидное выражение, а (i = 0; i < 10; i++) — нет
Так все что внутри скобок инструкции for тоже выражение!
Нигде в документации не сказано, что это относится только к логическим выражениям.
Нигде в документации не сказано, что это относится только к логическим выражениям.
да? быть может это «выражение» еще и может вернуть какое-то значение?
Фактически такой вид цикла называется «цикл с предусловием», который может быть представлен в такой нотации:
Это конечно больше философское суждение, но косвенно, инициализация условный переход и изменение состояния могут рассматриваться как часть одного выражения.
Мне просто не понятно почему во всех языках с которыми я работал для всех управляющих инструкция принята единая форма записи, в отличии от Go.
При этом я не пытаюсь осудить разработчиков языка, для меня сейчас важно понять его философию.
i = 0;
while (++i < 10) {
//...
}
Это конечно больше философское суждение, но косвенно, инициализация условный переход и изменение состояния могут рассматриваться как часть одного выражения.
Мне просто не понятно почему во всех языках с которыми я работал для всех управляющих инструкция принята единая форма записи, в отличии от Go.
При этом я не пытаюсь осудить разработчиков языка, для меня сейчас важно понять его философию.
А что по скорости? Первые версии джаве в разборе регулярок проигрывали по скорости. А в этой исправили?
Судя по бенчмаркам Go двухнедельной давности, не исправили:
shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=go&lang2=java
shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=go&lang2=java
При использовании GCCGO вместо 6g/8g быстродействие вырастает значительно. Но помимо быстродействия, следует учитывать и такие параметры как «потребление» RAM и CPU. В сферическом вакууме (с неограниченными памятью и процессорной мощностью) этим можно пренебречь, но на практике (в моём случае — HiLoad web apps) требования к RAM/CPU становятся критичными.
Проще говоря, для сохранении равной скорости ответа при «тяжёлой бомбардировке» запросами, реализация на Go требует в 4 раза меньше железа чем Java. И почти в 20 раз меньше «любимого всеми» PHP. Фактически, реальная производительность (учитывая бутылочные горлышки, от которых никуда не деться) приближается к реализации на C/C++.
Это, кстати, можно считать ответом на вопрос «зачем». Зачем нести издержки на 4-20 серверов там, где можно обойтись одним? А уж при оплате ресурсов по факту (на том же AWS) издержки снижаются ещё сильнее.
Скажу больше: примерно для 7 задач из 10 — Go-фронтенд (включающий в себя и само приложение) справляется с HiLoad успешнее чем Nginx.
NB: все доводы вы легко можете проверить самостоятельно с помощью ab/siege.
Проще говоря, для сохранении равной скорости ответа при «тяжёлой бомбардировке» запросами, реализация на Go требует в 4 раза меньше железа чем Java. И почти в 20 раз меньше «любимого всеми» PHP. Фактически, реальная производительность (учитывая бутылочные горлышки, от которых никуда не деться) приближается к реализации на C/C++.
Это, кстати, можно считать ответом на вопрос «зачем». Зачем нести издержки на 4-20 серверов там, где можно обойтись одним? А уж при оплате ресурсов по факту (на том же AWS) издержки снижаются ещё сильнее.
Скажу больше: примерно для 7 задач из 10 — Go-фронтенд (включающий в себя и само приложение) справляется с HiLoad успешнее чем Nginx.
NB: все доводы вы легко можете проверить самостоятельно с помощью ab/siege.
А зачем тогда нужны 6g/8g? Если с GCCGO все быстрее, то пилили бы его? В чем там подводные камни?
6g/8g быстрее работают, т.е. компилируют очень быстро, что позволяет легче использовать TDD к примеру.
Хм, а почему такая огромная разница получается www.opennet.ru/opennews/art.shtml?num=30784 — я как понимаю в тестах использовался 6g/8g, почему не провели тесты с использованием GCCGO?
А есть публичные бенчмарки, которые это подтверждают? А то всё, что я видел показывает обратную картину - ява опережает по производительности. Ну и логика подсказывает, что так и должно быть: кодогенератор и GC у неё давно вылизаны до блеска, а где ещё можно обойти - непонятно. Ну и да, статическая компиляция это минус, а не плюс - при генерации кода JIT-ом у нас есть готовый профайл исполнения, который помогает компилятору правильно генерить код.
>исполняемый код полностью переносим
Это как?
Это как?
Что-то я не заметил ориентированности на ясность кода…
На мой взгляд, главная WOW-фишка Python — визуальное форматирование (формирование блоков отступами). Раньше люди заинтересовывались питоном именно глядя на эту фишку.
Вот второй пример какой-то невыразительный, имхо.
Оговорюсь, что обращаю внимание только на синтаксис. Ибо о всем остальном говорить пока рано.
На мой взгляд, главная WOW-фишка Python — визуальное форматирование (формирование блоков отступами). Раньше люди заинтересовывались питоном именно глядя на эту фишку.
Вот второй пример какой-то невыразительный, имхо.
Оговорюсь, что обращаю внимание только на синтаксис. Ибо о всем остальном говорить пока рано.
WOW-фишка пайтона заключается в том, что форматирование кода не просто рекомендуется, но сделано обязательным. Но никто не мешает адаптировать PEP для любого языка, применяя самостоятельно и по доброй воле красивое форматирование.
Более того, «причесать» код написанный на языке Go легко можно простым инструментом gofmt, прилагающимся в комплекте :)
Более того, «причесать» код написанный на языке Go легко можно простым инструментом gofmt, прилагающимся в комплекте :)
НЛО прилетело и опубликовало эту надпись здесь
функция fib() возвращает функцию которая возвращает int, рекурсия по нашему, что тут непонятно?
Это — не рекурсия, это — замыкание.
Замыкание, это когда функция захватывает контекст в котором используется… а это просто функция возвращающая функцию.
А переменные a и b, это что, не контекст?
Замыкание, это когда функция захватывает контекст в котором используется… а это просто функция возвращающая функцию.
Это называется "Функция высшего порядка"
Да, прошу прощения, действительно замыкание.
Причем тут рекурсия? Это замыкание.
func fib() func() func() func() func() func() int {
…
}
А так можно будет делать?
…
}
А так можно будет делать?
Не знаю, потому как тело функции то одно, сразу после int, не ясно где тело других функций.
Можно: play.golang.org/p/KN4E1RotKl
Но я очень прошу так не делать :)
Но я очень прошу так не делать :)
О.О Вот и первые звоночки возможности наклепать говнокода при наличии кривых ручек и нежелания думать.
такая возможность есть в любом языке :)
можно еще переменные и функции называть a, b, c, a1, b2, cc, anotherA, тоже язык виноват наверно
можно еще переменные и функции называть a, b, c, a1, b2, cc, anotherA, тоже язык виноват наверно
Я имел ввиду не программный говнокод а эстетический. Мне по сути не так важно что возвращает пятая по вложенности функция, мне главное знать что первый вызов вернет функцию. Дальше я уже определюсь сам. Мне кажется такой шаг был бы более удобным в плане описания функций которые с лямбдами работают.
А на каком языке аналог выглядит более читаемо? :)
Имхо, читается легко слево-направо: функция fib() возвращающая функцию возвращающую int.
Имхо, читается легко слево-направо: функция fib() возвращающая функцию возвращающую int.
JS:
func fib(){...} — очень читаемо
PHP:
func fib(){...} — очень читаемо
Python:
def fib(): — очень читаемо
… Дальше лезть не буду, человек имел ввиду огранизацию вовзращаемых значений, это странно и непривычно как минимум.
func fib(){...} — очень читаемо
PHP:
func fib(){...} — очень читаемо
Python:
def fib(): — очень читаемо
… Дальше лезть не буду, человек имел ввиду огранизацию вовзращаемых значений, это странно и непривычно как минимум.
Ни один из приведенных Вами языков не является строго-типизированным, описанные функции могут возвращать что угодно. Так что такие примеры не подходят. А вот пример на C: int (*fib())()
Ну и что лучше читается? :)
Ну и что лучше читается? :)
На Haskell.
НЛО прилетело и опубликовало эту надпись здесь
например нечто похожее на хаскеле будет выглядеть как
fib :: [Int]
fib = 0:1:zipWith (+) fib (drop 1 fib)
то есть оно будет возвращать по одному элементу из списка, причём делать лениво. то есть получится эквивалент тому что выше.
Ну, или что-то более типизированное
data Stream a = Stream a (Stream a)
fib :: Stream Int
fib = createStream 0 1
fib :: [Int]
fib = 0:1:zipWith (+) fib (drop 1 fib)
то есть оно будет возвращать по одному элементу из списка, причём делать лениво. то есть получится эквивалент тому что выше.
Ну, или что-то более типизированное
data Stream a = Stream a (Stream a)
fib :: Stream Int
fib = createStream 0 1
Думаю, теперь можно и попробовать.
>
а почему не
a, b = b, a+bа почему не
a, b := b, a+b
С двоеточием это объявление, а без двоеточия — присваивание?
Поглядел — оказывается, := — это присваивание с автоматическим выведением типов.
Полагаю, вопрос был как раз о том, зачем объявление и присваивание по-разному оформлять.
По крайней мере, меня этот вопрос тоже заинтересовал.
По крайней мере, меня этот вопрос тоже заинтересовал.
Да, почти. С двоеточие это как в C# было бы var a = 1, или в C++11 auto a = 1. То есть это объявление переменной a c типом, который выводится из присваиваемого значения.
В Go все построено на том, чтобы наиболее популярные конструкции имели сокращенные варианты. Это авторы и называют «простотой» языка.
В Go все построено на том, чтобы наиболее популярные конструкции имели сокращенные варианты. Это авторы и называют «простотой» языка.
НЛО прилетело и опубликовало эту надпись здесь
Установка и тут же первые грабли сменил путь который был по умолчанию.
Пока только покрутить и посмотреть. Без хоть какой-то ide дальше сложно.
Пока только покрутить и посмотреть. Без хоть какой-то ide дальше сложно.
go-ide.com/
Еще когда-то вроде упоминалась какая-то IDE на самом сайте языка, я ее даже ставил, но сейчас что-то не находится…
Еще когда-то вроде упоминалась какая-то IDE на самом сайте языка, я ее даже ставил, но сейчас что-то не находится…
НЛО прилетело и опубликовало эту надпись здесь
Попробуйте GoLangIDE — отличная IDE для Go 1. Поддерживает сборку проектов через go tool.
НЛО прилетело и опубликовало эту надпись здесь
Какое совпадение!
Только вчера распечатал Learning Go
Стало удобно. На сайте теперь лежат бинарники под MacOs, в том числе, и вместо:
теперь достаточно сказать:
Однако вчерашний скомпилированный hello занимал 1,072,890 bytes,
в то время как сегодняшний 1,105,936 bytes
Интересно, на что пошли эти 33 килобайта :)
Только вчера распечатал Learning Go
Стало удобно. На сайте теперь лежат бинарники под MacOs, в том числе, и вместо:
$ 6g hello.go
$ 6l hello.6теперь достаточно сказать:
$ go build hello.goОднако вчерашний скомпилированный hello занимал 1,072,890 bytes,
в то время как сегодняшний 1,105,936 bytes
Интересно, на что пошли эти 33 килобайта :)
Хотелось бы немного дополнить пост:
Извиняюсь, clrl+enter сыграл со мной злую шутку
Примечаниях к выпуску — все значительные изменения с момента последнего релиза (r60), а также объясняется, как обновить свой код до Go 1.
Более подробно о совместимости программ, написанных под Go 1, с будущими версиями Go написано в документе «Совместимость Go 1».
Инструкция по сборке Go 1 из исходного кода.
Для меня самым заметным изменением относительно релиза r60 стало появление консольной команды go — это утилита для получения, сборки и установки сторонних Go пакетов и команд. С появлением этой утилиты, Makefile’ы уходят в прошлое. Эта команда работает по принципу convention over configuration, если структура проекта соответствует требованиям go tool, то Makefile для сборки не нужен. Все необходимые условия для сборки проекта go tool получит из исходного кода, определит отсутствующие сторонние пакеты, скачает и установит их. Описание go tool заслуживает отдельной заметки, которую я постараюсь написать в ближайшее время. В официальной документации есть замечательная статья “Как писать Go код”, в которой есть примеры работы с командой go. Всем проектам на Go разработчики рекомендуют перейти от использования Makefile к использованию go tool.
Примечаниях к выпуску — все значительные изменения с момента последнего релиза (r60), а также объясняется, как обновить свой код до Go 1.
Более подробно о совместимости программ, написанных под Go 1, с будущими версиями Go написано в документе «Совместимость Go 1».
Инструкция по сборке Go 1 из исходного кода.
Для меня самым заметным изменением относительно релиза r60 стало появление консольной команды go — это утилита для получения, сборки и установки сторонних Go пакетов и команд. С появлением этой утилиты, Makefile’ы уходят в прошлое. Эта команда работает по принципу convention over configuration, если структура проекта соответствует требованиям go tool, то Makefile для сборки не нужен. Все необходимые условия для сборки проекта go tool получит из исходного кода, определит отсутствующие сторонние пакеты, скачает и установит их. Описание go tool заслуживает отдельной заметки, которую я постараюсь написать в ближайшее время. В официальной документации есть замечательная статья “Как писать Go код”, в которой есть примеры работы с командой go. Всем проектам на Go разработчики рекомендуют перейти от использования Makefile к использованию go tool.
Ваш комментарий более важный и интересный, чем пост (да простит меня топикстертер).
Про команду go тоже кратко отметил выше в комментариях.
Может быть Go заслуживает уже своего собственного хаба?!
Про команду go тоже кратко отметил выше в комментариях.
Может быть Go заслуживает уже своего собственного хаба?!
Спасибо :)
На счет собственного хаба — я только за :) Только быстрый поиск по habrahabr.ru/info/help/hubs/ не дает ответ на вопрос, как же такой хаб создать.
На счет собственного хаба — я только за :) Только быстрый поиск по habrahabr.ru/info/help/hubs/ не дает ответ на вопрос, как же такой хаб создать.
Мне тоже не понятно, сам задавался подобным вопросом.
Может быть организовать опрос о нужности такого хаба, а потом результаты отправить администрации(?)
Может быть сюда прийдет какой-нибудь старожил и расскажет, как это сделать правильно.
Может быть организовать опрос о нужности такого хаба, а потом результаты отправить администрации(?)
Может быть сюда прийдет какой-нибудь старожил и расскажет, как это сделать правильно.
Готово :)
О! Отказ от makefile`ов + меньшее количество кода, да это просто прорыв для системного языка. Им осталось только производительность пофиксить и перейти к разработке инструментария.
Повторюсь, но с производительностью всё очень хорошо. Особенно если использовать GCCGO вместо родного инструментария. Если не заглядываться на сферические тесты, то в реальности Go лишь немного проигрывает C/C++.
Я бы сказал, что производительность Go вполне достаточная. То есть если мы пилим серверное приложение из разряда получить/отдать на обработку/вернуть результат, то врядли мы упрёмся в процессор. Однако синтетические тесты показывают, что математические вычисления/кодирование/архивация вполне могут быть в 3 раза медленнее.
Впрочем, я имел ввиду пофиксить тормознутость регулярок, не больше.
Впрочем, я имел ввиду пофиксить тормознутость регулярок, не больше.
НЛО прилетело и опубликовало эту надпись здесь
зато по памяти рвет :)
НЛО прилетело и опубликовало эту надпись здесь
Из 11 тестов только в двух проигрывает по памяти. В остальных 9ти тестах выигрывает в 2 — 7 раз.
А вообще, во-первых это все синтетические тесты, которые всей картины не раскрывают, а во-вторых язык еще молодой, оптимизациями еще никто особо не занимался. То, что он компилируемый, не использует виртуальной машины, промежуточного байт-кода, в перспективе должно позволить обогнать C#, Java и динамические языки. C и C++ и т.п. обогнать ему не удастся никогда.
А вообще, во-первых это все синтетические тесты, которые всей картины не раскрывают, а во-вторых язык еще молодой, оптимизациями еще никто особо не занимался. То, что он компилируемый, не использует виртуальной машины, промежуточного байт-кода, в перспективе должно позволить обогнать C#, Java и динамические языки. C и C++ и т.п. обогнать ему не удастся никогда.
Во-первых, не такой уж и молодой — уже 2.5 года. Во-вторых, Go изначально создавался оптимизированным, в том числе и по архитектуре. Некоторые «грустные результаты» синтетических тестов связаны с тем, что код написан не для Go, а простой калькой, не учитывающей специфику языка, особенно многопоточность.
Обогнать C/C++ цели перед создателями и не стояло, но максимально приблизить производительность удалось. Как я уже ранее говорил, учитывая узкие места аппаратного обеспечения системы, быстродействие в реальных задачах уже можно сравнивать именно с C/C++.
Важно учитывать философию Go — приближаясь по простоте к Python (дающей высокую скорость разработки и практически незаметную по времени фазу компиляции), приближать производительность к C/C++. И в этой сфере язык оказывается вне конкуренции.
Обогнать C/C++ цели перед создателями и не стояло, но максимально приблизить производительность удалось. Как я уже ранее говорил, учитывая узкие места аппаратного обеспечения системы, быстродействие в реальных задачах уже можно сравнивать именно с C/C++.
Важно учитывать философию Go — приближаясь по простоте к Python (дающей высокую скорость разработки и практически незаметную по времени фазу компиляции), приближать производительность к C/C++. И в этой сфере язык оказывается вне конкуренции.
Тесты на производительность очень субъективны.
Вот у bolk отличный пост на эту тему Google Go vs. Си. Так там Java проигрывает сильно. Но, повторюсь, все синтетические тесты не очень показательны.
Go привлекателен низким порогом вхождения (любой знакомый c С и Python его освоит), шикарнейшей многозадачностью и ориентированностью (в перспективе) на web (сейчас это AppEngine, дальше будет больше — уверен).
Вот у bolk отличный пост на эту тему Google Go vs. Си. Так там Java проигрывает сильно. Но, повторюсь, все синтетические тесты не очень показательны.
Go привлекателен низким порогом вхождения (любой знакомый c С и Python его освоит), шикарнейшей многозадачностью и ориентированностью (в перспективе) на web (сейчас это AppEngine, дальше будет больше — уверен).
Поправка. Go изначально неплохо ориентирован на web. Вот, например, два хорошо себя зарекомендовавших фреймворка:
github.com/garyburd/twister (вдохновлённый Tornado/Python)
github.com/hoisie/web.go (вдохновлённый Webpy/Python)
Есть замечательные либы для MongoDB, CouchDB, Redis, Cassandra, SQLite, Mysql. Отличные движки темплетов (помимо встроенного). Что ещё нужно для полного счастья?
github.com/garyburd/twister (вдохновлённый Tornado/Python)
github.com/hoisie/web.go (вдохновлённый Webpy/Python)
Есть замечательные либы для MongoDB, CouchDB, Redis, Cassandra, SQLite, Mysql. Отличные движки темплетов (помимо встроенного). Что ещё нужно для полного счастья?
Ух, спасибо! Свеженькие.
Еще бы все это хозяйство с uWSGI подружить — цены бы не было.
Еще бы все это хозяйство с uWSGI подружить — цены бы не было.
Никого не хочу обидеть, но uWSGI (равно как и FCGI, SCGI) — это по сути костыли, помогающие бегать в первую очередь интерпретируемым языкам. Web-приложения на Go достаточно стабильны и быстры (особенно если использовать одну из важнейших фишек языка — многопоточность), что даёт возможность их использовать в качестве самостоятельного фронтенда. Хотя, Nginx прикрывающий 3-4 Go-бэкэнда всё же надёжнее.
Согласен, конечно же. Всё время забываю, что Go — компилируемый и приравниваю его к Питону.
Насчет uWSGI — он просто обкатан, его не страшно в production ставить.
Надо попробовать с Go-бэкендом, как оно будет в реальных условиях.
И отдельное спасибо за все комментарии, которые вы оставили в этом топике. Жаль у вас нет постов по Go для web, но надеюсь с появлением у Go своего хаба, вы восполните эту нишу.
Насчет uWSGI — он просто обкатан, его не страшно в production ставить.
Надо попробовать с Go-бэкендом, как оно будет в реальных условиях.
И отдельное спасибо за все комментарии, которые вы оставили в этом топике. Жаль у вас нет постов по Go для web, но надеюсь с появлением у Go своего хаба, вы восполните эту нишу.
С вероятностью 99% там проигрывает не Java а запуск виртуальной машины и прогрев JIT компилятора. Это такой вид самообмана. Статически скомпилированный код запускается мгновенно, а JIT требует времени на прогон компилятора в рантайме. Честное сравнение предполагает, что гоняем код типа 10000 раз и замеряем время исполнения второй половины.
Я не совсем ещё безнадежный формалист, но предлагаю автору поста в качестве ссылки «Источника» поставить: blog.golang.org/2012/03/go-version-1-is-released.html,
а не просто на офф. сайт языка
а не просто на офф. сайт языка
После некоторого детального ознакомления с языком впечатления двойственные:
1) С одной стороны челюсть падает. Впечатляет простота и удобство, хотя бы testing с его Example* и Benchmark* чего стоит. Прям млин на уровне языка!!! Круто!
2) Писать все-таки придется много. К примеру в Hash-ах нет SHA-{128|256|512} и ряда других алгоритмов.
Вывод: пока подожду как будет развиваться ) Но на заметку взял, т.к. достаточно элегантен и прост)
1) С одной стороны челюсть падает. Впечатляет простота и удобство, хотя бы testing с его Example* и Benchmark* чего стоит. Прям млин на уровне языка!!! Круто!
2) Писать все-таки придется много. К примеру в Hash-ах нет SHA-{128|256|512} и ряда других алгоритмов.
Вывод: пока подожду как будет развиваться ) Но на заметку взял, т.к. достаточно элегантен и прост)
А кто-нибудь может сравнить с D? По простоте/продуманности синтаксиса, по наличию библиотек и т.д.?
D тоже очень интересный язык. Но по простоте однозначно выигрывает Go. По моим субъективным ощущениям — D в 10 раз сложнее чем Go.
Зато в D плюшек гораздо больше. Наверно тоже раз в 10 :)
Стандартная библиотека у Go существенно больше, чем у D.
Лично мне больше Go по душе.
Зато в D плюшек гораздо больше. Наверно тоже раз в 10 :)
Стандартная библиотека у Go существенно больше, чем у D.
Лично мне больше Go по душе.
оффтоп.
C, D,… Надо было вовремя договориться и стандартизировать названия языков.
P == PHP, R == Ruby, J == Java.
:)
C, D,… Надо было вовремя договориться и стандартизировать названия языков.
P == PHP, R == Ruby, J == Java.
:)
R уже есть, математический.
J и так за Java всегда. Все библиотеки, так или иначе имеют J: JGraph, ICU4J…
J и так за Java всегда. Все библиотеки, так или иначе имеют J: JGraph, ICU4J…
Имя J уже занято. Кстати, довольно необычный язык…
Наконец-то под винду сделали версию
Что значит «наконец-то»?
Для релиза r.60.3 уже c октября существует
Для релиза r.60.3 уже c октября существует
package main
import "fmt"
func main() {
fmt.Printf("hello, world\n")
}
В скомпилированном виде(#go build <hello.go file>) в MacOs весит 1,1 Мб
Я как минимум удивился.
Линковка-то статическая
golang.org/doc/go_faq.html
Why is my trivial program such a large binary?
The linkers in the gc tool chain (5l, 6l, and 8l) do static linking. All Go binaries therefore include the Go run-time, along with the run-time type information necessary to support dynamic type checks, reflection, and even panic-time stack traces.
A simple C «hello, world» program compiled and linked statically using gcc on Linux is around 750 kB, including an implementation of printf. An equivalent Go program using fmt.Printf is around 1.2 MB, but that includes more powerful run-time support.
Why is my trivial program such a large binary?
The linkers in the gc tool chain (5l, 6l, and 8l) do static linking. All Go binaries therefore include the Go run-time, along with the run-time type information necessary to support dynamic type checks, reflection, and even panic-time stack traces.
A simple C «hello, world» program compiled and linked statically using gcc on Linux is around 750 kB, including an implementation of printf. An equivalent Go program using fmt.Printf is around 1.2 MB, but that includes more powerful run-time support.
Трижды попытался проникнуться Go… но так и не смог побороть в себе неприятие синтаксиса. Наверное придется ждать нечто CoffeeScript для JavaScript. Идея отличная, местами просто отличная идеология(нет классов, только struct'ы, функции как first-class citizens, closures), но я не очень понимаю, как она могла излиться в таком синтаксисе в 2010 году.
Я не против скобочек, но я за читабельность и интуитивность.
Я не против скобочек, но я за читабельность и интуитивность.
«Вы не поверите» (с) Люди до сих пор пишут на C и C++ и даже на Objective-C (который сейчас стремительно набирает популярность). И там нет сборщика мусора, куча скобочек, define'ы и header'ы. И все это в 2012 году.
Мне руби тоже очень нравится, но каждому языку своя ниша.
Более того, Go не заменит C и C++ никогда, потому что из-за сборщика мусора, он не пригоден для realtime-critical задач. Например для realtime обработки звука. Вот D мог бы. Но он не пошел, к сожалению.
Мне руби тоже очень нравится, но каждому языку своя ниша.
Более того, Go не заменит C и C++ никогда, потому что из-за сборщика мусора, он не пригоден для realtime-critical задач. Например для realtime обработки звука. Вот D мог бы. Но он не пошел, к сожалению.
Вы не поверите, но я в курсе :)
Почему ObjC набирает популярность, думаю и Вы и я четко понимаем. Но это совсем не ориентир для создания нового языка, верно? Т.е. если Вы создаете платформу, которая интересна разработчикам, то можно использовать и Java, как сделали в Google. Популярность + пугающая простота + железобетонность языка позволили Android стать реальной альтернативой.
Но я видимо уже too old for all this shit, хочу получать удовольствие от разработки. Выбрал я Python для себя в своё время. Я точно знаю, что если мне нужна будет «скорость»(целебную ценность которой, имхо, переоценивают в наших странах(СНГ)), я знаю, что смогу написать на Cython или чистом C необходимые вещи, чтобы уйти от bottleneck'ов. Пусть это будет pain in the ass, но это будет ограниченный кусок задачи, сделанный на С с чётким пониманием «зачем».
Всякие специальные задачи типа realtime это специальные задачи, к которым подход _всегда_ будет специальный, если Go ориентировался на эти вещи, он проиграл бы ещё до выхода на ринг, имхо.
Чтобы стать распространённым языком сейчас, нужно быть языком, в который можно влюбиться. В ObjC влюбляются, т.к. платформа великолепна, т.к. можно заработать деньги, т.к. нет многих убожеств C++. Python/Ruby/CS любят просто за то, какие они есть, красивые, быстрые в разработке, лаконичные и понятные. Что есть в Go такого, чтобы в него могли влюбиться — пока неясно. Goroutines хорошо, но это как «красивые коленки» у девушки, оно вроде как бы плюс, но явно условие недостаточное :)
Почему ObjC набирает популярность, думаю и Вы и я четко понимаем. Но это совсем не ориентир для создания нового языка, верно? Т.е. если Вы создаете платформу, которая интересна разработчикам, то можно использовать и Java, как сделали в Google. Популярность + пугающая простота + железобетонность языка позволили Android стать реальной альтернативой.
Но я видимо уже too old for all this shit, хочу получать удовольствие от разработки. Выбрал я Python для себя в своё время. Я точно знаю, что если мне нужна будет «скорость»(целебную ценность которой, имхо, переоценивают в наших странах(СНГ)), я знаю, что смогу написать на Cython или чистом C необходимые вещи, чтобы уйти от bottleneck'ов. Пусть это будет pain in the ass, но это будет ограниченный кусок задачи, сделанный на С с чётким пониманием «зачем».
Всякие специальные задачи типа realtime это специальные задачи, к которым подход _всегда_ будет специальный, если Go ориентировался на эти вещи, он проиграл бы ещё до выхода на ринг, имхо.
Чтобы стать распространённым языком сейчас, нужно быть языком, в который можно влюбиться. В ObjC влюбляются, т.к. платформа великолепна, т.к. можно заработать деньги, т.к. нет многих убожеств C++. Python/Ruby/CS любят просто за то, какие они есть, красивые, быстрые в разработке, лаконичные и понятные. Что есть в Go такого, чтобы в него могли влюбиться — пока неясно. Goroutines хорошо, но это как «красивые коленки» у девушки, оно вроде как бы плюс, но явно условие недостаточное :)
Вам в журналы писать обзоры — харизматичный стиль (без шуток).
Но всё же язык — удобный (для определенных целей), легкий для освоения и перспективный (учитывая, какая компания за ним стоит). А насчет «влюбиться» — язык это инструмент, и не более того, он может быть удобным или нет.
Влюбиться можно в результат того, что сделано (хорошим) удобным инструментом.
А синтаксис/«красивые коленки» — это больше вкусовщина.
Но всё же язык — удобный (для определенных целей), легкий для освоения и перспективный (учитывая, какая компания за ним стоит). А насчет «влюбиться» — язык это инструмент, и не более того, он может быть удобным или нет.
Влюбиться можно в результат того, что сделано (хорошим) удобным инструментом.
А синтаксис/«красивые коленки» — это больше вкусовщина.
Вот уж никогда не подумал, что годен что-то писать, спасибо :)
Вот и я про то, что язык «для своих целей», для своей аудитории. По сравнению с С, это прыжок вперёд, как минимум. Если бы писал на с\с++ — перешёл бы на go без особых раздумий. Но увы, это сейчас нишевые языки, и именно на это и нужно напирать в первую очередь. Тут нет ничего страшного, бороться с другими general-purpose languages очень сложно, именно поэтому нужны такие фишки, которые будут «цеплять» разработчиков. Чтобы они не просто приходя на базар, выбирали этот молоток(как инструмент) не потому, что на нём красивый лейбл Google, а потому, что он реально подходит для их особых нужд и условий труда.
Проблема в том, что все замахиваются сразу на мировое господство, Google иначе просто уже разучился метить, в этом проблема. Поиск их был лучшим не с первых дней своего существования, он стал лучшим как следствие хорошей идеологической базы + сотен итераций. Говорить, что «большая компания — большая дорога всем начинаниям» не очень верно, иначе бы все давно уже писали на C# под win или Java под *.
Вот и я про то, что язык «для своих целей», для своей аудитории. По сравнению с С, это прыжок вперёд, как минимум. Если бы писал на с\с++ — перешёл бы на go без особых раздумий. Но увы, это сейчас нишевые языки, и именно на это и нужно напирать в первую очередь. Тут нет ничего страшного, бороться с другими general-purpose languages очень сложно, именно поэтому нужны такие фишки, которые будут «цеплять» разработчиков. Чтобы они не просто приходя на базар, выбирали этот молоток(как инструмент) не потому, что на нём красивый лейбл Google, а потому, что он реально подходит для их особых нужд и условий труда.
Проблема в том, что все замахиваются сразу на мировое господство, Google иначе просто уже разучился метить, в этом проблема. Поиск их был лучшим не с первых дней своего существования, он стал лучшим как следствие хорошей идеологической базы + сотен итераций. Говорить, что «большая компания — большая дорога всем начинаниям» не очень верно, иначе бы все давно уже писали на C# под win или Java под *.
Говорить, что «большая компания — большая дорога всем начинаниям» не очень верноСогласен, не очень удачно выразился.
Я имел ввиду, что психологически выгодней смотрится язык, который «выбрала» в production большая (прогрессивная) компания. Как с Python в свое время: язык был наравне с тем же Ruby, но Гугл рассказал, что использует в своих проектах Пайтон (gmail, если не изменяет память), включил его в AppEngine, дал бесплатно открыть аккаунты и размещать на них веб-приложения и качнулась чаша весов в сторону Python. Не только из-за этого, конечно, масса факторов, и за «красивые коленки» тоже, выражаясь вашим языком.
Вот и я про то, что язык «для своих целей», для своей аудитории. По сравнению с С, это прыжок вперёд, как минимумИменно. Но уместней сравнить с Java для веб. Go уже предпочтительней смотрится, хотя бы потому, что требует меньше железа. Быстрая компиляция, отличная многозадачность.
А на универсальность он и не претендует, и первенство так и не завоюет. Тоже ниша, тоже свою задачи. И это плюс, а не минус.
Инструмент должен быть узко специализирован, универсальность чаще всего во вред.
По поводу Python + buttleneck'и на C — я согласен полностью.
Фишка Go — goroutines и channels. Что позволяет проще писать сложные асинхронные вещи.
Судя по поведению Google — Go пиарить они не собираются. Он вряд ли будет массовым и популярным, но свою нишу займет и у него уже много поклонников.
Также фишкой Go считается быстрая компиляция — это реальный плюс, понятный только тем, кто сталкивался с компиляцией крупных C++ проектов. Это позволяет работать по Agile принципу, постоянно внося мелкие изменения и постоянно прогоняя Unit-тесты.
По поводу преждевременной оптимизации я тоже согласен. Но есть такие задачи, где сразу понятно, что нагрузки будут большие и писать на Python смысла нет. Сразу на C писать? Вот для таких задач Go и подойдет. Писать приятнее, производительность приближена к C. Пример: blog.golang.org/2011/12/from-zero-to-go-launching-on-google.html
В блоге есть еще примеры успешного применения Go на практике.
Я не считаю Go языком своей мечты, не все в нем мне нравится (мой родной язык — C#). Но в целом из прямых конкурентов: C, C++, ObjC, D — он мне нравится больше других.
Ну а вообще, я наверно не очень объективен, Go мне еще и просто «нравится», что самому себе объяснить иногда не просто :)
Фишка Go — goroutines и channels. Что позволяет проще писать сложные асинхронные вещи.
Судя по поведению Google — Go пиарить они не собираются. Он вряд ли будет массовым и популярным, но свою нишу займет и у него уже много поклонников.
Также фишкой Go считается быстрая компиляция — это реальный плюс, понятный только тем, кто сталкивался с компиляцией крупных C++ проектов. Это позволяет работать по Agile принципу, постоянно внося мелкие изменения и постоянно прогоняя Unit-тесты.
По поводу преждевременной оптимизации я тоже согласен. Но есть такие задачи, где сразу понятно, что нагрузки будут большие и писать на Python смысла нет. Сразу на C писать? Вот для таких задач Go и подойдет. Писать приятнее, производительность приближена к C. Пример: blog.golang.org/2011/12/from-zero-to-go-launching-on-google.html
В блоге есть еще примеры успешного применения Go на практике.
Я не считаю Go языком своей мечты, не все в нем мне нравится (мой родной язык — C#). Но в целом из прямых конкурентов: C, C++, ObjC, D — он мне нравится больше других.
Ну а вообще, я наверно не очень объективен, Go мне еще и просто «нравится», что самому себе объяснить иногда не просто :)
Я и говорю, что нишевость это то, на что нужно делать упор. Не надо стремиться быть языком, который «люб всем», коим в свое время был С. В нем нет ничего реально «прорывного», что было в С, в свое время. Это скорее просто современный вариант С.
Быстрая компиляция — да, это хорошо. Но если учесть, что сейчас 4 ядра это уже норма, на девелоперских машинах… когда подойдёт время, чтобы Go пошёл в массы, это не будет уже значительным плюсом, определяющим фактором при выборе языка для нового проекта, согласитесь? :)
Производительность… Если говорить о серверсайде. Можно просто подбить бюджет, который понадобится на высоконагруженный проект(реально таких не так уж и много, но вдруг) и в нем внимательно посмотреть на цифры ЗП разработчикам(в городе 1м+) и расходы на железки, то станет ясно, что бюджеты могут быть вполне сравнимыми. Но только вот я, будучи начальником-бывшим-технарем, ну никогда бы не дал добро на «переписать все на Эрланге или Го», просто потому, что я знаю ТОЧНО, что в случае чего, я не смогу найти замену члену небольшой команды, которая разрабатывает продукт. Я даже скорее предпочту Java, если вся команда имеет с ней наибольший опыт(при всей моей нелюбви к этому языку, которому я отдал около 7 лет своей жизни), чем дам экспериментировать на минном поле ради выигрыша в несколько сотен баксов.
Эта моя позиция сейчас сильно отличается от 3-5летней давности, когда я был «молод и горяч», но сейчас я вполне осознаю, что прагматизм должен быть при выборе технологии. И тут аргументы типа «просто нравится» заказчику могут не понравиться ;)
Быстрая компиляция — да, это хорошо. Но если учесть, что сейчас 4 ядра это уже норма, на девелоперских машинах… когда подойдёт время, чтобы Go пошёл в массы, это не будет уже значительным плюсом, определяющим фактором при выборе языка для нового проекта, согласитесь? :)
Производительность… Если говорить о серверсайде. Можно просто подбить бюджет, который понадобится на высоконагруженный проект(реально таких не так уж и много, но вдруг) и в нем внимательно посмотреть на цифры ЗП разработчикам(в городе 1м+) и расходы на железки, то станет ясно, что бюджеты могут быть вполне сравнимыми. Но только вот я, будучи начальником-бывшим-технарем, ну никогда бы не дал добро на «переписать все на Эрланге или Го», просто потому, что я знаю ТОЧНО, что в случае чего, я не смогу найти замену члену небольшой команды, которая разрабатывает продукт. Я даже скорее предпочту Java, если вся команда имеет с ней наибольший опыт(при всей моей нелюбви к этому языку, которому я отдал около 7 лет своей жизни), чем дам экспериментировать на минном поле ради выигрыша в несколько сотен баксов.
Эта моя позиция сейчас сильно отличается от 3-5летней давности, когда я был «молод и горяч», но сейчас я вполне осознаю, что прагматизм должен быть при выборе технологии. И тут аргументы типа «просто нравится» заказчику могут не понравиться ;)
только вот я, будучи начальником-бывшим-технарем, ну никогда бы не дал добро на «переписать все на Эрланге или Го», просто потому, что я знаю ТОЧНО, что в случае чего, я не смогу найти замену члену небольшой команды, которая разрабатывает продукт.Это понятная позиция, но от этого не становится веселее. Именно в силу такого подхода LiveJournal исаользует Perl, а Facebook — PHP. И те, и другие покупают, и покупают «железо» — потому что дешевле купить серверов, чем поменять платформу.
А Твиттер взял и выбрал «инструмент» сообразно назначению. Но да, квалифицированных программистов им находить и содержать сильно дороже. Ну и что? Просто разный подход.
Именно будучи начальником-бывшим-технарём, я дал зелёный свет Go ещё два года назад. Тут как в старом мультике — «лучше день потерять, потом за пять минут долетать». Увеличивая издержки на этапе разработки (хотя, увеличенные они оказываются лишь на первых двух-трёх разработках*, после чего язык столь обволакивает, что писать на Go становится проще, чем на Python) мы радикально снижаем постоянные издержки. И именно это становится решающим конкурентным преимуществом — себестоимость наших решений оказывается в десятки раз ниже, что позволяет откровенно демпировать цены на рынке (b2b) и тихой сапой выжимать из него игроков, предпочитающих «старый добрый PHP».
* — Одна из моих любимых цитат гласит: «Скорость копипаста одинакова для всех языков программирования». Фактически, задачи прикладного программиста (не путаем с системным) сводятся к паре десятков операций, которые легко копипастить в виде сниппетов с небольшими правками. Собственно говоря, на этом принципе (DRY) основывается распространённость фреймворков.
* — Одна из моих любимых цитат гласит: «Скорость копипаста одинакова для всех языков программирования». Фактически, задачи прикладного программиста (не путаем с системным) сводятся к паре десятков операций, которые легко копипастить в виде сниппетов с небольшими правками. Собственно говоря, на этом принципе (DRY) основывается распространённость фреймворков.
А разве DRY и копипаст не антонимы?
Как посмотреть. В более широком смысле принцип «не повторяй себя» позволяет избегать повторного написания одинакового кода. А уж реализация (процедуры, классы, библиотеки, фреймворки или обычный копипаст сниппетов) — дело вкуса. Например, я не люблю фреймворки, предпочитая выдёргивать из них исключительно нужные мне куски и интегрировать со своим кодом. Это несколько олдскульный подход, но зато на выходе не получается чего-либо монстроузного в стиле Microsoft-way :)
Вам повезло с командой, все что я могу сказать :)
Ну и Вы также уже в позиции «впрягшегося», я пока смотрю с позиции «есть новый проект, есть старая команда — почему я должен выбрать Go?»
И да, я совершенно не понимаю, как себестоимость решений может быть ниже… с каких пор хорошие сишники(ведь из них собрана команда?) получают меньше за свою работу чем пхписты? Разве что вы делаете нечто ультраспециальное для числодробления, а другие участники рынка пришли из веб-дева визиток.
Про копипаст и фреймворки я тоже недопонял, как и Mrrl.
Спрошу про другое — сколько сторонних библиотек используете? Именно гошных, не на С\С++ или всё берёте из того мира? :) А может сами всё сервисное «пишете», склеивая сниппеты со стаковерфлоу? :)
Ну и Вы также уже в позиции «впрягшегося», я пока смотрю с позиции «есть новый проект, есть старая команда — почему я должен выбрать Go?»
И да, я совершенно не понимаю, как себестоимость решений может быть ниже… с каких пор хорошие сишники(ведь из них собрана команда?) получают меньше за свою работу чем пхписты? Разве что вы делаете нечто ультраспециальное для числодробления, а другие участники рынка пришли из веб-дева визиток.
Про копипаст и фреймворки я тоже недопонял, как и Mrrl.
Спрошу про другое — сколько сторонних библиотек используете? Именно гошных, не на С\С++ или всё берёте из того мира? :) А может сами всё сервисное «пишете», склеивая сниппеты со стаковерфлоу? :)
Начну с себестоимости. Наша работа заключается не только в создании корпоративных приложений, но и в их размещении и поддержке. Полный цикл, так сказать. С расчётом на долгосрочное, чуть ли не вечное сотрудничество. Таким образом, постоянные издержки (инфраструктура) становятся важнее разовых (разработка).
Сами алгоритмы не представляют из себя чего-либо сложного, так что с написанием и поддержкой десятка проектов справляется один архитектор + два обученных индуса. Опять же, компилируемый язык со строгой типизацией позволяет совершать значительно меньшее количество ошибок, которые легко плодят «недорогие» кодеры на интерпретируемых языках с duck typing.
Так что расходы на команду не превышают обычных расходов в аналогичной компании использующей Python/Ruby/Java/PHP.
А вот постоянные расходы на вычислительные мощности и их обслуживание снижаются более чем значительно.
Выше вы упомянули разработчиков веб-визиток. Так вот, если заменить язык реализации с PHP на Go, то к ужасу легиона хостеров для обслуживания всех сайтов визиток рунета и окрестностей потребуется пара-тройка серверов.
Можно даже вполне развить конспирологическую теорию на тему того, зачем Google создал такой язык с блестящими характеристиками как простоты разработки, так и производительности. Например, чтобы постепенно загрести под себя размещение всех сайтов, предоставляя конечному пользователю простой интерфейс CMS для создания магазинов, журналов и прочих стандартных сайтов, доля которых стремится к 99% от всех имеющихся в сети. Такой ход конём позволил бы им как сократить издержки на индексацию (всё же на своих «жёстких дисках» индексировать и искать куда быстрее, чем на сервере забитого виртуального хостера где-нибудь в Улан-Баторе), так и получить новые огромные объёмы пользовательских данных, столь нужных для построения гибких рекламных кампаний. Но это уж я отвлёкся, извините :)
Что касается библиотек, то мне более чем достаточно стандартного комплекта поставки. Честно говоря мне было достаточно стандартных библиотек и в Python, поскольку любое заимствование сторонних библиотек снижает уровень безопасности и повышает зависимость от их разработчиков.
Сами алгоритмы не представляют из себя чего-либо сложного, так что с написанием и поддержкой десятка проектов справляется один архитектор + два обученных индуса. Опять же, компилируемый язык со строгой типизацией позволяет совершать значительно меньшее количество ошибок, которые легко плодят «недорогие» кодеры на интерпретируемых языках с duck typing.
Так что расходы на команду не превышают обычных расходов в аналогичной компании использующей Python/Ruby/Java/PHP.
А вот постоянные расходы на вычислительные мощности и их обслуживание снижаются более чем значительно.
Выше вы упомянули разработчиков веб-визиток. Так вот, если заменить язык реализации с PHP на Go, то к ужасу легиона хостеров для обслуживания всех сайтов визиток рунета и окрестностей потребуется пара-тройка серверов.
Можно даже вполне развить конспирологическую теорию на тему того, зачем Google создал такой язык с блестящими характеристиками как простоты разработки, так и производительности. Например, чтобы постепенно загрести под себя размещение всех сайтов, предоставляя конечному пользователю простой интерфейс CMS для создания магазинов, журналов и прочих стандартных сайтов, доля которых стремится к 99% от всех имеющихся в сети. Такой ход конём позволил бы им как сократить издержки на индексацию (всё же на своих «жёстких дисках» индексировать и искать куда быстрее, чем на сервере забитого виртуального хостера где-нибудь в Улан-Баторе), так и получить новые огромные объёмы пользовательских данных, столь нужных для построения гибких рекламных кампаний. Но это уж я отвлёкся, извините :)
Что касается библиотек, то мне более чем достаточно стандартного комплекта поставки. Честно говоря мне было достаточно стандартных библиотек и в Python, поскольку любое заимствование сторонних библиотек снижает уровень безопасности и повышает зависимость от их разработчиков.
Вы действительно пишете для Go веб-интерфейсы для b2b? Мне это очень интересно, у вас есть свой фреймворк для веб?
Не рискну назвать это фреймворком. Скорее документированный (для служебного использования) конструктор. Если вы посмотрите на стандартные библитеки Go, то поймете сами — там и без фреймворков всё достаточно просто. Единственные сторонние библиотеки которые мы для себя форкнули — связки с MongoDB, CouchDB и Redis.
Кстати, если выбирать из перечисленных языков — однозначно Go, мы просто в разных областях с Вами болтаемся, но выбор в этой _нише_ действительно очевиден, в плане чисто эстетических предпочтений — полностью солидарен! :)
Решил попробовать… Скачал и поставил… Скопировал HelloWorld… Запустил… Скомпилировал. Всё ок. Всё работает… Переписал под свой стиль (переставил открывающую скобку на новую строку — не переношу египетские скобки) — не работает! Он работает только с египетскими скобками!!! Удалил. Буду дальше любить C++…
Чертовски перспективный язык. Детские болезни пока есть, но эти проблемы с производительностью вполне решаемы. Отличная замена для С, когда требуется производительность, приближенная к максимальной — отставание в 2-5 раз вполне терпимо, всяко лучше чем 50-80 раз у PHP/Ruby/Python/Perl. Причем с возрастом отставание сведется до десятков процентов, а на некоторых задачах, решаемых на С/C++ через костыли — у Go ещё и выигрыш будет (я про SMP).
Заметно, что архитекторы языка всячески пытаются облегчить жизнь программисту, причем таким способом, чтобы не пришлось об этом жалеть в будущем, т.е. добавляют в язык только эффективные с точки зрения производительности новшества. Это радует.
Расстраивает, что исключили из спецификаций ексепшны. Некоторые программисты жить без них не могут, да и по производительности не так уж сильно бьют. Исключили скорее всего из-за предполагаемой ориентированости языка на системное программирование, но все равно жаль, концепция то полезная.
Заметно, что архитекторы языка всячески пытаются облегчить жизнь программисту, причем таким способом, чтобы не пришлось об этом жалеть в будущем, т.е. добавляют в язык только эффективные с точки зрения производительности новшества. Это радует.
Расстраивает, что исключили из спецификаций ексепшны. Некоторые программисты жить без них не могут, да и по производительности не так уж сильно бьют. Исключили скорее всего из-за предполагаемой ориентированости языка на системное программирование, но все равно жаль, концепция то полезная.
Своеобразная вариаця на тему еxceptions все-таки присутствует в Go, у неё правда другое название — panic. По сути это те же exceptions, только добавленные с другой целью. «Паника» в Go это не средство сообщение об класической ошибке, для этого возвращают два значения, где второе имеет тип error, а средство сказать что все пропало, Game Over, и упасть с стек трейсом. «Панику» можно словить и обработать как класический exception с помощью defer и recover, но это желательно использовать только когда без этого не обойтись (например для того чтобы безопасно закрыть удаленны ресурс.)
Кстати, постоянно забываю упомянуть об одной интересной фишке Go. Сей язык настолько юникодовый, что на родном языке можно называть и переменные и функции. Не назову это особенно мудрой практикой, но иногда удобно в дев-версии писать код вроде:
go разобрать(фигня)
<-ФигняРазобрана
go разобрать(фигня)
<-ФигняРазобрана
Лично мне кажется, что у стихийного CoffeeScript (не смотря на то, что это JavaScript, тем более, что последний набирает обороты на фронтэнде) уже больше шансов на нормальную жизнь и развитие. Имхо: Go away!
Go - очень компактный, красивый, удобный... устаревший на 40 лет язык. По уровню развития ЯЗЫКА он стоит на том же месте, что и Си. Что неудивительно - его делали ровно те же люди ровно того же возраста. Сегодня он выглядит как идеально сделанная из шикарных материалов очень красивая, удобная и аккуратная карета в ряду звездолётов.
Отсутствие ООП и исключений это кабздец. Я прям вспомнил молодость, втыкая в каждую вторую строку val, err = func; if( err != nil ) return err;
Ну и да - писать на нём - это убивать в себе объектное мышление. Это не сильно мешает написать код, но сильно мешает его поддерживать, так как вместо ООП в коде на Go будет куча лишних вызовов подпрограмм для симуляции наследования или, что скорее всего - куча скопированного кода. Исправление ошибок превратится в ад.
Этот язык сделан для тупых разрабов, живущих близко к индийскому океану.
Насчёт скорости: все реально взрослые тесты что я нашёл показывают, что он сливает и си, и яве. Увы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Google выпустила финальную версию языка программирования Go 1