ua-hosting.company: серверы в Нидерландах / E5-2650v4 / 10GB DDR4 / 240GB SSD / 1Gbps — $29 / месяц
×Закрыть

Про ниасиливших Scala (или фигак фигак и сервисы на Go лучше)

jimplush.com/...eam-from-scala-to-golang
вот вам интересная статейка

Внутря — стоны обиженных scalaz и проклятыми функциональщиками, рассказы про то как ’да я уже 7 (семь Карл) лет программирую и прочие стоны обиженых.

Интерисуют мнения, выводы да и срачь в коментах тоже.

Лучшие комментарии пропустить

ну то есть под Go нет
— IDE
— дебагеров
— дженериков
— исключений
И судя по всему на него активно переходят бывшие PHP программисты

Если вам нравится писать в виме это не преимущество, а недоразвитость go для которого за столько лет еще не сделали нормальную IDE с дебагером. Еще вопрос что проще — научить новичка писать на скале в intellij или на go в виме (имеется ввиду реальные проекты, а не hello world).

Если вам нравится if err != nil { .. } через строчку вместо эксепшинов, называйте это «своим, альтернативным подходом к обработки ошибок», но никак не преимуществом. Хоть я и сам не любитель ексепшинов.

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

Не нравится ООП? Не называйте отсутствие оного преимуществом.

и т.д., и т.п.

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

PS Действительно секта какая-то, не поверишь пока сам не столкнешься.

точно наркоман

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

Вы всерьез считаете, что экономическая целесообразность использования того или иного языка программирования определяется стоимостью IDE?

Эта статья не про то, какая Scala плохая или какой Go крутой, это про то, что найти 100 программеров на Go проект намного проще, чем столько же на Scala проект, причем это точка зрения не программиста и даже не Team Lead а CTO, у которого наряду с задачами написать проект красиво, есть так же задачи по поддержке и развитию, которые в прямую упираются в вопрос кадров. И на самом деле — найти 100 программистов на Scala не реально. Даже если Вы Twitter и готовы отстегнуть существенные бонусы — такого количества Scala программистов не найти. То есть они есть конечно, но все они повязаны контрактами и обязательствами и вот просто так повыдергивать их из текущих компаний/проектов не возможно. Порог вхождения в Scala большой. Если в проекте в полную используется scalaz + функциональное программирование — порог вхождения очень большой. То есть привлечь скажем PHP или JS программиста и посадить писать на Scala не получится. С другой стороны это можно сделать с Go ( то есть взять средней руки PHP программиста и научить его за пару недель писать сервисы на Go ). Именно об этом и была написана статья и все это полностью соответствует действительности.

Допустимые теги: blockquote, code, em, pre, i, li, ol, strike, strong, u, ul, a.
Ctrl + Enter
Допустимые теги: blockquote, code, em, pre, i, li, ol, strike, strong, u, ul, a.
Ctrl + Enter

Нехай приймають наші співчуття...

Сенсация!!! Вышел релиз новой версии Go 1.8 blog.golang.org/go1.8 что ознаменовало новую веху в истории программирования, девелоперская мысль поднялась на следующую ступень, и вышла на более высокий уровень развития!

Так там особо ниче не поменяли то

GC паузи в наносекунди з коробки!

Воно вам, фронтам, не потрібно.

так оно и другим особо не надо, или вы Кнута не читали?

так оно и другим особо не надо
Не знаю, не знаю. Мужики в Гуглі кажуть що вроді їм нада.
или вы Кнута не читали?
Кнута Гамсуна?
Не знаю, не знаю. Мужики в Гуглі кажуть що вроді їм нада.
а шо только в Гугле сидят программисты?
Кнута Гамсуна?
тот который Дональд
а шо только в Гугле сидят программисты?
Звісно що не тільки.
тот который Дональд
Цілком не читав, звісно. Так, листав окремі розділи. А до чого тут Кнут?
А до чого тут Кнут?
есть у него знаменитая фраза на этот счет:
Преждевременная оптимизация — корень всех зол

Пф... не думаю що паузи GC це передчасна оптимізація. Це так само як сказати що пришвидшення коду що генерує компілятор то передчасна оптимізація.

От випустили вам новий Хром із швидшим V8 всередині. Невже то буде поспішною оптимізацією?

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

В мене таке враження, що ви не розумієте що таке garbage collector, біль який STW паузи завдали людству, і відповідно яку вундервафлю запилили в Го (звісно, якщо воно все так гарно працює як заявлено).

Во первых, я думаю они оптимизировали GC только для некоторых сценариев, во вторых, если даже в JS научились решать STW проблемы (а тут вообще в этом плане все печально), то что-то мне подсказывает что и в Go, это не настолько большая беда. А вот слабый дизайн языка — это есть, и это то чтобы можно было улучшить, и то чтобы было более значимым вкладом в язык, а такого рода оптимизация, при общей бедности это является примером бесполезной оптимизации (но я таки уверен что была проблема с этим делом у какогото внутреннего проекта Гугла).

Ви помиляєтеся, у тій ніші, яку займає Го, паузи одна з головних бід.

Го задумувався як альтернатива С, а не Пітону. Як на мене, то він з цією задачею справився досить непогано. І весь плач про його примітивність йде саме від невірного бачення його природи. Це як говорити що нова само-віджимна швабра гірше робота-пилососа і які автори швабри ідіоти що зробили швабру а не пилосос.

Го задумувався як альтернатива С, а не Пітону.

Ніша Go якраз близька до Python та Java.
Відносно безпечне прикладне програмування.

Ніша Го це сервери, проксі та інші схожі штуки, по типу Nginx, Haproxy, vsftpd. Да, зараз на нього ледве не вордпреси переписують, але те не те для чого його проектували. Це підтверджують самі автори, кажучи що цілилися саме в С++ аудиторію, але аж ніяк не в Python.

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

А итогом Rust и Swift — эт современный С, а го — таки пиитон без блекджека и куртизанок.

Згоден, Раст виглядає круто. Але мені він здалеку (я з ним не знайомий достатньо) нагадує С++ своєю монстроподібністю.

І досі не можу зрозуміти чому Го порівнюють з Пітоном. За простоту?

Але мені він здалеку нагадує С++ своєю монстроподібністю.

И близко не рядом с С++. Rust, Kotlin, Swift — вот похожи весьма, как по мне, только последние 2 таки еще и с классами. Они больше похожи на С с генериками и блекджеком.

І досі не можу зрозуміти чому Го порівнюють з Пітоном. За простоту?

Питон нифига не простой. Го — простой, как рельса (т.е. как С), но безопасный (в отличии от С). Использовал питон именно из вашей аналогии в ответе на оригинальный коммент..

И близко не рядом с С++. Rust, Kotlin, Swift — вот похожи весьма, как по мне, только последние 2 таки еще и с классами. Они больше похожи на С с генериками и блекджеком.
Тоді круто.

шо ви людей Гамсуном і Трампом плутаєте?

Кроме 100-микросекундных пауз STW, в Go 1.8:
— увеличили производительность скомпилированных программ. Теперь они работают да 30% быстрее по сравнению с go 1.7
— увеличили скорость компиляции
— уменьшили в два раза накладные расходы на вызов С-функций
— оптимизировали кучу мест в стандартной библиотеке
— перевели бэкенд компилятора для всех поддерживаемых архитектур на SSA
— написали с нуля новый парсер go-кода, который работает быстрее предыдущего и показывает более качественные сообщения об ощибках
— добавили поддержку компиляции под новые архитектуры
— добавили поддержку кучи ассемблерных инструкций для работы с векторными данными на разных архитектурах
— добавили профилировщик мьютексов
— добавили поддержку динамической подгрузки внешних модулей (ака плагинов)
— улучшили поддержку http/2.0 и tls
— добавили sort.Slice, с помощью которого можно сортировать данные в одну строчку

Очевидно, что ничего не поменяли за полгода с момента выхода go 1.7 — просто переименовали go 1.7 в go 1.8 :)

— добавили sort.Slice, с помощью которого можно сортировать данные в одну строчку
github.com/...inikh/go-simple/issues/27
Пффффффф. Next level killer feature.
А вы говорили generics нужны.. Ещё пару версий и будет совсем как скала из коробки.

Иными словами добавили динамический подгрузчик модулей, http 2 и sort.slice — все равно печально

Да, унылые улучшения. Не то что implicit function types в scala. Интересно, сколько человек асилит прочесть до конца этот блогпост от автора Scala и какой процент из них поймет, о чем там речь?

Домохозяйки с волнением ждут filter в одну строчку кода в новой версии Golang.

Да, унылые улучшения. Не то что implicit function types в scala.
Та норм улучшение, позволяет еще больше сократить количество кода, оставаясь в рамках статической системы типов.
Интересно, сколько человек асилит прочесть до конца этот блогпост от автора Scala и какой процент из них поймет, о чем там речь?
Для тех кто не знает скалу и что такое имплиситы, очевидно что будет непонятно. Для тех кто знает — там нету ничего особо сложного.

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

Че там небось структуры выпилили с интерфейсами и дали возможность все делать на примитивах, для одаренных?

ассемблер наше все! быстрее ничего не будет

Да, поэтому в «следующая ступень программисткой мысли» по всей видимости сведется к выпиливанию всех типов данных кроме byte[] - размер мануалов на стандартной либе будет урезан процентов на 50%, а у Гошников есть все, что им надо что бы эффективно работать и не острелить себе ногу.

от вы ржете а я слышал про людей что так на java пишут

Разработчики go с вами полностью согласны — golang.org/doc/asm

Нет. Сделали возможность писать как в плюсах последних: а ну, угадай язык программирования по исходнику.

Исходник очень лаконичен, не смог обнаружить ни начала ни конца программы,полагаю это го.

Отлично. Можете пряник взять с полки, нашли письмо за 2011 год.
codahale.com/the-rest-of-the-story

є тільки один Дональд, а це якась лєвізна

На го так и не перешли, fail.

получается, что они не осилили, ни то. ни другое)) двойной фэйл)

В 2011 году go еще не вышел в релиз, поэтому они вернулись со scala на java. Сейчас небось уже на go сидят.

на java вроде
вообще откат на java стал сильно чаще как 8ка вышла

А вот я не понимаю, еси уже откатываться, то почему не котлин? К жабоэкосистеме не причастен, посему моя не понимать. У жабы 8 таки функции первого класса высшего порядка ужасны.

Котлин рискованней, и бенефиты не столь очевидны (перед 8-кой).

в котлине бабок нет

отлин рискованней, и бенефиты не столь очевидны (перед 8-кой).

А в чем риски-то? Бенефиты, как раз, очевидны. Нормальные функции высшего порядка и type inference, чтобы не писать монстров, как в жаба 8. Код, в общем случае, получается более короткий и элегантный, чем на жабе, чем-то приближается к скале по красоте.

А в чем риски-то?
Риски после скалы, нород думает как бы чего не вышло, и зачем оно надо.
Вообще рекламы-маркетинга пока не особо хватает.

Их микрософт купил и им стало ничего не надо :)
Вот обрывочные сведения: www.quora.com/...ology-stack-behind-Yammer

Так то некрафилить уже просто некрасиво, фу.

making.duolingo.com/...duolingos-engine-in-scala

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

Там на протяжении всего поста чувствуется, что его писали люди, недавно заболевшие скализмом головного мозга. Надеюсь, болезнь не безнадежна и скоро они осознают, во что вляпались. Ждем еще один пост о переходе на go от ниасиливших scala.

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

P.S Скалисты используют скалу как инструмент, а не как объект срача на форумах. Того же и вам желаю с го

Зачем тратить драгоценное время на изучение scala — мертвой ветви эволюции языков программирования?

— scala — очень сложный язык программирования, который многие не могут асилить

— при программировании на scala 90% времени тратится на ментальную маструбацию вида «как бы тут посложнее запутать код, чтобы меня считали гуру scala» или «какой из сотни возможных вариантов лучше использовать для данного участка кода?» и только максимум 10% времени тратится на собственно написание кода

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

— программы на scala компилируются вечность

— прогоаммы на scala обычно получаются тормозными и жрущими память

— при деплое программ на scala нужно заливать на сервер сотни левых зависимостей. И не дай бог ошибиться с версией хоть одной зависимости (привет, jar hell и jvm hell)

— в большинстве случаев невозможно перевести программу на scala с большим количеством внешних зависимостей на новую версию jvm/scala. Для этого нужно дождаться, пока авторы всех зависимостей соизволили портировать их на новуб версию scala/jvm. А это на практике малореально.

— scala — очень сложный язык программирования, который многие не могут асилить

Т.е. то, что часть из вайти в айти — хомо эректус, неспособные думать, а способные только копипастить — это пробелма языка? Мне ваш дискурс очень напоминает дискурс иосеров: (обжс против обжс с синтаксисом свифта против свифта, как надо). Во время одного из моих срачей те же самые аргументы, как и вы, приводили фанаты свифта, которые свифта-то толком и не знают и не используют возможности языка.

— при программировании на scala 90% времени тратится на ментальную маструбацию вида «как бы тут посложнее запутать код, чтобы меня считали гуру scala» или «какой из сотни возможных вариантов лучше использовать для данного участка кода?» и только максимум 10% времени тратится на собственно написание кода

Я, конечно, понимаю, что в Го других вариантов, кроме ХХП нет, т.к. парадигма языка такая, но в абсолютном большинстве других языков таки сначала думают, а потом делают, а не копипастят код повсюду.

Заметьте, вы свободу выбора в решении задачи выставляете, как минус. Т.е. тот же С++ или лисп тогда, в вашем понимании — это вообще ад, т.к. возможнотей-то там поболе будет, чем в скале.

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

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

Заметьте, вы свободу выбора в решении задачи выставляете, как минус. Т.е. тот же С++ или лисп тогда, в вашем понимании — это вообще ад, т.к. возможнотей-то там поболе будет, чем в скале.
Да

пару уточняющих комментов

— scala — очень сложный язык программирования, который многие не могут асилить

Это действительно так. Корень зла в том что можно вполне продуктивно писать полностью не осиливая, а используя небольшой сабсет фичь. Проблемы начинаются когда приходиться иметь дело с кодом который использует продвинутые фичи. Так все статьи про перешедших на го какраз из за этого.
при программировании на scala 90% времени тратится на ментальную маструбацию вида «как бы тут посложнее запутать код, чтобы меня считали гуру scala» или «какой из сотни возможных вариантов лучше использовать для данного участка кода?» и только максимум 10% времени тратится на собственно написание кода

Не «по сложнее» а наоборот «по элегантнее», изучая более продвинутые фичи и альтернативные подходы к написанию кода, старый свой код начинает видится как некрасивое овно. Потому местами нород тратит время на переписывание. Про 90% времени, конечно бред.
в большинстве случаев код на scala получается сложным для понимания и дальнейшего сопровождения
См пункт 1.
программы на scala компилируются вечность

Вопрос кривости рук настройки сбт и репозиториев. У нас одно время тоже «компилировалось вечность», пока какойто умник не сделал локальный прокси на репозиторий либ. Все вдруг полетело. Тоесть время не самой компиляции было длинным а скачиванием либ. Сейчас компиляция и запаковка модуля сноля занимает чтото типа минуты. И секунд 20 иннкрементал. Дольше чем джава и го, но никак не «вечность».
прогоаммы на scala обычно получаются тормозными и жрущими память

Вообще да, возможность написать одной строчкой кода то что в го занимает экран имеет свою цену. Цена заключается в куче неявных выделений кучи анонимных классов. Однако имея мозг на плечах, вполне можно ситуацию поправить в тех местах где это нужно. В крайнем случае можно всегда кусок кода на джаве написать.
при деплое программ на scala нужно заливать на сервер сотни левых зависимостей. И не дай бог ошибиться с версией хоть одной зависимости (привет, jar hell и jvm hell)

Проблема с зависимостями таки есть, однако про чтото кудато заливать на сервер — первый раз слышу. Все зависимости указываються в билд файле, и потом билд система все пакует в один архив, никуда ничего специально заливать не нужно.
— в большинстве случаев невозможно перевести программу на scala с большим количеством внешних зависимостей на новую версию jvm/scala. Для этого нужно дождаться, пока авторы всех зависимостей соизволили портировать их на новуб версию scala/jvm. А это на практике малореально.

Перевести на новую версию jvm — вооще бред какойто, без каких либо проблем все переводиться , и всегда переводилось, жвм изначально делалась совместимой, чего не скажеш о других системах.
Переводить на новую версию скалы — да есть проблема, с либами. Но не так малореально, народ таки по чуть чуть переводит основные либы на новые версии скалы.
Перевести на новую версию jvm — вооще бред какойто, без каких либо проблем все переводиться , и всегда переводилось, жвм изначально делалась совместимой, чего не скажеш о других системах.
Если все так радужно с обратной совместимостью разных версий jvm, почему многие проекты до сих сидят на java 6 и java 7, в то время как java 8 вышла несколько лет назад? Да и каждая версия scala, насколько я знаю, намертво привязана к конкретной версии java. Где-то недавно читал, что новая версия scala наконец-то перешла (или собирается переходить) на java 8.

В go с этим проще — вот неделю назад вышел go 1.8 — и все желающие уже перешли на него, т.к. для этого достаточно перекомпилировать проект новой версией go. Менять ничего не нужно ни в своем коде, ни в сторонних библиотеках.

почему многие проекты до сих сидят на java 6 и java 7, в то время как java 8 вышла несколько лет назад?

Код скомпилировный для джавы 6 будет успешно работать и на 8-й джвм. Не переходят потому что не хотят переходить, бояться лямбд, новых фичь, и стабильности новой платформы вообще.
Да и каждая версия scala, насколько я знаю, намертво привязана к конкретной версии java
Ноуп.
Где-то недавно читал, что новая версия scala наконец-то перешла (или собирается переходить) на java 8.
Имелось ввиду юзать новые фишки жвм которые ускоряют производительность.
Оно все обратно не совместимо — код скомпилированый 8-ой джавой не будет работать на 6-й джвм. Со скалой тож самое, если она таргетит 7-ую джвм, то на 6-ой джвм код работать не будет, но он прекрасно будет работать на 8-ой джвм.

С самой скалой однако есть проблемы, код скомпилированый под 2.10 не будет нормально работать с кодом скомпилированным под 2.11

Не переходят потому что не хотят переходить, бояться лямбд, новых фичь, и стабильности новой платформы вообще.
Ну вот видите, а в Go — бояться вообще нечего, преимущества очевидны.
В go с этим проще — вот неделю назад вышел go 1.8 — и все желающие уже перешли на него, т.к. для этого достаточно перекомпилировать проект новой версией go.
Це каже лише про косметичні зміни в релізі.

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

Если для вас следующие изменения в go 1.8 являются косметическими, то ОК:

— уменьшение задержек GC с десятков миллисекунд до сотен микросекунд;
— увеличение производительности скомпилированных программ до 30%;
— уменьшение времени компиляции программ до 20%;

Так, це, як на мене, фапання на хайп. Це таке собі ментальнодрочерство. Все дуже просто, ви не отримуєте щось, що зможе істотно поліпшити ані ваш код, ані його підтримку. Вам пропонують пограти в гру «хто швидше відріже собі палець». Наче й переможець є, але якось без кінцівки не дуже зручно тепер.

Ці всі відсотки «перемоги» — виключно маркетинговий хід. Він дуже ефективно працює на напівсліпих фанатів, тому що вони будуть носитися з цими безглуздими цифрами як дурні зі ступою. Через деякий час в фанів настане прозріння, але ринкова доля вже буде захоплена. Історія з хромом повторюється, тільки тепер в його ролі go.

Если вы не понимаете бенефитов такого подхода, это не значит, что их нет.

Вообще говоря, что С в свое время, что Го сейчас отодвигают индустрию на эпохи (с тз computer science) назад. И это печально.

Вообще говоря, что С в свое время, что Го сейчас отодвигают индустрию на эпохи (с тз computer science) назад.
Почему? Наоборот, благодаря С и Go на свет появилось много полезных программ, которыми все ежедневно пользуются.
Что, по вашему мнению двигает индустрию computer science вперед?
Что, по вашему мнению двигает индустрию computer science вперед?

Індустрія і computer science це дещо ортогональні речі. Індустрія сама по собі, наука десь далеко попереду (але частіше збоку від неї).

Вообще говоря, что С в свое время, что Го сейчас отодвигают индустрию на эпохи (с тз computer science) назад. И это печально.
Go — это движение в принципиально другом направлении, там реализованы подходы, поощряющие новые более перспективные практики программирования, новый взгляд на решение задач. Прежде всего, это параллелизм «из коробки», чего нет больше ни в одном промышленном языке. Современные процессоры не могут наращивать производительность до бесконечности повышая тактовую частоту и оптимизируя ядро, движение может происходить в сторону увеличения количества ядер. А значит жизнь требует новых подходов в программировании, более удобных для разработки многопоточного софта, в то время как во всех остальных промышленных языках приучили к «однопоточному» мышлению при написании софта. Go как раз решает эту проблему и открывает новые горизонты.

«параллелизм из коробки» (из либы) сделан много где. Сейчас не 2000 год, все-таки. Корутины — чуть ли не единственное, что мне в Го нравится, к слову. Хотя будь они сделаны отдельной либой, нравились бы больше.

«подходы, поощряющие новые более перспективные практики программирования» — это какие? Вездесущие «if nil == nil then return nil» ? о_О

А что не нравится — абсолютное отрицание всех идей, что появились после 70-х и перекладывают ответственность с программиста на компилятор, улучшают читабельность и поддержку (nil? generics? immutables? copy-paste-as-first-citizen? error handling? FP concepts?).

Проводя аналогию с цитатой Форда про автомобилей и коней, Го — более быстрая лошадь, и этим он тормозит развитие автомобилей, оттягивая ресурсы.

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

Ну вот это как раз 2-ой язык. Правда тут есть нюанс, что существует более 30 лет, и за это время заметного роста использования в проектах — не было. Возможно, из-за отсутствия поддержки и продвижения софтверным гигантом, а также не алголоподобным синтаксисом, получившим наибольшее распространение.

Проблема не в продвижении, проблема в моде.

Думаю синтаксис не исправил бы проблему

гоубои уже выяснили почему в соседнем топике в рейтинге языков го набрал целых 0.79% и занял почетное хрен знает какое место?

В этом топике четко прослеживается тенденция последних лет — доля go стремительно растет за счет доли scala.

Попробовал Atom, Visual Studio XCode c плагином для Go и Gogland от JetBrain.
Gogland от JetBrain лучше всего на сегодняшний день. Eclipsе не рассматривал, потому что плагин для Eclipse разрабатывал то же JetBrain.

Кстати, вот наткнулся на такой видос — www.youtube.com/watch?v=ic8ul45oBCc — и стало интересно следующее: разраб сего чуда (jgo)... смог ли он осилить и скалу, и го? или не смог осилить ни того, ни другого (ибо хз, развивается ли данный проект или нет...)? :-)

Кто что знает-думает по этому поводу?)

Выглядит как попытка скрестить ужа с ежом :) Вот их репозиторий на github — github.com/thomasmodeneis/jgo .

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

В полку ниасиливших Scala прибыло — movio.co/...blog/migrate-Scala-to-Go .

Недостатки Scala из статьи:
— медленная компиляция
— медленный деплой
— бессильность grep’а перед синтаксисом Scala
— сложность языка
— неадекватное коммьюнити, больное функциональным программированием головного мозга

Преимущества Go из статьи:
— простой в изучении (2 недели на изучение Go против полугода на понимание основ Scala)
— короткая и ясная спецификация языка
— легко читаемый код
— быстрая компиляция (пару секунд для кода на go вместо двадцати минут для кода на scala)
— программы на Go быстрее работают
— программы на Go требуют меньше памяти (our average Go docker container is 16.5MB, vs 220MB for Scala, we’ve had a major success when rewriting a crucial µs from Scala to Go and going from 4G to 300M for the worst-case scenario usage)

Классные цитаты из статьи:

What I would have done differently four years ago is use Java and not used Scala as part of this rewrite. [...] it would take an engineer two months before they’re fully productive and writing Scala code
It took some of us six months including some after hours MOOCs, to be able to get relatively comfortable with Scala. In contrast, we picked up ‘Go’ in two weeks
No map, no flatMap, no fold, no generics, no inheritance... Do we miss them? Perhaps we did, for about two weeks.
As it turned out, more flexibility led to devs writing code that others actually struggled to understand.
It’s not just the fact that channels and goroutines are cheaper in terms of resources, compared to threadpool-based Futures and Promises, resources being memory and CPU. They are also easier to reason about when coding.
Perhaps the fact that makes it simpler in ‘Go’ is that there’s usually one limited set of tools to work with, which you use repeatedly and get a chance to master. With Scala, there are way too many options that evolve too frequently (and get superseded) to become proficient with.

Я ни разу не фанат Скалы, но справедливости ради

полугода на понимание основ Scala
Лолшто?

Скала в режиме «улучшенная джава» учится за одну неделю максимум. Никто не заставляет учить теорию категорий и писать все с использованием scalaz.

Из опыта:

— медленная компиляция
Да
— бессильность grep’а перед синтаксисом Scala
Да. Уж очень он verbose. Тот же Хаскель ощутимо проще по синтаксису.

Имхо, если хочется адекватного компилируемого языка со статической компиляцией, вменямой системой типов и хорошим соотношением скорость_выполнения/память, стоит посмотреть на OCaml или Rust. У них есть свои особые моменты, увеличивающие порог вхождения (особенно у первого), но ничего экстраординарного.

Про Го ничего не скажу, хорошая игра вроде :P

Если отсутствует нeнависть к динамической типизации, то я бы советовал поиграться с Clojure/ClojureScript.

Скала в режиме «улучшенная джава» учится за одну неделю максимум. Никто не заставляет учить теорию категорий и писать все с использованием scalaz.

Неделя это для каких-то совсем основ, дальше идут куча неочевидных и редкоиспользуемых (для джавистов) фичь. Проблема возникает когда какойто умник прочитал про фичу, и начал ею пользоваться, другой чел, который фичу или такое ее применение не знает — код сходу не поймет ъ.
Скала в режиме «улучшенная джава» учится за одну неделю максимум.
имхо, в режиме «улучшенная джава» лучше учить не скалу, а котлин) вот его-то (по крайней мере базовые вещи) думаю точно за неделю можно выучить) ну или груви)
Если отсутствует нeнависть к динамической типизации, то я бы советовал поиграться с Clojure/ClojureScript
плюсую) плюс добавлю, «если отсутствует ненависть к скобочкам» :)

Так скобочек в кложуре в среднем меньше, чем в аналогичном коде на джаве =)

ну я имел ввиду «лисповый характер» скобочек, а так да. =)

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

— Вам не казалось что мерят популярность языка, первая версия которого вышла в 2003 году, по количеству написаних библиотек, довольно тупо. Так как большинство уже давно написано, и развивается. В отличии от го, где экосистема еще только растет + да и не стоит умалчивать про проблемы с пакетными менеджерами.
— Замеры в интернете, который показывают пинг-понг между горутинами и особенно хайп вокруг gc, просто уже задолбал. Вам не кажется что те цифры что вы называете, в продакшене будут немного поумеренней, из-за наличия все таки полезной работы. А чудо-gc, вызывает только одну улыбку, да бы любой человек понимающий немного о gc, знаем что ничего не дается бесплатно, если есть перевес в сторону коротких задержек, значит будет ограничение в пропускной способностью
— Ссылки которые вы скинули с quora, вы их вообще открывали ? Linkedin успешно держить нагрузку на scala, при этом один из инструментов kafka вообще уникальный среди всех существующий брокеров, и он написан на scala.

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

Извините если слишком агресивно, но было бы здорово если бы пересмотрели свои взгляды на продвижение go на dou.
Варианты:
— создать топик «Новости Go»
— еженедельный или месячный дайджест про Go

Картиночки для вброса:
pbs.twimg.com/...C3M9ThVWAAAo3VV.jpg:large
pbs.twimg.com/...C3M9ThVXAAAV7jE.jpg:large

блин, я как раз себе для scala-gopher [ github.com/rssh/scala-gopher ] иконочку думаю нарисовать. Есть ли такое со счастливым сусликом ?

Извините если слишком агресивно, но было бы здорово если бы пересмотрели свои взгляды на продвижение go на dou.
Варианты:
— создать топик «Новости Go»
— еженедельный или месячный дайджест про Go
Да, вот как по джаве, например. Без «все козлы, а Го — моя прелесть», а что-то по разделам:

— Новичкам
— Новинки, тренды
— Истории успеха
— И т.п.

см. мой ответ на идентичный комментарий — dou.ua/...orums/topic/6028/#1056361

Спасибо за идею насчет дайджеста по Go. Нужно попробовать.

Особенно понравилось

— бессильность grep’а перед синтаксисом Scala
Использовать grep для регулярного поиска по коду в 2017, серьезно?

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

Дальше сплошные «гиперболы»:

— простой в изучении
Если в бекграунде только QBasic с пхп, то да, Го проще. Если есть хотя бы опыт с Джавой — нет. Какие пол-года?
— легко читаемый код
Уж это точно не плюс Го. Императивная портянка с тонной «if nil return nil».
программы на Go быстрее работают
Просто ложь.
— программы на Go требуют меньше памяти
Ситуативно. И уж явно бредово меряться образом докер контейнера.

Общее впечатление от статьи — 4 человека с бекграундом в бейсике и пхп купились на хайп и начали писать на Скале. Что же могло пойти не так?

Бла-бла-бла без аргументации. А чем подкреплены ваши слова? Может это у вас ложь, простите.

Это про скорость Го против Скалы?
1) Оригинальный коммент именно что без аргументации, просто вброс.
2) На разных бенчмарках они показывают разные результаты. Ну и не стоит забывать, что бенчмарки крайне сложно сделать так, чтобы все остались довольны — например, в сравнении горутин с акка акторами замена последних на футуры сразу выводит скалу в лидеры. Почему-то этот PR не приняли. Я бы сказал, что «в среднем по палате» скорость абстрактного чего-то у Скалы и Го примерно одна.

И уж явно бредово меряться образом докер контейнера.
Размер докер контейнера отражает реальный размер программы вместе со всем необходимым окружением. Как видно из статьи, в среднем программы на go занимают в 15 раз меньше места, чем программы на scala:
our average Go docker container is 16.5MB, vs 220MB for Scala

Также кроме докер контейнера они измеряли потребление памяти при работе программы:

we’ve had a major success when rewriting a crucial µs from Scala to Go and going from 4G to 300M for the worst-case scenario usage

Т.е. после перехода со scala на go потребление памяти снизилось более чем в 10 раз.

Общее впечатление от статьи — 4 человека с бекграундом в бейсике и пхп купились на хайп и начали писать на Скале. Что же могло пойти не так?
Теперь они купились на другой хайп и начали писать на Go :)

Новая статья о том, почему вы должны учить Go — Why should you learn Go?

Там учить особо и не нужно, просто начинать писать

И как всегда неправильное позиционирование

чем горутины лучше Akka? и почему их сравнивают с обычными потоками, а не той же Akka при сравнение со scala или java?

Горутины — это обычные потоки с точки зрения программиста, пишущего на Go. Поэтому они предоставляют основное преимущество программирования потоков перед событийным асинхронным программированием (Akka) — простой и понятный линейный синхронный код, который легко поддерживать, дебажить и расширять.

В дополнение к этому горутины предоставляют два дополнительных преимущества, благодаря которым программа на Go может спокойно работать с миллионом одновременно запущенных горутин:
1) Меньшие накладные расходы на переключение между горутинами, т.к. в большинстве случаев переключение происходит непосредственно в программе на Go без перехода в режим ядра операционной системы, в отличие от потоков.
2) Динамически растущий стек для каждой горутины, начальный размер которого составляет 2Кб. Это в 1000 раз меньше стандартного стека для потоков, размер которого фиксируется при старте потока.

чем использование горутин отличается от использования генераторов/await в шарпе/ноде/питоне?

При программировании на Go не нужно помнить, где именно использовать генератор или поставить await / async / yield — за вас это делает компилятор, который ошибается намного реже среднестатистического программиста.

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

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

LiteIDE прекрасный редактор и отладчик для Go.

Деякі неофіти нам тут розказували що для го ні ІДЕ, ні дебагер не потрібні — просто пишеш на го, а воно вже без помилок і працює.

Без IDE писать можно не только на Go, и всё будет работать... Но с IDE дебажить несомненно лучше :)

А у мене таке враження що поки Пайк не скаже що ІДЕ і дебагер це добре чи погано гошніки так і будуть ніяковіти при обговорені цих тем.

Видимо Google просто не хочет вкладываться в разработку этих инструментов, тем более что VS они всё равно не догонят. Ну могли бы и плагины для VS намутить.

Видимо, Google платит Microsoft и JetBrains за разработку IDE с дебаггерами. Бюджет же на раскрутку большой — могут себе позволить оплачивать разработку инструментов для Go на стороне.

Как я понимаю плагин для vscode делали не Microsoft, а любители на github. Jetbrains будет продавать свою ide за реальные $ , у языка все же есть своя аудитория.

Как я понимаю плагин для vscode делали не Microsoft, а любители на github.
Только почему-то любители ведут разработку в аккаунте Microsoft — github.com/Microsoft/vscode-go , а большинство коммитов сделано «любителями», работающими в Microsoft — github.com/.../vscode-go/commits/master .
а большинство коммитов сделано «любителями», работающими в Microsoft
Если быть точным, одним любителем, что подтверждает тот факт, что упоротые гоубои, увы, разбрелись по топовым конторам и занимаются херней.

Про успех гошечки в экосистеме MS можете начинать говорить, когда там запилят Go.NET

Про успех гошечки в экосистеме MS можете начинать говорить, когда там запилят Go.NET

вангую, что если найдуться такие разрабы, то они быстро забросят проект, ибо ниасилят ни го, ни си-шарп))))

Про успех гошечки в экосистеме MS можете начинать говорить, когда там запилят Go.NET
Успехом в MS смогут считать, если C# не выпилят, как в своё время, 10 лет назад, канул в аналы истории J#.

Они пока заняты переписыванием .NET и инфраструктуры туда-сюда-обратно, как всегда.

Не переписыванием, а созданием параллельной (опенсорсной, кроссплатформенной) реализации (форк). Только вот многие по-прежнему нос воротят. Все им не так )

Там не просто форк. В .net добавляют новые апи которые должны заменить традиционные базовые вещи — работа с буферами, строками, пирсинг примитивов и сериализация — все с нулевыми аллокациями и без копирования. прирост производительности во много раз в Бенчах. Мс достаточно серьёзно занялся вопросом производительности возможностей у языка намного больше чем у того же го. Посмотрим как быстрый гербедж коллектор на го сможет тягаться с дотнетом без аллокаций.

Просто я на микрософтовских технологиях был еще до появления .NET и видел подобные переписывания уже 3 раза, поэтому очень скептически смотрю на это все. Бизнесу такие метания дорого обходятся.

C# уж больно популярен и в опенсорс он уже перешел.

Ну подсветка и автодополнение — это конечно удобно, но ещё лучше было бы увидеть дебаггер, где можно устанавливать breakpoints, делать пошаговое выполнение, смотреть содержимое переменных. Пока что этого нет, и всё интересующее приходится писать в консоль в рантайме.

Интересно. кто-то юзал/смотрел ранний билд новой IDE-шки для Go от jetbrains — www.jetbrains.com/go ? как оно?

Сам не пользовался — как ниже заметил sanchez, мне достаточно vim + ctags — но другие говорят, что неплохой редактор. Вообще, в прошлом году еще один крупный игрок на рынке IDE обратил внимание на go — microsoft. В результате появился плагин для microsoft visual studio — github.com/Microsoft/vscode-go . Судя по отзывам, очень неплох.
Вся эта возня с IDE для Go среди крупнейших игроков рынка еще раз подтверждает, что язык пошел в массы, в отличие от Scala.

З тими ресурсами, що виділяються на його розкрутку, що хочеш піде в маси...

Грошові, людські, серверні.

1) Почему мне ничего не перепало из бюджета на раскрутку go?
2) Где эти люди, которые рекламируют go за деньги?
3) Где эти серверы, выделенные для продвижения go?

Вот-вот, где эти серверы, выделенные для продвижения go?

Тому що ви працюєте не в Гуглі ;)

но другие говорят, что неплохой редактор
я в одном подкасте (Radio-T) в одном из последних их выпусков (вроде в последнем выпуске упоминули) слышал, что Gogland еще сырой. В общем надеюсь, что когда выйдет релиз этой идешки — сделают и Community версию.
В результате появился плагин для microsoft visual studio — github.com/Microsoft/vscode-go
ну это плагин не для IDE, а для редактора.
Вся эта возня с IDE для Go среди крупнейших игроков рынка еще раз подтверждает, что язык пошел в массы, в отличие от Scala
ну для VS Code я видел плагины и для скалы ( marketplace.visualstudio.com/...t=VSCode&sortBy=Relevance ). Думаю плагин для Scala и для Atom’а есть. Поэтому у меня подозрение, что по плагинам и средам разработки Scala и Go идут «ноздря в ноздрю». :)

Вообще Визуал Студию юзать удобнее, чем VSCode. Не понимаю, зачем вообще VSCode нужен, я поставил студию себе на виндовый планшет на базе процессора Atom, и всё отлично работает. Компилирует крупные проекты чуть медленнее, чем на Core i7, но разница во времени не столь критична.

ну для VS Code я видел плагины и для скалы ( marketplace.visualstudio.com/...t=VSCode&sortBy=Relevance ). Думаю плагин для Scala и для Atom’а есть. Поэтому у меня подозрение, что по плагинам и средам разработки Scala и Go идут «ноздря в ноздрю». :)
Прикол в том, что плагин для Go разрабатывается от имени Microsoft — см. ссылку сверху, а плагин для scala — от имени какого-то чувака.

Ну подсветка синтаксиса в визуал студии — и так работает, дальше выполнение команд build, rebuild и clean — настраиваются на выполнение go build, go install, go fmt, и можно удобно работать с проектами, как с обычным кодом C/C++. Разве только точек останова и трассировки нет.

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

А как получили билд? Заполняли early build форму? Как долго ждали?

Да, там надо на сайте их заполнить форму. Ответили вроде через неделю или две, уже не помню, и прислали ссылку на скачивание.

upd.

Заполнял их форму сразу после резила, ничего не приходило.
Заполнил снова и сразу пришла ссылка на почту.

<mode=av>
Фальшивый блеск и реальная нищета Goʼшного GC.
habrahabr.ru/...mpany/mailru/blog/318504
</mode>

Уже было — dou.ua/...rums/topic/16012/#1042597 . Там же и разоблачение этой заказной статьи (заказчики — адепты Scala, Java и JVM, озлобленные тем, что gc в go на три порядка быстрее их супер-навороченных gc)

Ага-ага, опять заговор и враги :)

Поскольку мой комментарий был удален (абсолютно заслуженно, так как содержал табуизированную лексику) предлагаю такой вариант развития событий erlach.co/pr/62u :-)

Aliaksandr Valialkin пойдет вторым.

Почему не первым? Обидно (
Не совсем понятны критерии отбора кандидатов.

У Пайка хоризма длиннее.

Я посмотрел эту штуку github.com/valyala/fasthttp
Годнота.
Задрочил все на преалоцированых буферах, избегаешь копирований, все правильно сделал
Держи звезду
net/http был аномально плохой, в три раза хуже Erlang.

Google выпустил транслятор из Python в Go — opensource.googleblog.com/...py-go-running-python.html . Ждем транслятор из Scala в Go :)

Тонко)

кто и зачем апнул топик ?)
вместо того, что б допилить один проджект, ушел учить GO поприколу ;) долго держался пытаясь вообще в него не лезть, но некогда приобретенный опыт намекает: что бы не замарачиваться поискам «Мама, я думаю это та самая единственная платформа под которую я хочу кодить до самой старости» и прочими холиварами, проще завести гарем и просто выучить что-то ещё для галочки.

стоны обиженных scalaz и проклятыми функциональщиками, рассказы про то как ’да я уже 7 (семь Карл) лет программирую и прочие стоны обиженых
ой вэй, жестко таки ГОшников erlang-исты, везде где не увидят гоняют, вот они злые такие ;)

да вот пока подсознание пытается научиться филосовски, с пониманием и толерантростью относиться к golang.org/...ef/spec#Type_declarations и golang.org/doc/faq#inheritance , лично я всё-же решил вернуться к основной JVM-рутине, но для «галочки», Go докурю ;)

После Go будет сложно вернуться на JVM, т.к. в Go есть:
— Настоящие first class functions, а не Runnable пародия из Java 8.
— Настоящие интерфейсы, а не пародия из Java, где их нужно явно перечислять для каждого класса, где они реализуются.
— Настоящие горутины, а не Thread-пародия из Java, из-за которой приходится создавать кучу асинхронного говнокода с кучей багов, который сложно дебажить, поддерживать и расширять.
— Настоящие channel’ы с возможностью ожидания сразу на нескольких channel’ах, а не BlockingQueue-пародия из Java.

Также в Go нет бесполезных штук из Java:
— Наследования, которое давно признано худшей идеей ООП.
— JVM&jar hell’а, т.к. программа на Go собирается в один самодостаточный исполняемый файл.
— Тонн бесполезных абстракций с паттернами проектирования.

После Go будет сложно вернуться на JVM
это вряд ли ;) Go приходят и уходят, а как enterprise, так и обычный потребитель, всё более и более будет нуждаться в адекватных IT-решениях, однако, лишний раз в этом:
PS Действительно секта какая-то, не поверишь пока сам не столкнешься.
лишний раз убедился ;)

не, с Go разберусь полюбому, ибо язык от бога, но это так, по фану

Это Ритчи можно было богом считать (и он в эту херню не полез), а тут — сборище диверсантов, оживляющих замшелые идеи 70-х.

Еще замшелые идеи 70-х от тех же диверсантов:
— Си, на котором до сих пор пишутся большинство ядер операционных систем и embedded софта.
— unix, благодаря которому сейчас есть linux, android, macOS.
— BSD license, благодаря которой теперь Microsoft входит в топ open source контрибьюторов.

Си, на котором до сих пор пишутся большинство ядер операционных систем и embedded софта.

То-то основной автор Ритчи не захотел участвовать в этом go-безобразии.

BSD license, благодаря которой теперь Microsoft входит в топ open source контрибьюторов.

BSD license никак не их разработка — это требование правительства США, которое не допускало закрытия того, что писалось на госденьги. (Вот нам бы так. Но это по любому не проблема конкретных людей.)

А при чём тут Microsoft?

unix, благодаря которому сейчас есть linux, android, macOS.

Единственное, что хоть как-то можно связать с нынешними авторами. И не имеет к Go никакого отношения.

Что ж, пытайтесь дальше натянуть сову на глобус :)

Еще идеи от диверсантов, разрабатывающих Go:
— unicode и utf8 от Rob Pike
— memcache и livejournal от Brad Fitzpatrick
— Java HotSpot и v8 для js от Robert Griesemer
— re2 от Russ Cox
— современные расширения tls и прочая прикладная криптография от Adam Langley.

Это вам не ангуляры с реактами и ноджсами пилить, которые устаревают, не успев выйти в релиз.

Кстати, tls от go быстрее, чем tls в nginx — blog.gopheracademy.com/...16/tls-termination-bench . Поэтому для веб-приложений на go нет необходимости в tls termination и в nginx/apache/haproxy.

Кстати, насчёт tls. Я на днях решил запилить сервер под https, и вобщем-то с этим никаких проблем не возникло, достаточно заменить ListenAndServe на ListenAndServeTLS, и написать пару параметров. В то время, как для той же задачи на C++ потребовалось бы для начала скомпилировать и подключить либу openssl, причём она так просто с 1-го раза раньше не компилилась, для этого нужны танцы с бубном, потом ещё написать кучу кода. Ну а здесь всё сразу заработало. Проблема только в том, что стандартная библиотека Go поддерживает довольно ограниченное число алгоритмов для генерации/чтения SSL-сертификатов, и так просто любой произвольный сертификат поэтому подставить не выйдет.

Насчет настройки tls в Go есть хорошая статья от CloudFlare — blog.gopheracademy.com/...osing-go-on-the-internet .
В Go поддержка tls на самом высоком уровне — см., например, результаты тестирования одного из наших серверов — overall rating — А . Попробуйте сравнить с каким-нибудь nginx или apache сервером — результаты будут неожиданными.

проще завести гарем и просто выучить что-то ещё для галочки.
С этой точки зрения го какраз бесполезен, ибо он несет ничего нового вообще совсем.
Таже тупая ручная императивщина с сборщиком мусора, вид сзади.
Например ФП принципиально иная парадигма, дающая совершенно иной ракурс на привычные вещи, потому для расширения кругозора ей таки имеет смысл заморочиться.

ФП — для любителей матана, витающих в облаках. Для программистов-практиков оно абсолютно бесполезно.

Немного не соглашусь, фп, правда в своеобразном виде, вполне процветает в последнем ангуляре : )

btw, смотрите какая прелесть: github.com/glycerine/zygomys
лисп компилируемый в го

ФП — для любителей матана, витающих в облаках.
Воно точно не для тих, в кого ООП головного мозку. :D

Гошники презирают ООП точно также, вы шо, там же паттерны, умные слова.

интересно, кто-то из местных использует golang для ML?

а зачем?

даже гугл этого не делает

Просто предположил, раз go такой быстрый и простой. Библиотеки так-то к нему есть. Комьюнити его обожающее тоже. Вот и любопытно стало. Я кроме веба ещё обработкой текста занимаюсь, хочется в будущем через ML развиваться в этой теме, вот и присматриваю на чем это делать, Python/Scala/плюсы etc. Чисто как бэк голанг мне точно не интересен, мне хватает .net’а с головой.

Я кроме веба ещё обработкой текста занимаюсь
мне хватает .net’а с головой
Аналогично.
Только я сделал небольшое исследование на предмет на чем же писать следующий text processing service. В начале очень уж хотелось запилить порт ntlk на .Net Core- но в итоге понял что проще уж на java веселье устраивать- там есть парочка отличных либ для этого.

А вот на Go я смотрю с не особым доверием. Текущее состояние языка и его развитие и хайп уж очень мне напоминает php в 2000-х

Обидно немного, что на .нетах как-то не развилась активно тема с ML, мне вообще шарп больше всего нравится из всего что пробовал

Кстати, ваш профиль (я смотрел его когда вы отписывались в теме с обработчиком текста на правилах) меня склоняет в сторону указанного в нем стека) Судя по посту 2013 года, когда оценивали технологии, и к чему пришли сейчас, стек прошел испытание временем

Обидно немного, что на .нетах как-то не развилась активно тема с ML,
Да, есть такое.
Мой стек долгое время оставался довольно прост:.Net и разные базы данных.
Еще до того как познакомился с NLP- собирал aлгоритмы со всяких white pages — реализовывал в своём проекте.Вот тут libgen.io нашел довольно много полезного.
Проект прошел довольно эпичный путь. Начинал разработку как обычный новостной агреггатор. (В то время были популярны типа редтрам и других) Даже привлек внимания Microsoft (они тогда набирали в бинг)В итоге запустил свой агрегатор новостей. Случайно упоминул о нем у себя в наработе в Люксе- так потом даже небольшая удитория появилась у аггрегатора.
А позже этот проект уже дорабатывал под финансовые новости/сводки. под заказ для одного крупного инвест банка( я когда -то об этом тут писал) системой даже какое-то время пользовались для тех анализа. но потом заказчик неожиданно купил готовое решение намного более крутое чем было у меня.
Выводы которые я сделал.
+ .Net отличная платформа.
+ C# язык позволяющий вести rapid development
— для NLP не хватает нормальных библиотек- все приходится писать либо самому либо пилить костыли по вызову java программ.
— нет доверия к платформе .Net у заказчиков из финансовой отрасли которые занимаются NLP, ML, AI. Там прочно сидят java, python, Julia, R и другое по мелочи.
— очень на хватало биндингов к всяким биг дата тулам- да и сами тулы в основном на java

Тут долго можно расписывать.
Мне очень нравится идея .Net Core. думаю это даст толчок развитию всего не достающего на .Net платформе. Но после того как я пару недель назад сам пощупал этот .Net core- понял — что он сырой еще от слова- совсем.

Я кстати последние несколько месяцев только на core и пишу бэк. В целом, мне очень нравится, но с инфраструктурой пока тяжеловато — с тем же ef.core приходится иногда очень извращаться. Но на старую платформу уже как-то не хочется.

А чем вообще в последнее время занимаетесь? Поле работ, так сказать

А чем вообще в последнее время занимаетесь
В мае этого года завершил агрегатор online casins and game jackpots comparison and prediction. Опять же использовал всё теже свои наработки по парсеру. Как известно онлайн казино очень редко пишут свои игры- они лишь организовывают площадки для игроков под своими брендами.
Вот тут самое интересное и начинается. Имея аккаунты в нескольких казино и собирая истории игры- можно попытаться предскагзать примерное время следующего джекпота.Это как то более или менее работает. Но тут пришлось конечно повозится с обходом их защиты от ботов.
Получился набор сервисов для мониторинга около сотни онлайн казино. Было интересно — так как выудил что многие грешат созданием рескинов к одной и той же платформе.

За время этого проекта понял что мне не хватает знаний- потому пошел на курсеру. заодно пару сертификатов получил.

Между делом готовился к слудующему проекту- изучал проекты Palantir (точнее крохи которые доступны). Но после того как один из их сотрудников написал в линкедин- типа что ищешь? — я как то даже расстерялся. Как эти рабята узнали что я собираю инфу о них и как меня нашли не знаю. Ну я сейчас нг близко да и по основной работе дел куча

Довольно интересно : ) А какие курсы проходили?

И спасибо за наводку на палантир, будет о чем почитать

мне очень не хватает фундаментальных знаний так как учился в крымском универе где никто и не слышал про computer science. Набив шишек «велосипедостроением» начал шерстить алгоритмы, теорию вероятности, ну всякие структуры данных.
Из того что прошел:

1 Data Structures and Performance
2 Advanced Data Structures in Java
3 Algorithms: Design and Analysis, Part 1
4 Algorithms, Part I by Kevin Wayne, Robert Sedgewick
ну и знаменитый вводный курс Andrew Ng

понял, спасибо)

я вот планирую с этим побаловаться:
fr.coursera.org/...tions/data-science-python

Не Севастопольский НТУ случайно?) У меня детство в Ялте прошло, так половина моих знакомых поступила в Ялтинский менеджмента, а технари в этот севастопольский

да, вот уж мир тесный.
ЯУМ- он самый. Ялтинский Институт Менеджмента как бы сам себя говорит. Я там учился на „компьютерных науках”
В севастопольский заборостроительный по семейным причинам не вышло поступить.

я вот планирую с этим побаловаться
Да должно подойти для начало- хотя мне больше курс Andrew Ng нравится

Вот мой todo список:

  • Data structures: Measuring and Optimizing Performance
  • Object Oriented Programming in Java
  • Java Programming: Principles of Software Design
  • Java Programming: Solving Problems with Software
  • An Introduction to Interactive Programming in Python
  • Principles of Computing
  • Algorithmic Thinking
  • Developing Data Products
  • The Data Scientist’s Toolbox
  • Machine Learning Foundations: A Case Study Approach
  • Data Science Specialization
  • Heterogeneous Parallel Programming
  • R Programming
  • Getting and Cleaning Data
  • Exploratory Data Analysis
  • Reproducible Research
  • Statistical Inference
  • Introduction to Big Data
  • Introduction to Big Data Analytics
  • Java Programming: Object-Oriented Design of Data Structures Specialization
  • Capstone: Analyzing (Social) Network Data
  • Introduction to Recommender Systems
  • Java Programming: Arrays, Lists, and Structured Data(Link)
  • Data structures: Measuring and Optimizing Performance
  • Python Data Structures
  • Machine Learning: Regression
  • Practical Machine Learning

О, приятно встретить кого-то с родных мест. Я сначала каждое лето туда ездил, к отцу, а потом на несколько лет совсем переехал, привет 15-ой школе им. Руданского. А в старших школах ездил чтоб на стройке поздаработать)

Кстати, спасибо за список. У меня два диплома, по одному инжинер-оптик, по другому физик, но как-то лучше всего получалось с прогой (кодил модули под автокады на лиспах, в лабаратории баловался с R, дип.проекты включали разработку ПО, обработку изображений). Увы, изначальную нехватку знаний компенсирую уже второй год постоянным самообучением)

Я успел годик отработать в Промте, занимаются машинным переводом (люблю иностранные языки). Парсерами баловался. Сейчас отошел больше в стандартный стек. Но мне nlp понравилось, так что потихоньку буду прокачивать скилл, пока на пет-проектах.

тут непочатый край ))) нлп — это счас или питон или джава. на джаве простора больше потому что нлп развивается в сторону фрейморков обработки неструктурированой информации типа УИМА и ГЭЙТ а они принимают джава или С++. на питоне остались только ntlk который хорош и развит, но следующий уровень абстаркций пока на нем не доступен. Если джавой не занимались то лучше продолжать питон, джава счас обросла фрейморками которые сами по себе требуют год на изучение. Питон -он очень хорош для парсингов, нлп и машин ленинга.

За УИМА -спасибо. Раньше об этом не слышал.
Пока что присматривался к open nlp и stanford nlp.

Если джавой не занимались то лучше продолжать питон
После шарпа- мне на много проще было начать использовать джава. Питон я смотрел только потому что поддался общему хайпу- что это просто и модно. После того как посмотрел исходники ntlk и обнаружил что он использует stanford nlp — решил окончательно что останусь на Java

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

Я в этом не разбираюсь, но на go это есть — github.com/ryanbressler/CloudForest
Также смотрите github.com/...esome-go#machine-learning

Спасибо, я видел что библиотеки есть, и погуглил на эту тему изрядно. Вопрос скорее в другом: если я хочу развиваться в ML-направлении, есть ли смысл развиваться через go (на самом деле, ответ я для себя уже нашел). Вообще, у меня есть идея через некоторое время попробовать всё-таки golang для простых текстовых парсеров на правилах, и посмотреть как быстро он прошуршит большие массивы текстов

Серьезно, мы здесь сравниваем скалу с го для ML и создания парсеров? Мир кактиться в какоето унылое г.

аээээм, не знаю где вы увидели здесь сравнение скалы и го для создания парсеров, да и для ml

ну я в контексте темы вообще. Даж рассматривать го както несерезно, штоле.

Так я от контекста темы оторвался. Я вот вообще себе нащупываю инструменты и путь на будущее, и задаю вопросы.

Т.е. в моем случае, я имею норм экспириенс с .нетом (ну и всякие там ангуляры), имею инженерный бэк ковыряния с железом и оптикой в лабах и обработкой стат.результатов в R. Имею опыт с обработкой текста/машинным переводом, ну и легкие познания в питоне/плюсах.

Чего хочу: годика через три-четыре хорошо прокачаться либо в nlp, либо в обработку изображений.
Ближайшее года полтора планирую учить общие концепции ML + подтянуть свой мат.аппарат, после чего решить на чем качать специализацию. Как инструментарий: скорее всего python/java(scala).

Да, я не знаю о го ровным счетом них**. Вот мне и интересно, имеет ли смысл его использовать в интересных для меня направлениях, пусть это и парсеры для начала.

ML: Python, OCaml, Haskell

я бы вместо ocalm’а уже тогда f# мучал бы, наверное

Для ML есть Python. Зачем там Scala?

Предновогодние новости от Scala-разработчика: Golang is really awesome and why it beats Scala/JVM

Мне вот странно почему Erlang не набирает оборотов, точнее его VM, крутейшая же задумка, да и Elixir выглядит уже не так эзотерически, но до психологию прийдется ломать

Він набирає оберти рівно настільки, наскільки може.
Проблема у тому, що Erlang є спеціалізованою мовою, на відміну від універсальних, які обговорюються у цій гілці — Scala, Go, Java.
З самого початку Erlang створювався як мова програмування телефонних комутаторів, яка має мати певні специфічні властивості (в т.ч. процеси-актори та обмін повідомленнями), має певні послаблення (продиктовані динамічною природою мови) і може не мати тих властивостей, які притаманні універсальним мовам (повноцінні рядки, підтримка деяких структур даних і т.п). Пізніше виявилось, що в якості узагальнення комутаторів, Erlang придатний і для програмування серверів, але все ж таки з тими самими обмеженнями, які, до речі, від версії до версії поступово усуваються (в останніх версіях з’явились Map-и — асоціативні масиви).
Якщо ж спробувати використати Erlang для чогось іншого — результати так собі (наприклад, Wings3D).
Щодо Elixir — він з’явився відносно недавно і оберти набирає поступово. Він закриває більшість недостач Erlang-у — структури даних, метапрограмування, але тим не менше, від нього тхне Ruby і оцими незрозумілими штучками, коли навіть прості конструкції викликають питання «а чо так, а не інакше?» (зараз не згадаю, але було щось там з функціями)
На мою думку, на швидкість набору обертів негативно впливає і те, що у Erlang/Elixir
— мала ком’юніті
— мало фреймворків
— OTP, як до сих пір заточена на «хардкорні сервери»
— нема «модного ООП» (хоча це скорше плюс).

А щодо задумок та ідей з Erlang VM — так їх тирять всі, кому не лінь: Akka на JVM, горутини на Go, greenlets у Python і т.д.
Щось таке.

Хорошая новость — Go обошел по популярности Scala в 5 раз:

* 699 проектов на Go с более 500 звездами — github.com/...?q=language:go stars:>500
* 134 проекта на Scala с более 500 звездами — github.com/...language:scala stars:>500

Также обратите внимание на место Go в колонке Languages слева — он уже обогнал C, C++ и Swift и дышит в затылок PHP:

4,567 JavaScript
2,057 Java
1,533 Python
1,279 Objective-C
1,096 Ruby
743 PHP
699 Go
653 C
629 C++
544 Swift

го же использует гитхаб как package store для единственно package managera в языке чего не делают другие языки. Придумай другой критерий популярности.

Покажите сайт, где количество и качество проектов на scala больше, чем на github.

Скоро программисты scala сами для себя неожиданно обнаружат, что стали писать код на Go.

Спустя месяц количество проектов с более 500 звездами на github выглядит вот так:
Go: +22 проекта — github.com/...?q=language:go stars:>500
Scala: +1 проект — github.com/...language:scala stars:>500

Итоговый счет — 22:1 в пользу Go.

Ну вот, 22 программиста уже перешли со scala на golang, а один по дороге заблудился.

Он просто подался в Свидетели Иеговы, что, впрочем, одно и то же.

Результаты специальной олимпиады проекты Go vs Scala с более 500 звезд спустя два месяца:

757(+58) Go
141(+7) Scala

Счет 58:7 в пользу Go. Опережение более чем в 8 раз. Go одерживает сокрушительную победу над Scala как на короткой, так и на длинной дистации.

Все еще сомневаетесь, что CTO, опубликовавший пост о переходе его команды со Scala на Go, поступил верно на 100%?

Блин, это же каким надо быть лузером, чтобы всё ещё до сих пор писать на скале!

Как и предсказывалось, в этом году Go уделал скалу по всем позициям согласно исследованию от github:
— go используется в наиболее популярных репозиториях, scala — нет
— 188k vs 70k pull requests
— +93% vs +54% yearly growth rate по pull request’ам

Последний пункт говорит о том, что в следующем году отставание скалы от гоу станет еще существеннее

И продул JS

hsto.org/...741b782bde4b9054ae371.png

а через год все будут писать, только, на swift и typescipt )

После написания кода на Go, решил позаимствовать очень полезную фичу «defer» для разработки на C++. Зачем писать кучу классов только ради того, чтоб выполнился деструктор, когда можно просто задать лямбду, которая выполнится при выходе из блока:

// Go-style defer pattern
class defer {
	std::function<void()> ondestroy;
public:
	defer(std::function<void()> arg) {
		ondestroy = arg;
	}
	~defer() {
		ondestroy();
	}
};
Теперь например после открытия какого-то хэндла, можно просто написать такой код:
HANDLE hFile = CreateFileW(........);
if (INVALID_HANDLE_VALUE == hFile) {
	throw std::runtime_error("Can not open file");
}
defer _file([=]() {
	CloseHandle(hFile);
});
так что вот, фичи из Go перекочёвывают в C++.
когда можно просто задать лямбду

www.boost.org/..._exit/doc/html/index.html

Поздравляю с изобретением велосипеда с 10-летним (минимум) опозданием.

так что вот, фичи из Go перекочёвывают в C++.

Оно было задолго до Go. Учите первооткрывателей, а не эпигонов.

есть такая штука — RAII — очень популярна в c++, советую ознакомиться

RAII в чистом виде чудовищно громоздок, когда действия по зачистке уникальны и приходится на каждое рисовать особый класс с кастомным деструктором. Обрамление в виде boost::scope как раз решает эту проблему ровно столь же удобным способом, как Goʼшный defer.

Go’шный defer выглядит красивее :)

А в go 1.8 он будет еще и быстрее — см. github.com/...66f645536e8031a132cfdf3dd .

Ждем в C++ ужасных в использовании подделок под go’шные горутины с channel’ами и select’ами :)

А в go 1.8 он будет еще и быстрее

Неуловимый Джо.

Ждем в C++ ужасных в использовании подделок под go’шные горутины с channel’ами и select’ами :)

Будут и не ужасные.

Будут и не ужасные.

Сомневаюсь. Достаточно сравнить удобство использования следующих фич в Go и C++:

— Работа с потоками. В гоу все сводится к ’go threadFunc(args)’. В С++ нужно инициализировать и передать кучу левых параметров в функцию запуска потока, сохранить где-то возвращенный дескриптор потока, который еще нужно не забыть закрыть после завершения потока, чтобы избежать resource leak.

— Лямбда-функции. Внутри функции на гоу просто обращаешься к необходимым объектам из родительских scope’ов. В С++ приходится явно перечислять эти объекты с помощью ужасного синтаксиса.

В С++ нужно инициализировать и передать кучу левых параметров в функцию запуска потока, сохранить где-то возвращенный дескриптор потока, который еще нужно не забыть закрыть после завершения потока, чтобы избежать resource leak.

Это не дело языка, но есть библиотеки, которые такое умеют.

В С++ приходится явно перечислять эти объекты с помощью ужасного синтаксиса.

>> [&] captures all automatic variables odr-used in the body of the lambda by reference
>> [=] captures all automatic variables odr-used in the body of the lambda by value

Читайте документацию, ламеры, она рулез.

Это не дело языка, но есть библиотеки, которые такое умеют.
Именно поэтому в гоу для решения большинства задач достаточно стандартной библиотеки, а в С++ для этого обычно нужно подключать кучу сторонних библиотек, большинство из которых такое же неудобное в использовании, как и стандартная библиотека.
>> [&] captures all automatic variables odr-used in the body of the lambda by reference
>> [=] captures all automatic variables odr-used in the body of the lambda by value
Читайте документацию, ламеры, она рулез.

Думаю, не нужно объяснять, к чему может привести использование внешней переменной по ссылке внутри лямбда-функции, которая может быть вызвана после выхода из родительской функции. Для кого эти грабли в С++?

В go компилятор сам определяет, какие переменные должны быть скопированы, а какие — переданы по ссылке внутрь лямбда функции.

Также go сам решает, какие переменные выделить на стэке, а какие — в куче. Поэтому в go следующий код не приведет к undefined behaviour, в отличие от С++:

func f() *int {
    var i = 123
    return &i
}

При желании можно повлиять на решения компилятора, чтобы добиться оптимальной производительности за счет ухудшения ясности кода. Но в большинстве случаев до этого не доходит, т.к.:
1) в типичном коде очнь мало performance bottlenecks, нуждающихся в оптимизации
2) большинство прикладных программ вообще не нуждается в низкоуровневой оптимизации

В итоге код на go получается проще и понятнее аналогичного кода на С++ при сравнимой производительности скомпилированных программ.

Именно поэтому в гоу для решения большинства задач достаточно стандартной библиотеки, а в С++ для этого обычно нужно подключать кучу сторонних библиотек, большинство из которых такое же неудобное в использовании, как и стандартная библиотека.

Спасибо, посмеялся.

Думаю, не нужно объяснять, к чему может привести использование внешней переменной по ссылке внутри лямбда-функции, которая может быть вызвана после выхода из родительской функции. Для кого эти грабли в С++?

Правильно, поэтому есть передача по значению. А сравнивать с языком, который принципиально мультипарадигменный и многоуровневый — показывает только некомпетентность сравнивающего. Вернитесь лучше к наездам на Scala, там они хоть как-то похожи ;)

В итоге код на go получается проще и понятнее аналогичного кода на С++.

Когда на всё, что вылезает за пределы предусмотренной ему ниши, «потребности в колбасе нет» — так и получится. В этой нише.

Go порвал Java со Scala почти во всех тестах — benchmarksgame.alioth.debian.org/u64q/go.html

Во первых не скале, а джаве (хотя сомнений что скала будет хуже нет), во вторых вчистую продул с\с++

больше выглядить как говна хлебнувшие с го

LOL. Чувак же написал «No need for concurrency or high speed here». Как язык Python поприятнее конечно. Честно говоря все же до конца непонятно зачем они изначально переходили на Go в этом кейсе

до конца непонятно зачем они изначально переходили на Go в этом кейсе
Потомучто Aliaksandr Valialkin написал что скоро другой работы не будет?
«No need for concurrency or high speed here». Как язык Python поприятнее конечно.
так все знают то читабельность и поддерживаемость кода в сто раз важнее скорости выполнения, за редким исключением. а го тут уступает почти всем мейнстрим языкам
в сто раз важнее скорости выполнения
это правда для большинства проектов, но у нас в долине на него компании(такие как dropbox, uber(чтобы не быть голословным)) переводят ряд проектов где efficiency/concurrency очень важны
читабельность и поддерживаемость кода
У Go с этим все не так уж и плохо. Язык не изящный, если не сказать бедный. Как следствие все пишут приблизительно один и тот же код: что джун что senior. При открытии чужих проектов — вопросов к читаемости у меня не возникало. Вроде в этой ветке скидывали статью о переводе проекта со scala на go, после чего го*нокод стал более стандартным, а благодарный менеджер добрее
больше выглядить как говна хлебнувшие с го
теперь-то они разобрались в сортах говна

Пока разработчики scala заняты бесполезными на практике монадами и паттерн матчингом, разработчики go уменьшили stop the world задержки в GC в 1000 раз — с одной секунды до одной миллисекунды — см. как Go помогает писать скоростные чаты для twitch’а

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

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

эм... ну насколько я знаю паттерн матчинг — это самая что ни на есть полезная (и очень мощная) на практике вещь) ровно как и монады — без них во многих функциональных языках (таких как хаскель и некоторых других) не было бы возможным программировать интерактивное взаимодействие с пользователем)
Есть альтернативное мнение, что функиональные языки программирования не подходят для решения большинства real world задач. А монады — всего лишь не очень удачные костыли, позволяющие кое-как использовать функциональщину в практических задачах. Это мнение где-то уже проскакивало в комментах к данному посту.
Это мнение где-то уже проскакивало в комментах к данному посту.

dou.ua/...orums/topic/16012/#844902

“И костыли в виде option/either только усложняют и без того сложный код на скале.”

© Aliaksandr Valialkin, 7 січня 11:48

подъе..нул )

Вообще-то имелось ввиду это мнение — dou.ua/...orums/topic/16012/#862852

Попытайтесь, хотя бы для справедливого сравнения, понять идеи за концепциями ФП. Сейчас вы похожи на школьника, который кричит, что производные с интегралами — никому не нужные на практике штуки, а он может писать игры/сайты/андроид уже сейчас.

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

Со своей стороны, я, как и говорил ранее в этом топике, честно потратил пару недель на изучение Го.
Неистово плюсую!
Сейчас вы похожи на школьника, который кричит, что производные с интегралами — никому не нужные на практике штуки, а он может писать игры/сайты/андроид уже сейчас.
Так школьник прав — для большинства прикладных задач производные с интегралами не нужны. Как и функциональные языки программирования
то функиональные языки программирования не подходят для решения большинства real world задач.
не стоит все ФП-языки под одну гребенку, ибо функциональщина функциональщине рознь.
Многие ФП-языки (разные Agda, Idris, Coq и т.п.) дейстивтельно предназначены для чего-то узкоспециализированного,
но есть, к примеру, Lisp, который подходит практически для всего (и имеет полноценное ООП, правда отличное от разных джав и си-шарпов), OCaml (который тоже как бы мультипарадигмальный и на котором тоже по идее все, что хочешь можно написать), тот же хаскель.

другое дело, что функциональные языки всегда находились в тени у императивных языков и многие библиотеки в этих языках либо сырые либо их попросту нет (и надо самому пилить, если приспичило). Ну и + большинство программеров привыкли к императивному стилю программирования и просто не понимают функциональный подход, и поэтому могут думать, что функциональные языки какие-то неполноценные.

К подобным мнениям можно прислушиваться пока нет успешных продуктов, а они есть. Я сталкивался с Kafka и Spark(и то и другое написано в функциональном стиле). Я не знаком с GO про этот ЯП нечего сказать не могу, но утверждение выше явно не обосновано.

Я сталкивался с Kafka и Spark(и то и другое написано в функциональном стиле)
Очень сомнительное утверждение про функциональный стиль.

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

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

Наивные. Скоро все, кто не знает Go, станут безработными или будут зазывать гоу-программистов фразой «свободная касса».

а я думал вы вытесните пхпшников с дна рынка

Тут вообще неочем даже говорить, какое нафиг вытеснение. Как миними большинство людей знающих скалу знают и джаву. И вы уж поверте даже, если завтра появится язык на котором можно делать все левой ногой с закрытыми глазами и при этом будет получаться идеальный код, то благодоря тоннам кода уже написанного на джаве, джаву по инерции будет держать на плаву минимум лет 5. А вот го в неком промежуточном состоянии из программ которые на слуху слышал только, что докер написан на go.
PS. Вот читаю ваши посты и от них все больше попахивает религией или наркоманией. Как можно во что-то слепо верить и делать категорические выводы не имя для этого весомых оснований

Как видно в большинстве случаев, проекты живут, пока над ними работают. Как только разработка нового функционала прекращается, они вскоре вытесняются с рынка. Говорят, что на коболе написаны несметные горы кода, ну и где это всё сейчас?

Я не застал времена популярности cabol, но логично предположить, что cabol начал терять популярность с увеличением популярности delphi, java, c#. И было — это очень давно. Сотрудник еще 2-3 года назад работал cabol программистом в Укр железной дороге. К томе же подозреваю, что уровень ЗП у спецов cabol в европе/сша довольно высокий.
Вот в вики прочел такие строки
In 2006 and 2012, Computerworld surveys found that over 60% of organizations used COBOL (more than C++ and Visual Basic .NET) and that for half of those, COBOL was used for the majority of their internal software
видимо у такого рода специалистов своя тусовка. Так, что инерция популярности были и продолжалась довольно долго.

тем более для чатов, где функциональщину использовать по-моему просто геморно

Пример чата на самой что ни на есть тру-функциональной скале в 100 строк коду github.com/...ree/master/src/main/scala

Этот чат может обслуживать одновременно 500К пользователей на одном компе с максимальным временем отклика в одну миллисекунду, как вышеупомянутый чат twitch’а, написанный на Go?

чето цыфры мельчают, еще недавно шел разговор о миллионах соединеней, теперь уже всего 500к

Уже были примеры где дот нет по перформенсу разрывает го

Сервер под дот нет наверняка юзает сокеты на портах завершения, а в Go юзаются на эвентах, поскольку кросплатформенный. А на IOCP производительность изначально выше.

.net использует libuv для кросплатформенности и там тоже ивенты.

Our lab runs show that ASP.NET Core is faster than some of our industry peers. We see throughput that is 8x better than Node.js and almost 3x better than Go, on the same hardware.

Что-то они врут. Смотрим последние результаты бенчмарка. У nodejs — 300К запросов в секунду. Значит, у asp.net core — 2.8М запросов в секунду. А у go (fasthttp) — 6.3M, т.е. в 2.5 раза больше, чем у asp.net core.

Токо на первом месте джава.
Апдейт: дот нета я чето там не нахожу

Он так считает бенчмарки:
node.js * asp.net core множитель < Go

Только они почему-то не размещают результаты go в своем репозитории. Боятся опозориться? Пришлось создать тикет. Пока нулевая реакция...

те цифры которые вы приводили в этом (или другом топике), вообще были ни о чем. вы тестировали в основном работу ОС, а это как бы ни о чем.

я как бы не по скале, но мне кажется (посмотрев код), что там используется не функциональгый стиль, а ООП (ну там object есть, что наверное намекает на ооп)... хотя... там есть мапы и паттерн матчинг, так что может быть там действительно ФП-подход.
ну а то что 100 строк — так это из-за того, что поподключали доп. библиотек. :)

1. ООП в скале есть и это хорошо. Просто убрать ООП из скалы было бы глупо, можо такие вещи оставить теоретикам. И в целом функциональный стиль не отрицает ООП, ФП нужно противоставлять императивному стилю, а это в первую очередь минимизация сайд эффектов. То есть функция при вызове с одиними и теми же параметрами, должна выдавать один и тот же результат(состояние).
2. Не совсем так, на джаве кода при использовании тех же библиотек будет существенно больше.

И в целом функциональный стиль не отрицает ООП, ФП нужно противоставлять императивному стилю, а это в первую очередь минимизация сайд эффектов.
ну вообще-то ООП — это и есть подвид императивного подхода) ибо есть два осн. подхода: императивный (процедурное пргограммирование и ООП) и декларативный (функциональное программирование и логическое).

А в целом их действительно не надо отрицать, а лучше комбинировать (применять какой-либо из них в зависимости от задачи).

Не совсем так, на джаве кода при использовании тех же библиотек будет существенно больше.
ну джава насколько знаю язык сам по себе многословный)
есть два осн. подхода: императивный (процедурное пргограммирование и ООП) и декларативный (функциональное программирование и логическое).

ФП, как выше было замечено, имеет только одну цель: упрощение «reasoning about code» (например, минимизация неявных побочных эффектов). Однострочник с map-filter-reduce не является ни необходимым, ни достаточным условием ФП.
Если вдаваться в малопрактичные теоретические дискуссии, то все эти понятия (фп, ооп, императивщина, ...) очень размыты и часто пересекаются, да и часто у участников свои определения.

Скала в первую очередь — ООП язык, и соответствующие стороны развиты куда лучше, чем в той же Джаве. А «функциональный подход» — чрезвычайно удобная именно на практике вещь, которая в итоге снижает ресурсы на понимание и поддержку кода. С оговоркой, что «що занадто, то не здраво» — пришедшие фанатики с «чистых» языков типа Хаскеля используют привычные паттерны, несмотря на их ужасный вид в адаптации (одни трамплины чего стоят). Ну так и ООП-фанатики могут написать сотню классов ради хеллоуворда, чего уж там.

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

Мда, утверждение из разряда «я не знаю ни ооп, ни фп, ни скалы, но мне кажется».

Но вообще да, фп на скале строиться поверх (а не вопреки) классов и объектов (и еще рада фич, вроде паттерн матчинга и имплиситов). Большущий плюс такого подходу в том, что таки реально разобраться как оно работает и что там происходит. Хаскель всегда выглядел как непонятная черная магия. В скале все понятно стало.

Мда, утверждение из разряда «я не знаю ни ооп, ни фп, ни скалы, но мне кажется».
ну как бы да — я чесно признался. что я не по скале и что не знаю, что и как там реализовывано, и могу только предположить)
Хаскель всегда выглядел как непонятная черная магия.
а вот хаскель я смотрел немного — самые базовые вещи вроде как понятны были (видимо на то они и базовые). А вот более сложный код как по мне тоже выглядит как черная магия (видимо сильно много матана), поэтому я хаскель забросил (не дорос еще)...

з.ы.

«я не знаю ни ооп, ни фп, ни скалы, но мне кажется»
и поэтому, если выбирать между го и скалой, я бы выбрал го)

ха-ха, точно, это ж надо еще так внимательно читать ))

Кстати, а что тогда с jobs.dou.ua/...ertamedia/vacancies/23932 ? В вашей компании, да ненужная функциональщина со Скалой?

А это для того, чтоб гоферам там было лучше кого писать.

А причем фишки языка scala, к внутреностями jvm (GC), за которые отвечают совсем другие люди.
Вот примеры GC’s для jvm c Low-Pause-Time:
— openjdk.java.net/jeps/189
— JVM от Azul c их С4
+ G1 который в jdk9 станет дефолтным

Новость устарела — в go1.8 STW паузы GC не превышают 100 микросекунд на любом размере хипа — news.ycombinator.com/item?id=12821586 . Go уходит в отрыв от тормозных garbage collector’ов в Java, Scala и .Net .

Да с такими тенденциями скоро работа GC в Go начнёт ускорять работу программы и повышать общую производительность системы!!!

Недавно статья попалась на глаза, где сомневаются в прорывности гошного gc
m.habrahabr.ru/...mpany/mailru/blog/318504

Статья ни о чем — в ней утверждаются очевидные вещи:
1) GC в Go проще, чем в Java.
2) GC в Go жрет на пару процентов больше процессорного времени по сравнению с GC в Java.
3) GC в Go по умолчанию требует столько же дополнительной памяти, сколько занято хипом.

Но это никак не может повлиять на факты:
1) STW паузы в Go не превышают 100 микросекунд out of the box на любых размерах хипа, в то время как STW паузы в Java сильно зависят от настроек GC и размера хипа, и в общем случае держатся в районе 100 миллисекунд, т.е. в 1000 раз больше, чем в Go.
2) Объем потребляемой памяти в приложениях на Go обычно в 10 раз меньше объема потребляемой памяти в приложениях на Java и Scala. И супер-навороченные GC не спасают.

А что это за конструкция?
if ident, isIdent := <em>x.(*ast.Ident)</em>; isIdent { (выделил нужное)

Разыменование ссылки на метод класса (в терминах более традиционных языков)? Что-то другое?

Ага, я к вечеру нашёл. Но всё равно спасибо за подтверждение.

Я ниасилю Скалу ибо туп: начал смотреть про pattern matching и акуел ... Зачем все так сложно?

это такой толстый троллинг?

Для вас сделали го, не переживайте

Вот отличная цитата, характеризующая одновременно scala и go:

I have found that all ugly things are made by those who strive to make something beautiful, and that all beautiful things are made by those who strive to make something useful.

Источник — groups.google.com/...c/golang-nuts/lsMy0kRy8zg .

Я иногда думаю: перенесли бы лучше библиотеку Go для C++. Ну так, чтобы на C++ фигнёй меньше маяться.

это точно, все-таки до с++ golangy еще очень далеко.

Во многом согласен, вся кошмарность Go и сосредоточена там, где вместо грамотной пользы пытались на карачках догнать единорога.

Вы все еще сомневаетесь, стоит ли переходить на Go? Тогда мы идем к вам.

Написал на Go одну утилиту, которая делает высоконагруженный расчёт. Раньше этот расчёт был написан на Lua, на Go время расчёта снизилось более чем в 20 раз, и примерно коррелирует с производительностью на С++. Расчёт можно разбивать в несколько тредов, в данном случае на несколько гоуротин, с минимальной синхронизацией данных (через мьютекс). Ну так вот, время расчёта с 1 гоуротиной оказалось минимальным (16 сек), с 2 гоуротинами 18 сек, с 8 около 20 сек. Число процессоров при этом установлено 8, что соответствует камню Core i7. При этом в случае 1 гоуротины загрузка 1 из ядер соответственно значительно возрастала (около 80%), в случае 2 гоуротин — на 2 ядрах, но загрузка при этом падала, на 8 гоуротин — общая загрузка чуть превышала обычную. То есть, распаралеливание не даёт эффекта. Тогда я рабочие гоуротины залочил в LockOSThread/UnlockOSThread, это дало незначительный прирост производительности, но в целом картина осталась прежней. Возможно, если повысить приоритет OS-тредов, тогда загрузка на ядрах возрасла бы, и расчёт происходил быстрее, но я такой возможности в стандартной библиотеке go не нашёл. Вобщем, вопрос: как повысить производительность за счёт очевидного распараллеливания?

Вобщем, вопрос: как повысить производительность за счёт очевидного распараллеливания?
Код под мьютексом не может исполняться одновременно на нескольких ядрах процессора. Судя по описанию, это ваш случай. Решение — избавиться от мьютекса. Или минимизировать время исполнения кода под мьютексом по отношению к коду не под мьютексом.

Код под мьютексом делает только инкремент шарового счётчика, больше ничего. Всё остальное происходит с локальными данными в каждой гоуротине. Причём «удельный вес» расчётов значительно больше инкремента под мьютексом.

Разобрался в сути проблемы. Там всё дело в том, что в некоторых ситуациях счётчик инкрементируется несколько раз подряд, с идущими друг за другом лок/анлок. Если это всё это поместить в одну залоченую секцию, производительность увеличивается. А писали же в мануалах, что залоченый код должен быть минимальным.

А писали же в мануалах, что залоченый код должен быть минимальным.

Так оно и есть — см. en.wikipedia.org/wiki/Amdahl’s_law :


For example, if a program needs 20 hours using a single processor core, and a particular part of the program which takes one hour to execute cannot be parallelized, while the remaining 19 hours (p = 0.95) of execution time can be parallelized, then regardless of how many processors are devoted to a parallelized execution of this program, the minimum execution time cannot be less than that critical one hour. Hence, the theoretical speedup is limited to at most 20 times (1/(1 − p) = 20).

Лічільник краще через атоміки інкрементувать.

А еще лучше инкрементить батчами — не по единичке, а по сотне, тысяче или вообще один раз во время завершения исполнения потока.

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

Супер, время расчётов сократилось на 8 ядрах в 3 раза! Причём на одном тоже вышел неплохой прирост производительности.

Код под мьютексом делает только инкремент шарового счётчика, больше ничего
Го не может в атомарные операции инкремента? пичальбида

если Го что-то не может — то значит оно и не надо!

Может, я просто не нашёл сразу. Производительность при этом значительно выросла, в том числе из-за сокращения вызовов lock/unlock. Кстати, это не удивительно, но и прямой вызов unlock гораздо производительнее, чем отложенный через defer.

А вот мы подумывали микросервисы на Питоне перевести на Го, но что-то по мере изучения сабжа ощущаешь что что-то тут не так. Мотивация все падает для внедрения Го в продакшен, так как непонятно, насколько вообще мода продлится на этот язык. Или гугл забъет на него как на ридер.

«Недолго музыка играла, недолго фраер танцевал»

Dropbox намучился с go и отказался от него в пользу rust
www.wired.com/...odus-amazon-cloud-empire

А ведь раздача файликов по сети это собственно то, ради чего go изначально и создавался

Жду негодавание гошников о ниасиливших го

Go даже ниасиливать можно в 10 раз быстрее ты чо

И в 10 раз быстрее перейти на другой язык

Это желтая пресса. На самом деле они написали на расте какую-то маленькую хрень. Все остальное осталось на го. Вот пруфлинк. А вот соответствующая цитата:

Actually, full disclosure, we really just rewrote a couple of components in Rust. Most of Magic Pocket (the distributed storage system) is still written in golang.

Также дропбокс не собирается переходить с гоу на раст в обозримом будущем. пруфлинк. Цитаты:

Yup, Dropbox Infra is mostly a Go shop. It’s our primary development language and we don’t plan to switch off any time soon.
Most of the storage system is written in Go and the only two components currently implemented in Rust

Цитата оттуда же про Rust vs Go

Performance is 3-5x better at tail latencies. Cost savings is.. dramatic. I can’t be more specific there.
Сразу вспомнил слова про простой язык, который имеет все что нужно для того что бы работать на старом ноуте. А если что-то не умеет и ложит сервера в продакшине выжираяю всю ОЗУ не поддерживая хвостовой рекурсии, то можно написать и на другом языке.
На самом деле они написали на расте какую-то маленькую хрень
:facepalm:
Performance is 3-5x better at tail latencies
...не поддерживая хвостовой рекурсии...
tail latencies не имеет ничего общего с хвостовой рекурсией. Это лишь означает, что очень маленький процент (под tail обычно имеют ввиду не больше 5%) ответов от гоу сервера выполняется в 3-5 раз дольше, чем в раст-сервере. Скорее всего, такие задержки связаны со stop the world фазой в garbage collector’е. Это может быть следствием двух вещей:

1) Они не оптимизировали свой сервер по потреблению памяти. GC не бесплатный — чем больше объектов находится в хипе, тем больше процессорного времени будет расходоваться GC на сканирование этих объектов. В расте, насколько я понял, GС отсутствует — там ручное управление памятью.
2) Они использовали старую версию гоу (до 1.5), в которой длительность фазы stop the world (STW) в GC линейно зависела от объема хипа. Например, при 10-гиговом хипе она могла достигать нескольких секунд. Начиная с гоу 1.5 фаза STW на 10-гиговом хипе снизилась до 20мс, а в гоу 1.6 — не превышает 20мс при хипе в 256Гб.

очень маленький процент (под tail обычно имеют ввиду не больше 5%)
Кстати, 5% — это совсем не мало на масштабе дропбокса

Latest news: scala+akka в 10 раз медленнее, чем Go с горутинами в skynet бенчмарке. При этом код на гоу простой и понятный, а на скале — черт ногу сломит.
Результаты тестов доступны тут — github.com/...net/blob/master/README.md . Кроме гоу со скалой там есть и другие представители. Некоторые даже быстрее гоу, если судить по бенчмаркам. Только код у них слишком сложный по сравнению с гоу.

При этом там же go в 3 раза медленнее чем async-ы в .NET Core, и в 5 раз медленнее чем Task Parallel Library в .NET Framework. Отакэ.

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

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

Это потому что кода на жаве с дотнетом не соответствует требованиям бенчмарка:

Creates an actor (goroutine, whatever), which spawns 10 new actors, each of them spawns 10 more actors, etc. until one million actors are created on the final level. Then, each of them returns back its ordinal number (from 0 to 999999), which are summed on the previous level and sent back upstream, until reaching the root actor.

Жава с дотнетом решили избавиться от такой “мелочи” как actor, и просто использовать хорошо замаскированный рекурсивный вызов фукнции.

Подробности тут и тут.

А зачем нужен какой-то «актор», если код все равно делает то же самое?

И если из-за акторов гоукод тормозит, я не знаю, может можно не юзать акторы в гоу и тогда он не будет сливать джаве?

Один хрен Go так же рекурсию использовал.
Если подитожить Го за счет несоотвествия требования тестам обошел Скалу и слился Java\.NET что использую также рекурсию.

Кстати, проверил у себя

Go: 916ms

.NET:
Sync sec: 0.052
Async sec: 0.414
TPL sec: 0.170

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

В итоге миф о офигенной эффективности гоурутинов успешно развеян — банальный синхронный код, как и прежде, решает.

Код на скале и .net не выдерживает никакой критики. При этом код на го вроде норм, сразу видно что го знают, а другие языки впервые увидели.

Может, потому что на гоу проще писать многопоточный код, чем на остальных языках?

Полная ерунда, сравнение, гхм, яблок с кирпичами. Скала версия через Future уделывает Гошный код в где-то три раза. github.com/atemerev/skynet/issues/4. Строго говоря, фьючуры тоже не являются аналогом горутинам, но они ближе к теме, чем акторы.

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

Интересная у вас методика пиара Го. Выбирать «правильные» бенчмарки, не разбираться в теме, а затем постить «разоблачения». Вам за это платят, что ли? Если да, то выберите другую стратегию, из-за такого поведения идет скорее минус репутации Го.

Так в свое время доказывали тормознутость ноды, вешали тяжелую синхроную операцию, и говорили что сервер не отвечает, и пример на джаве где эта операция в отдельном треде — результат предсказуем, тест вообще не валиден

nodejs в любом случае тормознутый. См. результаты бенчмарков.

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

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

так что это все разговор ни о чем

Набрасываю )

www.ageofascent.com/...llion-requests-12-6-gbps

Scala, go... тут новый ASP .Net Core, который кроcсплатформенный, который компилируется в native, на одной ноде на линуксе обрабатывает в 6 раз больше реквестов чем nodejs, на винде разрыв еще больше — в 7 раз. И это все на няшном, ламповом C#. Таки есть порох..., в верном направлении развернулись в МС, лишь бы не было поздно.

Откуда информа, что он компилиться в натив? Core clr на выходе дает dll даже под маком и требует dnx обязательно. Тесты где-то есть сеть выложены?

он вроде всегда JIT-ом компилился в найтив, что-то поменялось в core?

Если и компилировалось, то как-то через костыли. Они там что-то писали, что сам .net framework устроен так, что очень сложно все слинковать и скомпилить в native. В .net core они изначально заложили такую возможность.

Единственное что напрягает, что .net core это форк .net framework-а. Блин, если в очередной раз все меняете, сделайте уже правильно с нуля, зачем резать .net framework и приделывать костыли? Смахивает на какое-то очередное переходное, временное решение.

Единственное что напрягает, что .net core это форк .net framework-а. Блин, если в очередной раз все меняете, сделайте уже правильно с нуля, зачем резать .net framework и приделывать костыли? Смахивает на какое-то очередное переходное, временное решение.
Опыт ноды показывает, что если запилить нормальную платформу без библиотеки классов, то народ быстро напишет библиотеку классов и заопенсорсит

Что тогда что сейчас компилируется в IL, разница только в том, что в Core это нативный приложе хост, что создает managed domain и грузит в него сборки. Есть куски фреймворка которые не совсем легко сделать кросплатформенными в силу тесной привязки к винде, например credential cache, хранилище сертификатов. О каких костылях речь? Эти сборки пока не будут работать в Core, что-то добавляют по мере развития платформы. Скорее всего их оптимизация заключается в возможности отключать ненужны компоненты, глобально это как был managed процесс С Jit компиляцией так и остался.

Не совсем так. Компилируется все в native, то есть никакого jit-а, а вот рантайм да, пакуется. Все-таки сборщик мусора и managed процессы должны же где-то крутиться. С .net framework-ом толком не получалось такого сделать так как сложно было выделить зависимости и каждый проект тащил за собою чуть ли не половину .net фреймворка. В .NET Core они действительно оптимизировали зависимости, поэтому пакуется только то, что нужно проекту.

Core сбоока выполняется и под маком и под виндой и под линухой. Это уже априори говорит, что там нету native кода на выходе.

А что по вашему происходит с IL кодом на JITе? Чем по-вашему JIT занимается?

Jit выдает платформо зависимый машинный код, это самое большое заблуждение что Core clr можно собрать в сборку, которая будет иметь готовый машинный код. Для компиляции Рослину нельзя указать ни ось и ни процессор собственно и байт код он не генерить, а только MSIL. У мс был какой-то совершенно другой нативный компилятор в разработке для Win RT only. А так это попрежнему часть рантайма и одна из основных причин почему на каждую Ось нужно писать отдельный native host где будет развернут рантайм. Тут поменялось ровным счетом вообще ничего кроме того, что поддержка .NET реализована на уровне executable файла и не требует поддержку на уровне Оси, как есть в винде.

Jit выдает платформо зависимый машинный код

Так в чем проблема нагенерить этот код заблаговременно? Где вообще можно об этом нормально все почитать в контексте .net core? Как-то везде все расплывчато.

Рослину нельзя указать ни ось и ни процессор собственно и байт код он не генерить, а только MSIL.

А рослин тут причем? Как и старый компайлер генерит MSIL для JITа, и больше ничего от него не требуется.

Так в чем проблема нагенерить этот код заблаговременно?
Зачем его вообще генерить заблаговременно?

1. Чтобы не тратить время в рантайме
2. Более оптимизированный машинный код (из-за неограниченного времени на анализ кода, у JITа нет такой роскоши, он должен по-быстрому что-то выдать)

Хотя новый JIT, говорят, быстрый

Так новый «JIT быстрый» или

Не совсем так. Компилируется все в native, то есть никакого jit-а,
я уже запутался совсем в том что тут пишется.

По умолчанию все по старинке — установленный рантайм в системе и приложение в виде менеджед сборок. Ставишь флаг -native во время билда — получаешь одну экзешку с откомпилированным все в нейтив и встроенным рантаймом. Что-то на подобии го. По крайней мере я так это понимаю, не могу найти четкого описания кроме пейперов 2014 года.

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

Информации дофига.
github.com/...re/blob/master/roadmap.md
Вот их новый JIT
github.com/...n/botr/ryujit-overview.md

А зачем кросплатформенность для native сборок? По-моему очевидно что компилиться под конкретную платформу.

Откуда такая уверенность ?
.NET native
.NET Native is not so much an “edition” of the .NET platform as it is a set of native build tools for .NET Core. .NET Native is an Ahead-of-Time (AOT) toolchain that compiles IL byte code to native machine code, so that when the code is executed, there is only “native” code running. This means that the resulting binary is what the OS executes; there is no JIT-ing, no runtime compilation. This leads to better performance, as well as some security benefits.

В конце ссылки написано, что это для WinRT инструментарий.

.NET Native is primarily used by .NET Universal Windows Platform (UWP) applications.

Да, вы правы! Накрутил лишнего. Только

WinRT
Для windows 8, а
UWP
это уже windows 10

Какая няша!

В целом наброс годный.
В куче с возможностью писать многопоточный код с неблокирующим IO и возможностями оптимизации дотнета, плюшками рантайма в виде тех же generics, использованием стека потока , всем сахаром C# плюс заявленым в 7 версии языка выглядит куда более как node.js киллер чем проблемный Go. :)

Ну у go есть существенное преимущество — мощная библиотека. А тут огрызок от .net framework в виде .net core, и зная Майкрософт, наращивать функционал будут не очень быстро, скорое переделывать будут по несколько раз, как с мобильной виндой.

наращивать функционал будут не очень быстро, скорое переделывать будут по несколько раз, как с мобильной виндой.
Посмотрите на ноду, позорно маленькая стандартная библиотека классов, состоящая из 10 компонентов и тысячи их 3d party модулей выложенных на гитхабе.

Если MS запили хорошую базовую платформу, то весь недостающий функционал сообщество напишет с нуля или портирует очень быстро.

Посмотрите на ноду, позорно маленькая стандартная библиотека классов, состоящая из 10 компонентов и тысячи их 3d party модулей выложенных на гитхабе.
только стоит отметить что половина из них оставляет желать лучшего
только стоит отметить что половина из них оставляет желать лучшего
Большая часть из них это, что то вроде leftpad, на 12 строк кода.

даже они оставляют желать лучшего

Еще одно большое заблуждение. Core Clr может референсить любую сборку собранную под предыдущие версии дотнет ,если она не референсит явно функционал библиотек зависящих от виндовой части фреймворка. Например старый newtonsoft json собранный под. Net 4.6 будет работать под мак и линукс в Core clr. Остальные библиотеки, например зависящие от system. Io при чтении фалововой системы, могу быть легко портированный сменной типов проекта референсов.

В чем заблуждение? .NET Core на данный момент огрызок, и МС сознательно не тянули туда многих вещей из .NET 4.6, так как не могли обеспечить поддержку. То что при определенных условиях можно подключать определенные сборки и молиться что ничего не крякнет в рантайме — никак не влияет на этот факт.

Если Core огрызок, а не самодостаточный фреймворк каких жизненно необходимых компонентов не было реализовано в нем?

Не буду утверждать на 100%, руки к нему еще не дошли, лишь наблюдения из интернета и от самого майкрософта.

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

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

Core выглядит более обнадеживающе.

Не обязательно

не могли обеспечить поддержку
Есть куда более логические причины.
Discontinued Technology in .NET Core

Ха-хаха. Fasthttp под гоу на моем трехлетнем ноуте обрабатывает 1.3М запросов в секунду от 1К параллельных клиентов, работающих на этом же ноуте. А тут они решили гордиться 1.15М qps на топовом сервере.

Сравнение твоего http listener’a на гоу с ASP.NET вызывает ассоциации, как в известной пословице про х** и палец.

requestHandler := func(ctx *fasthttp.RequestCtx) {
    switch string(ctx.Path()) {
    case "/foo":
        fooHandler(ctx)
    case "/bar":
        barHandler(ctx)
    default:
        ctx.Error("Unsupported path", fasthttp.StatusNotFound)
    }
}
Разработчики ASP.NET и других платформ сильно недооценивают возможности Go с таким MVC..

Хотелось бы увидеть примеры кода на asp.net и других уважаемых платформах, чтобы понять, чем вам не угодил процитированный пример на fasthttp.

Да оно больше ни на что не годится кроме как файлики раздавать. В принципе можно что-то больше делать, но это будет боль и страдания. Может оно и обрабатывает 1.3М запросов в секунду (все-таки канкаренси в го годное), но это на холостом ходу. А подает это так, будто бекэнд твиттера на его трехлетнем ноутбуке может работать.

Сомневаюсь, что они тестировали что-то сложнее, чем hello world application. В таких тестах обычно измеряют производительность сервера, а не производительность обработчика запроса. Поэтому логично использовать что-нибудь вроде return «Hello, world» внутри обработчика запроса.

Кстати, где посмотреть код сервера, производительность которого они измеряли? Вот тут код fasthttp, который выдает 1.3М ответов в секунду на моем ноуте — github.com/...l/src/hello/hello.go#L214 . Можете проверить на своем компе с помощью wrk:

./wrk -t 4 -c 512 -d 10 -s pipeline.lua http://localhost:8080 -- /plaintext 16

Содержимое pipeline.lua:

init = function(args)
   request_uri = args[1]
   depth = tonumber(args[2]) or 1

   local r = {}
   for i=1,depth do
      r[i] = wrk.format(nil, request_uri)
   end
   req = table.concat(r)
end

request = function()
   return req
end

Ты не понимаешь самого предмета тестирования, ASP.NET это не веб сервер, это фреймворк. Если тебе кажеться, что твой http listener обслуживает байтовые массивы фиксированного быстрее чем Кестрел, ИИС или Апач на домашнем ПК — это отлично, можешь попробовать продать эту идею где-то еще кроме ДОУ, но я не вижу что бы даже Go коммьюнити была сильно keen on в твоем веб сервере, даже несмотря на то что ты заявляешь, что он 10 раз быстрее стандартного Go listener’a.
Так же я не понимаю, что ты хочет доказать коммьюнити этими цифрами. То что Go появившись в том же году, что и Node.js со всеми проблемами языка и колбек хеллом преуспела куда больше в рядах веб разработчиков чем перспективный и удобный Go для меня тоже показательно. Веб-разработчики не буду заниматься низкоуровневым программированием и считать байты в циклах, если уж совсем не будет вариантов, те кому нужна производительность так же как и ты смогут оптимизировать под свои конкретные нужды листенер и оптимизировать низкоуроневые операции с памятью, на других платформах с куда более приклекательными языкам.

Покажите пример hello world application на asp.net, чтобы я понял, чем он отличается от fasthttp, который вы почему-то называете не сервером, а каким-то listener’ом. Кстати, чем сервер отличается от лиснера в вашем понимании?

Листенер это и есть веб-сервер. Просто звучит менее гордо в глазах велосипедостроителей.
ASP.NET от fasthttp отличается тем же чем веб-фреймворк отличается от веб-сервера.

ASP.NET от fasthttp отличается тем же чем веб-фреймворк отличается от веб-сервера

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

Веб-фреймворк отличается от библиотеки функций тем, что обязывает программиста пользоваться только предлагаемым функционалом ака «каркасом». Хочешь расширить функционал, не предусмотренный создателями фреймворка — пиши кучу хаков и костылей. Которые обычно ломаются в следующем релизе фреймворка.
Библиотека функций не обязывает использовать только функции, предоставленные ею. Программист волен компоновать произвольные функции из других библиотек плюс собственные функции для достижения поставленной цели.

Fasthttp является библиотекой функций. Чем является ASP.NET?

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

Веб-фреймворк
и
Библиотека функций
у том что ты пишешь.
В Асп.нет я могу заменить любой компонент, взять его third party реализацию, могу заменить веб-приложение хост, все что мне надо соблюдать интерфейсы между слоями.
У тебя интерфейсы вообще никак не упомянуты, wtf?
Тебе нужно самом разобраться в своей терминологии раз ты уже сам ее придумал. До этого факт остаеться фактом. Твой
fasthttp
тянет максимум на Веб-хост, называй его хоть библиотекой, хоть операционной системой, сранивать его с АСП.нет пока увы нельзя.

и кстати, если уж речь про это зашла, то asp.net это контейнер для двух противоположных моделей MVC и WebForms, и обе используются параллельно
так что сам asp.net это скорее хост-контейнер, в котором может жить что угодно
но мода на MVC сбивает многих с толку

Посмотрел сорцы твоего гитхаба интересно как ты предлагаешь компоновать функции из других библлиотек с твоим сервером если у тебя внутренние абстракции сплошь и рядом точат наружу.. server, requestContext, request, response -интерфейсы которые надо соблюдать.

В ASP.NET это выглядит чуть более продумано и есть единственной зависимостью, которую нужно соблюдать между слоями и библоитеками и даже другими фреймворками для полной совместимости.
owin.org
Выглядит намного более долговечно чем куча библиотек, которые нужно компоновать адаптерами, если захочеться сделать что-то кроме как раздавать байтовые массивы фиксированного размера, не находишь?

Посмотрел на этот owin.org и пришел в недоумение. Все, что там описано — SendFile, WebSockets, Opaque streams — присутствует в fasthttp искаропки. Не понимаю, причем тут байтовые массивы фиксированного размера — fasthttp поддерживает произвольные http-ответы. Читайтее внимательно документацию.

Лучше расскажите, как с помощью asp.net сделать следующие вещи:
— принимать запросы с произвольного количества TCP портов.
— принимать запросы с Unix sockets.
— принимать запросы из произвольного файла.
— добавить поддержку шифрования соединений, отличную от ssl (tls).
— ограничить входящие подключения на основе произвольных правил (ака anti-DoS).
— обрабатывать запросы из произвольного байтового потока.
— собирать произвольную статистику по входящим запросам и/или подключениям.
— реализовать одновременно все вышеперечисленное в одном веб-сервере.
Fasthttp позволяет делать это элементарно.

ололо. Конечно поддерживает, у тебя веб Http сервер, а это расширения Http протокола
:facepalm:
Только вот если какой-то чел на гитхбае написал либу для WebSockets или может быть напишет поверх твоего http это не совсем из коробки и не совсем поддерживает, если ты конечно не собераешся саппортить и их косяки. Ну это уже мелочь с таким крутым листенером.

В целом не думал что такой матерый серверо строитель не различает понятия протоколов Application\Trasport Layer. И прочитав тех документ не поймет о чем в нем речь. Owin — спецификация с абстракциями для Application Layer протоколов.

Зы: Я правда предполагаю, что существующие ASP.NET сервера врядли поддерживают такую первой необходимости штуковину как Unix Sockets при разработке Http приложений. :) Можешь гордиться своим мощным веб-сервером! Ведь не за горами то время когда на .NET Core без обилия библиотек понабегут фрики с гитхаба и начнут запиливать кучу сомнительных фич для своих эксклюзивных веб-серверов и бибилотек.

Вообще-то unix sockets вовсю используются веб-серверами для проксирования запросов на локальный сервер, чтобы избежать накладных расходов и ограничений, связанных с TCP. Под винндой они тоже есть и активно используются, только называются named pipes.

Pipes все же не unix sockets и отсуствие их поддержки так же очевидно для меня(крослпатформенный ASP.NET пока еще в стадии RC)
я был не прав в своих предположениях в предыдущем посте. в kestrel добавлены unix sockets.
github.com/...trelHttpServer/issues/156
Все это к ASP.NET имеет мало отношения, потому что это транспортный уровень веб сервера. К чему ты вывалил список транспортных особенностей твоего сервака, риплаем на документ о Application level абстракциях внутри приложения мне по прежнему непонятно. Обьяснишься?

То что Go появившись в том же году, что и Node.js со всеми проблемами языка и колбек хеллом преуспела куда больше в рядах веб разработчиков чем перспективный и удобный Go для меня тоже показательно.
Node.js набрал популярность среди неквалифицированных разработчиков по тем же причинам,что и PHP — на нем легко наговнокодить, не соображая в программировании. Среднее качество кода проектов на nodejs это наглядно демонстрирует.

Тоесть JS проще чем Gо все-таки выходит?

Go проще, чем JS, но на JS проще наговнокодить, не соображая в программировании. Вот основные моменты:

— JS прячет ошибки наподобие обращения к неинициализированному полю объекта или выход за границы массива. Быдлокодеры обожают, когда их говнокод не валится по таким «пустякам», как выход за границы массива, и даже не выдает никаких ворнингов.
— JS «магически» преобразует один тип в другой сплошь и рядом. Говнокодеры балдеют от «магии». До тех пор, пока не придется искать коварный баг, связанный с автоматическим преобразованием типов.
— В JS можно «магическим» образом добавлять и override’ить произвольные поля в чужих объектах и классах (ака prototype’ах), в т.ч. во встроенных в язык типа

''.constructor.prototype.foobar = function() { alert("Я молодец! Я добавил во все строчки метод foobar!") }
window.open = function() { alert("Хрен вам, а не новое окно!") }

К во всему этому nodejs добавляет еще немного «магии» в виде callback’ов на каждый чих. Которые с течением времени превращаются в callback hell.

— JS прячет ошибки наподобие обращения к неинициализированному полю объекта или выход за границы массива.
TDD? не, не слышал
— JS «магически» преобразует один тип в другой сплошь и рядом
последний раз такая бага была полтора года назад, за последние года 4 (какие баги были до этого уже не помню) очень активного девелопмента на джс
— В JS можно «магическим» образом добавлять и override’ить произвольные поля в чужих объектах и классах (ака prototype’ах), в т.ч. во встроенных в язык типа
эммм.... за всю практику видел токо одного человека кто так сделал, но на код ревью забраковали
К во всему этому nodejs добавляет еще немного «магии» в виде callback’ов на каждый чих.
это единственное резонное замечание тут

Все вышеизложенное справедливо в контексте «почему nodejs популярнее, чем go среди низкоквалифицированных разработчиков». Судя по слову Senior в вашем профиле, вас эти проблемы не должны касаться.

Как много js кода ты проревьювил в свой жизни? Откуда тебе знать о предпочтения js говнокодеров?:)
Есть простые факты.
Есть платформа, Node.js, которая появилась в 2009 году так же как и Go если не ошибаюсь.
За это время преуспела в продакшине для веб девелопмента намного больше, чем go. На Node, что делают сайты визитки в CMS сотнями — нет, при чем тут дилетантские проекты на PHP?
и если человек не получает удовольствия от обработки коллекции в циклах 3х уровней вложенности решая высокоуровневую бизнесс задачу на своем веб проекте он скорее всего хороший девелопер, чем наоборот.
Этим размышления про маргинальные технологии для избранных бред еще тот.

в циклах 3х уровней вложенности

Вы предлагаете заменить простые и понятные циклы на «магические» калбэки трех уровней вложенности внутри всяких непонятных map’ов, filter’ов и reduce’ов? Спасибо, не надо.

непонятных map’ов, filter’ов и reduce’ов
Я просто залишу це тут.
assets.toptal.io/...g-image-1409691715906.png
Якщо що, навіть у сьомої джави робота з колекціями незрівненно краща за гошне убожество.

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

Нода взлетіла, бо вже була товпа народу, що знала джаваскрипт.

var result = client.PostAsync("/ingest/data", content).Result;

КГ/АМ, выкладывайте побольше таких винов Go

:facepalm: Автор теста http Хендлер написать простой на dotnet не может не подключив громоздкий мвц Фреймворк и блочит все потоки на io — авторитно протестировал производительность технологий, нечего добавить.

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

Да походу не особо, вот вопрос из официального FAQ go (golang.org/doc/faq)


Is Google using Go internally?

Yes. There are now several Go programs deployed in production inside Google. A public example is the server behind golang.org. It’s just the godoc document server running in a production configuration on Google App Engine.

Other examples include the Vitess system for large-scale SQL installations and Google’s download server, dl.google.com, which delivers Chrome binaries and other large installables such as apt-get packages.

Короче раздавалка файлов для хрома и андроида (переписали одним человеком с С++ , так что можете прикинуть размеры проекта), надстройка над mysql для ютюба ну и тулзовины/утилитки для внутреннего употребления.

Короче го в гугле за 5 лет (или сколько там ему) не взлетел

Короче раздавалка файлов для хрома и андроида (переписали одним человеком с С++ , так что можете прикинуть размеры проекта),
Вот презентация от разработчика (Brad Fitzpatrick) по этой раздавалке — talks.golang.org/2013/oscon-dl.slide#1 .

kubernetes же. Хоть и не мега-огромный проект, но на него завязана внутренняя инфраструктура и Google Container Engine

опять девопс задача, вообщем контекст применения Го раскрыт, в реальных проектах только для скриптов развертывания, сборки, и управления инфраструктурой, но никакой бизнес-логики на нем

Как-то рано флейму затухать. Набросим неплохой пост о том, почему некоторые программисты делают такой странный выбор и предпочитают скале Го. golang-basic.blogspot.nl/...-which-one-to-choose.html . Совпадает с моим субъективным ощущением и тем что я наблюдаю вокруг. Добавлю от себя что скала несомненно интересный язык и ознакомление с ней или Хаскелем однозначно полезно для расширения кругозора. P.S. не ПХПышник.

Given the language specs, it should be no surprise that Scala has more features than Go.

Does that mean Go is any less expressive than Scala?
No, you just might need to write a few extra lines to code to do what you want (but I don’t think that is a bad thing).

waat?

«Очевидно что у Мерседеса 500 лошадиных сил, у Ланоса 100. Означает ли это что Ланос менее мощный чем Мерседес? Нет! Вам всего лишь нужно смастерить Ланосу двигатель на 500 лошадиных сил (и я не вижу в этом ничего плохого).»

Как вообще можно сравнивать эти два совершенно разных языка для совершенно разных задач?


Как вообще можно сравнивать эти два совершенно разных языка для совершенно разных задач?
Ну не знаю как у вас там, а какбы топик начался из вот такого вот сравнения. И в моей среде возникают такие вопросы когда нужен хороший concurrency — куда идти — java, scala или go. Scala проигрывает.

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

Ну хорошо что ты вычитал что тебе нужно было.

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

Ну в этом определенный плюс в go, без шуток.

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

Другое дело go. Пишешь, видишь что получается говно, но душа спокойна, по-другому вообще никак нельзя, в go это стандартная практика. Поэтому сидишь, фигачешь говно, и получаешь результат. Как потом это все развивать и поддерживать — это уже другой вопрос.

поэтому всегда преследует мысль что код не идеален, что можно было написать лучше, что матерные скалисты посмотрят и засмеют, и в итоге многие куски переписываешь несколько раз.
Это если есть время то они переписываються, если нет времени то нет. Вообще проблема больше не в самопериписывании, а в том, что в команде народ может использовать разные стили/подходы совершенно, дговориться использовать один подход — невероятно тяжело. Поддерживать чужой код написанный в другом стиле — тоже не просто, от того все проблемы и растут.
Но это же не значит что от скалы нужно отказаться прям всем командам на всех проэктах в пользу копи-пейст го.
На скале есть куча способов сделать одно и то же разными способами
ну из за этого сразу возникает проблема, что чужой код нифига не читаемый. Или чел захочет
что можно было написать лучше
любуешься какой красивый получился дизайн
и начнет функциональщину пилить, тогда как бы все...

По собственному опыту, один и тот же проект на скалле и на го, после месяца перерыва, код на скалле вспоминается и читается лучше, чем код на го

Наверняка имееться ввиду свой код.
Хотя флетмапов вложеных фолдлефтов с _._1._2._1 можна побыстрому напилить так что потом уже через пару недель сам же будеш материшся, непонимая что происходит.

Ну код на го тоже мой. У меня главная цель это читаемость и понятливость кода, и скала позволяет писать читаемый код, а го нет — как не прыгай, все-равно глаза кровоточят, в основном из-за мусора в коде.

Тут я соглашусь, при прикладывании усилий на скале можна написать читаемо. Сколько усилий к го не прикладывай — дженерики там не появяться, всеравно копи пейстить нужно.

По собственному опыту, один и тот же проект на скалле и на го, после месяца перерыва,
А что был опыт когда один и тот же проект писался и на скале, и на гоу, (как раз под эту тему), а потом на месяц забивался ? :)

так pet проект же, там и на год может заморозиться )

Та я ж про читаемость чужого кода говорил...

Я к тому, что скала в принципе позволяет писать более читаемый и понятный код, но, все зависит от команды.

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

по-настоящему смешно будет, в разрезе этого топика, если Пайк с Фицпатриком таки ВНЕЗАПНО! дженерики запилят

Они никуда не денутся, без дженериков go так и останется языком для консольных утилиток

Сначала прочлось «улиток» :)

ти перебільшуєш, Павлуша, як завжди ©

let alone docker (хм, “консольная утилитка”?)

но ведь высоконагруженные сервисы вроде dl.google.com смотрят на вашу фразу, как на г-но (тестимониал от Брэда Ф. легко находится)

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

но я видел кое-какие internal testimonials (среди которых и переписывание высокнагруженных сервисов, вроде сжимающей прокси)

и они очень, очень впечатляющи, надо отметить

ну вот опять, по кругу...

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

вы таки выказываете явные признаки функциональной неграмотности,
прямо сейчас

вы точно этого хотели?

Что нефиг поднимать вопросы, которые уже обсудили. Читайте ветку, и отвечайте где вы не согласны. А то сейчас пойдет все по кругу:

я: докер консольная тулзовина
вы: какая тулзвовина?!?! Да там исходников на целых 10 мбайт!!!
я: 10 мбайт это фигня по сегодняшним меркам, да и логики особо никакой, вот докер на баше в 100 строчек кода
вы: бебебе, бебебе. Зато я на go могу держать миллион открытых соединений на одной ноде!
...

вы: какая тулзвовина?!?! Да там исходников на целых 10 мбайт!!!
вы: бебебе, бебебе. Зато я на go могу держать миллион открытых соединений на одной ноде!

простите, но вы путаете меня с демонами из своей головы

ЗЫ таки поднаброшу
вот еще «консольная тулза»
vitess.io/overview
я за нее сам не знал, честно говоря

на ней работает ютуб
весь

она опенсорс, вот хаб
github.com/youtube/vitess

enjoy

Тут вообще 5 мбайт исходников, причем по заявлению самих же разработчиков, производительность получилась на уровне джавы, мда.

Вопрос не в том можно ли писать что-то кроме консольных утилит в принципе, вопрос в целеобразности.

шито?

в целесообразности чего?

быстрого и надежного главного даунлоад-сервиса для гугла?
витесса для ютуба?

а?

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

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

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

Уже не смешно — Фицпатрик обещает следующие штуки в следующих версиях гоу:
— Generics
— Sum types
— List comprehensions
— Immutability
— ~memory @ownership
— Data races statically impossible

См. слайды 17-30 из его презентации docs.google.com/...lide=id.g118cf9b85c_0_263 .

Так оно же все не нужно! Разве нет? Да и го попробуй потом выучи, столько новых слов, конструкций, функционала, будет не проще джавы.

Если это все введется, и не будет крупных фейлов, то это будет совсем другой, отличный от текущего, Го. И это было бы круто. Еще бы тайпклассы появились (а с дженериками должны), было бы идеально, остальные нужные штуки подтянутся.

Забавно, что кое-кто активно спорит, что перечисленные вещи «не нужны».

Edit:
Пролистал презентацию, чувак просто троллит. Никаких дженериков и прочего не будет, не повезло гоферам.

Посмотрел все слайды. Забыли добавить, Go 2.0:

  • .....вышесказанное
  • Data races statically impossible
  • Years of mistakes revisited
  • Tons of feature request resolved
-> в конце Sorry! I lied ..... So when is Go 2.0 ? — No plans maybe never.

Приходите к нам в Go-секту праздновать выход новой версии Go 1.6 — dou.ua/calendar/9812 . Вход бесплатный. Обещают пиво с пиццой на халяву.
Ждем скала-адептов и любителей nodejs для обращения в нашу веру. Обсудим преимущества гоу за рюмкой чаю.

Щоб пожвавити дискусію накину і я.

Перше і головна проблема го це дійсно якісь занадто агресивні адепти. Вони як чеченські терористи — їх кілька сот людей може усього по світу, а галасу від них як наче їх мінімум кілька сот тисяч. І через них враження про інших представників народу складається упереджене.

Я вже колись пропонував Івану Данилюку написати quick sort на го: добре усім відомий алгоритм з нюансами який на будь-якій мові займає усього кілька рядків, можна продемонструвати всю красоту го-рутін, як передаються функції як параметри (компаратор) та інше. І я навіть знаю що одним з перших питань до реалізації буде «а як мені те саме зробити для абстрактного типу?». І навіть можете сказати що у архаїчному С qsort вміє працювати з довільними типами. На що Іван скаже «ха-ха-ха, вам не вистачає дженеріків? Неправильно ви критикуєте го, ось моя стаття як правильно критикувати го...».

І навіть якщо ви не дасте перетворити своє питання на жарт хтось з гошників почне вас питати «а нащо вам дженеріки» та «а як часто вам треба писати контейнери та сортування в реальному житті». На що я можу відповісти що дуже часто, майже щодня. В коді з яким я працюю і взаглі будь-хто працює у великому проекті контейнери та алгоритми використовуються повсякчасно і те саме сортування лежить в основі багатьох колекції та пошуках і виборках що є в нашому коді.

Також дуже помітно небажання приймати реалії такі як ризикованість переходу на го просто через відсутність програмістів на ньому та непопулярність і маловідомість мови. Ніякі статистичні дані з порівняння популярності та поширеності мов гошніками не приймають бо вони «неправильні», а запропонувати власний спосіб оцінювання крім «ось в цьому репозіторії на гітхабі все на го» чи зібрати власну репрезентативну статистику якось ніхто не спромігся.

Протиставлення го та С++ просто сміхотворне. Так, дійсно, С++ з історичних причин зараз використовується багато де це не має сенсу зараз і де є кращі альтернативи як Java/C# чи пітон. Щодо виживання і можливого поширення мови то я думаю з невпинними вливаннями гугла і при умові що вони не закинуть го через пару років як це сталося з черговими їхніми «усіх переможем» базом, вейвом та іншими вбитими технологіями то років через 5-10 можливо буде помітно як го тіснить пітон.

Думаю що самі творці мови прекрасно розуміють що вони створили просунутий шел-скріпт з підтримкою многопоточності куди ніхто руками не зможе залізти і ручна синхронізація не потрібна. Проста виразна мова для написання утіліт — це ж прекрасно! Але гошнікам чомусь таке визначення не подобається і їм обов’язково треба усім доводити що «скоро не буде С++, не буде дженеріків, не буде ексепшенів, не буде віндовса, не буде радіо і телебачення, не буде ГМО і РПЦ, буде один го».

смешались в кучу конелюди

Це щоб кожен знайшов на що побугуртити.

Прое́кция (лат. projectio — бросание вперед) — психологический процесс, относимый к механизмам психологической защиты, в результате которого внутреннее ошибочно воспринимается как приходящее извне[1]. Человек приписывает кому-то или чему-то собственные мысли, чувства, мотивы, черты характера и пр., полагая, что он воспринял что-то приходящее извне, а не изнутри самого себя

Недоречна цитата — така що по тексту, змісту, стилю, і речам яким дається оцінка не співпадає з текстом до якого цю цитату приведено. Наприклад:
А: я стверджую що X, Y та Z
Б: забагато непов’язаних тверджень
А: це щоб кожен щось для себе знайшов
Б: це у вас проекція <— недоречне твердження

вы за свое чванство и невынужденный комсомольский апломб будете НАКАЗАНЫ, товарищ

Ломай мєня полностью!

Я вже колись пропонував Івану Данилюку написати quick sort на го: добре усім відомий алгоритм з нюансами який на будь-якій мові займає усього кілька рядків

Зачем изобретать колесо, если оно уже изобретено в стандартной либе — github.com/...8f5b029d/src/sort/sort.go . Там и quicksort в пару строчек, и heapsort, и insertionsort. И все это работает для любых типов данных без дженериков.

Ето какой-то позор! ©

Де ж там го-рутіни, де компаратор? Чи це треба усі мої типи даних від Interface успадковувати і імплементувати operator < для них? Поясніть плз.

Зачем горутины в quicksort?

А для чого вони в го взагалі? Я думав це якась гітлєр-фіча якою будуть вбивати всі інші мови. Ну і попросив демонстрацію цієї фічі на добре усім відомому і короткому в реалізації алгоритмі.

Горутины — это аналог потоков в других языках. Только с горутинами работать легче. Например, можно наплодить миллион горутин, не беспокоясь, что они сожрут всю память с процессором. В quicksort они не нужны. А вот в каком-нибудь высоконагруженном сервере нужны.

Тут не питання доцільності, прохання було продемонструвати го-рутіни та може якісь інші особливості мови на добре усім відомому алгоритмі реалізація якого вкладається у кілька рядків.
Мені здається я це вже рази 2 чи 3 повторював. І поки що почув як і очикував що «дженеріки не потрібні» та «як часто вам доводиться писати ...?» в купі з абсолютно чарівним «що складного скопіпастити код?».

Ну а если масив в терабайт — распаралелить ?

Для массива, который не помещается в памяти, нужно использовать mergesort, а не quicksort. Иначе задолбетесь ожидать на random IO операциях. И SSD тут не спасет.

У _quick_sort нет прыжков random i/o, процесс разделения отрезка идёт двумя встречно сжимающимися без прыжков указателями. Если чуть-чуть помочь ОС в понимании нужности страниц (возможно при mmap через madvise()) - получается не хуже, а часто и лучше, чем mergesort и прочие «внешние» сортировки. И даже если не помогать — алгоритмы VM работают достаточно неплохо.
(Вместе с упоминанием единственного mergesort среди всего огромного пространства внешних сортировок наглядно показывает ваш «уровень» знания вопроса.)

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

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

Стандартный шедулер горутин мешать не будет, т.к. у него очень низкие накладные расходы. Только что проверил — он может запускать и уничтожать 6 миллионов горутин в секунду на моем ноуте. Причем эта скорость остается постоянной при любом количестве параллельно выполняющихся горутин от четырех штук до четырех миллионов штук. Вот соответствующий код для проверки:

func BenchmarkGoroutineOverhead1(b *testing.B) {
        benchmarkGoroutineOverhead(b, 1)
}

func BenchmarkGoroutineOverhead10(b *testing.B) {
        benchmarkGoroutineOverhead(b, 10)
}

func BenchmarkGoroutineOverhead100(b *testing.B) {
        benchmarkGoroutineOverhead(b, 100)
}

func BenchmarkGoroutineOverhead1000(b *testing.B) {
        benchmarkGoroutineOverhead(b, 1000)
}

func BenchmarkGoroutineOverhead10000(b *testing.B) {
        benchmarkGoroutineOverhead(b, 10000)
}

func BenchmarkGoroutineOverhead100000(b *testing.B) {
        benchmarkGoroutineOverhead(b, 100000)
}

func BenchmarkGoroutineOverhead1000000(b *testing.B) {
        benchmarkGoroutineOverhead(b, 1000000)
}

func benchmarkGoroutineOverhead(b *testing.B, parallelism int) {
        b.SetParallelism(1)
        b.RunParallel(func(pb *testing.PB) {
                ch := make(chan struct{})
                for pb.Next() {
                        go func() {
                                ch <- struct{}{}
                        }()
                        <-ch
                }
        })
}

Вот результаты тестов:

$ go test -bench=. 1_test.go 
testing: warning: no tests to run
PASS
BenchmarkGoroutineOverhead1-4      	10000000	       184 ns/op
BenchmarkGoroutineOverhead10-4     	10000000	       183 ns/op
BenchmarkGoroutineOverhead100-4    	10000000	       183 ns/op
BenchmarkGoroutineOverhead1000-4   	10000000	       184 ns/op
BenchmarkGoroutineOverhead10000-4  	10000000	       183 ns/op
BenchmarkGoroutineOverhead100000-4 	10000000	       183 ns/op
BenchmarkGoroutineOverhead1000000-4	10000000	       183 ns/op
Стандартный шедулер горутин мешать не будет, т.к. у него очень низкие накладные расходы.

То есть даже минимально вдуматься в смысл моего сообщения Вы не попытались. Спасибо за подтверждение моих выводов.

Я не гоубой, но вижу, что в вашем коде в benchmarkGoroutineOverhead параметр parallelism игнорируется и всегда вызывается SetParallelism(1)

Можно в двух словах объяснить в чем СУТЬ этого бенчмарка?
И почему при увеличении кол-ва параллельных потоков производительность не увеличивается? По логике должна увеличиваться, пока вы не уткнетесь в кол-во ядер

Правильно заметили — вместо единицы должно быть parallelism. Иначе все время измеряется скорость создания горутин из четырех параллельно работающих горутин. Но если заменить единицу на parallelism, то результаты не изменятся.

И почему при увеличении кол-ва параллельных потоков производительность не увеличивается? По логике должна увеличиваться, пока вы не уткнетесь в кол-во ядер
Все верно. Просто при parallelism=1 бенчмарк запускается на количестве потоков, равному количеству ядер. На моем ноуте это четыре. Поэтому при увеличении количества параллельных потоков скорость не растет. Но и не падает.

Что мне подсказывает, что бенчмарк не правильный. Если потоков больше чем ядер — должны быть накладные расходы на переключение, ни один го это не обойдет.

там по сути BenchmarkGoroutineOverhead1 запускается кучу раз и все, а benchmarkGoroutineOverhead тупо игнорирует второй аргумент, короче бенчмарк ни о чем, как и его объяснение о его логике...

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

Можно сказать иначе — никогда ещё доказательство O(1) == O(1) не было таким запутанным. :)

Причем тут реализация? Вопрос в использовании. Вот небольшой примерчик:

struct Person {
    Age int
    Name string
}

people := []Person { ... }

peopleByAge = ...

А теперь поведай нам непутевым, как на выразительном go, на котором код «в 10 раз короче» ©, отсортировать людей по возрасту? И это ведь самый что ни есть элементарный пример.

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

Не зря же морозиться, многие даже не догадываются насколько все плохо:

struct Person {
    Age int
    Name string
}

type ByAge []Person

func (a ByAge) Len() int {
    return len(a)
}

func (a ByAge) Swap(i, j int) {
    a[i], a[j] = a[j], a[i]
}

func (a ByAge) Less(i, j int) bool {
    return b[i].Age < b[j].Age    
}

people := []Person { ... }

sort.Sort(ByAge(people))

Это сортировка только для одного типа по одному свойству. Хотите еще по чему-то отсортировать? Фигачьте еще одну кастомную коллекцию и имплементьте интерфейс.

И вот с этим они собираются убивать скалу, джаву, C#...

Ну какбы не однострочник конечно, но и страшного ничего такого в этом нету. Покажите лучше как вы в скале, Джаве или шарпе создадите подпроцесс типа горутины и получите из него данные а ля go chan.

Ну какбы не однострочник конечно, но и страшного ничего такого в этом нету.

Ну в go комьюнити вообще в отсутствии дженериков с дебагером ничего страшного не видят, а некоторые даже выдают это за преимущество.

Покажите лучше как вы в скале, Джаве или шарпе создадите подпроцесс типа горутины и получите из него данные а ля go chan.

Типа это единственное правильное решения. У скалы есть akka, у C# - async/await:

var result = await DoSomeHeavyComputationAsync()
Ну в go комьюнити вообще в отсутствии дженериков с дебагером ничего страшного не видят, а некоторые даже выдают это за преимущество.
 а что страшного в отсутствии дебагера для матерых программистов и не желающих смешиваться с ниасилившими? Настроить все-таки какой-то из дебаггеров? Или может скала прямо так легко дебажится с несколькими абстракциями и лямбдами в одной строке? Ну то есть было бы конечно неплохо с дебаггеризацией попроще, но опыт фронтэнда показывает что и без дебаггера жизнь вполне себе есть.

Отсутствие дженериков — да, для меня лично плюс. Плюс по сравнению с недо-дженериками джавы или супердженериками скалы. Особенно после переезда на микросервисы (отдельный вопрос в чем это хорошо, а в чем плохо) в моем лично опыте большинство работы с дженериками ушло на уровень объявления типа коллекции. Добавят в Го дженерики хорошо — ок. Не добавят — не смертельно.

Типа это единственное правильное решения.

О том и речь. Дженерики это не единственное правильное решение.

хотел что-то писать, потом заметил:

Mykola Gurov Жирный тролль

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

Ну а что отвечать человеку, для которого фигачить кастомные типы и копипастить функции по каждому пчиху это

для меня лично плюс

Это нужно хорошо упороться, чтобы вот это:

func FindRatesTo(rates *[]ExchangeRate, rateTo string) *[]ExchangeRate {
    result := Rates {}
    
    for _, r := range *rates {
        if (r.To == rateTo) {
            result = append(result, r)
        }
    }

    return &result
}

usdRates := FindRatesTo(&rates, "USD")

считать плюсом по сравнению с этим:

val usdRates = rates.filter(_.to == "USD")

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

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

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

Ну а что отвечать человеку, для которого фигачить кастомные типы и копипастить функции по каждому пчиху это
ну прежде чем отвечать неплохо бы понять собственно на что. Я говорю что дженерики плохо или что Го лучше без дженериков. Я говорю что Го лучше без таких дженериков как в Джаве или Скале.

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

опыт фронтэнда показывает что и без дебаггера жизнь вполне себе есть.

То-то в Chrome встраивали самые продвинутые developer tools, а один мой бывший босс — фронтэндщик говорил, что это единственный нормальный браузер, именно из-за этих тулзов. Среди которых отладчик с возможностью хотя бы посмотреть внутрь объекта занимает совсем не последнее место.

а что страшного в отсутствии дебагера для матерых программистов

Отладчик это не только тулза для «остановиться по breakpoint и посмотреть переменные», хотя и это крайне важно для освоения новых средств (при первичном обучении программированию — для новичков, при переходе на новые языки, среды, фреймворки — для опытных), но и средство анализа истории события, включая посмертные состояния. «Страшного», конечно, в большинстве случаев нет, а вот потеря времени на непроизводительные движения вместо съёма конкретного состояния — может быть существенна.

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

Отсутствие дженериков — да, для меня лично плюс.

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

... Среди которых отладчик с возможностью хотя бы посмотреть внутрь объекта занимает совсем не последнее место.
очень близко к последнему, ИМХО. В принципе если кусок нормально тестируем то console достаточно удобна.
средство анализа истории события, включая посмертные состояния.
это про мемори дампы? Для меня эти задачи как-то с дебагерром не очень связаны. Может что-то пропустил?
Тогда покажите замену для ранее приведённых примеров, где их отсутствие приводило к порождению лишнего кода.
это не есть самоцель.
Для меня эти задачи как-то с дебагерром не очень связаны. Может что-то пропустил?

Э?


$ gdb ./foo /var/tmp/foo.core
gdb> bt
gdb> f 0
gdb> p arg1
gdb> p *arg1

ну и так далее.

это не есть самоцель.

Не понимаю связи этого предложения с поднятым вопросом.

troll-mode-on:

import gopher._

 def fibonacci(c: Output[Long], quit: Input[Int]): Future[Unit] = go {
     var (x,y) = (0L,1L)
     for(s  <-  select.forever) {
      s match {
        case z: c.write if (z == x) => 
                      x = y 
                      y = z+y
        case q: quit.read =>
                 implicitly[FlowTermination[Unit]].doExit(())
      }
   }
 }

def run(n:Int, acceptor: Long => Unit ): Future[Unit] =
 {
    val c = makeChannel[Long](1);
    val quit = makeChannel[Int](1);
    val r = go {
        var i = 1
        while(i <= n) {
            val x: Long = (c ?)
            //Console.println(s"received: ${i}, ${x}")
            acceptor(x)
            i += 1
         }
        quit <~ 0
    }
    fibonnacy(c,quit)
}

Из github.com/rssh/scala-gopher

Фигачьте еще одну кастомную коллекцию и имплементьте интерфейс.

Да, так сложно объявить «кастомную коллекцию» в одну строчку и скопипейстить три элементарных метода. Зато, в отличие от других языков программирования, стандартная сортировка в гоу работает с произвольными коллекциями, реализующими три вышеуказанных метода, а не только с array’ем.

Да, так сложно объявить «кастомную коллекцию» в одну строчку и скопипейстить три элементарных метода.

Сортировка это только один из 1000 случаев. Еще парочка примеров велосипедостроения:

func Contains(array *[]ExchangeRate, from string, to string) bool {
    for _, pair := range *array {
        if (pair.From == from && pair.To == to) {
            return true
        }
    }

    return false
}

rates := []ExchangeRate {
    ExchangeRate { "UAH", "USD", 0.04 },
    ExchangeRate { "EUR", "USD", 1.07 },
}

if (Contains(&rates, "GBR", "USD") == false) {
    blah blah
}
func FindRatesTo(rates *[]ExchangeRate, rateTo string) *[]ExchangeRate {
    result := Rates {}
    
    for _, r := range *rates {
        if (r.To == rateTo) {
            result = append(result, r)
        }
    }

    return &result
}

rates := []ExchangeRate {
    ExchangeRate { "UAH", "USD", 0.04 },
    ExchangeRate { "EUR", "USD", 1.07 },
}

usdRates := FindRatesTo(&rates, "USD")

И это только самые элементарные примеры. Как-то многовато выходит для языка, у которого «код получается в 10 раз короче» ©, не находите?

Зато, в отличие от других языков программирования, стандартная сортировка в гоу работает с произвольными коллекциями, реализующими три вышеуказанных метода, а не только с array’ем.

Озвучьте список таких языков пожалуйста

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

Не так то, что в нормальных языках все так:

val rates = 
    ExchangeRate("UAH", "USD", 0.04) ::
    ExchangeRate("EUR", "USD", 1.07) :: Nil

if (rates.exists(r => r.from == "GBR" && r.to == "USD")) {
    blahblah
}

val usdRates = rates.filter(_.to == "USD")

Вообще удивительно, модификаторы доступа в java, C# для вас это ужас-ужас, а вот всякие велосипеды на каждом шагу в go в виде отдельных типов, функций и интерфейсов — «не вижу проблем». Это все-равно чтобы целый день считать калории, есть здоровую пищу, заниматься в спортзале, потом прийти вечером домой и перед сном сожрать большую пиццу, запивая ее пивом.

Модификаторы доступа и прочая verbose хрень в жаве не несет смысловой нагрузки. Поэтому не нужна. В скале же бросаются в другую крайность, жертвуя простотой в угоду краткости кода.

В вашем примере код на гоу проще и понятнее кода на скале.
Для понимания скала кода нужно знать, как работают exists и filter, какие у них есть подводные камни, что такое ’=>’, ’_’, а также сокращенный синтаксис лямбда-функций.
Для понимания гоу кода достаточно базовых знаний программирования — переменных, функций, циклов и условий.

В гоу, в отличие от скалы, соблюден идеальный баланс между простотой и краткостью кода. Поэтому большие проекты на гоу занимают в 10 раз меньше строчек кода, чем на скале.

епт, а для понимая кода на го нужно иметь начальные знания паскаля или хотя бы знать что такое ’:=’

Для понимания скала кода нужно знать, как работают exists и filter, какие у них есть подводные камни, что такое ’=>’, ’_’, а также сокращенный синтаксис лямбда-функций.
ок ты сделаешь тоже самое, нахерачив 20 строк кода и применив 3 вложенных цикла. это можно сделать в любом языке, не надо даже базовую теорий множеств и английский язык учить. обычно на код ревью за такой бестолковый низкоуровневый код руки отбивают, потому что нужно знать
какие у них есть подводные камни
прежде чем дублировать реализацию алгоритма
.
Такую безальтернативность инструментария, называть
идеальный баланс между простотой и краткостью кода.
самообманом заниматься

ОК, признаюсь — в гоу мне иногда не хватает list comprehensions из Python. Только не говорите про это Робу Пайку.

так чего ж говорить, если в оф доке к языку пишут что мозгуют как Дженерики подкостылять бы.
Видать Роб Пайк таки не до конца доволен такому балансу простоты, когда в каждой бибиотеке надо пустой интерфейс обьявлять с бесодержательным названием и сознательно прибивать плюшки статической типизации.

В гоу, в отличие от скалы, соблюден идеальный баланс между простотой и краткостью кода. Поэтому большие проекты на гоу занимают в 10 раз меньше строчек кода, чем на скале.
У пациента явно проблемы с логикой )

Проблемы не с логикой, а с тем, что я дал недостаточно развернутый ответ, чтобы вы могли уловить смысл :)

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

Чем больше проект, тем меньшую роль играет краткость синтаксиса в минимизации объема кода. На первое место выходит архитектура проекта. Чем проще архитектура, тем меньше кода. Архитектура проекта сильно зависит от идеологии выбранного языка программирования:

— Java поощряет лишние абстракции.
— Scala — в дополнение к лишним абстракциям от своего предка-Java добавляет лишнюю мультипарадигменность и матан.
— Go поощряет простоту архитектуры.

Поэтому большие программы на гоу получаются в 10 раз короче и в 10 раз проще программ на скале.

Вы смешиваете синтаксис и семантику в языке. Синтаксис, действительно, почти ни на что не влияет. А вот семантика является именно тем, что отличает языки программирования.

К слову, я так и не понял, за счет чего Го «поощряет простоту архитектуры» ? Интерфейсы == тайпклассы для бедных, горутины == еще-один-способ-для-параллелизации (который зачем-то всунули в ядро языка). Богатая стдлиба, которая извлекла уроки из ошибок той же джавы — это, безусловно, плюс. Но стдлиба вообще никак не относится к языку. И сам вопрос «чья стдлиба круче» открытый.

Ожидаю ответа в духе «Го дает простоту архитектуры за счет: фича1, фича2, ...». Код-ревью лежит вне ЯП, и не является фичей. Фичи должны быть конкретными, а не «блаблабла проще читать, блаблабла поощряет хорошую архитектуру, ...». Желательно с примерами, когда задача А на Го решается в 10 строчек, а на Скале в 100. Примеры обратного я, если хотите, могу предоставить.

Ну я явно вашего дзена не постигаю, видимо трава не та.
Нету дженериков — нужно плодить 100500 класов, а код все же короче получаеться.

Любой большой проект это взаимодействие модулей, желательно со слабой связностью. Каждый модуль это набор абстракций, взаимодействующих между собой. Каждая такая абстракция состоит из функций. Абстракции и функции уже напрямую зависят от выразительности и функциональности языка. Скала, например, позволяет писать компактные типы и функции, go же наоборот, для каждой «скальной» функции провоцирует создавать дополнительные типы и функции-сателиты. То есть на этом уровне go сливаеться в сухую. Теперь вопрос, как синтаксис и идеи go, могут сократить количество абстракций и модулей в проекте?

А вообще, это прекрасно я считаю:

стандартная сортировка в гоу работает с произвольными коллекциями, реализующими три вышеуказанных метода, а не только с array’ем.

всего пару часов назад чуть ниже:

Какие контейнеры кроме array и hashmap вы используете каждый день?

(facepalm)

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

Ага, і цей спосіб яким вона «работаєт» називається «хіба так складно зробити ще один копі-паст?». Дуже, дуже передові технології!

Так складно користуватися мовою в якій копі-паст не є необхідністю?

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

Какие контейнеры кроме array и hashmap вы используете каждый день? Эти два контейнера встроены в Go и позволяют работать с произвольными типами. Остальные контейнеры используются настолько редко, что не составляет никакого труда написать их кастомную реализацию под требуемый тип данных.

Какие контейнеры кроме array и hashmap вы используете каждый день

map (той що на tree побудовано), set, list, multiset. А ще є алгоритми типу find_if, transform, copy та інші.

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

Під всі кілька сотень моїх типів даних у кількох десятках проектів? Ні, дякую, приходьте зі своїм го коли у вас буде рішення яке не вимагає копіпасти у обсязі половини моїх сорців.

map (той що на tree побудовано), set, list, multiset. А ще є алгоритми типу find_if, transform, copy та інші.

set и multiset заменяется на hashmap.
list — на array или blocking queue aka channel в зависимости от контекста.
map — на hashmap или sorted array в зависимости от контекста.

find_if — на обычный цикл или sort.Search в зависимости от того, отсортированы ли данные в контейнере.
transform — обычный цикл с вызовом нужной функции.
copy поддерживается Go для массивов любых типов.

Welcome to Basic? Ще раз ні, їжте це самі.

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

По-перше, копі-паст це ней той спосіб яким недосвічені програмісти можуть підтримувати код у стані простоти. А, по-друге, у нас вже є прості і виразні мови без колекцій/дженеріків/ексепшенів та повторного використання коду взагалі, але з циклами. Го серед них виглядає дуже пристойно тому що вміє у многопоточніть і тому що гугл поки що вливає в неї.

Я ж не проти го, і якщо виникне необхідність буду на ній писати так само як при необхідності пишу на Power Shell, shell, python та навіть cmd. Мені не подобаються оці казочки що на го можна писати і переписувати складні і старі системи.

Последние новости — Intel использует golang — habrahabr.ru/...ompany/intel/blog/275709 .

Нет, т.к. гоу поддерживает винду.

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

Це не зрада, а перемога. Под виндой не работает бОльшая часть популярных сторонних библиотек. Так что виндокодеры обречены на адские муки :)

Бородатые линуксоиды одобряют.

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

Мабуть просто ще ніхто прийом «хіба так складно зробити копі-паст?» не застосував.

Справедливости для, копипаст иногда предпочтительнее архитектурного выделывания в духе «вооот эти две штуки почти одинаковы, а потому давайте сделаем общий интерфейс». Потому что это «почти одинаковы» может как сузиться, так и расшириться, а попытки натянуть «общий интерфейс» на изменившуюся предметную область наверняка останутся.

Но это частный случай YAGNI, и к Го не имеет отношения. У последнего нет оправданий для своего бескомпромиссного навязывания копипаста. Например, почему нельзя было сделать interface тайпклассом?

Справедливости ради, вышеуказанная проблема с интерфейсами разрешается через концепт утиной типизации, реализованный в Go.

Решается (еще бы и она не решалась, хех). Только интерфейсы — не «утиная типизация», а недотайпклассы (тк первые доказательно более слабые, чем вторые). И, как многие Го-паттерны, выглядят убого на фоне конкурентов.

Для справки, в последнем зарплатном опросе, скальных анкет не много, но получают они дофига. Го вообще в списке нет, а если бы и были, то получали бы на уровне ПХП, питона. Так что в интересах разработчиков, чтобы скала развивалась и шагала по планете. Менеджерам конечно лучше продвигать что-то простое типа go. Поэтому немного удивляет когда некоторые разработчики болеют за go и искренне верят что он убьет скалу, джаву, .net и захватит мир. Или все вы спите и видите себя стартаперами набирающих студентов за гроши? Может единицы из вас и станут стартаперами, но вот большинство из вас будут в роли этих студентов работать за гроши.

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

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

Ну го вообще не спасает от этого.

Вот играюсь сейчас с go, наговнокодить там раз плюнуть. Да, он прост в изучении, но чтобы писать нормально спроектированные, поддерживаемые программы, нужен опыт, и над дизайном нужно так же само хорошо думать как в другом любом языке. Вот стандартная библиотека go спроектирована и написана нормально, любо глянуть, видно что умные, опытные люди писали. Но вот открыть репозиторий типичного гофера, «изучившего го на выходных и собирающегося запустить стартап с гоферами студентами» — там ад и Израиль. Да он написал то что хотел, и оно вроде как работает, но кроме него там никто ничего не разберет. Ну и кому нужны студенты изучившие го на выходных, если они не смогут въехать в проект написанный такими хипстерами?

ну они стараються и хорошо отбирают — умных и не жадных
соотведственно многим умным и жадным они совсем как работодатель не подходят

Так что в интересах разработчиков, чтобы скала развивалась и шагала по планете.

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

Опасения излишни, поскольку потребности в разработке софта растут и никуда не исчезнут, пока есть цивилизация. Несмотря на развитие php с увязанными фреймвёрками, другие языки и технологии тоже успешно развиваются, и php их не демпингует. Тут есть как раз другой момент. За счёт инкамеров с низким порогом входа рынок будет только расширяться и развиваться.

Прикольная логика, в которой вся илитарнасть как на ладони.
Во-первых после того не означает вследствие того. Программисты которые реально перешли на скалу обычно и ранее зарабатывали выше среднего.
Во-вторых призыв к сговору работников, программистов в данном случае, о требовании повышения оплаты не по результатам труда, а по использованию инструмента... Это да.
В-третьих — явное непонимвние что деньги берутся не из тумбочки, а колбаса не из холодильника.
В-четвёртых — интерес, мотивация разработчика ПО почему-то свелся к зарабатывания бабла лукавым способом.

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

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

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

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

В-третьих — явное непонимвние что деньги берутся не из тумбочки, а колбаса не из холодильника.

То есть вы хотите сказать что зарплата программиста зависит от успешности компании? Что же тогда гиганты как майкрософт и гугл платят даже чуть ниже рынка, хотя учитывая сколько они генерируют чистой прибыли, могли бы платить в 2 раза больше?

Язык программирования — не инструмент. Как и русский, японский и английский.
Но массово программерские илиты тупят.

Язык программирования — не инструмент.

Что по вашему тогда инструмент ? И что тогда по вашему язык программирования ?
Что по вашему тогда инструмент ?
то что работает, чем можно пользоваться без изменения мышления, а выполняя автоматические инструкции.
например еще НЕ инструменты — паттерны проектирования.
И что тогда по вашему язык программирования?
способ коммуникации, когда-то, вначале между человеком и компьютером, сейчас между людьми которых называют программистами.
Но как и с обычным языком — люди его используют не задумываясь о его свойствах.
Прикол случается тогда, когда они не задумываясь берутся рассуждать как филологи или лингвисты.

Scala — не инструмент, а язык более удобный для выражения мыслей, чем другие, для программистов определенной категории.
Haskell — не инструмент, а язык более удобный для выражения мыслей, чем другие, для программистов определенной категории.
Go, PHP, ... — о каждом можно сказать такое.

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

но нелеп вывод что себестоимость программы зависит от выбранного ЯП.
как и заявления — «нужно выбирать язык под задачу», «для одних задач лучше один язык, для других — другой» (хотя некоторое рациональное зерно есть, как в мнении что итальянский для оперы, а немецкий для армии).

Тобиш если вы хорошо знаете пэхэпэ, то вы готовы взяться писать и высоконагруженные сервисы, и драйвера и ОС на нем, потомучто вам в нем удобнее мысли выражать, а те кто выбирают язык по задаче — жалкие неудачники? Я вас правильно понял ?

я вам уже задавал этот вопрос
если на основании моих уж 6000 постов на доу вы пришли к четкому убеждению что я полный кретин — то чем я вам могу помочь? ничем. кретинизм такого 6к уровня неизлечим. ;)

зачем же вы задаете такие идиотские вопросы?
не иначе чтобы всем показать что вот он — конченный недоумок?
;)

ну а дочитавших отсылаю подумать над моей фразой:

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

Пару лет назад немножко потрогал Го, и первые впечатления были: «Ребята, вы серьезно? Си с GC и асинхронностью? Назад в 70-е — это, по-вашему, и есть инновации? Да и родословная от OS Plan9, чье название кагбе сознательно намекает на пожизненное лузерство? Да ну вас фтопку».

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

Ниша у Go определенно есть, но мне кажеться она сильно отлчаеться от Scala ниши

Конечно, т.к. у Scala нет ниши после прихода Go.

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

Все больше утверждаюсь что главный недостаток go это вовсе не отсутствие дженериков, и даже не отсутствие дебагера. Главный недостаток go это упоротое комьюнити. И дело не в том что плохие специалисты, нет, что Valialkin, что Данилюк, вроде не дурные люди, но вот это фанатическое помешательство на гугле и go, абсолютная вера в правильность идей Пайка и полное нежелание видеть другую сторону — это все сводит на нет.

у меня закралось это сомнение после того как в radio-t кажеться был совершенно нахрен поехавший малолетний гоферохам ( и кажеться бывший пехапешник) но после этого треда я в этом окончательно убедился :-)

Да, там не просто какой-то гофоман, там был один из ведущих golang show. Меня вообще удивляет само существование подкаста про go. Что там вообще можно обсуждать? Это же простецкий, примитивный язык для небольших задач. За выпуск, максимум два можно все фичи языка и практики обсудить. Разве что они там библиотеки обсуждают и новые проекты.

величие Пайка же обсуждать и объем его бицухи.

после прихода Go
Та приход что надо !
www.tiobe.com/...paperinfo/tpci/index.html
Если хочешь найди «Go» используй «ctrl + F» он восседает на троне между «EXEC. Forth» и «Hack, Icon»..... Чесно говоря нифига про такие языки и не слышал, как и про некоторые более передовые по сравнению с Гоу..... Приход просто ошеломительный....

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

PS. Гоу будет на первом месте по популярности в следующем году.

Если вдумаешся в смысл этой зомбофразы, поймешь что уже надо писать ’в этом’

Ну про Го я тоже не слышал, первый раз про него прочитал в этом топике

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

Если в самом начале года компьютер выиграл в Go у чемпиона Европы в пяти матчах из пяти (раньше считалось, что компьютеры не могут играть наравне с людьми в эту игру из-за слишком большой комбинаторной сложности), то это 100% год Go.

www.wired.com/...player-at-the-game-of-go

О_о

А какая связь между Го-языком и Го-игрой? Программа-победитель написана (как будто это имеет значение, но все же) на диалекте Lua.

Ну пусть даже есть сакральная, сокрытая от непосвященных вроде меня связь. Если Го-игру выиграл комп, то каким образом это «успех Го» ? Наоборот ведь.

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

Взаимосвязь очевидная: как известно, Go так же как и Lua в отличии от scala имеет хорошо проработанный концепт коротинов, функции могут возвращать несколько значений. Однозначно, это успех Go.

точно наркоман

Ну вот видите, Go покорил новую целевую аудиторию, в отличие от scala. Какие ещё могут быть сомнения в наступившей эре Go?

мне кажется он всех троллит... ну не может такого быть по-настоящему...

Та уныло. Если вначале еще был какойто энтертеймент, то сейчас тупо скучно смотреть на «дискусси» такого уровня.

PS. Гоу будет на первом месте по популярности в следующем году.
Ну это уже банальное трололо. Или же через некоторое время в обиход пойдет словосочетание новой болезни — «ГОвизм головного мозга», на подобии «православия головного мозга» и т.д.

Чуваки, разработавшие scalaz, точно болеют «скализмом головного мозга». А вот чуваков с «говизмом головного мозга» я пока не замечал.

Чуваки, разработавшие scalaz,
Покрайне мере, они не вопят в каждой ветке о том, что scalaz выйдет на первое место в следующем году.

Это потому, что даже они прекрасно понимают, что на первое место выйдет Go.

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

Эти статьи могут быть исключительно в целях чёрного пиара Go, очевидно же.

Го виділяється серед інших настільки ж «популярних» мов лише тим що нею опікується гугл і постійні вливання не дають їй бути непоміченою.

Что-то Dart не взлетает. Тоже детище гугла.

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

У Го другая ниша

Простота это хорошо, если не возводить ее в абсолют.

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

А разве был выбор? Там где нужен был перфоманс, или низкий уровень, приходилось использовать С, ну или С++ на худой конец. Потратили новонавернене количество человеко-ресурсов чтобы эти проекты запилить и потом поддерживать, но что делать, выбора не было. Сейчас есть go, rust, часть из этих задач они вполне могут взять на себя. По удобству не java/C# конечно, но уже гораздо лучше чем С/С++.

Предлагаю обсудить вот эту цитату:

I like a lot of the design decisions they made in the [Go] language. Basically, I like all of them.” — Martin Odersky, creator of Scala.

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

Я думал, что Scala и Go находятся на одном уровне — там, где Java и C#. Или вы думаете, что CTO, написавший блогпост о переводе его команды со Scala на Go, сошел с ума и решил сделать даунгрейд? Исходя из вашей логики, следующий пост от этого CTO будет о переходе с Go на asm :)

1. вполне вероятно что скала не подходила под все нужды компании и где-то была избыточна, вне зависимости от того на что он перешел.
2. Go подходит под их технические требования и справляется лучше чем скала, за что они готовы мериться с какими-то недостатками.
3. Они перевели на Go только часть сервисов там где Go хорош, там где лучше справляется скала оставили скалу.
4. Наверное в большинстве, если не во всех, книгах по микросервисам написано, что один из главных бенифитов это то что каждый сервис можно писать на наиболее подходящем языке.
5. И если будет место где максимально эффективно решить задачу можно будет разве что с асм, и выхлоп оправдает затраты на разработку и саппорт решения, то почему бы и нет?

Ну блин, о каком уровне ты говоришь? Джава, С# и особенно скала созданы для решения проблем на гораздо высшем уровне, и к этим задачам go очень далеко. Другое дело что эти языки использовались так же и для более простых задач, так как альтернатив особо не было, и вот эти задачи теперь можно покрыть на go.

Ну блин, о каком уровне ты говоришь? Джава, С# и особенно скала созданы для решения проблем на гораздо высшем уровне, и к этим задачам go очень далеко. Другое дело что эти языки использовались так же и для более простых задач

Было бы неплохо увидеть примеры задач «на гораздо высшем уровне» и «более простые задачи» в вашем понимании. Желательно, чтобы примеры были не сферическими конями в вакууме, а с линками на настоящие проекты.

Да любые задачи с бизнес логикой, с обработкой данных. То что в нормальных языках делается одной строчкой, в go без котстылей не обойтись. А все из-за того, что какой-то самовлюбленный фрик решил выкинуть нафиг дженерики, которые уже лет 10 как являются стандартом. Ну какие адекватные аналоги в go к этим конструкциям которые в типичном scala/C# проектах на каждом шагу?

var count = students != null ? students.Length : 0;
var rate = rates.First(r => r.From == "USD");
var rate = tickets.SortBy(t => t.Price);

Короче, хорошая задумка с go, хреновая реализация из-за маразматика Пайка.

Можна запитати чому Ви все на Командора списуєте? Там ж в них політика одностайності, тому інші члени команди не менше причепні. Це раз. А по-друге, серед них є особи, як мінімум, не менш відомі та видатні ніж він.

Тому що це світоч для гошників, який просто не може бути неправий, і якщо він щось робить не так, значить так має бути

І да, го таки дитя Пайка. Не спорю що багато людей приймали участь в його створені, но головний ідеолог все-таки Пайк.

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

Ну и Го ориентирован на программистов «нижнего квартиля классификации», и для этой задачи он успешен. Вопрос в том, действительно ли это нужно программированию как индустрии. Я искренне надеюсь, что нет.

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

Ну и Го ориентирован на программистов «нижнего квартиля классификации»

Go ориентирован на программистов из Google. Если они принадлежат к 25% худших программистов, то где работают остальные 75% «лучших проораммистов»?

Квалификация бывает в разных областях, и здесь я имел в виду сугубо «квалификацию software engineering». Те человек может отлично знать нюансы работы ядра линукса или тонкости тюнинга SVM, но это слабо коррелирует с его способностью писать человекочитаемый и поддерживаемый код (очевидно, в разных ситуациях приоритеты навыков разные).

Уточню цитату, Го ориентирован на «молодых выпусников, с небольшим опытом работы». Те это очередная попытка сделать язык, в котором у вышеописанного программиста шанс написать хороший код будет выше среднего. Замысел отличный (та же Джава с чем-то похожим стартовала), и в своей нише Го хорош. Вот только эта ниша крайне узкая и специфичная, и за ее пределами Го как язык оставляет желать лучшего.

Го ориентирован на «молодых выпусников, с небольшим опытом работы».
...
ниша крайне узкая и специфичная
Прицел на эту нишу может выстрелить и в других. Скажем наблюдаетсяя некоторое оживление вокруг Го в инфраструктурных и около-девопских кругах, где у контингента часто разнородный уровень именно программирования-программирования и Го находится в неплохой sweet spot.

Вот для «инфраструктуры» Го крут, не буду спорить. Я, например, следующий «скрипт», когда в нем возникнет надобность, сделаю на Го, эксперимента для (до этого в основном Пайтон с Башем использовал). Для разных задач — разные инструменты, писать скрипты в 20-100 строчек на Скале глупо.

писать скрипты в 20-100 строчек на Скале глупо.

Кстати почему ? на 100 строчек скалы можно уложыть логики в несколько сотен строк слабочитаемого баша. Особенно если юзать аминит опс lihaoyi.github.io/Ammonite

Если скрипт будет запускаться один раз, то можно. А вот ждать прогрева Скалы несколько секунд (каждый раз) надоедает.

Можно, конечно, сделать какой-то висящий в памяти процесс, которому будет кормиться текст скриптов (например, через scala.reflect-овский ToolBox, он работает шустрее всего, что я пробовал), но это извращение. Придется думать про ограничения по памяти, сборку мусора, не будет ли глюков в выбранном велосипеде, и так далее.

В итоге, проще взять Пайтон для чего посложнее и Баш для несколькострочников.

Тут вопрос не в логике, а в настройке окружения. Запутанная структура попок (хотя может это из-за intellij), непонятно что куда складывается, что куда грузиться, на выходе куча джарников, зависимость от jvm. Это кстати главный недостаток по сравнению с тем же go где все просто и прозрачно. Для больших проектов это фигня, но для маленьких — лишний оверхед который хотелось бы избежать.

Установить джаву, а потом по инструкции выполнить

$ mkdir ~/.ammonite; curl -L -o ~/.ammonite/predef.scala git.io/v0FGW

$ curl -L -o amm git.io/v0FGO chmod +x amm; ./amm

Это бесспорно огромный и тяжелый кусок работый невыполнимый для большинства гоферов и пыхеров.

Всего то навсего ).

С другой стороны можно просто создать одни файлик с расширением .go или .py и тупо напедалить туда код. Не надо уподобаться гошникам и возводить все в абсолют. Каждой задаче свои инструменты.

С другой стороны можно просто создать одни файлик с расширением .go или .py и тупо напедалить туда код.

Ну, если питон еще во многих системах по умолчанию присуцтвует, то го, как минимум еще установить нужно, так что не все прям так гладко :-)
Каждой задаче свои инструменты.
Тут я не спорю, однако считаю что разширять кругозор и спектр возможностей — неплохо.
Для начала — вообще непонятно что делает компилируемый статический го в списке скриптовых инструментов. Всегда было
взять Пайтон для чего посложнее и Баш для несколькострочников.
Ну, если питон еще во многих системах по умолчанию присуцтвует, то го, как минимум еще установить нужно, так что не все прям так гладко :-)

Я даже больше скажу, в go еще дополнительно нужно окружение настроить, один раз для всех проектов. Настраивается быстро, за 5 минут, но все-равно, пол дня потратил чтобы разобраться что к чему и в чем логика этого всего. После — все становиться понятно и прозрачно.

Для начала — вообще непонятно что делает компилируемый статический го в списке скриптовых инструментов.

Статическая или динамическая типизация, скриптовый или нескриптовый язык, это все дело второе. Главное чтобы инструмент позволял решать определенные задачи c наименьшими телодвижениями. А go, несмотря на свою топорность и примитивность как языка, имеет довольно мощную библиотеку которая из коробки позволяет делать много чего без шариния в Интернете.

Ну, если питон еще во многих системах по умолчанию присуцтвует, то го, как минимум еще установить нужно

Для запуска программ на Go не нужен ни компилятор, ни стандартное окружение Go, ни внешние зависимости. Т.к. скомпилированная программа на гоу представляет из себя один самодостаточный бинарник, которому пофиг на внешние зависимости.

Т.к. скомпилированная программа на гоу представляет из себя один самодостаточный бинарник, которому пофиг на внешние зависимости.
тобиш один бинарник с «пофиг на внешние зависимости» можна и на винде и на юниксах вот так вот запускать? круто, че.

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

Кстати, настроек компиляции что-то не увидел. Есть ли поддержка SSE для x64, или AVX. Скорее всего регистры SSE не юзаются никак. Делаются ли компилятором типичные оптимизации, или самому внимательно смотреть что пишешь в циклах.

Кстати, настроек компиляции что-то не увидел.

Потому что там только две настройки — переменные окружения GOOS (целевая операционная система — linux, windows, darwin, etc.) и GOARCH (целевая архитектура — 386, amd64, arm, etc.) — см. dave.cheney.net/...s-compilation-with-go-1-5 и golang.org/...nstall/source#environment .

Есть ли поддержка SSE для x64, или AVX.

Есть — см. например, github.com/...301badf1b762888e2c69e6c57 , github.com/...5235e838839c7847da7723378 , github.com/...b11f21ea462856aeb1f6ec0c0 , github.com/...8f07c82508f0fa88e6dd69ea7 .

Делаются ли компилятором типичные оптимизации, или самому внимательно смотреть что пишешь в циклах.

Делаются. См. неполный список тут — github.com/...iki/CompilerOptimizations . В версии 1.7 будет новый компилятор на основе SSA ( en.wikipedia.org/...ic_single_assignment_form ), на котором будет много новых оптимизаций — см. github.com/golang/go/tree/dev.ssa .

Жависты смотрят на пыхеров свысока — вместо принятого у пыхеров curl | sh они делают curl | java, и вместо скриптиков по трубе идёт 30MB сжатого энтерпрайзного байткода.

doublefacepalm.jpg

Остановите эту планету плиз, я сойду.

Ну, во первых, не джавы а скалы.
Во вторых 30 мб сейчас не критично.
В третих — если скрипты большие и мудреные, избавляться от шела имеет очень большой смысл.

dou.ua/lenta/articles/language-rating-jan-2016/
Статистика вот показывает, что у нас Go юзают люди с опытом, а язык при этом молодой. Видимо, глядя на другие языки, возможность избавиться от лишних абстракций выглядит привлекательно, и писать простой рабочий код.

Это кстати странно, так как после общения с местными гоферами складывается впечатление, что ничего кроме go они в глаза не видели, максимум питон/жаваскрипт/пхп.

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

Кстати есть такое ощущения, но такой же простой понятный код можно писать практически на любом языке, было бы только желание. У го преимущество что стандартная библиотека молода, которая писалась на основании существующего опыта под современные задачи. Поэтому она мощна, и в то же время не имеет ничего лишнего. У .net/java много оверхеда, который накапливался 10+ лет и который излишен или ненужен в большинстве современных задачах. Но и там активно все переписывается и упрощается, что позволяет писать легкий (по крайней мере снаружи), минималистический код.

Тоже обратил внимание на эту диаграмму. Думаю, что речь идет не об основном языке использования (иначе что там делают Паскаль с Бейсиком?). Но, в любом случае, это показатель, что Го метит в нишу «любимый рабочий язык менеджеров» (в хорошем смысле этого слова), ведь последние ориентируются на «что попроще», ввиду потенциальной ограниченности «кадров». Один из моих знакомых ругался на разные виды стрелок => -> (не считая кастомных) в Скале. Думаю, Го ему бы понравился больше.

Резюмируя, с тз программистов Го весьма уныл, а с точки зрения ПМов _может_оказаться_ предпочтительным. Осталось дождаться крупных проектов на Го. Лично я не верю, что одним взмахом руки Пайк уберет всю ту сложность, с которой борятся «лишние абстракции и накрученный ООП». Они часто overused, но и без них никуда.

Есть такие вещи как check style и т.п. которые всегда могут сделать форматирование и стилистику однообразной, ограничить язык просто, есть куча статик код анализаторов и т.п. которые можно встроить в билд, а вот расширить — нет.

Осталось дождаться крупных проектов на Го.

Уже дождались — Docker, Kubernetes, Cloudflare, etcd, CoreOS и т.д.

Докер, который на баше уместили в 100 строчек кода?
github.com/...bocker/blob/master/bocker

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

(кстати, почему в каждом проекте своя директория для зависимостей?)
(корреляция между количеством строчек кода и «размером» проекта, очевидно, сильная)

find . ! -path ’*/Godeps/*’ ! -path ’*/vendor/*’ ! -path ’*/third_party/*’ -name ’*.go’ | xargs wc -l

docker: 146877
kubernetes: 568527 (386469 с exclude ’*generated*’)
etcd: 82274

Я бы не назвал эти проекты уж очень крупными. У Kubernetes подозрительно большой отрыв, может, я забыл заэксклюдить чего? Ну и не стоит забывать, что Го не самый выразительный язык, что также сказывается на количестве строчек кода.

именно основном. С другой стороны — возможно это просто отражение того, что в малых группах больше аномалий

Гугл набирает академщиков, которые бы алгоритмы знали и олимпиадные задачки решали. То что у них хорошо и быстро мозги работают, совсем не означает что они хорошие, прикладные программисты, решающие реальные проблемы. Это одна из причин, почему у гугла не так уж и много успешных продуктов доведенных до ума. Большая часть либо подыхает на разных стадиях, либо страшные и неюзабельные. Приходят такие модные хипстеры, наговнокодят на го что-то, что как бы работает, но что с ним дальше делать и как этот говнокод разгребать не знают, поэтому сбегают на другой проект и так по кругу. Такой себе антипод эпла — тот из говна конфетку может сделать и продать, гугл же из конфетки делает говно, но все-равно часто умудряеться продавать из-за отличного пиара.

смиявсь

много, глубоко за гугл знаете, я смотрю — позвольте поинтересоваться откуда?

На гоу можно писать код под браузеры — github.com/gopherjs/gopherjs . Так что скоро он заменит не только node.js, но и 100500 over-complicated js-фреймворков под браузеры.

p.s. Насколько я понимаю, на скале такого нет.


p.s. Насколько я понимаю, на скале такого нет.
www.scala-js.org ?

просто гоферов в гуле банят
ЗЫ хуже чем писать js на каком-то другом языке наверное еще ничего не придумали.

ЗЫ хуже чем писать js на каком-то другом языке наверное еще ничего не придумали.

Утверждение спорное, но таки почемуто все эти языки невзлетают.

тайпскрипт взлетел, jsx взлетел для реакта

Беру свои слова обратно :)
Зато на хабре нет статей про скалу, криптовалюту и Катю, а про гоу, криптовалюту и Катю есть:

— habrahabr.ru/...ompany/dcoin/blog/272695
— habrahabr.ru/post/273333
— habrahabr.ru/post/274885

Это там, где народ просит убрать го нафиг и писать только про Катю? )

Это там, где пхп-программист успешно перешел на гоу.

что как раз многое объясняет

www.scala-js.org

Вообще говоря, в джс сейчас разве что брейнфак не перегоняют, и то не факт.
github.com/...guages-that-compile-to-JS

Если повторить ходя бы успех ГВТ, то тогда сможете говорить об успехе этого проекта, а пока вызывает только улыбку

чем как GWT лучше сразу в топку без мучений

ну гвт использовали в продакшене. кофискрипт тоже.
А вот используют ли го, или туже скалу для компиляции в джс — вопрос.

Некоторые в теорию могут, но лично не видел и не слышал

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

Ну на фоне го -не самая худшая альтернатива:)

т.е. вы хотите сказать, что гоу — это фортран и кобол будущего?

нет, го _такой_ популярности не наберет никогда
надоест гуглю с ним возиться — и фсе, на свалку истории
фортан и кобол живи и сейчас, из-за _огромного_ количества легаси кода, тянущегося из 60-70-80-х
и то только потому что другие языки в те времена плохо подходили для решения финансовых и расчетных задач, а эти были заточены под ряд специфических областей и решали задачи на то время отлично
го на мой взгляд не имеет никаких конкурентных преимуществ кроме агрессивного маркетинга от гугля, в остальном — ниже среднего

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

На гоу можно писать код под браузеры — github.com/gopherjs/gopherjs . Так что скоро он заменит не только node.js, но и 100500 over-complicated js-фреймворков под браузеры.
не заменит)
ибо:
1. это просто компилятор кода Go в джаваскрипт. А подобных языков и компиляторов уже есть воз и маленькая тележка, начиная с CoffeeScript и TypeScript, и заканчивая разными Dart’ами и
диалектами лиспа, написанными на джаваскрипте (типа такого lispyscript.com ).
2. Я знаю минимум 5 языков, для которых написаны диалекты, транслирующие код в джаваскрипт: Clojure (Clojurescript), Haskell (Fay, Haste, GHCJS), F# (Funscript), Scala.js (см. ниже), Standard ML (SMLtoJs — www.smlserver.org/smltojs ).
3. адепты ноды, реакта, ангуляра и метеора не дадут, чтобы их убили)))
p.s. Насколько я понимаю, на скале такого нет.
У скалы есть аналогичная хрень — Scala.js ( www.scala-js.org ).
Так что скалисты тоже могут запявить, что скала скоро убьет ноду и джаваскрипт))))

А я б еще добавил, что наличие такого зоопарка компилирующихся в Javascript языков, прямо говорит о говёности чистого Javascript, особенно при написании более-менее крупных приложений, в чем лично убедился на практике. Для небольших скриптов — пойдет, для остального — Welcome to hell!
Вот ClojureScript одобряю, пишешь и прям душа поет!

уже 1000 комментариев — неплохо пофлудили

В 4 раза больше чем на хабре, Ищенко должен быть довольным

Вот ради интереса пытаюсь написать маленький скальный проект на го.

Функция на скале:

def getExchangeRates(currencyPairs: Seq[CurrencyPair]): FutureActionResult[String, YahooResponse] = {
    val pairs = currencyPairs.map(p => s"\"${p.from}${p.to}\"").mkString(", ")
    val query = s"select * from yahoo.finance.xchange where pair in ($pairs)"
    val url = s"http://query.yahooapis.com/v1/public/yql?q=$query...blahblah"

    for {
      response <- Http().singleRequest(HttpRequest(GET, url))
      json <- Unmarshal(response.entity).to[String]
      yahooResponse = json.decodeEither[YahooResponse]
    } yield yahooResponse
  }

Та же функция на го:

func GetExchangeRates(currencyPairs []CurrencyPair) (*YahooResponse, error) {
	pairsAsStrings := make([]string, len(currencyPairs))
	for i, pair := range currencyPairs {
		pairsAsStrings[i] = fmt.Sprintf("\"%s%s\"", pair.From, pair.To)
	}

	pairs := strings.Join(pairsAsStrings, ", ")
	query := url.QueryEscape(fmt.Sprintf("select * from yahoo.finance.xchange where pair in (%s)", pairs))

	u := fmt.Sprintf("http://query.yahooapis.com/v1/public/yql?q=%s...blahblah", query)
	response, err := http.Get(u)
	if (err != nil) {
		return nil, err
	}

	defer response.Body.Close()

	var res YahooResponse

	decoder := json.NewDecoder(response.Body)
	err = decoder.Decode(&res)
	if (err != nil) {
		return nil, err
	}

	return &res, nil
}

Знатоки go, что можно сделать с функцией, чтобы она выглядела менее печально и велосипедисто? Или хотя бы предложите как правильно отформатировать чтобы читалась легче. Спрашиваю абсолютно без издевок, просто не знаю всех тонкостей языка и гайдлайнов.

def getExchangeRates(currencyPairs: Seq[CurrencyPair]): FutureActionResult[String, YahooResponse] = {
val pairs = currencyPairs.map(p => s"\"${p.from}${p.to}\"").mkString(", ")
val query = s"select * from yahoo.finance.xchange where pair in ($pairs)"
val url = s"query.yahooapis.com/...c/yql?q=$query...blahblah"

for {
response <- Http().singleRequest(HttpRequest(GET, url))
json <- Unmarshal(response.entity).to[String]
yahooResponse = json.decodeEither[YahooResponse]
} yield yahooResponse
}

можна вообще весь реквест в фючу запихнуть, чтобы операция на мапаньи пеиров не блокировалась, и не броса