P.S.: Статья, как и большинство статей, на мой взгляд, отражает опыт и мнение автора, которое может не совпадать с вашим, и это нормально — сколько людей, столько и мнений.
Изображение взято с ресурса kirael-art.deviantart.com/art/Go-lang-Mascot-458285682
“Go станет серверным языком будущего.”?—?Tobias Lutke, Shopify
За последние пару лет произошёл мощный рост нового языка программирования: Go, или Golang. Согласитесь, ничто так не может свести с ума разработчика, как новый язык программирования. Поэтому, я начал изучать Go 4-5 месяцев назад и вот что я могу сказать о том, почему вам стоит изучить этот новый язык.
В этой статье я не собираюсь учить вас, как написать «Привет, мир!!». Есть много других статей об этом. Я собираюсь прояснить текущее состояние компьютерного аппаратного и программного обеспечения и зачем вам такой новый язык, как Go. Ведь если нет проблем, то и решения не нужны, верно?
Ограничения железа:
Закон Мура не работает.
Первый процессор Pentium 4 с тактовой частотой 3.0 ГГц был представлен ещё в 2004 году компанией Intel. Сегодня, мой Macbook Pro 2016 имеет тактовую частоту 2.9 ГГц. Таким образом, около десятилетия нет особого прогресса чистой вычислительной мощности. Ниже на графике, вы можете увидеть сравнительный график роста вычислительной мощности по времени.
По графику можно понять, что однопоточная производительность и частота процессора оставалась стабильной почти десятилетие. Если вы думаете, что добавить больше транзисторов — это хорошее решение, то вы ошибаетесь. Так происходит потому, что в более меньших масштабах начинают проявляться квантовые свойства объекта (такие как туннелирование, [или туннельный эффект. — прим.перев.]), а добавление большего количества транзисторов действительно может привести к дополнительным расходам (почему?) и количество транзисторов, которые вы можете добавить за один доллар стремительно начинает падать.
Поэтому, для решения проблемы выше,
- Производители начали добавлять больше ядер в процессор. На текущий день нам доступно 4-х и 8-ми ядерные процессоры.
- Также положено начало гиперпоточности.
- Добавили больше кэша в процессор для увеличения производительности.
Но решения выше также имеют свои ограничения. Мы не можем добавить больше кэша в процессор, поскольку кэш имеет физические ограничения: чем больше кэш, тем медленнее он становится. Добавление большего количества ядер в процессор тоже имеет свою цену. К тому же, это невозможно делать до бесконечности. Все эти многоядерные процессоры могут запускать множество потоков одновременно и это придаёт нашей картине многозадачность. Мы поговорим об этом позже.
Итак, раз мы не можем полагаться на улучшение аппаратной части, то единственный выход из этой ситуации — это более эффективное программное обеспечение. Но, к сожалению, современные языки программирования не так эффективны.
“Современные процессоры похожи на забавные автомобили, заправленные нитро, — они превосходны в гонке на четверть мили. К сожалению, современные языки программирования, как трасса Монте-Карло — полны изгибов и поворотов.”? —? David Ungar
В Go есть горутины !!
Как говорилось ранее, производители аппаратного оборудования добавляют всё больше ядер в процессор, чтобы увеличить его производительность. Все дата-центры запускаются на этих процессорах и нам стоит ожидать увеличения количества ядер в ближайшие годы. Более того, современные приложения используют множество микросервисов для поддержки соединений с базой данных, очередей сообщений и кэширования. Таким образом, разрабатываемые нами программное обеспечение и языки программирования должны легко поддерживать многозадачность (concurrency. — прим. перев.) и они должны быть масштабируемыми при увеличении количества ядер.
Но большинство современных языков программирования (такие, как Java, Python) пришли из однопоточной среды разработки 90-х. Хотя большинство этих языков поддерживают многопоточность, но реальная проблема связана с одновременным выполнением, блокированием потока, состоянием гонки и тупиковой ситуацией. Эти вещи осложняют создание многопоточного приложения на вышеназванных языках.
Например, создание нового потока в Java неэффективно использует память. Поскольку каждый поток потребляет примерно 1МБ памяти из кучи (динамически распределяемой памяти. — прим. перев.) и в итоге, если вы запустите тысячи потоков, то они окажут колоссальное давление на память и могут вызвать завершение работы приложения из-за её нехватки. К тому же, если вы хотите, чтобы два или более потока могли общаться между собой, то сделать это будет довольно трудно.
С другой стороны, Go был выпущен в 2009 году, когда многоядерные процессоры были уже доступны. Вот почему Go был создан с учётом многозадачности (concurrency. — прим. перев.). Go использует горутины вместо потоков. Они потребляют почти 2КБ памяти из кучи. Поэтому, вы можете прокручивать хоть миллионы горутин в любое время.
Как работают горутины? Подробнее: golangtutorials.blogspot.in/2011/06/goroutines.html
Другие преимущества:
- Горутины имеют расширяемые сегментированные стеки. Это означает, что они будут использовать память только по необходимости.
- Горутины имеют более быстрое время запуска, чем потоки.
- Горутины поставляются со встроенными примитивами для безопасного обмена данными между собой (каналы).
- Горутины позволяют избежать необходимости прибегать к блокированию мьютексов при совместном использовании структур данных.
- Также, горутины и потоки ОС не имеют сопоставления 1:1. Одна горутина может запускаться во множестве потоков. Горутины объединены (multiplexed. — прим.перев.) в малое количество потоков ОС.
Вы можете посмотреть отличное выступление Роба Пайка Многозадачность — это не параллелизм, чтобы более глубоко разобраться в этой теме.
Все вышеупомянутые пункты делают Go очень мощным для обработки многозадачности так же, как в Java, С и С++, и в то же время сохраняя красоту и естественность кода, как в Erlang.
Go вобрал в себя лучшее из обоих миров. Одновременно лёгкий в написании и эффективный в управлении многозадачностью
Go запускается непосредственно на железе.
Одно из самых значимых преимуществ использования С/С++ вместо современных языков, типа Java/Python, это их производительность. Потому что С/С++ компилируются, а не интерпретируются.
Процессоры понимают только двоичный код. Как правило, когда вы пишете приложение на Java или других, основанных на JVM, языках, то при компиляции вашего проекта, он компилируется с человекопонятного кода в байт-код, который понятен для JVM или другой виртуальной машине, которая запускается поверх ОС. При выполнении, VM интерпретирует этот байт-код и конвертирует его в двоичный код, понятный процессору.
Этапы выполнения кода, основанных на JVM
С другой стороны находятся С/С++, которые не используют виртуальные машины, и это позволяет убрать один этап из схемы выше, повысив при этом производительность. Происходит прямая компиляция человекопонятного кода в двоичный.
Но очистка и распределение переменных в этих языках — та ещё боль. В то же время, большинство языков программирования обрабатывают распределение и удаление объектов, используя сборщик мусора и алгоритмы подсчёта ссылок.
Go вобрал лучшее из обоих миров. Как и низкоуровневые языки, типа С/С++, Go компилируемый язык. Это подразумевает производительность, близкую к низкоуровневым языкам. Он также имеет свой сборщик мусора для распределения и удаления объектов. Больше malloc() и free()! Круто!
Код, написанный на Go, легко поддерживать.
Позвольте мне сказать вам одну вещь. У Go нет такого безумного синтаксиса, как в других языках, — всё очень аккуратно и чисто.
Разработчики Go в Google имели это ввиду, когда создавали его. Ввиду того, что у Google огромная кодовая база и над ней трудятся тысячи разработчиков, то код должен быть простым для понимания остальными разработчиками, и один участок кода должен иметь минимум побочных эффектов на другие участки. Это делает код более простым для поддержки и внесения изменений.
Go намеренно не содержит множество особенностей ООП языков.
- Нет классов. Каждая вещь делится только на пакеты. Вместо классов Go использует только структуры (structs. — прим.перев.).
- Не поддерживает наследование. Это упрощает модифицирование кода. В других языках, типа Java/Python, если класс ABC наследует класс XYZ, и вы при этом делаете какие-то изменения в классе XYZ, то это производит дополнительное изменения во всех наследованных от него классах. К тому же, без наследования, код Go становится более простым для понимания (так как нет super классов, на которые нужно обращать внимание при изучении участков кода).
- Нет конструкторов.
- Нет аннотаций.
- Нет дженериков (универсальных шаблонов. — прим.перев.).
- Нет исключений.
Вышеназванные изменения отличают Go от остальных языков и это делает программирование на нём не похожим на программирование на других языках. Вам, возможно, не понравятся некоторые пункты выше. Но это не означает, что вы не сможете написать своё приложение без этих возможностей. Всё, что вам придётся сделать, это написать лишь на 2-3 строчки больше. Но зато, с другой стороны, это сделает ваш код более чистым и понятным.
Читабельность кода против его производительности.
График выше показывает, что Go почти так же эффективен как С/С++, и имеет такой же простой синтаксис, как Ruby, Python и другие языки. Это беспроигрышный вариант (win-win. — прим.перев.) как для людей, так и для компьютера!
Синтаксис Go очень стабилен, чего не скажешь о другом новом языке Swift. Синтаксис не изменился с момента его публичного релизе версии 1.0 в 2012 году. Это наделяет его обратной совместимостью.
Go поддерживается Google.
- Я знаю, что это не совсем техническое преимущество. Но Go разработан и поддерживается Google. У Google самая большая облачная инфраструктура в мире и она всё ещё расширяется. Google создала Go для решения их собственных проблем с поддержкой масштабируемости и эффективности. С этими же проблемами вам придётся столкнуться и при создании своего собственного сервера.
- Более того, Go используется такими компаниями, как Abode, BBC, IBM, Intel и даже Medium. (Источник: github.com/golang/go/wiki/GoUsers)
Заключение:
- Хотя Go отличен от других ООП языков, это всё тот же зверь. Go предоставляет вам такую же высокую производительность, как в С/C++, высокоэффективную обработку многозадачности, как в Java и такое же удобство написания кода, как в Python/Perl.
- Если вы не планируете изучать Go, то я всё же скажу, что лимит аппаратного обеспечения оказывает давление на нас, разработчиков ПО, которые хотят писать очень эффективный код. Разработчику нужно понять железо и соответственно оптимизировать свою программу. Оптимизированное ПО можно запустить на дешёвом и медленном устройстве (типа IOT), что в целом лучше влияет на опыт взаимодействия конечного пользователя (UX. — прим.перев.).
Комментарии (321)
chemtech
18.04.2017 16:47+36Изображение «Красота и естественность кода» мне кажется очень холиварная.
Тоже самое могу сказать и про изображение «Эффективность и производительность для компьютера»
YaakovTooth
19.04.2017 02:43+8Да там вообще всё отвратительно.
Настолько, что даже читать не стал вообще.
andreymal
18.04.2017 16:53+43Go запускается непосредственно на железе
Rust тоже.
Код, написанный на Go, легко поддерживать.
Сложно назвать легко поддерживаемым код на языке, в котором можно случайно забыть написать «if err != nil». Rust за это надаёт по ушам ещё при компиляции, да даже C++ выкинет исключение во время работы.
Классов в Rust нет, наследования нет, конструкторов нет, исключений тоже нет (про остальное точно не помню)
Go почти так же эффективен как С/С++
Rust тоже
Синтаксис Go очень стабилен
Подозреваю, синтаксис Rust ещё более стабилен)
Go поддерживается Google
Rust поддерживается Mozilla и целым сообществом и используется много кем
Горутины, думаю, можно заменить на Futures и в будущем async/await.
А ещё у Rust zero-cost abstractions и отсутствие gc.
И почему же мы должны учить Go, а не Rust? :)
(на правах вброса:)
DorianPeregrim
18.04.2017 17:00-8Сложно назвать легко поддерживаемым код на языке, в котором можно случайно забыть написать «if err != nil».
Ну, вроде как, Go все же возмутится за неиспользование переменной err на уровне сборки.
И почему же мы должны учить Go, а не Rust? :)
Я думаю тут большим аргументом выступит порог вхождения в эти языки. У первого он, я считаю, на порядок ниже.
HaruAtari
18.04.2017 18:12+17Вот интересная ситуация. Низкий порог вхождения в php записывают ему в минусы и постоянно тычут этим. А у go это уже плюс. Двойные стандарты.
DorianPeregrim
18.04.2017 18:18Лично я не записывал и не тыкал, просто выразил мнение. Но Растариане не дремлют :)
DorianPeregrim
18.04.2017 18:32+4Мне б кто-то объяснил за что минусы ставят, может я бы и переосмыслил точку зрения? Не могу понять в чем я не прав.
HaruAtari
19.04.2017 01:28+3Я это не лично вам писал. Просто часто сталкиваюсь с этим доводом в обоих его представлениях. И вот стало интересно отношение аудитории к этому.
Zanak
19.04.2017 13:16Скорее порог вхождения не должен являться аргументом при рассмотрении самого языка. Например, высокий порог вхождения в Haskell совсем не делает его хуже в своем классе задач.
Логика мне видится примерно такой: низкий порог вхождения ведет к росту комьюнити вокруг языка, широкое комьюнити оправдывает использование языка в коммерческих проектах, удачные примеры проектов — потенциальные инвестиции в развитие самого языка и его экосистемы, что опять приведет к росту количества практикующих на этом языке разрабов.
zerkms
18.04.2017 23:33+1> возмутится за неиспользование переменной err на уровне сборки.
Если она была присвоена — да, а если нет — то нет.
foo()
Если функция `foo` возвращает значение типа `error`, то этот код вполне себе скомпилируется. Правда, для обнаружения таких проблем есть линтер: https://github.com/kisielk/errcheck
jetu
18.04.2017 18:56-4Все эти неоспоримые плюсы перекрывает сложность написания и сложность чтения когда на Rust. Увы, но в таком виде он не пойдет в массы, ибо Rust не для средних умов, а таких большинство.
andreymal
18.04.2017 19:06+9А это ещё целая тема для срача, минус ли «не для средних умов» или таки плюс :D
Но вообще я считаю себя весьма
посредственным«средним умом», но после питона основы раста выучил довольно легко, и в чужом коде уже доводилось копаться без особых проблем, так что возможно всё не так уж плохо)
sshikov
18.04.2017 20:41+8Знаете, я вот совсем недавно интересовался, для каких языков есть клиентские библиотеки к docker. Среди тех, что мне были интересны, были и Go и Rust.
Де факто мой практический опыт для обоих языков почти одинаков и невелик. Так вот, для меня не было никакой сложности в том, чтобы читать код на обоих. И Rust ничем тут не сложнее. Я больше скажу — думаю что для тех, кто видел java generics (или другие языки с параметризованными типами данных, скалу скажем или хаскель), или алгебраические типы, знает хоть один язык из функциональных — читать Rust значительно проще.
Ну и каждый желающий вполне может эти реализации сравнить живьем. Это тот редкий случай, когда функциональность идентична — в обоих случаях мы имеем место с клиентом для REST сервиса.
Prolych
18.04.2017 23:04Ещё бы, докер то написан на Го.
sshikov
20.04.2017 10:01+4Вы уверены, что поняли мой коммент? Клиент к докеру, написанный на Rust, не сложнее (а на мой личный вкус — проще), чем клиент к докеру, написанный на Go. То что Rust хуже
сложнее читается — в значительной степени миф. Объемы кода сопоставимые.
Так понятнее?
lain8dono
18.04.2017 19:22+13Go запускается непосредственно на железе
Rust тоже.И на голом железе без особой потери функциональности. В отличии от Go, в котором есть сборка мусора.
if err != nil
По крайней мере выдаст варнинг, если не поставить затычку.
А ещё там можно вызвать функцию от nil. И даже нормально обрабатывать это. Где-то в недрах stdlib даже используется.
конструкторов нет
Есть же. Но не как часть синтаксиса, а как часть хороших практик.
type Thing struct { a int } func NewThing() Thing { return Thing { 10 } }
struct Thing { a: isize } impl Thing { fn new() Self { Self { a: 10 } } }
При этом в rust ещё и трейт Default есть.
исключений тоже нет
Но раскрутка стека есть. В golang перехватываемая при помощи recover. В rust убивает весь поток выполнения, но из родительского потока перехватывается. При этом в последнем есть оптимизации на этот счёт.
Go почти так же эффективен как С/С++
Rust тожеRust на текущий момент лишь чуть медленнее оных (примерно на разницу между llvm и gcc/msvc и компанией).
Go не особо быстр в сравнении с фаворитами, но намного быстрее скриптовых ЯП. Он больше про экономию памяти при общем удобстве, чем про чистую скорость в отличии от.
Кстати. И у того и другого есть костыли для полуавтоматического транслирования с няшной сишечки. Иногда даже получается.
Подозреваю, синтаксис Rust ещё более стабилен)
Не на столько стабилен. Но обратная совместимость поддерживается в пределах мажорной версии. Кроме того есть достаточно годная система ввода новых возможностей в язык.
Rust поддерживается Mozilla и целым сообществом
С корпорацией добра и зла не сравнить, да.
Горутины, думаю, можно заменить на Futures и в будущем async/await.
Пф. Уже есть https://github.com/dpc/mioco А каналы в stdlib присутствуют.
А ещё у Rust zero-cost abstractions и отсутствие gc.
И
приятнаяболь от borrow-checker'а.
И почему же мы должны учить Go, а не Rust?
Сначала golang, потом rust. :3
grossws
19.04.2017 01:44+3Но раскрутка стека есть. В golang перехватываемая при помощи recover. В rust убивает весь поток выполнения, но из родительского потока перехватывается. При этом в последнем есть оптимизации на этот счёт.
Начиная с 1.9.0 не верно, можно изолировать панику не на уровне нативного потока, см. https://doc.rust-lang.org/std/panic/fn.catch_unwind.html
ozkriff
19.04.2017 07:42+1И еще всю раскрутку очень легко можно отключить через
panic='abort', так что в общем случае в библиотеке на нее полагаться тем более не стоит.grossws
19.04.2017 12:07Полагаться, ессно, не стоит. Для меня
catch_unwindактуален, чтобы не произошла раскрутка через ffi'ную границу (сишный код дёргает callback моей библиотеки, которая дёргает пользовательский callback).
lain8dono
19.04.2017 17:44Основная проблема rust — посты про него устаревают ещё до их написания. Однако и это плюс. Ибо живой язык, не слишком обременённый обратной совместимостью.
lek
18.04.2017 20:48Rust слишком многословен. Синтаксис Go действительно проще, порог входа ниже, и начать программировать на нем можно очень быстро. Когда я последний раз ковырял Rust, они постоянно что-то меняли, ломали совместимость и т.д. Не знаю, как с этим счас, это было давно. Плюс Go действительно заточен для написания приложений, работающих с сетью / микросервисов. Все, что нужно в нем есть из коробки. В прочем, в Go тоже есть куча своих проблем.
ozkriff
18.04.2017 22:06+5Когда я последний раз ковырял Rust, они постоянно что-то меняли, ломали совместимость и т.д. Не знаю, как с этим счас, это было давно.
https://blog.rust-lang.org/2015/05/15/Rust-1.0.html — 1.0 давно уже вышел, с того времени строгая обратная совместимость поддерживается.
VioletGiraffe
18.04.2017 22:27+1Осталось понять, зачем нужен Rust, когда уже есть С++ и огромное количество совместимых с ним библиотек :)
Отсутствие ООП — странное преимущество, очень странное.andreymal
18.04.2017 22:49+4C++ позволяет выстрелить в ногу, если случайно забыть про меры предосторожности. Rust позволяет выстрелить в ногу, только если явно воткнуть в код стопицот предупреждений «да, я в здравом уме и твёрдой памяти хочу выстрелить в ногу ради всегобщего блага».
А остальное касается любого другого языка, сабжа в том числе, и на ООП свет клином не сошёлся
domix32
19.04.2017 10:54+2ООП как таковое и не отсутствует. Отсутствуют классы и наследование. Вместо них трейты и композиция. Принципы ООП при этом никуда не делись.
VioletGiraffe
19.04.2017 11:07Хм, ладно. Статья обходит это стороной, и можно подумать, что в Гугл переизобрели С.
domix32
19.04.2017 22:14В статье вроде как про Go, а ваш комментарий касался Rust.
Ну и как бы основной целью ржавчинки является создание языка с полной потокобезопасностью и отсутствием утечек памяти и прочих неприятных ошибок и при этом иметь не слишком большой оверхэд во время исполнения в сравнении с теми же плюсами. В плюсах бороться с утечками даже с умными указателями на порядок сложнее. Про потокобезопасность в плюсах можно даже не начинать. Без статического анализатора такого добиться почти нереально. Зато быстро.ozkriff
20.04.2017 00:31+1основной целью ржавчинки является создание языка с… отсутствием утечек памяти
кхем, нет, с утечками железных гарантий не дают — https://habrahabr.ru/post/281370/
domix32
20.04.2017 01:47Как и прочие все же стремится к этому. Хотя не уверен, что существует даже теоретический механизм, который смог бы гарантировать полное отсутствие утечек.
VolCh
19.04.2017 12:19Наследование (на классах ли, на прототипах ли, может ещё на чём) — один из основных факторов отделяющих ООП от других парадигм.
CrazyFizik
20.04.2017 10:07Хз, наверное потому что за 30+ лет своего существования ООП так и не взлетела.
Ну реально, в мейнстримовых интерпрайз языках все что можно было запретить в ООП — запретили, все что можно было порезать — порезали, ибо
а) Наследование не работает. Ну реально, больше 2 ступенек иерархии наследования уже трудно-сопровождаемые (я как-то видел глубину наследования в 20+ классов — это был страшно), наличие наследования заметно заметно снижает скорость вызова функций (наплодить сотни тысяч и миллионов экземпляров класса СO2, который является наследником классов C и O, а те в свою очередь являются наследником абстрактного класса H и все это заставить моделировать термодинамику — увы и ах, но не получится), плюс к этому огребаем кучу неприятных моментов, как сильное связывание, хрупкие базовые классы и прочий рутинный трешняк
б) Полиморфизм тоже не работает. С множественным наследованием нас обламалали, напридумывали всяких там еретических интерфейсов. В общем ромбик уже не тру
в) Ну классы/типы вроде как какую-то пользу приносят, вот только всякие там структуры были еще задолго до этого вашего ООП
г) В принципе использование ООП несет большие накладные расходы. Сейчас правда все ошалели от гигагерцев частоты и гигабайтов памяти… в итоге требования к ресурсам растут и растут, а вот функционал — нет. Если честно в программах с HPC все кладут болт на на это ООП и переходят на композицию
Ну т.е. реально, на бумаге и когда рядом стоит умный архитектор, который сходу придумает структуру всего проекта и учтет все ньюансы, то ООП красиво выглядит, а вот когда надо выпустить совершенно новый продукт… в общем за 15 лет я еще ни разу не видел что бы ООП работало как обещали, а самые ответственные куски кода в итоге выполняются, например, как описано в этой статье https://habrahabr.ru/company/mailru/blog/319194/VolCh
20.04.2017 10:21+1в общем за 15 лет я еще ни разу не видел что бы ООП работало как обещали
А как обещали?
CrazyFizik
20.04.2017 23:09-2На XXII съезде КПСС обещали построить коммунизм к 1980 году… но коммунизм так не построили, поэтому решили изобрести ООП и сказать, что вот оно счастье. Приверженцы этой новой парадигмы обещали возможность создания повторно используемых классов и паттернов, и это звучало заманчиво. Возможность комбинировать эти классы в многократно используемые и настраиваемые бизнес компоненты казалась Святым Граалем индустрии ПО. (с — https://habrahabr.ru/post/143620/ )
Но мы не будем говорить о наступлении кодерского коммунизма, т.к. ключевые обещания: наследование, инкапсуляцию, полиморфизм и абстракцию нифига не выполняются дальше чем сферовакуумные примеры.
VioletGiraffe
20.04.2017 10:46Не работает? Вот же блин, а я-то не знал, и по наивности пользуюсь…
CrazyFizik
20.04.2017 23:10Уверены, что пользуйтесь? :-) На Smalltalk'е поднимайте здоровенные бизнес-проекты с какой-нибудь зубодробильной математикой? :-)
VioletGiraffe
20.04.2017 23:48Smalltalk в 2017 году? Увольте.
Не думаю, что древний legacy-код на Smalltalk вообще может обладать хорошей архитектурой.CrazyFizik
21.04.2017 01:36-2Smalltalk в 2017 году? Увольте.
Не думаю, что древний legacy-код на Smalltalk вообще может обладать хорошей архитектурой.
Ну т.е. Вы тока что расписались, шо чистое ООП — это УГ, и подтвердили мои слова :-)
Вы знайте, по возможностям ООП Java от Smalltalk отличается менее чем никак (на самом деле Жаба все же более куцая, в отличии от неё Smalltalk использует чистую ОО модель, компиляторщики вон говорят, что он так вообще — первый и единственный ООП язык, а они люди вумные — с ними лучше не спорить). Ну у C# правда есть еще мультиметоды — супер-достижение, которое перебивается паттерном Визитёр.
В общем, если не копаться в глубь (шо нынче не в моде), то существенной разницы не заметите:
|f| "A comment" f := Foo new: 'AString';
Foo f; // A comment f = new Foo("AString");
Разница просто гигантская, не правда ли? :-)
initReports "Initialize the list of reports by reparsing the index file." | parser | self resetReports. parser := IndexFileParser documentBase: self documentBase source: self getIndexFileStream. [parser atEnd] whileFalse: [self addReport: parser next]
/* * Initialize the list of reports by reparsing the index file. */ public void initReports(String reportBase) { IndexFileParser parser; Report report; resetReports(); parser = new IndexFileParser(getDocumentBase(), getIndexFileStream()); while ((report = getNextReport(parser)) != null) { addReport(report); } }
Ну я все-таки подскажу одно значительное отличие на котором попадаются все хелоувордщики:
|i| i := 1+(5*6).
int i; i=1+5*6;
Впрочем порой он даже более читабелен:
Rectangle width: 100 height: 200
new Rectangle(100, 200);VioletGiraffe
21.04.2017 16:17Вот ничего плохого про язык Smalltalk не хотел сказать. Да и вообще, наверное, я неправ, но у меня Smalltalk ассоциируется только с легаси-кодом, а легаси-код с большим трудом ассоциируется с хорошей архитектурой. Даже если на момент разработки в 1981-м она была хорошей.
Спасибо за примеры, интересно взглянуть на синтаксис (да, разница колоссальная).CrazyFizik
21.04.2017 18:43-1Ну как я слышал, Смоллтолк нынче больше популярен как обучающий язык программирования, т.к. все остальные ООП языки так или иначе испытывали его влияние. Но язык действительно не смог взлететь (ну по сравнению с С++, Жаба, C# и т.д.) — я хз почему, только могу предположить, мне кажется потому:
1/ Он появился слишком рано и сообщество, как и оборудование было не готово с ним работать,
2/ За этим языком не стояло никакой корпорации Зла, зато ее Жаба с ним конкурировала, я вообще про Смоллтолк узнал, когда знал уже C# (лучше бы не знал)
3/ Ну и последнее, это потому что чистое ООП оказалось не практичным и торчать в рамках одной парадигмы не тру, что С++, что Жаба, что C#, что Object Pascal — все они гибридные и мультипарадигменные языки, а в некоторых из них ООП так вообще не главное, и вероятно это не с проста.
Собственно все эти Расты, Голэнги и F# которые вообще исповедуют совершенно другие принципы появляются также не с проста. Я правда хз — взлетят ли они.
Синтаксис у Смоллтолка, конечно немного архаизмов, но в целом все тоже самое получается шо и в современных языках, некоторые вещи кажутся вполне себе даже удачными (пример с Rectangle)
Sirikid
21.04.2017 21:38Легаси это не обязательно плохой код, это всего лишь продукт, активная разработка которого прекращена. (Имхо.)
VioletGiraffe
21.04.2017 22:16Скорее, это продукт, который активно разрабатывали несколько десятков лет несколько десятков (или сотен) человек.
VolCh
22.04.2017 10:39-1Легаси — это скорее состояние кода, при котором сложно прогнозировать последствия даже минорных изменений, обычно из-за того, что не осталось в команде ни одного человека, который этот код достаточно хорошо знал.
develop7
21.04.2017 15:33OO design patterns пользуетесь? про что они вообще, замечали?
VioletGiraffe
21.04.2017 16:24Наверняка пользовался неосознанно, изобретая самостоятельно уже известные паттерны. Я просто решаю стоящие передо мной задачи способом, который кажется наиболее простым и логичным. И я хорошо понимаю, что если делать то же самое без классов и абстраций, получится неподлдерживаемый и нерасширяемый, а главное — никому не понятный, спагетти-код.
Паттерны, очевидно, про хорошие способы решения типовых задач. Вот только на практике задачи редко бывают настолько типовыми, и без доработки напильником паттерны из той книги на задачу не натягиваются.
Sirikid
20.04.2017 11:07+2экземпляров класса СO2, который является наследником классов C и O
Ну если писать вот так оно конечно не будет работать. (CO2 точно не наследовать от C и O надо.)
CrazyFizik
20.04.2017 22:59-1А от чего их надо наследовать? От Господа Бога? :-)
Впрочем их вообще не надо ни откуда наследовать, Data oriented design и композиция отлично справляется, но это уже нисколько не ООП :-)fireSparrow
20.04.2017 23:41Правильно. А класс «кошка» нужно наследовать от классов «усы», «лапа», «хвост». Но ни в коем случае не от класса «животное».
При таком понимании ООП понятно, откуда у вас такие претензии…
Мартышка к старости слаба глазами стала;
А у людей она слыхала,
Что это зло еще не так большой руки:
Лишь стоит завести Очки.
Очков с полдюжины себе она достала;
Вертит Очками так и сяк:
То к темю их прижмет, то их на хвост нанижет,
То их понюхает, то их полижет;
Очки не действуют никак.
«Тьфу пропасть! — говорит она, — и тот дурак,
Кто слушает людских всех врак:
Всё про Очки лишь мне налгали;
А проку на-волос нет в них».
Мартышка тут с досады и с печали
О камень так хватила их,
Что только брызги засверкали.
К несчастью, то ж бывает у людей:
Как ни полезна вещь, — цены не зная ей,
Невежда про нее свой толк все к худу клонит;
А ежели невежда познатней,
Так он ее еще и гонит.
sshikov
20.04.2017 21:06В иерархии классов стандартной библиотеки Java очень часто встречается многоуровневое наследование. Уровней пять могу припомнить легко. Думаю что 10 найдется.
Ну и достоверность остальных аргументов тоже слегка того… упрощаете вы. Или излишне обобщаете.
Я прекрасно помню, как выглядело скажем программирование на PL/1. Или Фортран. До ООП, в общем. И не надо далеко ходить, чтобы понять, что сегодня прикладные программисты в значительной степени занимаются тем, что собирают программы их готовых уже кусков. Не везде и не всегда — но там где это прокатывает (в первую очередь по ресурсам) — там это реально ускоряет разработку.
Так что термин "ООП не взлетело" я бы переформулировал скорее как "не смогло захватить мир". Так будет правдивее.
CrazyFizik
21.04.2017 00:40-5Вероятно просто у Оракла индусов больше чем классов, так что если кто-то что-то сломает на самом верху этой 5-и уровненной пирамидки, то они просто натравят всю эту ораву прилаживать костыли. В принципе им должно хватить всех сотрудников, шоб натравить на пирамидку из 12 ступенек наследования. А так-то большинство паттернов содержат 2-3 слоя наследования, ну было дело -пришлось как-то забацать 4 иерархии наследования (крайне специфическая задача). А все что 5+ ИМХО просто отсутствие архитектуры, клацц-клац и в продакшен, а рефакторинг для трусов, а может просто разработчики писали калькулятор для конкурса сайта http://govnokod.ru
Тем более Java наглядный пример того, что не все йогурты одинаково полезны — там вообще много чего можно и много чего есть, но это не значит что это хорошо (иногда даже об этом предупреждают) — тут даже на хабре можно много примеров найти.
Дык, на Фортране я и сейчас отлично иногда программирую — отличный язык, жалко шо бабосов стоит немерено (хотя один фиг выходит дешевле Матлаба), и при написании больших моделей выполняемых на супер-пупер-компьютерах (да и вообще для научных вычислений) выбор тут не особо велик: либо Фортран, либо Си.
Что касается того шо программисты собирают программы из готовых кусков, то эта тема не нова: злые языки поговаривают, что так и Модула умела в 70-ых года и вероятно такой подход был известен и ранее. Ну а всевозможные LAPACK, LINPACK и прочие BLAS, рожки которых торчат там где нужно выполнять операции сложнее сложения двух чисел, также были написаны на упомянутом Вами Фортране еще до того как я наверное родился (это чисто гипотеза)… не ну иногда встречаются велосипеды переписанные на Си, но без этих ваших ++ Т.е. заслуги очередной серебряной пули под названием ООП я тут не вижу.
А по поводу взлетело-невзлетело, это уже вопрос личной терминологии. И вот по-моему мнению ООП как раз таки смогло захватить весь мир: посмотрите — все мейнстримовые ЯП пытаются реализовать так или иначе ООП (мыши кололись, плакали, но продолжали есть кактус). Есть конечно небольшая группа лямбда-извращенцев, растаманов и прочих хипстеров из фанклуба Гугла, но это пока все попытки выйти из порочного круга и погоды они не делают. А вот взлететь ООП как раз таки не смогло, начиная с самого простого — любые нетривиальные абстракции текут (вроде изобретатель stackoverflow.com сказанул как-то не подумав) а дальше уже начинается… Ну или например где это ваш полиморфизм (вот только сегодня думку думал кагбэ мне написать супер-полиморфные функции, которые смогут переварить 100500 самых разных типов данных)? Мне вот нравиться как это сделано в С++ или в богомерзком Пухтоне, можно даже ромбиком наследоваться, но все кругом считают шо это не тру, поэтому давайте напридумываем всяких бесполезных интерфейсов…sshikov
22.04.2017 23:22По-моему вы путаетесь в показаниях. Либо ООП "не взлетело", либо "смогло захватить мир". Либо ничего серьезно лучше нет — либо одно из двух (с).
Да, про Оракл вы просто гоните, потому что ситуация в коде скажем Spring примерно такая же — пять и более уровней наследования даже долго искать не придется, откроете документацию — и вот оно. Не везле, далеко не везде — скажем, один класс из десятков, но такая вложенность встречается, во вполне промышленных количествах.
И я вам даже на пальцах объясню, откуда она берется — да, один паттерн это как правило 1-2 слоя, больше вряд ли. Но это совершенно не значит, что в сложном фреймворке есть только один паттерн. Вот отсюда она и берется. А вот четыре иерархии и 10 уровней наследования — это совершенно перпендикулярные вещи.
TheShock
22.04.2017 23:30+1В Unity3D мы все объекты наследуем от MonoBehaviour, который наследуется от Behaviour, который наследуется от Component, который наследуется от Object. 5 уровней, с которыми каждый день работаешь и ничего — никто не путается.
CrazyFizik
23.04.2017 02:55-2Конечно не путаются, ведь разработчики не могут добраться своими кривыми ручками до Object (внезапно), который является родителем всего и всея (внезапно). Добрые дяди уже позаботились, так что можете работать лишь с наследниками MonoBeheavor, все что выше — уже Вас не касается — это черный ящик. Правда Юнити далеко не образчик стабильности — после каждого обновления обнаруживается несовместимость со старым API, да и производительность движка оставляет желать лучшего, что кагюбэ намекает ;-)
Но в любом случае имеем в Юнити всего 4 иерархии наследования, не 5, а именно 4 — отделяйте мух от котлет, точнее говнокод от фреймоврка, вы еще посчитайте сколько иерархий наследований в сорцах ОС и тоже их добавьте ;-)
При этом: object — в принципе обязательный (без него никак), а component — необходимый для реализации игровой логики, т.к. Юнити это вообще не про ООП, там изначально используется компонентная модель, если что.TheShock
23.04.2017 07:57+2Юнити это вообще не про ООП, там изначально используется компонентная модель
С каких пор паттерн «Компонент» перестал быть ООП? Юнити очень даже про ООП.
который является родителем всего и всея (внезапно)
Внезапно, я говорил оUnityEngine.Object, а не оSystem.Object.
Правда Юнити далеко не образчик стабильности — после каждого обновления обнаруживается несовместимость со старым API
Да, если они переписывают какой-то компонент, то иногда меняется API. А вы можете привести пример, как добавить новую функциональность не изменив API?
производительность движка оставляет желать лучшего, что кагюбэ намекает ;-)
Это универсальный игровой движок, который способен выдавать 60+ fps сложной логики с физикой и рендером на слабых мобильных устройствах. О каких проблемах с производительностью вы говорите? Более производительный только Unreal Engine за счет С++, но там ровно такое же ООП.
могут добраться своими кривыми ручками
Так проблема в количестве иерархии, или в том, что «могут добраться»? Ибо если в том, что «могут добраться», то и с 1 уровнем можно добраться. Или вы думаете, что если использовать композицию вместо наследования добраться внезапно становится нельзя?CrazyFizik
23.04.2017 17:45-3С каких пор паттерн «Компонент» перестал быть ООП? Юнити очень даже про ООП.
С таких, что компонентно-ориентированное программирование это независимая парадигма программирования, которая была придумана Виртом для решения проблем внезапно возникших у ООП, и реализованная в языке, который является ОО менее чем никак
https://ru.wikipedia.org/wiki/Оберон_(язык_программирования)
Оттуда КОП ушло в ныне мейнстримовые языки и стало их частью, т.к. действительно, в большинстве случаев композиция предпочтительнее наследования. Тут же на хабре, уже ни раз обсуждали разницу между КОП и ООП.
Да, если они переписывают какой-то компонент, то иногда меняется API. А вы можете привести пример, как добавить новую функциональность не изменив API
Вот только недавно это на работе обсуждали, правда в контексте Python 2 RIP: программа написанная на С++ в 1989 году, компилится в 2017, программа написанная на C# под .NET 1.0 в 2002..2003 годах (язык был стандартизирован по ISO в 2003 вроде бы, а бета-версию вроде как опубликовали эдак в году 2001), точно также внезапно скомпилится и заработает в 2017 году. Хотя там тоже бывали костыли, например, до появления Джнерик-типов в .NET 2.0, в общем обратная совместимость худо-бедно выполняется. Хз, чего там у Жабы — не занимался такой глубокой интроспекцией в ней, но думаю худо-бедно норм.
Однако в большинстве своем все не так безоблачно.
Так проблема в количестве иерархии, или в том, что «могут добраться»? Ибо если в том, что «могут добраться», то и с 1 уровнем можно добраться. Или вы думаете, что если использовать композицию вместо наследования добраться внезапно становится нельзя?
Ну потому что, то что зарыто внутри фреймворка, разработчика уже не касается, т.к. отнаследовавшись один раз для него вот энта проблема:
https://ru.wikipedia.org/wiki/Хрупкий_базовый_класс
еще не актуальна, все что внутри фреймворка — это уже головная боль его создателей. К счастью, у них индусов (в штате, на аутсорсе, на аутстафее) вероятно больше чем классов а также есть вумные архитекторы-надсмоторщики с кнутами, так что они могут себе позволить сопровождать, поддерживать и развивать ПО где объемы наследования очень-очень велики.
Так что в условиях неограниченных ресурсов (как индусо-часы, так и ресурсы вычислительных машин) — это работает. Но у большинства ресурсы ограниченные — и тут выясняется, что сложность программы (как разработки, так и цикломатическая сложность) растет экспоненциально от глубины наследования. В тоже время какой-то учитель математики по фамилии Степанов в 3.5 написал STL, которая уже больше 20 лет успешно используется и включена в стандарт. Заранее предупрежу, что STL это тоже не про ООП, а Степановтак вообще один из самых ярых критиков ОО-подхода.
Это универсальный игровой движок, который способен выдавать 60+ fps сложной логики с физикой и рендером на слабых мобильных устройствах.
Слабое мобильное устройство — это Нокиа 1100, еще космические спутники (там до сих пор летают на 51-ой архитектуре и килобайтами памяти). А современные говносмартфоны и говнопланшеты по вычислительной мощности круче домашних писюков начала 2000-ых. К слову сказать Unreal и Quake были изначально написаны на чистом Си еще в 90-ых
Более производительный только Unreal Engine за счет С++, но там ровно такое же ООП.
Вы просто всего 2 движка знайте
… способен выдавать 60+ fps сложной логики с физикой....
Уравнения Максвелла тожее умеет решать, или кварк-глюонную плазму смоделирует? В физике там ничего особенного: коллизии, 2-ой закон Ньютона, уравнение движение и т.п. — примерно 1-ый курс… потом студенты в рамках лабораторных работ/курсовых сами пишут куда более сложные физические модели.
способен выдавать 60+ fps
Если там на сцене живет 3.5 МоноБихеавор, то да, а так:
https://forum.unity3d.com/threads/general-performance-optimization-tips-for-unity.386338/
В общем удже давно известно, что производительность и Юнити ТрыДэ это несовместимые понятия. Но Unity3D не за это любят, а за
Это универсальный игровой движок
Но за все надо платить https://ru.wikipedia.org/wiki/Технический_долг
Более производительный только Unreal Engine за счет С++, но там ровно такое же ООП.
Обычно там внутри что-то типа такого:
https://www.youtube.com/watch?v=rX0ItVEVjHc&t=270s
Что тоже не ООП. У меня вон тоже, когда говнокодю на C# начинают плодиться всякие unsafe:
public unsafe static Matrix UnsafeMultiplication(Matrix A, Matrix B) { int h = A.Height; int w = B.Width; int l = A.Width; Matrix resultMatrix = new Matrix(h, w); unsafe { fixed (double* pM = resultMatrix._matrix, pA = A._matrix, pB = B._matrix) { int indexA, indexB; for (int i = 0; i < h; i++) { indexA = i * l; for (int j = 0; j < w; j++) { indexB = j; double result = 0; for (int k = 0; k < l; k++, indexB += w) { result += pA[indexA + k] * pB[indexB]; } pM[i * w + j] = result; } } } } return resultMatrix; }
Это примерно раз в 10 быстрее чем вот такое:
public static Matrix NaiveMultiplication(Matrix A, Matrix B) { Matrix resultMatrix = new Matrix(A.Height, B.Width); for (int i = 0; i < resultMatrix.Height; i++) { for (int j = 0; j < resultMatrix.Width; j++) { resultMatrix[i, j] = 0; for (int k = 0; k < A.Width; k++) { resultMatrix[i, j] += A[i, k] * B[k, j]; } } } return resultMatrix; }
Правда unsafe это вообще не про .NET, а так — грязный трюк (да, мыши кололись, плакали, но продолжали жрать кактус). И ООП тут встречается в гомеопатических количествах, лишь при описании собственного класса Matrix. Впрочем к версии 4.5 .NET все же узнал, шо есть такая офигенная штука как SIMD (Intel Pentium MMX, 1997 год, 16кБ L1, 166 МГц), так что жить стало лучше, жить стало веселее.
Потом да, потом это все будет обернуто со стороны клиента уже в читабильный ООП-код
CrazyFizik
23.04.2017 03:12По-моему вы путаетесь в показаниях. Либо ООП «не взлетело», либо «смогло захватить мир». Либо ничего серьезно лучше нет — либо одно из двух (с).
Открою тайну — это два разных понятия, если не догадались. Что значит «не взлетело» — я пояснил, что значит «захватило мир» — я тоже пояснил, так что Ваше непонимание вызывает у меня недоумение 0_0
Да, про Оракл вы просто гоните
Т.е. Вы считайте, что у них классов все же больше чем индусов? Ну допустим.
Не везле, далеко не везде — скажем, один класс из десятков, но такая вложенность встречается, во вполне промышленных количествах.
Так не везде или все же в промышленных масштабах? Определитесь уже. Вы похоже пытайтесь выдать исключительную ситуацию за рядовую, при этом мой рекорд в 20+ иерархий наследования так и не побили. При этом я могу дать подсказку (по крайней мере для .NET), где искать большую вложенность — обычно в компонентах UI любят наплодить дофига наследников (но правда 20+ Вы там все равно не найдете), на то даже есть свои причины
grossws
23.04.2017 03:18не совсем про наследование, но про стектрейсы в JavaEE
CrazyFizik
23.04.2017 14:29-2Странно шо Вы не выложили снимок всего дампа памяти. Вы просто путайте стэк вызовов с наследованием. Можно и в Сях без всякого наследования получить не меньше, а если еще и функция рекурсивная…
Другое дело, шо как форма отражения цикломатической сложности, снимок стэка вызовов должен отразить её повышение при использовании наследованияgrossws
23.04.2017 15:44Не бойтесь, не путаю. Просто вы не осилили прочитать название спойлера.
CrazyFizik
23.04.2017 17:53-1Нет, просто я не очень понимаю:
1) Какое это имеет отношение к сабжу (если забыли, то это Go)
2) Как это имеет отношение к срачу про наследование
То что Вы осилили Java.lang.Thread.getStackTrace() меня, конечно, несказанно радует, но не обязательно об этом на каждом углу кричать? А то вдруг набижит бородатый погромист и выложит свой дамп :-)
CrazyFizik
20.04.2017 22:57-2Вброс засчитан… осталось только выяснить, шо такое Rust и использует ли его хоть кто-нибудь, кроме Мозиллы для задач сложнее ХеллоуВорлда. Я вот только про игру с таким названием слышал, но сомневаюсь, что это хоть как-то связано с этим языком, его популярностью и применимостью…
DarkEld3r
21.04.2017 13:21+2Я вот только про игру с таким названием слышал
Показательно, только не в том смысле, что ты думаешь.
CrazyFizik
21.04.2017 14:31-3Показательно это то что Rust в продакшене не используется от слова «совсем» (ну допустим «почти совсем»), по крайней мере за пределами Мозилы и 3.5 фанбоев. В то время как на сабже написан тот же Докер, а пользуются всякие Атлласианы, Адобы, АйБиЭмы и прочие Дропбоксы, даже китайцы на нем пишут — вот это показательно.
Так шо я даже хз, представляет ли слово Rust хоть какой-нибудь интерес за пределами одноименной игры :-) Вероятно нет — все его хвалят, но никто замуж не берет, пичалька :-)andreymal
21.04.2017 14:41+3и прочие Дропбоксы
Действительно
CrazyFizik
21.04.2017 16:09-2Странно, не хватает еще скриншотов с IBM, Atlassian, Adobe, ну и т.д. по списку, пичалька, ну шо Вы ей Б-г прям как маленький — ищите и обрящите: https://github.com/golang/go/wiki/GoUsers
Ссылку на rust-friends для сравнения судя по всему сами в состоянии найти ;-)andreymal
21.04.2017 16:46Ещё даже пары лет не прошло как раст релизнулся, просто не успели же ещё ничего накодить, это вам не фигак-фигак и в продакшен, ну шо Вы ей Б-г прям как маленький :)
CrazyFizik
21.04.2017 18:56Да, первый релиз спустя 5+ лет существования языка это конечно достижение :-)
Помниться мне первая версия C# появилась одновременно с появлением самого языка в 2002 году и она уже была стабильна, через год — в 2003 году — язык был стандартизирован в ISO, а в 2005 вышла уже 2.0 в которой он уже предстал полностью сформированный языком (дальше пошли свистели и переделки, да синтаксический сахар для индусов). И да, никаких проблем с обратной совместимостью (это правда не значит что хорошо использовать ArrayList!) За 15 лет существования.
Аналогично можно сказать и за Голэнг — он причем ровесник Раста, но первая версия релизнулась еще 5 лет назад :-)andreymal
21.04.2017 19:31+2Ну так результат наглядно виден: Rust намного более тщательно проработан чем Go или C# :D
DarkEld3r
23.04.2017 22:26+2Да, первый релиз спустя 5+ лет существования языка это конечно достижение :-)
Учитывая постоянные передёргивания, на нормальный ответ не надёюсь, но всё-таки. Про C# пишут, что в январе 1999 была уже сформирована команда, которая занималась языком. Причём мне что-то подсказывает, что видение конечного результата было уже сформировано. Раст же начинался как проект одного человека, язык прошёл через множество экспериментов до того как окончательно оформился. Я уж не говорю о том, что ресурсы мозиллы и майкрософта не сопоставимы.
В общем, даже если сравнивать время первого упоминания, то получается не так, как ты рассказываешь, а уж если сравнить человеко-часы, так тем более.
CrazyFizik
24.04.2017 00:11Ну вообще я об этом и говорил.
Сообществу .NET был предоставлен сразу рабочим (ну почти, где-то за год подписчики msdn получили бета-версию .NET, меня в их числе естественно тогда еще не было — я с говнокодингом на нем познакомился лишь в 2005 году), после чего он очень шустро был стандартизирован, и тут же пошел в продакшен и начал набирать популярность. Java конечно он не переплюнул, но вполне с ней конкурирует и даже вопреки политике Microsoft стал кросс-платформенным языком, да и Java куда старее и к моменту появления C# у неё уже было устойчивое сообщество погромистов. И всю свою публичную историю существования этот язык идет по пути расширения и добавления новых свистелок и переделок.
И это важно, т.к. предыстория появления языка может быть очень долгой и богатой — вообще C# можно считать потомком Delphi, создавали их одни и те же люди, вообще папа Delphi и C# — создатель компилятор Turbo Pascal, так что при желании можно отследить историю языка начиная с даты рождения Вирта. А еще у Корпорации Добра была своя Жаба.
Но вот история конкретно языка начинается все же с его обнародования и начала использования — официальная дата его рождения: 2000-ый год (я так понимаю его тогда анонсировали), а в 2002..2003 пришла Visual Studio.NET где он был. Так что история использования языка и платформы .NET начинается с 2002 года. Ясно, что до этого его упорно разрабатывали несколько лет и никому не показывали (шоб народ не спугнуть).
Причём мне что-то подсказывает, что видение конечного результата было уже сформировано.
Об этом я собственно и толкую. С видением проект у создателей Раста явно какие-то проблемы (но сейчас вроде обещают, что все стало норм), а вот у создателей его ровесника (и вероятно конкурента) — Golang, который тоже кстати показали людям до того как выкатился в релиз, с этим дело обстоит вероятно несколько лучше. С видением всяких Java и прочьих дотНетов вероятно вообще все замечательно.
Я уж не говорю о том, что ресурсы мозиллы и майкрософта не сопоставимы.
Об этом я тоже где-то здесь уже писал (Оракл и его тысячи и тысячи индусов). Впрочем я также упомянул и товарища Степанова, который с еще одним человеком написал STL. А еще вот всопмнился язык D — его тоже одиночки поднимали. Не сказать что он убер-популярный, скорее совсем непопулярный, но кое-кто им пользуется, я даже кусок живого проекта на нем видел.DarkEld3r
24.04.2017 11:03+1Ясно, что до этого его упорно разрабатывали несколько лет и никому не показывали (шоб народ не спугнуть).
Так в чём вред того, что язык показали ещё до релиза? Никто ведь, на тот момент, ничего не обещал, даже наоборот — всячески предупреждали, что использовать можно только на свой страх и риск. В итоге большинство поглядывали на прогресс с "безопасного расстояния", зато заинтересованные люди могли повлиять на конечный результат. С майкрософтом о последнем можно только мечтать.
Поэтому дорелизные события интересны исключительно как история: почему были приняты те или иные решения. Если оно кого-то пугает — ну что ж, жаль, но я точно могу сказать на своём примере, что открытый процесс разработки "некоторым" кажется наоборот преимуществом.
С видением проект у создателей Раста явно какие-то проблемы
Не очень согласен, но безотносительно этого: как по мне, лучше пусть будет много экспериментов до релиза, чем потом будет язык из стороны в сторону бросать. Интересно было бы послушать если ли какие-то претензии к языку в этом плане после версии 1.0.
Впрочем я также упомянул и товарища Степанова, который с еще одним человеком написал STL.
Ну положим они больше пруф оф концепт делали, чем конечную (современную) реализацию.
А еще вот всопмнился язык D — его тоже одиночки поднимали.
Вот мне кажется, что все эти метания с D1/D2 и фобос/деймос, в немалой степени, тому причина. И если бы они подольше подержали язык в "дорелизном" состоянии, то этого, возможно, удалось бы избежать.
DarkEld3r
21.04.2017 17:11+3Дык, изначально речь шла о том, что вообще никто кроме мозиллы не использует? Рад, что мы достигли взаимопонимания, что это неправда.
CrazyFizik
21.04.2017 19:07-3Если внимательно прочитайте, то речь шла о том, что за 7 лет существования Раста им пользуется только Мозилла, да 3.5 фанбоев — увы, но такова жестокая реальность :)
Может еще лет через 7, когда выйдет очередная «теперь точно стабильная версия» на нем и начнут что-нибудь выпиливать интересного :-)DarkEld3r
23.04.2017 22:30+2Ну то есть, все, кто перечислен в списке "друзей раста" — это те самые три с половиной фанбоя? Если так фактами оперировать, то и правда можно доказать всё, что угодно.
когда выйдет очередная «теперь точно стабильная версия» на нем и начнут что-нибудь выпиливать интересного :-)
А это к чему? С версии 1.0 совместимость вполне обеспечивается. Есть конкретные претензии или это просто сотрясание воздуха?
DarkEld3r
21.04.2017 17:09+2Показательно это то что Rust в продакшене не используется от слова «совсем»
Лично мне достаточно, что у нас есть проект на расте. Правда пока показать не могу, но относительно скоро будет выложен в опенсурс.
CrazyFizik
21.04.2017 19:40-2Ну также можно запилить проект на Брейнфаке, и это наверное будет очень показательно…
Проект на Растет и у меня был, но пока не наберется критической массы таких проектов, говорить о суперуспешности Раста в контексте Голэнга говорить несколько опрометчиво. Голэнг уже успешен, Растт — нет, он даже в 20-ку языков по версии IEEE и TIOBE не входит — гордо тусуется в компании всяких узкоспециализированных Верилогов (но им не стыдно, ибо эртээльщики народ особый и их мало), а вот Scratch входит :-)DarkEld3r
23.04.2017 22:37+1говорить о суперуспешности Раста в контексте Голэнга говорить несколько опрометчиво
А кто говорит о суперуспешности? Изначальное утверждение звучало совсем не так. Я просто хочу сказать, что на расте работу найти реально. Да, её (очень) мало, но тот самый "продакшен" имеется.
Ну и поразительная осведомлённость, как для человека, который "только про игру с таким названием слышал".
CrazyFizik
24.04.2017 00:59Ну тут гипербола. Просто оперировать «вот мы щас пилим проект на Расте и нам этого достаточно» — выглядит не совсем корректно. Я вот как-то запилил целый Asteroids на F# (самом деле XNA+C#+F#), но это не делает его языком выбора, не смотря на все его достоинства и няшность. И естественно я никому его не навязываю (не смотря на его няшность). И даже кое-что на Расте заговнокодил (есть у меня подозрение, не для того, для чего его обычно используют), что и его не превращает в язык выбора (тем более F# няшнее)…
А еще у меня в универе был знакомый который на протяжении нескольких лет запилил на асме игровой движок (ТрыДэ!) — что, конечно, круто, но не понятно, нафига это. Ну в общем хвалиться не прикольно.
Впрочем у Раста в этом плане все же дела лучше — хз на сколько, но вот про вакансии Java-программистов с опытом разработки в Rust и Golang 0_0 я уже слышал, ну и по крайней мере его хотя бы Samsung начал активно педалить. Но все равно пока это «самый любимый язык программирования на котором никто не кодит» https://stackoverflow.com/insights/survey/2016#technology-most-loved-dreaded-and-wanted
а самымой популярной технологией по-прежнему остается богомерзкий ЖабаСкрипт https://stackoverflow.com/insights/survey/2016#technology-most-popular-technologies
Хз, может он и через пару лет выбъется в топ-20 используемых языков общего назначения (и холивары Go vs Rust станут еще более острее, что не может не огорчать)DarkEld3r
24.04.2017 12:22но это не делает его языком выбора, не смотря на все его достоинства и няшность.
Почему? Если в каком-то определённом случае достоинства перевешивают недостатки, то как по мне, язык вполне можно рассматривать
Ну в общем хвалиться не прикольно.
Конкретно в моём случае ситуация несколько другая — это не я "продавил" использование раста, наоборот позвали на существующий, пусть и молодой, проект. И насколько я могу судить со своей колокольни, выбор языка выглядит вполне вменяемо: команда пока небольшая, новых людей находить удаётся, не-растовых зависимостей не особо много, сложностей с самим языком тоже не возникает.
grossws
21.04.2017 19:58+1Мы тоже пилим небольшой проектик на rust, который пойдёт в open source (под GPLv3+, т. к. samba, которая используется внизу, под GPL). Когда запилим пока неясно, т. к. висят более приоритетные задачи.
Есть ещё одна библиотека, которую я планирую нафигачить сам с перспективой использование на работе. Только там сначала надо написать dissector для wireshark'а и отреверсить протокол xD
CrazyFizik
23.04.2017 03:14-3Ок, с прожектерством разобрались, теперь ждем первого человека, кто пилил-пили и все же таки запил свой проект на Rust ;-)
grossws
23.04.2017 03:20+2Вы не осилили в поиск по гитхабу или как?
CrazyFizik
23.04.2017 20:09-1Ок Гугл, покажи мне Nelder-Mead:
Languages
14 C#
13 C++
11 Python
4 C
2 JavaScript
2 Jupyter Notebook
2 Matlab
1 Go
1 Java
1 Julia
Хм… чего-то не хватает. Ок, Гугл, нука покажи nonlinear optimization:
Languages
26 Matlab
17 C++
14 C
11 Python
6 Java
6 R
5 Julia
4 Fortran
4 Jupyter Notebook
3 Haskell
Хм… Хаскель — есть, C# — есть, Фортран — есть, Джулия — есть, Пухтон тоже есть, как и R, C/C++, C#, Java, внезапно даже сбаж [если не забыли, то говорили о Go] есть.
Хм, что я делаю не так? Ах да, точно, можно же было бы посмотреть сводную статистику, например тут https://octoverse.github.com/
Понимайте, мне нет нужды целенаправленно выискивать сорцы языка Мозиллы и прожектеров, т.к. есть 20 десятка наиболее везде-используемых языков + нишевые специализированные языки (типа Verilog или VHDL), на половине из которых я худо-бедно говнокодю. А еще на них говнокодят миллионы других людей, а еще больше пользуются их продуктами.
А вот по логике веще, что-то выискивать и показывать должны фанбои Раста. В контексте холивара я даже привел пример Докера и список компаний использующих Golang, в ответ: какие-то скриншоты и обещания: «вот мы на нем говнокодим, скоро-скоро будет релиз, и вы все офигейте».
Но вообще-то для конструктивной беседы было бы хорошо провести сравнение с языком сабжа [еще раз напомню — это Go]: какие компании пользуют, сколько выпущено реальных проектов, какой был получен перфоманс в индусо-часах при переводе проекта на этот язык, сделать разбивку по нишам и секторам, ну и провести прочий серьезный анализ. И все это даже влезет в компактную таблицу, которая будет играть явно не в пользу Rust. При этом Go и Rust вообще-то ровесники.
Может быть, когда-нибудь, когда на Марсе начнут сажать яблони (а может даже и завтра), к Rust проснется вторая волна интереса и на нем начнут массово писать, тогда да, тогда Rust будет интересен, сейчас куда более интересен тот же COBOL, например.
DarkEld3r
23.04.2017 22:38Тоже похвастаться хочется, но сдержусь до того момента как проект официально анонсируют и когда можно будет ссылку на гитхаб дать. (:
k12th
18.04.2017 16:55+23Как круто, автор наконец изобрел универсальную объективную метрику "красоты и естественности кода"! Ну вот теперь заживем, теперь-то узнаем, кто говнокодит, а кто рефакторингом занимается! Интересно, в чем она измеряется, в сусликах/1k LOC, или еще как-то? Хотелось бы так же узнать точные значения для js/perl/python/ruby и прочих неудачников из левого нижнего угла, чтоб выяснить раз и навсегда, кто наименее отстойный.
neit_kas
19.04.2017 04:32Меня особо js интересует. По каким таким критериям он попал в список красивых и естественных?
k12th
19.04.2017 09:48Вот это щас обидно было!
А вы вообще заметили, в каком месте он находится на графике?
neit_kas
19.04.2017 10:57Да, графики перепутал, но удобным и читаемым я бы его тоже не назвал бы.
taujavarob
19.04.2017 21:22но удобным и читаемым я бы его тоже не назвал бы.
К примеру, отобразите на другом языке такое лаконичное в JS:
let sobaka = { klichka: «Jim», poroda: «dog», say() {console.log( this.klichka + ":gav" )}};
sobaka.say();TheShock
19.04.2017 21:45К примеру, отобразите на другом языке такое лаконичное в JS:
C#. Никто в здравом уме, конечно, такое делать не будет:
var jim = new { Name = "Jim", Breed = "Dog" }; Console.WriteLine( jim.Name + ":woof" );
Sirikid
19.04.2017 21:58+1F#
let jim = { name = "Jim"; breed = "unknown"; say = fun self -> printfn "%s: woof!" self.name; }
тип, правда, самому придется написать.
senia
19.04.2017 23:51+2Scala.
scalafiddle.io
val sobaka = new { val klichka = "Jim" val poroda = "dog" def say() = println(klichka + ":gav") } sobaka.say()
neit_kas
20.04.2017 08:10+3Тут люди думаю достаточно привели не менее лаконичных примеров. Сам на плюсах в основном, а с его местом в том графике я вполне согласен, так что вариант от туда приводить не буду. А так, что лично мне не нравится в читаемости js:
1) Полное отсутствие типизации. Меня это дико напрягает. Это удобно в использовании, но в оочевидности.
2) Когда this может оказаться совсем не this.
3) В реальном коде в нём часто куча артефактов от html. Сам html убирается всякими библиотеками, а вот классы несколько мешаются.
4) ES6 явно позитивно не сказался на его читаемости.
Я бы его в самый низ графика ясное дело не засунул, но и в самую верхушку тоже.taujavarob
20.04.2017 21:57-5Тут люди думаю достаточно привели не менее лаконичных примеров.
Разберём эти примеры на лаконичность:
TheShock C#.
var jim = new { Name = "Jim", Breed = "Dog" }; Console.WriteLine( jim.Name + ":woof" );
Хм, зачем тут new? — И это же структура, а не объект. Не так ли?
Поэтому вам и пришлось использовать внешнюю функцию, которая никак не связана со структурой jim
Печально.
Sirikid F#
type Dog = { name : string; breed : string; say : Dog -> unit; } member self.callSay () = self.say self let jim = { name = "Jim"; breed = "unknown"; say = fun self -> printfn "%s: woof!" self.name; } jim.callSay ()
Хм, это лаконично?
Я не понял — а как jim связан у вас с «type Dog»?
Эта строка — «member self.callSay () = self.say self» — очевидно крутая, и имеет наверное какой-то смысл, но явно не лаконичный.
«say = fun self -> printfn „%s: woof!“ self.name;» — тут похоже «fun» от слово «function», но не помешало бы убрать его вообще, заменив на ().
%s глазами нужно сопоставить с self.name? Это конечно было давно придумано. Привыкнуть можно. Но и глаза ломаются, если много параметров надо в шаблон подставлять. Имхо.
Ну, ладно, я бы по лаконичности поставил этот код не на первое место.
senia Scala.
val sobaka = new { val klichka = "Jim" val poroda = "dog" def say() = println(klichka + ":gav") } sobaka.say()
Scala — это здорово. Особенно отсутствие запятых, их похоже заменяют слова «val» и «def»
А «println(klichka + »:gav")" — без лишних (обрамляющих скобок в данном случае) — это лаконично.
Так и не использование «this» в строке:
def say() = println(klichka + ":gav")
Это впечатляет, однозначно.
Слово new конечно не даёт лаконичности, но ладно. Терпимо. Имхо.
neit_kasЧто лично мне не нравится в читаемости js:
1) Полное отсутствие типизации. Меня это дико напрягает. Это удобно в использовании, но в оочевидности.
Типизация — это признак "бюрократичности" языка.
Конечно, она помогает.
Но иногда её хочется не использовать. В JS её можно применить (Flow, TypeScript — ну, это конечно, не так бронебойно как в иных языках) или нет. Выбор есть.
neit_kas2) Когда this может оказаться совсем не this.
Вот тут не поспоришь. Кое-что меняется — стрелочные функции. Но всё же тут надо думать, это верно.
neit_kas4) ES6 явно позитивно не сказался на его читаемости.
Но лаконичности добавилось. Это несомненно. Имхо, конечно, имхо (С)
P.S. и ещё пример на лаконичность (JavaScript):
var klichka = 'Jim'; var poroda = 'dog'; var sobaka = { klichka, poroda, say(){console.log(`${this.klichka} : gav` )}}; sobaka.say();
В коде создаётся объект:
Object {klichka: "Jim", poroda: "dog", say: function}
Ну, разве это не лаконичное создание объектного литерала?
(А как же лаконично выглядит сейчас выражение без "+" в console.log метода say()!)
TheShock
21.04.2017 00:51+3К примеру, отобразите на другом языке такое лаконичное в JS:
Видите ли, ваша задача в такой постановке вопроса не имеет смысла. Даже когда я пишу на JS — я не пишу такой плохой код, ибо пускай он лаконичный — он:
1. Не имеет смысла в таком виде (например, зачем тут вообще использовать метод?)
2. Не расширяется.
Так что на любом языке задачу в такой постановке можно записать очень кратко:
Console.WriteLine("Jim:gav")
Вопрос обычно к реюзу кода, а тут что в JS, что в C# код будет приблизительно одинаковый и все более выравниваться с увеличением кодобазы.taujavarob
21.04.2017 22:49-4Так что на любом языке задачу в такой постановке можно записать очень кратко:
Я привел пример лаконичного создание объектного литерала и вызова у него метода.
Я это выше выделил и не раз.
Остальные либо не привели ничего такого, либо, как вы, не поняли, что же нужно привести в пример лаконичного.
Ну, а что касается С# — возможно это и лаконичный язык, но пока это не видно мне, но зачем его вообще придумали я даже не знаю (он же "улучшатель" Java, не более того).
TheShock
22.04.2017 00:02+1Понимаете ли, вы ставите ненужное в программировании условие.
Вот давайте я вам приведу пример шоковицкого (от моего никнейма) куска кода на C#:
public class Progression { public readonly int Time; public int Progress { get; private set; } public bool IsReady { get { return Progress >= Time; } } public Progression () { Progression(0); } public Progression (int time) { Time = time; Progress = 0; } }
Видите, как шоковицки у меня получилось? Просто 10 из 10. Попробуйте повторить на JS! И как только у вас на JS получится так же шоковицки, то я обязательно вам напишу лаконично все, что захотите.
Конечно, данная метрика никакого отношения к практическому написанию кода не имеет. Как и ваша, впрочем.
senia
22.04.2017 12:23Создание объекта без формализации его контракта — занятие в общем случае бесполезное.
И в JS для этого раньше использовались методы-конструкторы. Сейчас появился синтаксис с классами, а ещё лучше — полноценная типизация с Flow.
В этом отношении мой пример на Scala был призван продемонстрировать то, что на других языках так не пишут не потому, что так не получится, а потому, что бесполезно. И лаконичными делают на этих языках полезные конструкции. Но иногда, как на Scala, и бесполезные конструкции случайно оказываются лаконичными. Не стоит из этого делать далеко идущие выводы.taujavarob
26.04.2017 16:22-4senia >
В этом отношении мой пример на Scala был призван продемонстрировать то, что на других языках так не пишут не потому, что так не получится, а потому, что бесполезно. И лаконичными делают на этих языках полезные конструкции
TheShockКонечно, данная метрика никакого отношения к практическому написанию кода не имеет. Как и ваша, впрочем.
«Сражение в Фермопилах было выиграно персидским царём Ксерксом, но… известен лаконичный ответ царя Леонида на предложение сложить оружие в обмен на жизнь: «Придите и возьмите»» (Википедия)
Так что полезность (практичность) и лаконичность — это перпендикулярные понятия. (С)
TheShockВидите, как шоковицки у меня получилось? Просто 10 из 10. Попробуйте повторить на JS!
Повторить что? Ваш совсем не лаконичный код что делает то?
P.S.
Пример на JS лаконичной, но по мнению автора этих строк — «сонной сортировки» — "sleep sort")
var numbers = [7, 1, 77, 15, 145, 9, 5]; numbers.forEach( num => { setTimeout(() => {console.log (num)} , num); });
Разве это не супер! ;-)codemax
26.04.2017 16:39+4Нет, не супер. Все эти дрочерства на призрачные и в общем случае не самые полезные метрики типа «лаконичность» и «смотри как я могу» обычно заканчиваются трудночитаемым и трудноподдерживаемым кодом.
Azoh
27.04.2017 08:01+4Мне кажется, вы лаконичность с краткостью спутали. Лаконичный ответ Леонида содержит много смысла в малом количестве слов. А ваш "лаконичный" код содержит только глупую шутку в стиле "смотри как я могу".
taujavarob
27.04.2017 16:45-1Мне кажется, вы лаконичность с краткостью спутали. Лаконичный ответ Леонида содержит много смысла в малом количестве слов. А ваш «лаконичный» код содержит только глупую шутку в стиле «смотри как я могу».
Сами понимаете, что отличие пошлого(или глупого) анекдота от остроумного — оно не в количестве текста анекдота, а в голове внимающего, хотя всё же «Скверный анекдот» — это рассказ.
Что касается JS — то он и был фактически создан для лаконичного написания кода, выполняющегося в броузере, в отличии от развесистого синтаксиса Java и прочих подобных языков.
codemaxНет, не супер. Все эти дрочерства на призрачные и в общем случае не самые полезные метрики типа «лаконичность» и «смотри как я могу» обычно заканчиваются трудночитаемым и трудноподдерживаемым кодом.
На любом языке можно написать трудно читаемый код. Но есть языки на которыхнельзятрудно написать лаконичный код.
intsurfer
18.04.2017 16:55+2а что у Go с поддержкой GTK3? Гугл сказал, что пока не очень. Может я и ошибаюсь. Но переписывать все под другой язык, только потому, что он лучше, как-то влом…
Gemorroj
18.04.2017 17:13+14Может я такой нулёвый, но мне кажется, что с этим багажом:
Нет классов.
Не поддерживает наследование.
Нет конструкторов.
Нет аннотаций.
Нет дженериков (универсальных шаблонов. — прим.перев.).
Нет исключений.
сложно будет написать поддерживаемый код.
Хотя если развить мысль «Go станет серверным языком будущего», в направлении, что всё уйдет на клиент и у нас будет огромный объем клиентского кода на js, и тоненький бэкенд на go, то все может быть =)andreymal
18.04.2017 17:16+3Например, в Rust для всего этого предоставлены довольно удобные альтернативы, которые юзать иногда таки сильно проще чем классическое ООП (композиция, типажи, функции у структур (не экземпляров), Option/Result, замыкания итп), возможно в Go тоже что-то такое есть
MacIn
18.04.2017 17:18+3Нет, позвольте, но и до эпохи ООП можно было писать поддерживаемый код. Да, написать мусор в процедурном стиле легче, но это же не требование. Не баг, а фича.
Вот по дженерикам да, плачу и мечтаю.
kx13
19.04.2017 10:20тоненький бэкенд на go, то все может быть
Естественно, если программа занимает строчек 100-200 кода, то все вышеперечисленное конечно не нужно (можно легко без этого обойтись).
Поэтому если применять Go там где ему место, то все будет отлично.
Чем проще синтаксис тем лучше подходит язык для узкой ниши для которой этот синтаксис задуман.
Чем более богат синтаксис, тем более универсален язык, но и писать на нем не так удобно, зато можно сделать большее. Эдакая диалектическая борьба простого со сложным.
В этом плане отличный пример — это язык HQ9+
Писать на нем программу типа "Hello world". Очень просто и удобно. Никто на нем микросервисы писать не будет.
Ну и на Go не надо писать огромные программы, где все ограничения языка очень быстро вылезут наружу.
MacIn
18.04.2017 17:16+1Горутины сжаты (multiplexed. — прим.перев.) в малое количество потоков ОС.
multiplexed это не «сжаты». Я бы сказал, что это «распределены» в данном контексте.
Гошники, или как правильно? К вам вопрос: это по сути пул worker-thread'ов, которые выполняют поток команд в легковесных нитях?
sefus
18.04.2017 17:48Смысл в том, что N горутин выполняется в M потоков ОС, где число M обычно гораздо меньше N. Поэтому происходит объединение нескольких горутин в один поток.
MacIn
18.04.2017 18:27Это и есть мультиплексирование, тут все понятно. «объединение» означает все равно последовательное выполнение, верно? Это означает что вот эти вот горутины стоят в очереди на выполнение этим потоком. Или другим. Нет?
sefus
18.04.2017 19:44+1Да, в оригинальной статье так и сказано, что они мультиплексированы. Про сжатие автор сам придумал.
KarafiziArthur
18.04.2017 20:27-3Спасибо за замечание, поправил. Мультиплексированы — для новичков было бы непонятно, думаю. Поэтому заменил на близкий по значению термин (со сноской на оригинальный термин для продвинутых).
MacIn
18.04.2017 17:22+1Вышеназванные изменения отличают Go от остальных языков и это делает программирование на нём не похожим на программирование на других языках
Я бы сказал, что это делает его современным BASICом, в хорошем смысле. Низкий порог вхождения, богатая библиотека, возможность быстро сделать серьезную вещь.
boblenin
18.04.2017 17:34+4он компилируется с человекопонятного кода в байт-код, который понятен для JVM или другой виртуальной
машине, которая запускается поверх ОС. При выполнении, VM интерпретирует этот байт-код и конвертирует его в
двоичный код, понятный процессору.Серьезно? А пацаны-то (James Gosling) думали, что там JIT compiler.
kishchenko
18.04.2017 17:42+9Не поддерживает наследование.
Нет конструкторов.
Нет аннотаций.
Нет дженериков (универсальных шаблонов. — прим.перев.).
Нет исключений
Я бы сказал, что это именно минусы, причем очень и очень существенные.andreymal
18.04.2017 17:44+1Если есть альтернативы, это может быть и плюсом, не стоит подпускать ООП головного мозга)
Siemargl
18.04.2017 22:20+5Вообще то наличие корутин и отсутствие вышеперечисленного весьма напоминает Active Oberon
Он не взлетел, может потому что его Гугл не пропихивал?
Goodkat
18.04.2017 17:43+11Я знаю, что это не совсем техническое преимущество. Но Go разработан и поддерживается Google.
Это можно отнести и к недостаткам, см. кладбище Google.
Scf
18.04.2017 17:44+10"Go быстрый" — сомнительно мне очень
"Go простой" — слишком простой, я бы сказал.
И не указаны уникальные преимущества этого языка:
- очень быстрая компиляция, значительно облегчающая TDD/turnaround
- очень быстрый старт приложений (привет, Java!)
- компиляция в единственный бинарник, что упрощает деплоймент
- очень хорошая поддержка модульности вкупе с очень простым языком позволяет натравить на один проект орду миддлов с шансом на успех
Free_ze
18.04.2017 19:39+2компиляция в единственный бинарник, что упрощает деплоймент
Кто сейчас так не умеет? Динамическая линковка — это, как правило, фича.VolCh
18.04.2017 20:19Джава разве умеет создать один бинарник со всем своим рантаймом?
YourChief
18.04.2017 23:14С рантаймом не умеет, но JAR-файл со всеми зависимостями получить можно. Очень удобно.
VolCh
19.04.2017 06:28+1Очень удобно получать именно единый бинарник, который достаточно скопировать на целевую систему с голой ОС, ничего на ней не устанавливая.
bat
19.04.2017 07:38-1Добавлю, что Go-приложение (при определенных условиях) может запускаться в докер-контейнере без ОС (FROM scratch).
grossws
19.04.2017 12:13+3Мало-мальски нетривиальное потащит за собой libpthread, libc, linux-vdso.so, ld-so.
bat
19.04.2017 12:33все верно
$ go build
$ ldd main
linux-vdso.so.1 => (0x00007fffd4bf7000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fc4679b7000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc4675f0000)
/lib64/ld-linux-x86-64.so.2 (0x000055cfc4c89000)
но, при определенных условиях это не так
$ CGO_ENABLED=0 GOOS=linux go build -ldflags "-s -w" -a -installsuffix cgo
$ ldd main
не является динамическим исполняемым файлом
Pro-invader
19.04.2017 11:33Это не то?
http://docs.oracle.com/javase/8/docs/technotes/guides/deploy/self-contained-packaging.htmlVolCh
19.04.2017 13:10Типа того, только не каталог или инсталлер, а просто один бинарник. Наверное можно организовать.
Pro-invader
19.04.2017 13:47Можно.
Есть такая программа launch4j
А тут как сделать с помощью ее один .exe-файл (упаковать свой .jar-проект и JVM, чтобы Ваш проект мог запускаться и работать без предустановки JVM).
http://stackoverflow.com/questions/7071133/how-to-bundle-a-jre-with-launch4j/7582064#7582064
Scf
18.04.2017 23:11-1java, .NET, python...
Free_ze
19.04.2017 11:08+1Java собирается в {J,E,W}AR-пакеты. Аналог в .NET — сборки, в которые помещаются логические единицы — модули.
То есть собрать в один файл все добро со всеми зависимостями — это не проблема, чаще же напротив, для гибкости (релиза, деплоя) и модуляризации стремятся разнести по разным сборкам различные компоненты. Пример такой идеологии — .NET Core, представляющий собой (в перспективе) аналог огромного во многих частях монолитного .NET Framework.
sshikov
22.04.2017 23:40+3Опять эти сказки. В который уже раз — JVM стартует быстро. Я уже как-то демонстрировал, что маленькие классы на groovy, которые делают примерно следующее:
- сконнектиться к JMX порту
- взять там некие метрики процесса
- обработать все это, и отдать скажем в Nagios (просто записать в файл)
Так вот это вот все отрабатывает меньше чем за секунду, если JMX порт локальный, и сервер отвечает тоже быстро. Т.е. JVM успевает за секунду запуститься, отработать класс, и завершить работу.
А медленный старт — это медленный старт приложений. Самих.
Что до поддержки модульности — то извините, но это мимо. Есть множество языков, где с этим намного, намного лучше. Скажем, все языки из мира JVM — ну просто потому, что модули уже собраны, под любую платформу, лежат в стандартном репозитории мавен централ, с известным API, в общем — вокруг этого есть инфраструктура.
А что взамен мы видим у Go? Guthib? Ну это как бы не самое плохое решение, но далеко не самое универсальное. Понятно, что у языка компилируемого в бинарник под конкретную платформу, с этим все сложнее by design, но тем не менее факты налицо.
Кстати, что там с работой за файрволом? Вот в случае maven, скажем, в 99% случаев достаточно завести внутренний репозиторий, и переключить всех клиентов на него (одним пинком ноги). А что делается в случае go get, если вы в интранете?
Scf
23.04.2017 07:37Сама jvm стартует быстро, да. helloworld запускается меньше, чем за миллисекунду. Но загрузка и JIT занимают существенное время и способа написать на java большое быстро стартующее приложение нет. Предкомпиляция в java9 может улучшить ситуацию, но не принципиально — она выдает на выходе объектники в 100-200 мегабайт.
sshikov
23.04.2017 09:27Ну так давайте формулировать преимущества как-то более корректно что-ли?
А то я могу написать примерно так: запускаем (написанный на Go) docker что-нибудь, а он, собака, отрабатывает сто лет. А почему? А потому что нужного нам image не оказалось в наличии, и мы пошли его загружать, а registry медленный, потому что интернет, а диски тоже не очень быстрые, ну и пошло-поехало. Вывод — Go медленный, не? )))
Поэтому все эти оценки — они слишком субъективные (хотя и не кажутся такими на первый взгляд). И реально сделовало бы оценивать с учетом архитектуры, оптимальной для каждого случая.
Хотите быстрый старт в Java? Сделайте так, чтобы JVM вообще не поднималась, а была запущена всегда. Так можно, и так делается легко — таких приложений множество.
Хотите продемонстрировать реально быстрый старт приложения на Go (а не просто какого-то мелкого бинарника) — покажите реальное приложение, которому нужна куча ресурсов (скажем для UI, картинки всякие, шрифты, и прочие разности) — и посмотрим, сколько времени оно это будет загружать с диска, и насколько у него эффективные механизмы для этой цели.
В общем, суть вопроса в том, что вы упрощаете, формулируя преимущества. Не сильно, но тем не менее.
компиляция в единственный бинарник, что упрощает деплоймент
А представьте, что у вас много хостов разной архитектуры (ну например, вы деплоитесь на смартфоны). Вы все еще уверены, что единственный бинарник упрощает задачу деплоймента, а уже не наоборот?
Scf
23.04.2017 11:54Какая уж тут субъективность :-)
На JIT языках без предкомпиляции нельзя писать приложения с быстрым стартом, а на компилируемых языках можно. Вот и вся разница.
Быстрый старт, как правило, нужен в двух случаях — тяжелые утилиты командной строки и GUI приложения. Если в первом случае оставлять экземпляр в памяти после завершения выполнения имеет смысл, то во втором — значительно страдает UX, т.к. юзер либо долго ждет первого запуска, либо приложение загружается при старте системы — замедляя загрузку и потребляя память.
Я имел в виду отсутствие зависимостей, которые нужно ставить на целевую систему. Давайте оставим в покое телефоны, у них свой подход к деплойменту. У Go немного другая сфера применения.
sshikov
23.04.2017 12:17Про телефоны я просто для ясности — очевидно что бывают такие случаи, когда мы разворачиваемся на разных устройствах, с разной архитектурой, и нужны как разные бинарники, так и разные ресурсы. И тут такое свойство, как "компиляция в единственный бинарник" вовсе не очевидно, что реально упрощает деплоймент. Скорее наоборот. Сказать, что это не сфера применения Go — ну это же не ответ, очевидно.
А про быстрый старт… ну вот смотрите — любой GUI на базе web, для простоты, как пример. http сервер запущен, и всегда готов к работе. Время его старта никого никогда не волнует. И это с таким же успехом может быть тяжелый сервер типа вебсферы, или легкий и примитивный, потому что критерии быстроты тут уже другие.
Это к тому, что архитектура, обеспечивающая быстрый старт, она просто должна учитывать, что именно нужно пользователю.
aynanenane
18.04.2017 17:57+3Первое же ограничение железо — «Закон Мура не работает.»
Это почему оно не работает? Собственно, в ссылке автора на закон в первых же строках:
«He noticed that the number of transistors per square inch on integrated circuits had doubled every year since their invention.»
Мур ничего не говорит про тактовую частоту. Он говорит о плотности транзисторов.
Первый процессор Pentium 4 с тактовой частотой 3.0 ГГц был представлен ещё в 2004 году компанией Intel. Сегодня, мой Macbook Pro 2016 имеет тактовую частоту 2.9 ГГц
Да, частота меньше. Но сколько ядер в процессоре Macbook Pro 2016 и сколько ядер в Pentium 4. При этом размеры процессоров одинаковы.Pakos
19.04.2017 11:50А ещё производительность на гигагерц на ядро выше, потому меньше тепла при той же полезной работе. Попробовал бы автор поставить P4 в свой ноутбук. Помимо SpecINT есть и другие тесты и там хорошо виден рост за десяток лет.
Shatun
18.04.2017 17:58+9мне очень нравится в этой статье «удобство и читабельность кода», где js выше джавы, го и на уровне питона)
«При этом красота и естественность» у джса, с++, джавы и питона одинаковая и сильно проигрывают с#)evocatus
19.04.2017 12:13Я так понимаю, что автор оценивал «простоту и естественность» при использовании concurrency.
Sirikid
18.04.2017 18:01+16Но большинство современных языков программирования (такие, как Java, Python) пришли из однопоточной среды разработки 90-х.
…
С другой стороны, Go был выпущен в 2009 году, когда многоядерные процессоры были уже доступны. Вот почему Go был создан с учётом многозадачности (concurrency. — прим. перев.).Тогда каким образом объясняется создание таких языков как Ada и Erlang в середине 80-х годов?
Горутины имеют более быстрое время запуска, чем потоки.
Также, горутины и потоки ОС не имеют сопоставления 1:1. Одна горутина может запускаться во множестве потоков. Горутины сжаты (multiplexed. — прим.перев.) в малое количество потоков ОС.Ну тредпул же, файберы и так далее.
Горутины поставляются со встроенными примитивами для безопасного обмена данными между собой (каналы).
Но не обязывают их использовать.
Горутины позволяют избежать необходимости прибегать к блокированию мьютексов при совместном использовании структур данных.
Это каким образом?
ПолыханиеНет конструкторов.
Отлично, правда если мы хотим проинициализировать поля значениями, отличными от дефолтных, мы должны либо копировать постоянно код инициализации структуры, либо выносить его в функцию. И, конечно, мы не в коем случае не будем называть такую функцию конструктором.
Нет аннотаций.
https://golang.org/ref/spec#Tag
Нет дженериков (универсальных шаблонов. — прим.перев.).
Нет и системы типов.
Нет исключений.
Как и других типов-сумм, вместо них, какая ирония, мы используем типы-произведения.
KarafiziArthur
18.04.2017 19:29+3Спасибо за комментарий. Я в начале написал, что статья (оригинальная) — это отражение опыта и мнения автора, защищать или опровергать его я не могу. Вполне возможно, что вы гораздо опытнее автора.
Sirikid
18.04.2017 19:45Зачем тогда переводить?
KarafiziArthur
18.04.2017 20:05По Go мало вводных статей на русском. На мой взгляд, эта статья стоит перевода. Она хоть и содержит субъективную оценку, но также содержит и моменты, на которые стоит обратить внимание в начале его изучения.
codemax
19.04.2017 09:53+7По Go прям много таких статей на русском, в том числе и на хабре. И очень многие из них содержат «субъективную оценку» в виде «смотрите, какой он крутой, вы непременно обязаны его изучить».
Возможно даже (не берусь утверждать на 100%), что ни про какой другой язык здесь не выходило такого количества однообразно оформленного восхищения.
sshikov
18.04.2017 20:50+4Тогда каким образом объясняется создание таких языков как Ada и Erlang в середине 80-х годов?
Ой, да бросьте. Это не более чем малограмотный вброс. Вы бы еще спросили, зачем в Java класс Thread, с первой версии (а это 1996 где-то). А еще средства координации потоков, разнообразию которых Go может только позавидовать белой завистью.
Sixshaman
18.04.2017 18:45+6Go
Красота кода
Выберите что-то одно.
А если серьёзноКрасота — понятие крайне субъективное. Поэтому приводить в качестве важного свойства языка «красоту» кода на нём неправильно. У меня, например, глаза вытекают, если я вижу фигурные скобки на той же строке, что и условие. При этом WinAPI-код с его капсом и венгерской нотацией у меня вызвывает восхищение.
Пожалуйста, перестаньте оценивать языки по субъективным критериям. На любом языке можно сделать как и совершенно нечитаемый, так и наглядный код. Не постите больше подобных графиков. Хотите сравнить языки — пишите об особенных фичах и как их использовать.dimack
18.04.2017 18:54+6Не поддерживает наследование. Это упрощает модифицирование кода. В других языках, типа Java/Python, если класс ABC наследует класс XYZ, и вы при этом делаете какие-то изменения в классе XYZ, то это производит дополнительное изменения во всех наследованных от него классах. К тому же, без наследования, код Go становится более простым для понимания (так как нет super классов, на которые нужно обращать внимание при изучении участков кода).
Т.е. повсеместно будет использоваться агрегация и изменения класса XYZ коснуться всех классов, которые содержат XYZ… так в чем тут преимущество у Go?
Вообще, статья про то как превратить особенности языка в его сплошные преимущества.TheShock
18.04.2017 19:46+11превратить особенности языка в его сплошные преимущества
Именно
«Общеизвестно, что поворот налево — опасный маневр, потому создатели автомобиля Гоу использовали гениальное решение — автомобиль может поворачивать только направо, а при необходимости повернуть налево — просто поверните направо трижды. Одного этого факта достаточно, чтобы понять, насколько Гоу лучше других автомобилей!»
astec
18.04.2017 19:23+2Перешёл с Python на Go, не понимаю почему на диаграмме Python в нулях по красоте и естественности кода?
nightwolf_du
18.04.2017 19:54-2Может, потому что в нем невидимые символы являются значимыми лексемами?
Вообще диаграмма крайне холиварная, в отношении того же erlang. (например строка = список чисел).
С производительностью тоже не всё в порядке — все интерпретируемые языки на картинке по оверхеду самого языка на производительность плюс-минус однохренственны, больше зависит от решаемой задачи и используемой библиотеки.andreymal
18.04.2017 20:02-2невидимые символы являются значимыми лексемами
Только в начале строки. А так как все всё равно форматируют код лесенкой, это не является проблемой
nightwolf_du
18.04.2017 20:20+2Это не проблема, но табы против пробелов могут доставить боль. А выглядят много где одинаково.
А влияние форматирования на интерпретацию — крайне холиварная тема.andreymal
18.04.2017 20:22-1Это да. Но pep8 настаивает на чётырёх пробелах, подключаем pylint для проверки сего и можно жить
grossws
19.04.2017 01:56Pre-commit хук и/или линтер на CI-сервере снимают проблему. Когда смесь табов и пробелов (очевидно, подавляющее большинство языков) не влияет, в коде средних и крупных проектов рано или поздно появляется каша, если нет явного битья по пальцам за несоблюдение code style. Наблюдаю во многих open source проектах, например.
nightwolf_du
20.04.2017 10:15Да проблема не в репозитории и правилах, когда есть большой проект — правила форматирования всё равно рано или поздно накатываются.
Проблема больше во всяких мини-скриптах, небольших чужих приложения ( например, игрушки на питоне) — там, где ты редактируешь код быстро, и чаще всего — не из родного редактора.
Значимость невидимых на письме символов при компиляции — расходится с практикой естественных языков, не самая ожидаемая для человека вещь.
pawlo16
18.04.2017 19:31Я уже примерно 2 года как Go-пник. И мне это постепенно начинает нравится чорт вазьми! несмотря на все минусы, там реально всё проще, тоньше и быстрее в итоге — деплой, сопровождение, инструменты.
Все эти баги с мьютексами и "if err==nil" (и проч, что обычно приводят в доказательство ущербности go) на самом деле легко обнаруживаются при наличии минимальных юниттестов. Ну и стат.типизация даже без джененриков после петона и похапе — щастье же.
По поводу rust. Представим гипотетическую ситуацию, при которой коллективу кодеров приказывают на него перейти с условного жабопетона — взвоют. Go — поноют немножко, и будут кодить как ни вчем не бывало.
Idot
18.04.2017 19:40+1Посмотрел вакансии в родном городе, нашёл две вакансии по Go:
- одна с очень большим разбросом зарплат от джуниора до сеньора, требует Go, Python, Java и Scala
- другая с очень большой зарплатой, с требованием помимо Go знать ещё и PHP
VolCh
18.04.2017 20:25Вторая, вероятно, связана с переписыванием чего-то с PHP на Go. Либо, как вариант, бэкенд в целом на Go, а PHP — шаблонизатор. Третий вариант, приходящий в голову, наоборот требования подразумевает — главное надо знать PHP, но ещё и Go для какого-нибудь веб-сокет сервера.
ArsenAbakarov
18.04.2017 19:57+9Хочу статью " Почему вам не стоит изучить Go?"!!!
TyVik
18.04.2017 22:56+13Ловите подборочку: Что бы я изменил в Go, Почему Go не так хорош, Почему Go — плохо продуманный язык программирования, 50 оттенков Go. Последнюю особенно рекомендую — вообще непонятно зачем так язык проектировали.
dplsoft
19.04.2017 01:34+3Скорее не «непонятно зачем так язык проектировали», а «непонятно как его так спроектировали» )
Спасибо за подборку!
VolCh
18.04.2017 20:28+2Язык в настоящее время мало что значит для массовой разработки. Главное, его экосистема — библиотеки, фреймворки, вот это всё. Упускать это из обзора — или не понимать, что нужно от языка массовой разработки, или умалчивать скудность экосистемы.
sshikov
18.04.2017 20:54Сорри, промахнулся и поставил минус. А хотел плюс.
Очень хороший пример, кстати, средства работы с базами данных в стандартной библиотеке, и наличие драйверов под все известные базы.
bat
19.04.2017 07:58+1По мне так интерфейсы для работы с БД не очень.
sshikov
20.04.2017 10:06+1В смысле у Go? Мне они показались наиболее рабочими. После Java и .Net, скажем так, у которых пожалуй есть драйверы под все базы вообще, и API наиболее полноценный.
bat
20.04.2017 11:08+2А мне не очень. API довольно таки скудный.
Да, универсально, пул под капотом, потокобезопастность тоже…
с другой стороны (это то что наболело)
— пул плохо настраивается, макс кол-во соединений и макс. кол-во простаивающих соединений и все, а я бы хотел задать мин. кол-во простаивающих соединений, кол-во соединений при старте, чтобы не ждать пока соединение откроется
— средств профайлинга нет. измерить время выполнения запросов можно и снаружи, а вот какие затраты были на установку соединения при вызове db.Query и были ли вообще — непонятно
— следствия универсальности: нет доступа к спец. возможностям субд, нельзя получить из пула соединение. Даже если разработчик драйвера предоставит методы для работы с API, то надо предоставлять механизмы для создания соединений и отдельный пул, т.к. к стандартному доступа нет. А если такое случится, то нафига тогда database/sql/
— с логированием, если ошибаюсь, тоже никакsshikov
20.04.2017 11:29Ну, если сравнивать с JDBC — то да, вы правы. Причем я бы так сказал — компилируемый язык, без VM, инструментировать код наподобие того, как делается в мире JVM, чтобы добавить профайлинг или логирование уже после разработки — это вряд ли.
Но если сравнивать например с Python, где драйвер MS SQL урезает строки до 100 — это все-таки более рабочее решение.
taujavarob
18.04.2017 21:08+7Не поддерживает наследование.
Нет конструкторов.
Нет аннотаций.
Нет дженериков (универсальных шаблонов. — прим.перев.).
Нет исключений
Go это реинкарнация PL/1 ?
newpy
18.04.2017 23:07+2реализация concurrency (JAVA) и синтаксис (гомоиконность) мне больше по душе в Clojure. Только там еще иммутабельность, которая так необходима для этого. delay, futures, promises, atoms, refs, agents.
В общем в контексте использования для concurrency Clojure мне видится более приятной чем Go.
xRay
19.04.2017 00:43+1В Go time format не привычен для нас привыкших к strftime.
Кого-то это сильно взбесило и он запилил сервис http://fuckinggodateformat.com
dplsoft
19.04.2017 01:03+3Задам свой любимый вопрос: а что там с обратной совместимостью?
Код написанный на го, будет хотя бы собираться в новых версиях компилитора хотя бы через 3-5 лет? я молчу про такую «ынтерпрайзную роскошь», как «работать точно так же»…
Или будет как с руби? (гугль выпутит новую, улучшенную версию языка, не совместимую с предыдущей, и через 2 года снимет старую с поддержки, со словами, мол, " мы скорбим, что до сих пор ещё много проектов не смогли перейти на новую версию, из-за проблем с перерабокой исх. кода, но мы все-таки снимаем старую версию с поддержки. (читаем между строк: «Мы плевать хотели на ваши проблемы. Это ваши проблемы, трудоемкость и деньги. А мы будем дальше делать наш красивый язык, ибо нас волнует только красота нашего поделия.»)?
Ещё, во всей статье, так и не нашел позиционирования языка. Под какие задачи он заточен? Какой сдк и библиотеки под него есть?
Ещё вопрос, как разработчика с 20 годами стажа, которого, вопреки заявленному в статье тезису, никогда не сводили с ума новые языки, которого эта череда «новых откровений» банально достала: зачем нужен ваш язык, если всё, что нам надо, мы прекрасно делаем на уже существующих технологиях: java, javascript, с/с++? кто то еще вспомнит про си-диез (простите, не люблю я его — но и ладно..., живет и даже что ть полезное можно на на нем делать)… кто то вспомнит про питон ( скажу — «остыньте, уже не модно»), руби ( «и вы пойдете на свалку моды»), хацкель (подмигну -ну ты понял, посмтри на питон и руби)… Но чем го отличается от этого разношерстного безобразия? Это нишевый язык или общего назначения?
Да, вы проводите какие, весьма спорные, сравнения, очень пахнущие глубоким субъективизмом, картинки рисуете. Говорите про какую-то понятность… Но вот я так и не понял — это замена питону или башу в скриптах инициализации линукса?
Это скриптовый язык с возможностью компиляции и возможностью использовать .dll/.so? Или это легкое нечто которое позволяет набросать что то на коленке типа мини утилиты? Или это нечто для веб, компилируемое и мегашустрое в обработке мегатонн микро-запросов?.. Ведь нечто большое, мега-интерпрайзное этот язык, как сложилось впечатление, в силу отсутствия ооп -банально не потянет (в си же вон от структур и пакетов к ооп перещли?.. зачем, не понятно, наверное… но си, сегодня, остался, видимо, только при программировании микроконтроллеров...). Или го — это замены простому си, пригодному для програмирования микроконтроллеров?
Какие прикладные пакеты есть в го?(кодогенератор веб сервис-клиента из .wsdl-файла есть? Я могу тестовый скриптик типа как для junit набросать? А к базе данных могу подключиться? jdbc-драйвера он понимает? Нет? а odbc?) Какие средства для управления GUI есть? я могу его интегрировать с Qt? нет? а какие средства есть для воддержки веб-интерфейса? Поддержка вебсокетов есть?
Эти, и ещё полсотни других влпросов я могу задать, и не остановиться, потому, что есть еще много за этой полсотней…
Не должен я учить го. Не вижу я в этой статье, чем го отличается от мегасотен других «откровений». Извините.
Зачем мне писать что то серьезное на го, если никто не гарантирует, что завтра они не выкинут такой же финт как руби? или как питон не выпустят новую версию, на которой старый код не работает?
А если не серьезное — то что тогда писать? как этот язык поможет улучшить жизнь моему бизнес-заказчику? какие проблемы я могу на нем решать? плевать на синтаксис ( хотя, нет, не плевать — за отступы-табы-проблемы в питоне надо «бить в голову с ноги»)))))(шутка)) но как этот язык облегчит мне жизнь?dplsoft
19.04.2017 01:23Простите, пропустил, с просонок ту часть, где говорится по синтаксис в части обратной совместимости.
Обратная совместимость не только стабильностью синтаксиса гарантируется. В джаве вон синтаксис меняется, но обратная 100% совсестимость остается. То, что гугль заморозил синтаксис, это может быть и хорошо, но что с базовыми библиотеками? Или будет как в си? (через 5 лет, на другой платформе, теоретически, собрать софтину можно, но вот половины библиотек уже нет или они просто не перенесены на эту платформу? да и разрядность уже поменялась, потому вылазят нулл-поинеры да сег-фолты?)
Что у языка с кроссплатформенностью?
И повторюсь: не увидел, даже после перепросмотра статьи производственных задач, которые решаеются языком у тех или иных вендоров! Или вы как «свидетели руби» — обосновывают выбор руби для сложного «иниерпрайз» проекта с ЖЦ длительностью лет 10 тем, что «там-то оно используется» — а когда выясняешь как именно используется — выясняется что там 5-и строчники-скриптики для тестирования оборудования на нем пишут?)))Prolych
20.04.2017 03:00-2Что значит «Что у языка с кроссплатформенностью?»
Компилите исходник в нужную платформу: о)
Странный вопрос канеш: о))) Не поленитесь потратить десять минут на Го ЧаВо.dplsoft
20.04.2017 10:10+5У руби тоже типа с кроссплатформенностью все хорошо.
На бумаге. На словах.
Но различные реализации интерпретаторов руби, под разные платформы, в разных средах, на практике оказываются малосовместимы друг с другом, или ведут себя по разному (код ведет себя по разному) (тут я сошлюсь на мнение знакомого рубиста. бывшего рубиста.).
И у с/с++ тоже с кроссплатформенностью все хорошо. Ну как хорошо — только анси-си в примитивном виде можно переести между платформами. Но это не точно. Не факт, что после сборки взлетит (банально, int у всех разной длины.).
Самый яркий пример красот кросскомпиляции C++ кода — необходимость фазы метакомпиляции в Qt, когда универсальный кроссплатформенный Qt/C++ превращается в код код конкретный компилятор. мол в линуксе — gcc, но код, который gcc проглотит, не проглотит майкросовтовская вижуал студия (ну не понмает она шаблонные классы — generic, и это в 21м веке, году 2010 от Рождества Христова....) и тд. и тп.
Потому и спрашиваю — как в гоу с кроссплатформенностью на самом деле. Хочу ответ услышать с деталями.
* Как обеспечивается кроссплатформенность. Как решены проблемы присущие С/С++ коду при сборке на разных системах?
* Eсть ли (как у джавы, снова) процедура сертификации компилятора/интерпретатора на соответствие стандарту? (ибо как вы собираетесь кроссплатформенность соблюдать без наличия четкого стандарта).
* Сам стандарт на язык вообще есть и в каком виде? или «оно как в питоне» — это некая малоформального вида бумага, поддерживаемая автором и сообществом?(поправьте если ошибаюсь).
А если уж отсылаете в фак, то надо отсылать с выдачей ссылки, а не посылать в пустоту. Где ссылка? Вы предлагаете мне продираться сквозь тонны рекламной мишуры? Дайте ссылку на самый правильный фак, какой вы сами считаете есть. Вы эксперт по языку, а не я. Я потенциальный потребитель, который пока задает вопросы, и не будет тратить время на ваш язык, если вы не в состоянии ответить на эти вопросы.
Ибо кроме вас есть еще руби, питон, раст, хаскель, свифт, сишарп, ди, 1с,… и каждый кричит — все просто, все на поверхности, вот почитай фак/идеологию/роадмап/вижен/идею… да вы что, все, смеетесь?)))
Вы эксперт — вы и ответьте, пожалуйста на вопросы. Со ссылками. Заранее спасибо.
divan0
19.04.2017 03:34-5Судя по вопросам, которые вы задали, как только вы получите на них ответы, следующий проект вы будете писать на Go :)
dplsoft
19.04.2017 09:07+2Вы, вместо громогласных заявлений, ответили бы для начала хотя бы на часть вопросов.
Рубисты/питонисты говорили точно так. Но нет, подташнивает. А ещё, все знают об "успехах" рубистов на проекте в росреестре. Сданый вовремя проект, довольный заказчик, коммерческий успех компании подрядчика, безоблачные перспективы команды проекта… ага...
Следующие свои проекты, особенно после прочтения статьи "50 оттенков го", я буду писать на java. Как и последние несколько лет.
divan0
19.04.2017 12:00+1Вообще-то, это был комплимент тому, насколько ваши вопросы свидетельствуют о хорошем практическом опыте разработки. Это правильные и нужные вопросы (ну, кроме "про драйвера jdbc понимает" — тут я даже усомнился в своей оценке), и главный конфликт Go с последователями других языков в том, что многие решения приняты из практического опыта, а не из теоретических фантазий академиков.
На вопросы себя тут не утруждаю отвечать, поскольку
- а) большинство из них лежат на поверхности, стоит только захотеть,
- б) я уже немало написал постов, в которых ответы на эти вопросы присутствуют и
- в) чем больше вопросов в одном посте, тем меньше вероятность получить исчерпывающий ответ на каждый из них, из чего можно сделать вывод, что вопросы были заданы не ради получения ответов, что подтверждается пунктом а).
Собственно, мой пост был к тому, что задавая такие вопросы, и захотев действительно узнать ответы, вы будете настолько приятно удивлены, что, учитывая низкий порог входа в Go, я не вижу причин, почему вам не захочется попробовать Go на практике в первую же неделю.
Но раз подташнивает, то пишите на Java, конечно, как и последние несколько лет, никто ж не заставляет :)
dplsoft
20.04.2017 01:57+5Пока, список моих потребностей, в части поддержки тех-же wsdl, xsd, xml, orm на уровне, на котором мне это требуется что бы решать быстро и легко практические задачи — и попытка прояснить а как же дела с этим в гоу — говорит что дела у гоу с этим «никак».
Как вы предлагаете мне приятно удивиться?
Вы говорите ледит на поверхности? на поверхности вон по wsdl например — лежит пакет goWsdl (спасибо камраду за ссылку). но из описания пакета, я понял, что в сравнении с тем, что умеет в этой части джава — goWsdl это дешевая студенческая поделка. Где генерация wsdl, где xsd 1.1, где сериализация и десериализация в код через аннотации?
Извините, не хочу я тратить время на изучение очередного изделия. Таких изделий каждый день -десятками плодится — на всех жизни не напасешься ознакамливаться. Надоело, если честно.
Если от идеологов нет ответов на конкретные вопросы — значит изучать уже никто не будет. И аргумент мол на поверхности, сразу найдете ответы — во первых не катит, потому что то что поверхности уже не впечатляет, а во вторых — это просто гнилой маркетинговый подход, согласитесь. Не буду я тратить время на изучение кота в мешке.
Особенно, плохо звучит такой ответ (начните изучать и будете приятно удивлены, вместо конкретного ответа) — если сравнить такой ответ с ситуацией, когда я спрашиваю у мастодонтов джавы «что есть в джаве для этого?» — мне говорят конкретный набор буков и я иду гуглить этот пакет или технологию.
парой пос ов пиже, я описал вполне конкретные вопросы и ситуации про вебсервисы, wsdl и soap. у вас есть что ответить? и да, ответ я много раз отвечал — тоже гнилой ответ. отвечали — дайте ссылку, сделайте фак и ссылайтесь на него. но не отсылайте в никуда)divan0
20.04.2017 02:19-1Вот заладили вы со своим WSDL. На поверхности лежат ответы на вопросы про обратную совместимость, кросскомпиляцию, возможность использования .so и так далее. Я понимаю, что у вас нет времени открыть Golang FAQ и получить более, чем исчерпывающие ответы на эти вопросы — оно занято написанием длинных комментариев.
Отвечая про WSDL — приятно был удивлён, что оно ещё не умерло и кем-то используется, хехе — всё на что есть спрос в современной серверной разработке, в Go реализовано — коммьюнити то большое, и, в основном, очень технически сильное. То на что спрос особый — вообще в стандартной библиотеке.
Извините, не хочу я тратить время на изучение очередного изделия.
Да мне какое дело, вот прицепились ) Я всего лишь обратил внимание на то, что ваши вопросы намекают на то, что ответами (которые есть в FAQ) вы будете удовлетворены.
sshikov
20.04.2017 21:33+2про WSDL — приятно был удивлён, что оно ещё не умерло и кем-то используется, хехе
Это говорит лишь об одном — определенной (узкой) направленности вашей работы. Попросту говоря, soap — это весь ентерпрайз. SAP какой-нибудь. А еще например Sharepoint. То что вы с этим не работаете — ни разу не означает, что этого нет в природе.
Кстати, у Go и с JSON тоже все не очень хорошо. По сравнению скажем с Groovy — так вообще не впечатляет. Та же клиентская часть докера — так это ужас-ужас какой-то (там собственно внутри же REST, поэтому оно все из такого кода состоит). Поэтому мне лично заявления "ну так докер же на Go" — они довольно-таки смешные. Читается этот код докера ужасно, и писать кучу такого же своего — никакого желания не возникает.
codemax
19.04.2017 10:06+4Вот интересно. Статья у нас про то, что нам всем надо изучить Go (с некоторыми странно выглядящими попытками это аргументировать).
Пришел человек, задал некоторые вопросы, много вопросов задал, интересуют его ответы от кого-нибудь из Go-сообщества.
Пришел представитель сообщества и ответил только одно: «следующий проект вы будете писать на Go». Wat? Это всё? Даже секты как-то больше заморачиваются с объяснениями того, зачем все должны в них вступать :)divan0
19.04.2017 12:01-1и ответил только одно: «следующий проект вы будете писать на Go»
Это не то что я ответил, но вы можете трактовать, как вам удобно :)
Pakos
19.04.2017 12:08-1Пришел представитель сообщества и ответил только одно: «следующий проект вы будете писать на Go».
Очень простой и правильный встречный вопрос, позволяющий ответить "теперь точно нет" и не терять время.
pav5000
19.04.2017 10:31Удобнее всего на го писать небольшие веб-приложения, в которых важна производительность или большое количество одновременных соединений. Это легкое нечто, которое позволяет на коленке набросать микросервис или утилиту. Компиляция очень быстрая, а полностью статический бинарник упрощает деплой.
Рантайм у го довольно легковесный, так что можно писать и для слабых встраиваемых систем.
Неполный список прикладных пакетов
Драйвера баз данных из этого списка
Вебсокеты поддерживаются отлично, для веба есть куча фреймворков разной степени удобности и быстроты.
Для бизнеса го выгоден из-за простоты и единообразия. Легко обучить разработчиков, которые писали на других языках и легко разбирать код из-за автоформатирования и простого синтаксиса. Насчет отступов и вообще форматирования кода, кстати, они расставляются автоматически, а соответственно, единообразно у всех. gofmt — это стандарт де-факто.
Го уже используется столькими проектами, что Гугл вряд ли просто так его выкинет.VolCh
19.04.2017 13:06А как он подходит к сложным бизнес-процессам? Тот же веб-сервис, но со сложной логикой, а не просто CRUD-морда к базе данных. Пока у меня о Go представление как о гибриде C как системного инструмента и чего-то типа NodeJS как инструмента создания мостов и фасадов к СУБД, сложным SOAP-сервисам и т. п.
pav5000
19.04.2017 13:45-1Бизнес логика будет многословнее, чем в более сложных языках, но проблем с её написанием я не вижу. Особенно удобно то, что пишется все просто как последовательный код, без коллбэков и прочей лапши с промисами.
MacIn
19.04.2017 17:27Особенно удобно то, что пишется все просто как последовательный код, без коллбэков и прочей лапши с промисами.
Хе-хе, а история-то идет по спирали, ага.
lek
19.04.2017 14:01Go не для GUI. На нем backend высоконагруженный хорошо программировать, микросервисы всякие. К базам подключаться умеет, WSDL — сторонние библиотеки есть. Docker и Kubernetes на нем написаны, части высоконагруженного бекэнда DropBox'a, Juju, Heroku.
NIKOSV
19.04.2017 04:15Тоже был ярым противником Go пока не запилил реальный проект на нем. Вся его красота в наивной простоте и в тоже время в мощности и возможностях как у взрослых. Можно через год возвращаться к проекту (проверенно) и продолжать его допиливать без потери времени на разборки что да как, особенно при хорошей структуре проекта. Исходники стандартной библиотеки тоже читаются на ура — нет желания по-быстрее их закрыть как у других языках.
Go приучает к простому и понятному коду, хоть и чуть избыточному, вместо писанины «смотри как я могу». Невольно эту практику переносишь в java/C#.
Не спорю, может rust не хуже в этом плане, даже лучше, никогда его не использовал, но go сам по себе — хороший практический язык.
ulvham
19.04.2017 06:17+1ЯП — средство разработки. Никто же не задумывается, почему отверток разных видов так много.
ЯП в достатке — выбирай, пробуй, тестируй, работай, хвали, ругай, помогай в развитии. Адекватными при сравнении считаются аналитические заключения о соответствии ЯП целям поставленной задачи, остальное вода в ступе.
Некоторых прям неадекватно распирает от «экспертных» оценок.dplsoft
19.04.2017 09:12+1Вот именно о задачах, которым соответствует описываемый язык — в статье нет ни слова. Не о чем делать аналитические заключения. Статья — реклама, рассчитанная на восторженного наивного, не отягощенного практикой новичка. Потому и "срач". Имхо.
Siemargl
19.04.2017 09:44Просто все знают, что Go — для веб-сервисов
VolCh
19.04.2017 10:20+1А мне казалось, что для быстрой (псевдо)параллельной работы большого числа (псевдо)потоков. С требованиями к веб-сервисам это пересекается, но не более.
dplsoft
19.04.2017 10:55+2а что именно под «вебсервисами» вы понимаете? для меня вебсервисы описываются в .wsdl, работаю я с ними с использованием soap, а http — это только один из транспортов, причем не самый идеальный.
Это вебсервисы, потому что это они описываются в спецификациях с соответствующими названиями.
Если открыть википедию, то там как раз о wsdl/soap/xml и говорится.
А что для вас «вебсервисы»? о каких именно вебсервисах вы говорите, о которых «все» (кто эти все?) знают? — можете обозначить назвария технологий, номера специфицаций и стандарты, которыми описываются ваши «вебсервисы»?
для каких именно «вебсервисов» предназначен этот язык?Siemargl
19.04.2017 11:50Задать абстрактный вопрос, сославшись на абстрактный стандарт (даже не стандарт, а рекомендацию)?
Получите абстрактный ответ. Да, Go поддерживает все эти буквы библиотеками + WDSL.
Собственно, он больше толком ничего и не поддерживает, как я посмотрю (но я тоже не гоадепт — web не моя экосистема).dplsoft
20.04.2017 00:14+3wsdl значит поддерживает?
а как именно «поддерживает»? вы эту «поддержку» с джавовским стеком сравнивали?
давайте по порядку: первое — кодогенератор по ссылке — это клиентская часть или серверная?
если серверная, то для какой серверной платформы или какого сервера приложений ?(такое понятие в гоу есть?)
я к чему — управление ресурсами в этом сервере есть? пул потоков, скажем? А то, знаете, видели мы тут недавеча «супер сервер». на руби писанный. Когда ему 5 потоков запросов в параллель пускаешь… он… падает. Понимаете, Карл,… падает!!! Не выдает 5хх-й код, не закрывает соединение с месседжем типа — превышены ресурсы, и продолжает работать, как это делает практически любой сервер приложений для всеми ненавидимой джавы… а просто падает.
Как в гоу решается вопрос управления русурсом подключений? Так же, как в руби на том сервере?)))
Ладно. Следующий вопрос: где генератор wsdl по коду? обратный, так сказать, генератор? я могу написать структуры, массивы, определить их обязательность или не очень, функции… а она мне — по моему коду — и wsdl, и опубликованный сервис на сервере и сразу подключайся-не-хочу… умеет? почему джава и сишарп (мать его))) — умеют, а гоу… для вебсервисов ориентированный, все поддерживающий — … умеет?
Теперь следующий вопрос: xml schema 1.1 — где? А то нам тут АТ-К прислали файлики как-то раз… так мы их едва открыли… кстати, не wsdl прислали, а xsd.
xds..., да, а что у нас с xsd? Что с валидацией xml, на соответствие xsd?
Что, с сериализацией/десериализацией xml? Есть в «красивом синтаксисе гоу» аналог джавовских аннотаций? Есть возможность просто «промаркировать» поля структуры xpath-ами — и отдать структуру в некую «фабрику», а на выходе — получить xml-заданной структуры? ну не охота мне руками раскладывать поля по элементам xml…
Что с ОРМ? Могу я в «аннотациях структур» гоу описать какое поле в какой таблице в какой колонке лежать? И что бы была просто фабрика, которой, подсовываешь струтуры, а она сама тебе и базу данных перестроит, и сохранение-восстановление сделает? и что бы мне — только одну строчку над каждым полем прямо в классе прописать. можно так в гоу? или только gowsdl пакет, который, судя по всему, упадет если ему на вход подать не корректную структуру?
и я ещё много могу рассказать чего у вас в вашем распрекрасном гоу нету, что есть в ненавидимой хопстотой «джаве-йе-йе».
…
просто я к чему? гоу, насколько я могу сейчас судить, находится на уровне технологичности джавы 1 или 2. аннотации, вон, и «рефлекшен» в какой джаве появиоись? в третьей кажется, поправьте? какой это год? начало 2000-х? вот и гоу сейчас — примерно на этом уровне готовности для «промышленной разработки». Играйтесь конечно, но прошу, давайте не портить пространство воплями типа «большой код», все умеет, вебсервисы… вы видели «большой код»? сколько читающих этот пост хотя бы знает о «монструозности» стека приложений «ibm websphere»? а «рейшионал»? вы пытались писать систему которая должна хранить ваши данные 75 лет после вашей смерти? Эта «простая задача» сейчас решается в пенсионке. На джаве и майфреймах ibm. Ну смешно же выглядят сказки про «большой код» на гоу, на фоне достаточно примитивного набора возможностей языка. Ну серьезно, народ)))) Не ведитесь.
Да, в нем есть, вероятно прикольные фичи типа горутин (так и не понял из статьи, что эта за фигня, кстати) — но это не делает картины на фоне провала по всем остальным фронтам. Не может сделать, извините.
В пхп вон тоже поддержка wsdl есть. и причем на уровне более серьезном, чем это единственное поделие «gowsdl»… только что с этого?..Prolych
20.04.2017 00:30-3Ну если вы вообще не в курсе, что такое Го, то к чему эти вопросы?: о)
dplsoft
20.04.2017 01:30+1К тому, что интерес к языку либо академический, либо практический.
Посмаковать синтаксический сахар на досуге — это прекрасно.
Но я описываю интерес практический. и я прошу оппоннта ответить на эти вопросы хотя бы самому себе.
Как язык поддерживает те или иные технологии, и что имено означает эта «поддержка».
В частности, к прмеру — была заявлена поддержка вебсервисов.
Я начинаю «разбираться» — описываю кейсы (рабочие ситуации) и проблемы с которыми мы столкнулись в жизни, с примерами «провала кейса» на «других модных языках».
Что бы узнать, как именно обстоят дела в части «поддержки всех этих букв» в сабжевом языке.
На самом деле, вероятный ответ я уже знаю, но мне важно, что бы оппонент осознал что, заявленная «поддержка буков» на ко оруб ор сослался — это филькина грамота, мало общего имеющая с потребностями в части «поддержки указанных буков»за пределами академической среды.
Хотя, остается шанс, что я не прав, и я буду приятно удивлен.
Увы, но такое впечатление, что очень многие идеологи новомодных языков и их последователи как правило мало подкованы в технической части и практике применения IT в жизни. Для них сложный код — это сложная курсовая. для них важнее запилит красивую модную фичу в язык, а не обеспечить 100% ьбратную совместимость. Их понимание того, что такое технология и как она применяется — толькь пара лежащих на поверхности случаев, причем о проверке валидности структур и об обработке ошибок и исключерий — они и не слышали, или даже хуже — сознательно выпилили это из языка.
Первое чему приходится учить стажера — это критический взгляд, и умение строить зашиту от дурака в своем коде/системе. Подавляющее число технологий на новомодных языках — не серьезны, и крайне плохо обрабатывают проблемные ситуации. Пример с руби сервером который падает на 5 потоках запросов — очень характерен для идеалистических выходцев из академической среды в розовых очках. Или для хипстоты.
Другая причина почему я это все говорю — надежда, что сегодняшний «свидетель гоу/руби/питона/хацкеля», погрущившись в детали технической части и сравнительный анализ возможностей языков — начнет изучать нечто более серьезное, и будет смотреть на вещи более критично. Для этого, имзо, достаточно просто ответить на вопросы которые я задаю. Только честно. Хотя бы самому себе )))
Адекватных инженеров очень мало.
Когда-то, мне перла для веб — вполне хватало. Для дипломной работы. Но потом был пхп, дельфи, си++, джава… Задали бы мне пяток таких вопросов в свое время…
Prolych
20.04.2017 01:58-2Например «пул потоков».
Я не вижу, какой смысл в пуле потоков в Го, так как есть горутины. В промышленных приложениях работают сотни тысяч горутин.
Или у вас задача мапить потоки вашего приложения на потоки ОС и поэтому вам нужен собственный супервизор потоков?
Вобщем ваши вопросы звучат не для Го, потому что либо в Го таких вопросов нет, потому что они решены не вашими средствами, либо вы не знакомились с Го, поэтому ваши вопросы выглядят чужеродно: о)
dplsoft
20.04.2017 02:25+4Да не вопрос, нет пула потоков — опишите как управляются горутины, как они исчерпывают ресурсы системы (и какие есть ресурсы вообще? память, процессорное время, потоки, ещё что то?) и как их лимитировать на сервере гоу, как не дать гоу серверу банально подохнуть с серфолтом (или аакой тип ошибок у вас там в гоу?) под потоком запросов?
Давайте по сути обсуждать, а не по форме?) я знаю что вам кажется все это чужеродным в отношении гоу ) да, я не понмаю «этом вашем гоу» — и я задаю вопросы в терминах, которые сейчас применяются в промышленных технологиях. В общепринятых тезнологиях. а Термин горутины — это специфиака. «Ваша специфика». Проведите параллели с промышленными терминами и объясните на пал цах как не дать гоу серверу вывалиться в нерабочее состояние при попытке перерасхода выделенных ресурсов? и как вообще ему выделять ресурсы?)Prolych
20.04.2017 03:10-2Полагаю, что в документации по Го описано правильнее и полнее, чем я смогу тут описать в паре абзацев: о)
dplsoft
20.04.2017 00:44+5а будущим авторам статей (самим авторам и переводчикам тоже) типа «про прекрасное гоу»: предлагаю: вместо заявлений, типа вот гоу такой хороший — описали бы ниши, и как ниже хорошо в одном посте сказали — кейсы применения описали с конкретными параметрами, и задачами, вместо того, что бы разводить «какой то рекламный буллшит».
гоу — как я сейчас понимаю нишевый язык. очень нишевый. с, судя по всему, очень особенной поддержкой, которую устраивает текущее состояние, при котором многих бесят некоторые недофичи языка (ссылаюсь на статью «50 оттенков гоу»).
Так вот и опишите эти ниши. Конкретно. С техническии деталями и подробностями.
Так вы завоюете больше последователей. Мне вот все равно на чем писать на проекте — надо было -мы на сишарпе «прокси» с интерфейсом на вебсервисах для доступа с андроида к доксвижену сделали. Хотя сам я джаву люблю — но надо — ращобрались и сделали.) есть на Qt проекты. Будем понимать нишу гоу — почему бы на гоу не продать пару проектов — но нужны конкретные примеры с тех подробностями. Я вот не буду разбираться в интимных откровениях и проблемах недо-языков за свой счет — мне бы сделать бизнес-задачу, что бы клиент был доволен))) А гоу пока не ложится ну никак супротив джавы, имхо. и не будет ложиться, пока будут дешевые переводные статьия с рекламным буллшитом, вместо сухих технических данных и статистики с плюсами и минусами. когда мы инструменты для проекта выбираем — надо профиль понимать, и риски минимизировать.
… а вместо этого — половина сторонников гоу, в комментариях выше и ниже только радостными воплями разрождаются про то, как им понравилось, и какой экстаз они испытали… да плевать на это. глубоко плевать, извините) Факты давайте.
pav5000
19.04.2017 13:58Вебсервис — это обычно нечто, отвечающее по протоколу http.
Внутри http оно может класть html, json или всякие другие данные, хоть вебсокет. Граница довольно размытая, на самом деле. Думаю, имеется ввиду, что приложение является при этом частью системы сайта.
UA3MQJ
19.04.2017 09:53Интересно было узнать, что у Erlang — выразительный код.
Есть у меня друг — не программист. И я решил ради эксперимента, научить его программировать, причем сразу на Erlang'e. И вот глядя на то, как у него ничего не получается, прихожу к выводу, что да, синтаксис Erlang прост и логичен. То же самое я сейчас вижу глазами Elixir разработчика. Но Erlang сложен из за того, что надо понять, как правильно его применять, как решать на нем задачи, типичные приемы, идеологии ОТП.nwalker
19.04.2017 18:51+3Ну вообще, по сравнению с С-подобными языками код Erlang ОЧЕНЬ выразительный в смысле "количества смысла" на символ кода. Pattern matching, даже обычный, не binary, решает.
UA3MQJ
19.04.2017 19:32Я немножко перефразирую: приятно было услышать от специалистов на Go, что у Erlang выразительный код )
А то обычно нападки. Мир, дружба )
monah_tuk
19.04.2017 10:45А как с отладкой горутин? Какие отладчики существуют, что бы можно было пощёлкать контексты, посмотреть где что и в каком состоянии? А то мне в Asio понравилось писать с короутинами, но зело сложно отлаживаться с ткущим инструментарием.
Coocos
19.04.2017 11:34Первый процессор Pentium 4 с тактовой частотой 3.0 ГГц был представлен ещё в 2004 году компанией Intel. Сегодня, мой Macbook Pro 2016 имеет тактовую частоту 2.9 ГГц. Таким образом, около десятилетия нет особого прогресса чистой вычислительной мощности.
Только производительность одного потока выросла в 3 раза.
DaylightIsBurning
19.04.2017 12:03+5Perl отнесли к самым легкочитаемым языкам! Perl! Эту оценку инопланетянам доверили что ли?
Frank59
19.04.2017 13:52+3Статья — какой-то рекламный буллшит, местами с перевиранием и притягиванием за уши удобных примеров.
Лучше бы вместо отого описали реальные кейсы, в которых Go применять действительно удобно.Prolych
19.04.2017 18:19+2На Го удобно писать всё, что не требует ГУЯ и риалтайма. Хотя ГУЙ можно отдать фронтенду, включив в прогу на Го вебсервер. А с реалтаймом типа онлайновых игр придётся разбить сервер на микросервисы, чтобы не притормаживать при сборке мусора в монолитном сервере. Хотя вон Juju вроде монолит на Го на полмиллиона строк, ну так жужа и не риалтаймовая.
Вобщем Го — красивенький, и на нём уже много критичных серверных приложений написано.VolCh
20.04.2017 08:47Сложную транзакционную бизнес-логику систем класса ERP, CRM и т. д. удобно писать? Задержки на секунды не критичны, если надежно обеспечена блокировка при старте транзакции, но простая команда типа signContract(contractId) может вызывать создание и изменение сотен записей в СУБД и генерацию десятка событий в MQ/шину.
Prolych
20.04.2017 14:44Насчёт бизнес-логики не скажу, потому что не имел опыта. А вот насчёт как принять миллионы событий и обработать их и разослать — в этом Го — вентилятор. Мне кажется, что те куски приложений, которые конвейеризуются — самое то для применения Го.
VolCh
20.04.2017 16:57Тут скорее речь про то, чтобы принять одно событие и сгенерировать по сложной логике с десяток.
Prolych
20.04.2017 17:12-1Ключевое слово «сложная логика»?: о)
Ну не замечал сложностей в Го для такой логики. а мож не сталкивался: о)
Но если нужно сожрать, переварить и выдать мегаллионы байт, то тут Го канеш безусловный фаворит.dplsoft
20.04.2017 22:51+1Ключевое слово «сложная логика»
именно. то что вы не сталкивалсь с этим, говорит только о том, что вы мелко плаваете. или о том, что любимый вами язык никто в здравом уме не применяет для серьезных задач.
вопрос с интерпрайзом не в мегатоннах байт и простых запросов, а в сложных и часто постоянно плавающих бизнес правилах.
всем плева-ть на миллион запросов в секунду. совершенно.
важно, что бы хотя бы один отработал за преемлемое время, сопоставимое хотя бы с часом.
потому что когда воодушевленные хайлоад-конференциями школьники приходят и делают систему на этих модных «производительных» технологиях, а потом вдруг оказывается, что их творение не способно построить справку об исполнении поручений первого лица города за неделю, и уже 6 часов это «хайлоад творение» пытается собрать «просто отчет» (просто потому, что правила по которым вы понимаете исполнено поручение или нет — уже это сложно рассчитываемый признак) а потом ещё надо посчитать на сколько дней оно было просрочено поручение (рабочие дни! не календарные! ) и планируемый срок окончания — вот тут начинается совершенно иная песня.
особенно после того, как совещанме мэра начинается _без_ основной бумажки об исполнительской дисциплине. потому что язык, способный перелапачивать мегатонны байт в секунду, и миллины рест запросов — не смог за 6 часов построить один-единственный отчет, на горизонте событий 1 неделя, попоручениямодного человекаProlych
21.04.2017 00:11А причём тут Го, если ваши спецы не могут собрать отчёт за шесть часов?
VolCh
21.04.2017 11:08Например, из-за того, что модуль типа linq Go агрегировать данные из БД умеет только на стороне приложения, а генерировать SQL запрос с агрегацией на стороне СУБД не может. Пример абстрактный, без понятия есть ли вообще подобный модуль в Go.
DjOnline
22.04.2017 09:50В GO нельзя написать свой SQL запрос руками, без всяких linq?
VolCh
22.04.2017 12:12-1Можно, но в целом это не дело прикладных программистов писать SQL-запросы руками. Это или разработчики/администраторы базы должны делать, или экосистема языка генерировать.
DjOnline
22.04.2017 13:02Ну если разработчик тупой и не может написать хороший быстрый SQL запрос и вообще боиться выйти за рамки ORM, кто же виноват.
VolCh
23.04.2017 14:10-2Тупые разработчики ОРМ, которые не могут написать генератор хороших быстрых SQL-запросов? :)
Scf
23.04.2017 15:01+2ну, вообще говоря, да :-)
ORM добавляет накладные расходы в виде анализаторов графов объектов/генераторов sql + не умеет писать оптимальные запросы. К примеру, сложности начинаются, когда в целях оптимизации нужно выбирать не все данные, переформулировать запрос иначе для лучшего понимания планировщиков или добавить хинты.
DjOnline
24.04.2017 00:12+1Это невозможно априори. Зачем изобретать велосипед, если есть SQL, где можно описать любой сложный случай?
VolCh
24.04.2017 06:48-1Сколько диалектов SQL есть хотя бы? А если в требованиях поддерживать хотя бы MS SQL, Oracle, MySQL и PostgreSQL, хотя бы пары последних версий?
Scf
24.04.2017 07:05+2Когда-то я и сам аргументировал за хибернейт именно так. Но суть в том, что приложения, которые должны работать на разных СУБД, достаточно редки. А проблема быстрой миграции на другую СУБД проще решается наличием тестов на слой DAO, а не ORM.
VolCh
25.04.2017 08:22-2Для коробочных продуктов не такая уж редкость, если есть желание охватить как можно большую долю рынка, чтобы потребители не отказывались от решения лишь потому, что у них всё крутится на MySQL, есть специалисты по нему, а внедрение PostgreSQL потребует дополнительных вложений, без которых продукт нормально эксплуатировать будет весьма затруднительно вплоть до полной невозможности.
А вообще мой тезис в том, что обычный прикладной программист не должен уметь писать более эффективные SQL-запросы по сравнению с профессиональным генератором запросов. А если такого в экосистеме языка нет, то для прикладной разработки он мало пригоден, если отсутствуют в штате специалисты по конкретным СУБД, которые будут получать от прикладного программиста задания с описанием того, что он хочет получить и реализовывать получение оптимальным способом.
heleo
19.04.2017 18:36Спор из разряда: «Вершки или корешки». Смотреть на это надо в первую очередь исходя из поставленных задач и применимости.
Всё равно одним инструментом решать сложные комбинированные задачи затруднительно. Проще разбить на отдельные микросервисы\приложения и использовать заточенный под эти задачи инструментарий. А если вспомнить про то, что существует большое наследие готовых и отлаженных библиотек для старых языков, языки используются, не заброшенны и развиваются, то и говорить о полном написании на одном универсальном языке не совсем корректно со стороны времени\сложности.
Так что фраза «Go станет серверным языком будущего» возможно и корректна, но берёт на себя слишком много.
Вообще можно найти свою область применения языка и на её примерах вещать о «сферическом языке в вакууме».
Prolych
19.04.2017 23:56-2Пять удобств Го:
1. Программа на Го компилируется в один бинарник. Можете скомпилить бинарник на своём макпро, зааплоадить на сервер под линукс и там запустить. Никаких зависимостей!
2. Статические типы. Ошибки отлавливаются на этапе компиляции.
3. Го быстрый. Потому что компилится в исполняемый код целевого процессора.
4. Для работы с веб в Го достаточно стандартных пакетов из коробки.
5. Для Го есть не только плагины к IDE, но и отдельные IDE.
По мотивам 5 Reasons Why We switched from Python To GoVolCh
20.04.2017 08:50Для работы с веб в Го достаточно стандартных пакетов из коробки.
Что вы подразумеваете под работой в веб? Достаточно ли стандартных пакетов из коробки для создания веб-приложения (пускай чистого бэкенда с JSON HTTP API, фронт совсем отдельная разработка) по функциональности аналогичного 1С?
bat
20.04.2017 10:28-2https://golang.org/pkg/net/http/
https://golang.org/pkg/encoding/json/VolCh
20.04.2017 10:40Это о том как отдавать результаты работы и как получать её параметры. А как собственно полезную работу делать?
bat
20.04.2017 10:56зависит от задачи
мой ответ можно расценивать как расшифроку что понималось под фразой «4. Для работы с веб в Го достаточно стандартных пакетов из коробки.»
зы
не агитирую за го, но если конкретизируешь «полезную работу», может смогу что-то пояснить.VolCh
20.04.2017 11:22+1Автоматизация сложных бизнес-процессов для систем типа ERP, CRM и т. п., да даже банальній интернет-магазин с корзиной покупателя и накопительной скидкой. С ООП решается обычно созданием полноценных объектов с методами, отвечающими за бизнес-логику и достаточно прозрачный маппинг данных этих объектов на СУБД с помощью ORM с преобразованием связей между таблицами в связи между объектами.
Пока что я вижу по Go он хорош в качестве шустрой и простой прокладки (бридж, адаптер, гейт, шина и т. п.) между различными сервисами и протоколами, задача которой в основном преобразовывать данные из формата в формат (например из JSON в SQL и обратно), но только один пример за несколько лет "хайпа" попался пускай с примитивной, но попыткой прикладной разработки по DDD.
Prolych
20.04.2017 14:54«Пока что я вижу по Go он хорош в качестве шустрой и простой прокладки (бридж, адаптер, гейт, шина и т. п.) между различными сервисами и протоколами, задача которой в основном преобразовывать данные из формата в формат (например из JSON в SQL и обратно)»
Да, это обычно самое первое применение Го при начале его применения — сделать быстро конвертер, который маленький, быстрый, не требует зависимостей, кроссплатформенный, понятный в чтении и сопровождении. Тут Го конечно фаворит.
jetexe
20.04.2017 10:49+2Программа на Го компилируется в один бинарник. Можете скомпилить бинарник на своём макпро, зааплоадить на сервер под линукс и там запустить. Никаких зависимостей!
Зависимости появились не на пустом месте, а статическая линковка как была 30 лет назад так никуда и не делась.
Статические типы. Ошибки отлавливаются на этапе компиляции.
Не все, не всегда. Опять же статические типы данных далеко не нововведение.
Го быстрый. Потому что компилится в исполняемый код целевого процессора.
Вот эту часть не понял совсем. Дпя процессора? Язык со сборщиком мусора? Что-то я не видел приложений на го под AT.
Для работы с веб в Го достаточно стандартных пакетов из коробки.
Выше уже ответили.
Для Го есть не только плагины к IDE, но и отдельные IDE.
Это вообще какое отношение к языку имеет?
PS. И что же мы имеем в сухом остатке от этих «удобств»? да ничего.VolCh
20.04.2017 11:25+2PS. И что же мы имеем в сухом остатке от этих «удобств»? да ничего.
Похоже (чисто по подобным постам), что имеем C с ссылками на структуры данных вместо указателей на память, со сборщиком мусора для этих структур и каким-то подобием или реализацией зеленых потоков.
grossws
20.04.2017 12:11Ну, в целом примерно так и выглядит. Более-менее нормальная реализация корутин с сегментированным стеком и неблокирующаяся стандартная библиотека. Вот дёрнуть что-нибудь сишное и блокирующееся в go может быть фатально.
MacIn
21.04.2017 01:26Ну, еще интересный сахар типа возврата пары значений из функции — это то, что меня лично позабавило.
Prolych
21.04.2017 02:10-1Можно несколько значений возвращать: о) Удобно, когда промежуточные значения функции тоже имеют смысл, чтобы не вызывать две+ функции. А в основном второе значение используется для возврата ошибки. Ещё удобно игнорить возвращаемое значение подчёркиванием, когда оно не нужно. Например:
a, _ := foo() или _, err := foo()
grossws
20.04.2017 11:56+2- Только если специально постараться, иначе будут зависимости на libpthread, libc и ld.so, как минимум. А если используется что-то не из нативных библиотек, то может быть нереально собрать статический бинарник вообще.
- Ага, и
interface{}как самый статический используется регулярно. И ошибка "отлавливается" на этапе компилирования путём вставки в код if'а с паникой, если что-то пошло не так в рантайме.
3.1. Компиляция в бинарник ещё ничего не гарантирует. Можно собрать в один бинарник какой-нибудь интерпретатор и в соседнюю секцию положить код для интерпретации.
3.2. Компилируется код абстрактного процессора, в документации даже сходу не находится какого. Т. е. под какую архитектуру собирать (march/mcpu, если говорить про gcc), какие наборы команд включены (sse4.2/avx/avx2), какие оптимизации включены и пр. Откуда узнать, что он собрал под, скажем sandy+, а не под core2+? - Почему же тогда народ и в go, и в python тащит внешние библиотеки для веб-приложений? И там, и там достаточно стандартной библиотеки.
- Каким боком это является аргументом — не понятно. И для python'а есть отдельные IDE, и что?
DarkEld3r
20.04.2017 17:39+1Каким боком это является аргументом — не понятно. И для python'а есть отдельные IDE, и что?
Справедливости ради, у молодых языков с поддержкой IDE может быть плохо. Вот только я не уверен, что у Go всё прямо так шикарно в этом плане. Ну есть плагины и Gogland от джетбрейнс, которая ещё не зарелизилась.
Prolych
20.04.2017 17:47-1Честно говоря, для Го и ИДЕ особо не нужна в большинстве случаев: о) Хватает редактора с подсветкой.
VolCh
20.04.2017 18:09В Гоу всё в одном файле, понятия "проект" не существует?
Prolych
20.04.2017 18:41-1Канеш существует: о) Просто в Го как-бы нету лишних депендансов, хедеров всяких и прочего.
По большому счёту папка src, а внутри папки с исходниками разных частей.VolCh
21.04.2017 11:10А как редактор с подсветкой обеспечит переход на объявление используемой в одном файле нужной структуры или функции, объявленной в другом? Текстовым поиском по всем файлам? А если строковый литерал такой же есть или в комментарии упомянуто?
Prolych
21.04.2017 16:19Плагины под Го для некоторых редакторов такое умеют, хотя это уже конечно задача для ИДЕ.
TheShock
20.04.2017 18:50+2о) Хватает редактора с подсветкой
А вы писали проекты, в которых больше 1000 строк кода на Гоу?Prolych
20.04.2017 19:06-3Да. Но нет смысла иметь все тысячи строк в одном файле.
Разбиваем пакет на несколько файлов, просто внутри будет один оператор
package xxx
а содержание разное.
Я обычно делаю два-три файла на пакет, в одном у меня то над чем работаю сейчас, а в других файлах уже отлаженные части етого пакета.
А Го умеет собирать пакет из нескольких файлов.
grossws
20.04.2017 18:33Ну, ссылка "5 Reasons Why We switched from Python To Go" намекала на сравнение с python'ом, который молодым языком назвать сложно.
Idot
20.04.2017 10:17отличии от Go, в котором есть сборка мусора.
А отключить Сборщик Мусора (как в C#) возможно?
Inobelar
20.04.2017 12:36+5Нет дженериков (универсальных шаблонов. — прим.перев.).
Всё, что вам придётся сделать, это написать лишь на 2-3 строчки больше. Но зато, с другой стороны, это сделает ваш код более чистым и понятным.
Не представляю реализацию мат.библиотеки: vec2, vec3, vec4, mat3, mat4, quat, для разных типов, хотя-бы float и double, с оверхедом всего-лишь «в пару строчек» ))grossws
20.04.2017 14:36+3Вам так сложно скопипасть кусок кода для каждого типа или сгенерировать код? Ну и пользователи библиотеки могут сделать то же для своих типов. /sarcasm
snuk182
20.04.2017 18:54+2Про оверхед в пару строчек — вспомнился момент из личной практики, когда я долго тыкал палочкой в go generate, очень стараясь не произнести вслух «вот это, что ли, нам предлагают на замену дженерикам?»
MacIn
21.04.2017 01:30+1На самом деле они всерьез обсуждают введение дженериков, и я уверен, что они будут. Но там есть сложности с увязкой с существующими конструкциями. Я не вдавался в подробности, но у меня коллега тесно общается в их сообществе по этому поводу.
Prolych
21.04.2017 02:30-6Не нужны женерики в Го.
TheShock
21.04.2017 04:02+1«Ну не нужна автомобилю возможность поворачивать налево»
Prolych
21.04.2017 04:19-4Женерики — ето несбыточная мечта программистов сделать единую функцию для всего.: о)))
Вобщем такая гипертрофированная кнопка «убить всех».
Но реальная жизнь не терпит женериков, поетому женерики не нужны.Sirikid
21.04.2017 05:02+3Может вы и интерфейсы не используете? Ведь это тоже полиморфизм.
MacIn
24.04.2017 18:08Ну… есть такое. Только чисто абстрактные классы. Хотя отличие от интерфейса только в названии получается.
VolCh
25.04.2017 08:24Абстрактный класс предполагает какую-то реализацию по умолчанию, интерфейс же — нет.
MacIn
27.04.2017 16:33Вы имеете в виду, что а.к. будет иметь некий конструктор по умолчанию, который по сути ничего не сделает, если в классе нет полей?
Это несущественное различие, различие скорее в реализации. Я бы сказал не функциональное. Потому что от того, что мы объект а.к. можем создать, он не становится полезным, это лишь пара полей для VMT в памяти.VolCh
27.04.2017 22:43Нет, я имею в виду, что:
- в абстрактном классе может быть свое состояние, причём даже скрытое от наследника
- в абстрактном классе могут быть дефолтные реализации методов, которые можно переопределить
- в абстрактном классе могут быть методы, которые вообще нельзя переопределить
- в абстрактном классе могут быть методы, использующие позднее связывание
В интерфейсах же могут быть только абстрактные методы, которые мы должны переопределить.
MacIn
28.04.2017 02:05Разумеется. Я имею в виду использование полностью а.к. в качестве интерфейса при отсутствии такой конструкции. Т.е. полей или неабстрактных методов нет.
MacIn
24.04.2017 18:10Дженерики — это нежелание писать один и тот же код N раз, а потом править его в N разных ипостасях. Я сейчас пишу по работе на старом Delphi 7 и вы не представляете как задалбывает и угнетает писать по 10 раз один и тот же код-обертки для контейнеров и прочей стандартной мути.
VolCh
25.04.2017 08:25Дженерики — это нежелание писать один и тот же код N раз, а потом править его в N разных ипостасях.
Справедливо только для статической типизации.
snuk182
21.04.2017 10:40+1Это невероятно, невероятно радует. Я знаю только официальную информацию — тикет, RFC, ветку обсуждения, где никакой конкретики нет.
ik62
1) «you should» != «вы должны»
2) беглое прочтение статьи показывает что из всего перечисленного для Go уникальным является только «Go поддерживается Google.», это (без иронии) мощный агрумент.
TyVik
Загляните на кладбище проектов Google.
ik62
ну пока язык не на кладбище — поддержка гугла ему только в помощь. а что будет дальше — жизнь покажет.
TheShock
Dart тоже поддерживается Google
CodeViking
Извините, но вы сейчас привели глупое сравнение. У всех людей могут быть идеи как благоприятно восприняты обществом, так и нет. И к слову Dart мог быть очень популярным языком, если бы не одна история во время его разработки.
DarkEld3r
За языком не следил, но любопытно. Можно в двух словах?
semI-PACK
Присоединюсь, тоже любопытно.
kirias
Самому стало интересно, нашел только https://arc.applause.com/2015/03/27/google-dart-virtual-machine-chrome/
Как я понял, гугл не захотел добавлять виртуальную машину для Dart в хром
snuk182
sevikl
можно ссылку на историю для тех, кто не в курсе, но интересуется?
TheShock
Почему глупое? Я просто акцентировал на том, что факт поддержки Гуглом ничего не означает