×Закрыть

Про ниасиливших 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 — Why should you learn Go?

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

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

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

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

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

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 .

Ну подсветка и автодополнение — это конечно удобно, но ещё лучше было бы увидеть дебаггер, где можно устанавливать 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++. Разве только точек останова и трассировки нет.

<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 уделал скалу по всем позициям согласно исследованию от 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
}

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

def buildCurrencyQuery(currencyPairs: Seq[CurrencyPair]):Future[String] = Future {
    val pairs = currencyPairs.map(p => s"\"${p.from}${p.to}\"").mkString(", ")
    val query = s"select * from yahoo.finance.xchange where pair in ($pairs)"
    s"http://query.yahooapis.com/v1/public/yql?q=$query...blahblah"
}

def getExchangeRates(currencyPairs: Seq[CurrencyPair]): FutureActionResult[String, YahooResponse] = for {
     url <- buildCurrencyQuery(currencyPairs)
     response <- Http().singleRequest(HttpRequest(GET, url))
     json <- Unmarshal(response.entity).to[String]
     yahooResponse = json.decodeEither[YahooResponse]
    } yield yahooResponse

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

Тогда уж лучше так:

def getExchangeRates(currencyPairs: Seq[CurrencyPair]): FutureActionResult[String, YahooResponse] = for {
	response <- {
		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"

		Http().singleRequest(HttpRequest(GET, url))
	}
	json <- Unmarshal(response.entity).to[String]
	yahooResponse = json.decodeEither[YahooResponse]
} yield yahooResponse  
Разве что для эстетики — оверхед на создание Future будет больше, чем тот меппинг.
Да, я забыл что стандартный скаловский Future это, не ленивый scalaz Task. У нас все кому не лень уходят от использования фючэ и переходят на использование тасков. А некторые потом отправляються в свободное космическое плавание используя scalaz-streaming. Гранды говорят что этот фреимворк крут как яйца сталоне, и вообще. Мне самому пока толком покурить не удалось.
Можно еще так:

Этот вариант ничем от вашего первого не отличается. Читаемость субьективно несколько хуже. А вот юнитТестируемость лучче в варианте с двумя функциями, причем не важно под фьюче оно или нет.

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

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

хотелось бы услышать клоуна который рассказывал про код на Go в 10 раз короче Scala

код на go в 10 разів коротше всього, не тільки скала. при чому, код на скала в 2 рази коротше коду на джава, але код на go рівно в 10 разів коротше коду на скала і коду на джава. от такий він, суровий go.

але з позитиву — нарешті знайдено ту єдину, правильну і аху*нну мову програмування, якій всі інші мови тихо заздрять. 5 років тому це був пітон, зараз всі вже нагамнокодились пітоном по самі нехочу, і тепер всіх врятує go

Ну ніша пітона нікуди не ділася, просто її починає окуповувати go, відбираючище ще й ніши всякого трешака тіпа nodejs.

go насправді не такий же і поганий, топорний правда місцями, але простий і прямий як пробка, при цьому доволі потужний. Такий собі американський muscle car серед машин.

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

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

Що не кажи, але плюси go очевидні — можливість писати швидкі, легкі, компільовані, програми, а вчити C, C++, haskel влом.

Ну, якщо появиться щось нове яке усуне проблеми і недоліки go — чому б і ні? Прогресс — це завжди добре ).

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

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

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

Все на что-то похоже, и все — уникально.

ИМХО Паскаль-Дельфи от нас ушел потому что:
Был упущен момент пришествия веб. PHP + Adobe Flash(Flex) в массовом вебе и Java в корпоративном оказались более адекватным средствами. А потом и Ruby сделал Рельсами контрольный выстрел в голову.
Паскаль-Дельфи так и не смог победить предложение для разработки GUI приложений от MS. а выход .NET окончательно лишил Паскаль-Дельфи преимуществ. Расширение же до ASP.NET добило бы его и без указанных выше успешных «веб яп»

т.е. Даже если бы Go был копией языка программирования Паскаль — у него будет другой путь. Его рантайм уже сразу реализован по другому.

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

Был упущен момент пришествия веб
Ну у уеба своя ниша. А , например, в научной тематике так и рулят плюсы, Фортраны, даже тот же Пасхаль у седобородых, ну и из новых Эр, Пытон и таже Скала... Про Гов наверно и не слышали...

тотже спарк, кроме скалы имеет биндинги только на Рэ, питон и джаву, и все.
Это говорит о многом :-)

да, не хватает интерфейса на PHP.

Я вот более-менее матерый джавист, но если бы начинал новый стартап, то писал бы на го. Потому что вместо одного джава синора за $4000, я смог бы нанять целую команду джунов и обучив их писать более-менее сносный код по SOLID и по TDD и затем вполне себе продуктивно релизить фичи.
Для меня самый большой плюс — простота, это дает несравненные экономические преимущества перед другими экосистемами.

так в этом и прелесть Го — на нем разработка дешевле

дешевле — измеряемый критерий.
а что такое — «лучше»?

это таже цена в будущем.
дешевле сразу != дешевле потом.

То есть будущее уже можно посчитать.
Не знал.

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

Вам как специалисту должен быть знаком термин «технический долг» ?

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

Вообще, это прикольно, почему умники что-то мне дауну отвечают...

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

На ~90% (на взгляд) это так. Но остаются интересные 10%, когда можно и нужно пытаться предсказывать и идти вперёд. Собственно, в умении это предсказать и проявляется опыт. Я пытаюсь периодически пересматривать свои старые решения или просто высказанные пожелания на тему, состоялось такое изменение или нет, иногда очень интересные вещи находятся...

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

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

Но остаются интересные 10%, когда можно и нужно пытаться предсказывать и идти вперёд
для этого нужно быть визионером типа Джобса. и бросать программирование.
частный случай такого подхода кода мной обсуждался на примере reset($arr) в двух темах

Мнэээ... я практически не разбираюсь в PHP и не могу оценить дискуссию. Насколько я понял по результатам гугления и чтения, шла речь о том, что «массив» в PHP это или сущность из последовательно нумеруемых элементов, или мапа произвольных ключей, форсировать только один из этих вариантов нельзя, реально массив может содержать оба типа ключей, и использование одного вместо другого даст кашу и неожиданные побочные эффекты. Я правильно понял? Если да, то я вообще не знаю, что тут можно и как предсказывать с таким диверсионным рантаймом, и чи не лучше будет вообще перейти на другой язык. Но при всём при этом я не понял, где тут вообще «предсказание» будущего.

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

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

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

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

то есть там диспут вышел о мышлении.

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

как ниже ответили — саппорт процедурного спагетти через 3-5 лет будет стоить оочень недешево:)
хотя возможно именно этого гоферы и добиваются
хотят стать в одну когорту со злыми коболерами:)

Понятно теперь почему саппорт систем на джава весьма дорог.

Ещё будет интересно посмотреть во сколько обойдётся саппорт фронтендного новья в виде ангуляров.
По той сложности которую уже ваяют...

Процедурный же стиль плох не из-за спагетти.

Ещё будет интересно посмотреть во сколько обойдётся саппорт фронтендного новья в виде ангуляров.
По той сложности которую уже ваяют...
Вот тут соглашусь на все 100500%
Процедурный же стиль плох не из-за спагетти.
Это одна из причин, но не главная. Главная в том, что этот подход устарел на 30 лет
Главная в том, что этот подход устарел на 30 лет
технологии не физические сущности чтобы стареть.
«устаревание» технологии это следствие ее свойств, и появления, развития технологий, которые предлагают что получше.

т.е. «подход устарел» — ничего не поясняет. подход может и помолодеть.

Не вижу предпосылок для «помолодения» процедурного подхода

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

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

Что можно вежливо ответить на пост с классическим демагогическим ходом и аналогией в качестве аргумента?

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

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

Тыщи строк процедурного кода от кучи джунов это ад похлеще «абстракных адаптеров фабрик синглтонов» написанных джава синиором.
В том то и дело, что пока джава джун будет изучать спринг, джуниора гофера можно натаскивать писать читаемый код с интерфейсами (low coupling), тестами и более-менее сносным дизайном. Тем более, что есть код ревью.

Только система на Java выдержит миллионы запросов пользователей и не «ляжет». А то что написано «побыстрее» — не факт.

Если у стартапа есть миллион пользователей, то и пара десятков лямов инвестиций тоже. А значит проблема с количеством запросов не критичная. Кроме того, golang отлично скейлиться.

Разве в джава мире нет более легких альтернатив для простых задач? Или там принято спринг везде пихать? Просто в том же .net веб сервис для микросервиса можно в три строчки поднять и никаких особых знаний не нужно.

В Джава-мире принято на спринге делать абсолютно все — даже в простейшей консольной тулзе обязательно должен быть спринг во весь рост.

(И это, сука, бесит!...)

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

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

Фишка в том что сейчас джун без спринга нафиг не кому не нужен.

Если нечто большое
так это как проектировать.
большое — не означает монолитное.
Тыщи строк процедурного кода от кучи
я тут в очередной раз присматриваюсь к GroupWare софту, почитал про Liferay, не следил лет 5.
300 мб джарников, позакрученные API, и т.д. и т.п.
джуны писали? или все же это результат монолитного приложения на «абстракных адаптерах фабрик синглтонов»?
так это как проектировать.
большое — не означает монолитное.

Если не монолитное, то либо модульное, либо (микро)сервисное.
Все эти подходы имеют pros & cons, и при неблагоприятных обстоятельствах превращают работу в ад.
я тут в очередной раз присматриваюсь к GroupWare софту, почитал про Liferay, не следил лет 5.
300 мб джарников, позакрученные API, и т.д. и т.п.
джуны писали? или все же это результат монолитного приложения на «абстракных адаптерах фабрик синглтонов»?
Вас, как всегда тяжело понять. Вам не нравиться джарники и позакрученные API ?
Предложите ваш вариант, так чтобы функционально, гибко и секьюрно.
функционально, гибко и секьюрно.
если нечто сложно, дорого изменить — то это уже не гибко.
Предложите ваш вариант,
в ИТ постоянно что-то предлагается. что-то оказывается просто мечтами, что-то навозом для другого предложения.
Вам не нравиться джарники и позакрученные API ?
джарники такое дело. а вот чтобы кому-то нравились позакрученные API — как-то не слышал.
новичкам может быть. а так, обычная жалоба самих джавистов на монстров разростающихся годами.
и мой посыл был в том что монстров этих творят вовсе не джуны, и не тыщами строк процедурного кода.
если нечто сложно, дорого изменить — то это уже не гибко.
Проблема растет из за меняющихся требований.
Можна для примера смотреть какойнить опенГЛ.
Умные дяди несколько лет посидели, придумали требвания, и выкатили довольно хороший (как для процедурного) апи. И посмотрите во что этот апи превратился за годы добавления всяких фичь, шейдеров и прочего.
позакрученные API — как-то не слышал.
новичкам может быть. а так, обычная жалоба самих джавистов на монстров разростающихся годами.
и мой посыл был в том что монстров этих творят вовсе не джуны, и не тыщами строк процедурного кода.
Ну давайте возьмем пример из процедурного мира, старый добрый выньАпи32. Комуто когдато нравилось с ним работать ?

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

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

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

Ответьте, пожалуйста, на следующие вопросы:
1. В каком стиле написано ядро линукс? Подсказка — github.com/torvalds/linux
2. В каком стиле написано ядро виндовс? Подсказка — technet.microsoft.com/...ysinternals/bb963901.aspx
3. В каком стиле написано ядро макоси? Подсказка — *BSD.
4. Линукс, виндовс и макось — это большие (монолитные) проекты?
5. Почему мы до сих пор не видим операционных систем, написанных на новых языках программирования (джава, сишарп, скала, джаваскрипт, С++ и свифт) с «родной» поддержкой ООП и других крутых парадигм типа функциональности и метапрограммирования?

5. Почему мы до сих пор не видим операционных систем, написанных на новых языках программирования (джава, сишарп, скала, джаваскрипт, С++ и свифт) с «родной» поддержкой ООП и других крутых парадигм типа функциональности и метапрограммирования?

потому что, винда и линукс были написанны во времена когда ничего кроме си небыло? А изобретать велосипеды долго и дорого ? Впрочем велосипеды есть но они без инфраструктуры, прикладных программ и драйверов никому не нужны, например таже en.wikipedia.org/...larity_(operating_system .

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

В каком стиле написано ядро линукс?

В объектном. Да, на C, а не C++. Код вида


 if (file->f_op->read)
  return file->f_op->read(file, buf, count, pos);
является вызовом виртуальной функции объекта по указателю. И так там практически во всём.
В каком стиле написано ядро макоси? Подсказка — *BSD.
Подсказка неверна и попросту некомпетентна, для «ядра макоси» микроядерность и обмен сообщениями существеннее вопроса процедурность/объектность.
Почему мы до сих пор не видим операционных систем, написанных на новых языках программирования
Потому что не умеете даже элементарно гуглить. BeOS была целиком на C++ и не выжила не потому, что на нём написана, а потому, что все ниши были заняты, а 1e11$$ на выдавливание конкурентов не нашлось.

Так что сплошное «мимо» по всем пунктам.

Почему мимо? Тут некоторые утверждали, что C и Go годятся только для процедурного кода, т.к. в них «нет поддержки ООП», т.е. нет наследования и полиморфизма «как в C++ или Java». Надеюсь, теперь они прозрели.
Насчет последнего пункта — основная причина, по которой BeOS не взлетела, — C++ слишком сложный по сравнению с C. Поэтому не нашлось достаточно профессиональных разработчиков для ее развития. Погуглите, что думает Линус Торвальдс о C++ и C++ разработчиках.

Погуглите, что думает Линус Торвальдс о C++ и C++ разработчиках.

Видел. Торвальдс слишком агрессивен. Но он прав в том, что ООП на C для специфики ядра обеспечить легче, чем на C++.

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

Нашлось бы, если бы были деньги.

Тыщи строк процедурного кода от кучи джунов это ад

Интересно, ООП-шников на курсах процедурным стилем запугивают, что ли?
«Плохого» или какой-то синоним. Просто «кода от кучи джунов», ok, все начинают с ошибок.

Тыщи строк процедурного кода от кучи джунов это ад похлеще «абстракных адаптеров фабрик синглтонов» написанных джава синиором.

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

Синьйоры синьйорами рознь.
Имел дело с очень эрудированными ребятами в цс. Но которые в работе на таску «зафигачить данные из базы в цсв файл», где у джуна это займет день работы и пару сотен строк джава кода, а у обычного синьйора чтобы сделать энтерпрайзнинько со спрингом, ДИ, гибкой моделью, мониторингом и юнит тестами — два дня. У данного индивида заняло больше двух недель времени, и в конце он выкатил 50+ (!!!) классов абстрактных фабрик адаптеров. Причем чел реально умный был, математек, все такое.

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

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

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

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

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

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

4 го джуна != 1 джава синьер

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

которые нужно поддерживать годами
стартап на ранней стадии
Не вписаться в рынок опаснее чем отрефакторить/переписать быдлокод :)

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

Чаще всего я лично вижу: «пилять, да кто за это деньги вообще платит и почему?!»

Off topic: а кто может подсказать литературу по Scala для начинающих? Кто как её учил?

Лично я начал с Хорстман К. — «Scala для нетерпеливых». Потом курс на www.coursera.org/course/progfun .

Вот хорошая серия статей, правда перед этим желательно ознакомиться с языком и ФП:
danielwestheide.com/scala/neophytes.html

Самое главное в изучении scala, это знакомство со scalaz отложить на по-дальше и по реже заглядывать в исходники библиотек ). Это сильно бьет по мотивации изучать дальше.

Самое главное в изучении scala, это знакомство со scalaz отложить на по-дальше и по реже заглядывать в исходники библиотек ). Это сильно бьет по мотивации изучать дальше.

Это как заглянуть в исходники boost’а или STL’а для C++ - см., например, реализацию vector — github.com/...include/bits/stl_vector.h :) Это говорит о сложности языка программирования. В гоу исходники библиотек читать намного проще — см. golang.org/src .

Рад за go, это реально преимущество и этого у него не отнять.

Вот только читать код мало, надо его понимать, видеть смысл, и тут уже больше от программиста зависит чем от языка. Взять к примеру первую попавшуюся функцию из одного популярного http сервера написанного неким Aliaksandr Valialkin )

func clientDoTimeout(req *Request, resp *Response, timeout time.Duration, c clientDoer) error {
	if timeout <= 0 {
		return ErrTimeout
	}

	deadline := time.Now().Add(timeout)
	for {
		err := clientDoTimeoutFreeConn(req, resp, timeout, c)
		if err != ErrNoFreeConns {
			return err
		}
		timeout = -time.Since(deadline)
		if timeout <= 0 {
			return ErrTimeout
		}
		sleepTime := (10 + time.Duration(rand.Intn(100))) * time.Millisecond
		if sleepTime > timeout {
			sleepTime = timeout
		}
		time.Sleep(sleepTime)
		timeout = -time.Since(deadline)
		if timeout <= 0 {
			return ErrTimeout
		}
	}
}

Ну и как тут читаемость go поможет мне разобраться в функции?

Какой sleep вообще на сервере, усыпить поток ОС чтоли? В Go, насколько помню, крутится количество потоков, пропорциональное числу ядер, что если попадутся столько же клиентов одновременно в этом коде?

Это go, там до потоков ОС тебя никто не пустит. У них есть свои потоки, их много, они легковесны, есть менеджер который сам распределяет их по потокам ОС, точнее по ядрам процессора. C этими гошными потоками можно делать все что захочешь — можешь слипать, можешь вешать ненужные операции, можешь вешать IO запросы, менеджер потоков все разрулит. С точки зрения программиста, ты тупо педалишь синхронный код, который потом скармливаешь гошным потокам в местах, где нужна ассинхронность. Короче go развращает программистов в работе с потоками так же, как сборщик мусора развращает в работе с памятью.

It’s ok, до тех пор когда тебе не нужна действительно хорошая оптимизация, для типичных энтерпрайзов сойдет.

К нас этот код обслуживает на одном компе до миллиона одновременно подключенных клиентов, генерирующих 100К запросов в секунду. На каждого клиента выделен отдельный поток. Подробности тут — github.com/...valyala/fasthttp/issues/4 .
Это хорошая оптимизация или энтерпрайз приложение?

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

Потрясающий результат, и это судя по всему на блокированных сокетах.
С точки зрения программы на Go сокеты блокирующие. На самом деле Go работает с неблокирующими сокетами. Но все эти epollы с event loop’ами и state machine’ами спрятаны в рантайме Go — программист работает с обычными блокирующими сокетами.
Если предположим достаточно большой канал связи, на чём предел возникнет — на загрузке проца, или на потреблении памяти?
Обычно программы на Go потребляют намного меньше памяти по сравнению с аналогичными программами на Java. Например, наша прога потребляет 10Гб памяти при обслуживании миллиона одновременных подключений. Так что узким местом, скорее всего, окажется CPU, который будет не в состоянии обработать слишком большое количество сетевых пакетов.
В Go нет такой темы как в JVM, что данные жрут лишнюю память? И что там с циклами сборки мусора?

Проблема с потреблением лишней памяти в Go встречается намного реже, чем в Java. При желании ее можно легко побороть с помощью встроенного в Go профилировщика памяти.
Сборник мусора в Go до недавнего времени мог тормозить при большом хипе, но начиная с версии 1.5 теперь все ОК. В 1.6 обещают, что максимальная задержка исполнения программы из-за GC не будет превышать 20мс на хипе в сто гигабайт.

Миллион работающих соединений — это действительно впечатляет, учитывая что 15 лет назад была так называемая проблема 10K. Я некоторое время назад написал сервер на IOCP-сокетах, работающий с несколькими десятками тысяч, правда на старом железе. Узким местом тоже была загрузка процессора. Производительность значительно проседала за счёт общения с БД, основные оптимизации касались именно этого...
Если GC будет очищать 100G мусора за 20 мс — это тоже что-то невероятное. Судя по всему, GC программистом не управляется, и механизм его работы в Go не совсем понятен. Может он очищает единоразово, или может по мере исполнения кода (какова агрессивность сборщика), настраивается ли объём кучи до вызова сборщика.

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

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

Я работу с БД сделал следующим образом: когда юзер авторизуется, читаются единоразово все его данные, в дальнейшем больше ничего не читается, а только периодически отправляются апдейты. Между запросом и ответом клиенту, общение с БД — тоже исключается.
Главное бутылочное горлышко — это если при горизонтальной интеграции серверов синхронизация идёт через БД, это уже относится к архитектуре в целом.

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

Если GC будет очищать 100G мусора за 20 мс — это тоже что-то невероятное
20мс — это максимальная задержка исполнения кода программы в связи с работой GC. Например, если среднее время обработки запроса к серверу на гоу составляет 1мс, то максимальное время запроса при 100Гб хипе будет равно 21мс. Это вовсе не означает, что гоу чистит весь хип за 20мс.
Судя по всему, GC программистом не управляется, и механизм его работы в Go не совсем понятен. Может он очищает единоразово, или может по мере исполнения кода (какова агрессивность сборщика), настраивается ли объём кучи до вызова сборщика.

В гоу есть только один параметр для настройки GC — максимальный объем мусора, выраженный как процент от объема полезных данных в хипе. По умолчанию он равен 100%. Например, при хипе в 1Гб максимальный объем мусора будет тоже 1Гб, а максимальный объем используемой памяти будет равен 2Гб. Подробности тут — blog.golang.org/go15gc .

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

Ещё интересно насчёт сервера: что делаете для проверки обрывов соединения, когда клиент отвалился, а FD_CLOSE не приходит? Пингуете, или так и висят? Запросы пинга посылает сервер на клиент, или клиент обязан сам периодически отправлять уведомления? И как часто?

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

Ну понятно. Значит, рассылки уведомлений сервером — нет в модели общения.

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

ну он наверно может хорошо пойти простые сервисы с котиками писать — если выбирать Node.js или Go-lang я бы Go выбрал 100%
а для ентерпрайза инфраструктуры нет — даже говорить пока не очем

у меня на JS код понятнее

А бекенд или фронтенд?
Недавно смотрел на ноду, был в шоке когда узнал что там имеет значение очередность объявления методов контроллера. Вообще сложилось мнения, что нода относительно крутая и реально шаг вперед для людей которые пишут например на php, но явно шаг назад по сранвению с ror или java+spring mvc или чем-то подобным(может в каких-то коренр кейсах и выиграет но в целом организация и разделение кода + общая читаемость явно хуже), хотя с другой стороны реально круто использовать тот же хендл бар как дефолтовый темплит энжин...

шо фронт, шо бек.

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

нода не особо конкурент джаве или си шарпу, но ее ниша далеко не всегда пхпешная.

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

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

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

www.amazon.com/...fRID=0NNKH6A0QTV9PM2PD0TX
Functional Programming in Scala by Paul Chiusano мне понравилась в MEAP

Это не для начинающих ;-)

ну я ж не знаю с каким бекграундом люди начинают — может как раз хорошо зайдет, весело задорно — это вам не унылый Одерски

думаю было бы клево, если бы кто-то написал книженцию а-ля learnyousomeerlang.com , только про скалу. Типа «Изучай Scala во имя добра».

а у меня эта книжка что то валяется без движения- не идет хоть ты тресни :|

Мне понравился курс www.udemy.com/...va-developers-ru/learn/ Он стоит 199 дол, но там часто акции бывают и его можно купить за 15 дол.

У нас в scala-дайджест #0 была подборка: с чего начинать обучение. dou.ua/...a/digests/scala-digest-0

А тем временем пришол неподтвержденный инсайд:

fwiw I talked to a (functional) Scala developer at Crowdstrike about that blog post, and they said that they hated the blog post, but it prompted them to finally resolve the go/scala tension that had long been present there, and that things are actually much better for the scala devs now.
Basically they came to a consensus on “we’ll use Scala for X and Go for Y and when we use Scala we can write idiomatic functional Scala instead of trying to write it to be familiar to Go devs”
at least that’s my understanding

Такчто, гомагедон отменяется.

Ничего себе инсайд! Про него в оригинальном блогпосте было написано:

Scala will not be leaving our stack completely. In fact it will complement where Go does not shine. Scala is a big part of our machine learning / analytics stack. It’s interop with java projects we use, and its ability to provide a nice DSL that our analysts can use still make Scala a solid choice.
Перевод для плохо владеющих английским :

Скалу оставим для всякого матана, где ей и место. А 95.7% продакшн кода будет на гоу.

Про него в оригинальном блогпосте было написано:

Было написанно так, быдто действительно

95.7% продакшн кода будет на гоу.
На практике же подругому выходит.

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

Scala — це ублюдочний Haskell

ну вот к сожалению у хаскеля такая репутация что бизнес от него шарахается как черт от ладана а scala можно протянуть как почти java LOL

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

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

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

у хаскеля такая репутация что бизнес от него шарахается как черт от ладана а scala можно протянуть как почти java
Значит пора в бизнес протянуть Frege github.com/Frege/frege =) ну чтобы он создал репутацию хаскелю как «почти java»)) может тогда бизнес хоть не будет так шарахаться от хаскеля))))

OMFG да, это прям хорошо зашли. Добавлю в список людей пугать
<quote>
[ (x,y,z) | x <- [1..10], y <- [x..10], z <- [x..10], x*x + y*y == z*z ]
</quote>
уже представил что могут написать мои далекие индийские коллеги при такой то мощще

Такое же есть, например, в python. И что не так с этим кодом?

Где вы такое видели в python?