×Закрыть

Про ниасиливших 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, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Как сделать бэкенд многопользовательской игры на Go — blog.u2i.com/...​owser-game-in-go-for-fun

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

Как использовать Go вместо MapReduce и Spark для обработки BigData — thinkfaster.co/...​ang-instead-of-mapreduce .


Memory Leaks

The toughest issue I faced was a nasty memory leak. After an hour or so of running, my Go program would eventually consume all of the 200-300 GB’s of RAM on my AWS machine. I didn’t even think it was possible for a program to use that much RAM.

....

I never got to the bottom of the issue. I ran out of time, and I had to „solve” it by changing the slice size to 5000 from 50,000 for that event type. This increased the recycling frequency and solved the issue.

Сборщик мусора ГО в действии. Дальше не читал.

I was also shocked to find that the Python implementation of Spark doesn’t support counters. I’m not sure how people run multi-day jobs without being able to see running values, error rates, etc.

После этого можно не читать.

Как использовать Go вместо

Далі не читав.

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

Любой надо осиливать

Да не, если писал на C++ то Java к примеру понять легко, а вот к примеру LISP нада будет осиливать

Ага, аж три часа осиливать.

года три я бы сказал.

С хорошим ментором я думаю можно за один управится.

Лисп три года осваивать? о_О

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

Хелло ворлд, да, займет часа 3, скачать кложу там, нагуглить туториал, отредактировать и запустить.

а если писал на ЛИСП то кложур тоже легко, а вот джава полная смена концепции

Про монадирующих программистов или как придумать проблему на ровном месте — m.habrahabr.ru/post/327030 . На go бы написали понятный код за пару минут не задумываясь и не привлекая матан с монадами.

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

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

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

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

Многие процессы можно упрощать до уровня понятного для «домохозяйки». Это как с паттернами, можно говорить много слов и описывать суть паттерна, а можно сказать название. В профессиональных кругах так удобнее и лаконичнее.
Как по мне вокруг функционального подхода в программировании слишком много мифов связанных с обязательностью глубокого понимания матана.
Взять теже монады. Это обертка над значением которая умеет принимать фунцию и вызывать ее для значения после чего снова возвращает обертку над значением. Что тут математического?
С другой стороны можно писать код на процедурном языке, там вообще все просто, линейно и понятно, но большое приложение написать и поддерживать сложно.

PS. А в статье автору захотелось поиграться в каноничного функционального программиста.
Я недавно в коде видел проверку существования файла перед чтением в функциональном стиле
... Option(new File(...)).filter(_.isFile).getOrElse(//throw exception)
Оно вроде как правильно с точки зрения ФП, но как по мне — это перебор и я так не пишу. В любом подходе есть крайности и нужно сохранять здравый рассудок.

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

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

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

+100500 насчет как с паттернами. Тут ток следующие но: 1. Концептов в фп гораздо больше чем паттернов. 2. Паттерны ООП нечеткие — описывают примерное взаимоотношения между обджектами их можно по разному комбинировать, и по разному реализовывать. Концепты в фп выведенны из математики; монада это не просто
обертка над значением которая умеет принимать фунцию и вызывать ее для значения после чего снова возвращает обертку над значением.
там есть четкие законы которые должны строго соблюдаться, иначе оно все боком вылезет. В результате все это таки нужно изучать и прикладывать мозг. Многие изучать и прикладывать мозг не любят, им проще ГоГо ивпродакшен.
... Option(new File(...)).filter(_.isFile).getOrElse(//throw exception)
Оно вроде как правильно с точки зрения ФП

Вообще ниразу не правильно :-)
В результате все это таки нужно изучать и прикладывать мозг. Многие изучать и прикладывать мозг не любят, им проще ГоГо ивпродакшен.
Эта проблема великолепно решается следующим образом: пишется просто код на Go, а потом прикладывается мозг для решения ребусов, кроссвордов и занимательных задач по математике.

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

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

Вот жеж троль :)

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

С уважением,
Кэп

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

У ФП траблы в первую очередь с исполнителями. Вернее с тем, что у них в головах. Умы пытливые, потому часто делают одно и тоже N разными способами :)

Встречал в описании README.txt примерно следующее. Мы потратили немного времени, чтобы написать пару десятков строчек на скала. Смотрите и разбирайтесь. Если умные, то поймёте а если глупы — то вам ничто не поможет.

Ну и ещё часто видел полное отсутствие тестов на clojure проектах. Работает в REPL — работает всегда :)

А я в clojure так и не приучил себя к лайв кодингу, мне тесты привычнее.

Работал в скала команде где тесты были более чем норма — мне понравилось

а какая связь между отношением к тестам и скалой? Даже на родном курсе по скале от Одерски куча тестов во всех заданиях.

В своих постах в этом топике я не сравнивал языки программирования. Писал о головах.

Тесты, кагбы не особо спасают.

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

И второе, если даже не первое — напрочь игнорить «мелочи» производительности. Выбрать O(N^2) вместо O(N) или добавить десяток аллокаций/оберток на элемент коллекции, увы, многими считается нормой. Или там родить запутанный иммутабельный код, где так и просится мутабельность (локальная).

Ну я скорее говорил про обычный нормальный код, а не о каком-нить radical point-free style, например :)

Я имею в виду так ок:

shifts = map (caesar . subtract ordA . ord) $ repeatKey

И так ок:

sumProducts x = sum . zipWith (*) x

И вот это ок:

chunksOf n =
        takeWhile (not . null) . map (take n) . iterate (drop n)

Так уже не очень ок

caesar :: Int -> String -> String
caesar i s = map (chr . (+ a) . (`mod` 26) . (+ i) . subtract a . ord) s
  where a = ord 'A'

А вот так уже плохо-плохо и это при том, что никакой математической магии, просто композиция функций:

curry $ uncurry (||) . (uncurry(==) &&& uncurry(((':':).) . isSuffixOf))

И как такое продебажить?

isDomainOf = ap (ap . ((||) .) . (==)) ((. B.append ".") . B.isSuffixOf)

Повторюсь, большинство так не делает, но да, запутать можно капитально.

Еще «сложность восприятия» зависит от языка. На некоторых языках код получается чище и проще, чем на других. Пример: degoes.net/…​articles/modern-fp-part-2
Там не о том, какой язык лучше, какой хуже, но имхо пример того, почему Скала нуждается в упрощении (не в том смысле, в котором это имеют в виду гоу-бои и гоу-герлы).

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

Усложнять просто. Даже, если учесть правила монад, то их вполне можно понять без глубоких знаний матана.
Я в основном работаю со Spark и для меня scalaz больше академический инструмент чем практический и яркое тому доказательство, что в самых успешных продуктах написанных на scala не используется scalaz. Я имею в виду продукты из бигдата мира — Spark, Kafka, Ignite. Подозреваю что в Akka и Play картина похожая.

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

Тут можно много вариантов придумывать, но изнутри бросать исключение — не фп вообще ни разу.
Это обертка
Не всегда. Тот же Reader или IO из хаскеля не обвертка.

Я не знаком с хаскель. Но почитав о Reader понял, что это обертка которая содержит функции.

Еще один топ Node.js дев перешел на сторону Go twitter.com/…​status/837130223770533889

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

Говорят, что умных AI ботов лучше писать на scala. Если он будет на go, то может случайно запостить статьи о переходе с go на scala.

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

Конечно есть. Вот и вот.

Их правда еще надо допилить, но в целом свою работу по продвижению Го выполняют.

~:{)

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

На популярном ресурсе про java рекламируют go -
www.javaworld.com/…​-googles-go-language.html

Там дипломатично, без лишнего троллинга намекают, что пора java-обезьянам переходить на Go. Нашим сектантам надо брать с них пример.

Martin Odersky наконец-то понял, что implicit conversions — зло: github.com/lampepfl/dotty/pull/2060 . Затем он поймет то же самое о наследовании, перегрузке операторов и других бесполезных фичах scala. В итоге scala превратится в Go :)

— сами же смеетесь с примитивности Go, так держать

Только забыли добавить еще ссылку dotty.epfl.ch
Где перечисляются нововедение, одно из главных:
— Union, intersection and literal singleton types

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

Второе предложение противоречит первому

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

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

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

В итоге scala превратится в Go :)
Не превратится, чтобы достичь уровня Go, скале надо ещё развиваться и развиваться.
В итоге scala превратится в Go :)
а я грешным делом было подумал, что Мартин Одерски после всего этого перестанет разрабатывать скалу и перейдет на Go)))

Да он бы перешёл, но ведь надо сначала как-то сообщество убедить в этом, а для скалистов это долгий эволюционный путь.

Да он бы перешёл, но ведь надо сначала как-то сообщество убедить в этом
походу это проблема не только скалистов)) вон еще есть любители всяких Nim’ов dou.ua/lenta/articles/nim (да и сам Nim судя по гитхабу активно пилится), Rust’ов dou.ua/forums/topic/12748 и прочих хаскелей)

Nim и прочие — не поддерживают ни Google, ни Microsoft, ни Apple, ни даже Adobe.

именно поэтому удивительно, почему те, кто пилят код на Nim и прочих, до сих пор не перешли на Go)

У них очень важная языковая миссия: доказать своим примером правильность выбора Go. Глядя на них, для всех выбор становится очевидным.

т.е. они таки куплены гуглом) xDD

Дык судя по этому топику, пачки же скалистов и так сами бугут и переходят, или автор топика врет ?

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

Гошники слидят за скалой больше, чем собственно сами скалисты. Это уже на уровне паранои с с шизофренией )

Просто оставлю это здесь
www.indeed.com/...nds/q-scala-q-Golang.html
redmonk.com/...0/language-rankings-6-16
stackoverflow.com/...echnology-top-paying-tech

Учитывайте что со скалой вы можете заниматься очень широким спектром задач, начиная от разработки фронтенда(scalajs) заканчивая bigdata data processing & mining.
Что кроме написания бекендов(серверов) и консольных утилит делают на го?

Выводы делайте сами.

Scalajs звучит так же смешно как и гвт

Не, gwt говно совсем другого порядка
со scala js можно жить

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

Да и в 2005 он уже был говно говном если нужно делать сложный UI
вообще как только в голову приходит идея писать код на java который потом няшно напрудит лапши из убогих компонентов на страницу- надо смело, с размаха бится головой о стол и больше такое не думать

код на java который потом няшно напрудит лапши из убогих компонентов на страницу
 Хз в 200(~8) это было 90% всех фреимворков.

не делает этот подход лучше ни на копейку (JSF этот еще , zalupa сотоны)

JSF
не надо здесь это упоминать.

лично знаю людей которым нравиться и они это выбрали базовой технологией в 2012 кажется
и EE7

JSF i Java EE 7 добровільно вибирати в 2012? це де такі психи живуть?

Java EE 7

Про ЕЕ 7 хз, но пописал на ЕЕ 6 какраз в 2012. Для своих целей норм технология, вполне конкурент была пресловутому «спринг+хебирнейт».
Но
JSF
... вспоминаеться www.youtube.com/watch?v=0B61_5sRoBI

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

Можно привести примеры кто это использует в проде? Есть ли полноценные фреймворки для написания SPA?

> www.indeed.com/...nds/q-scala-q-Golang.html

За 2016 год скала выросла в два раза, гошечка — в четыре

> redmonk.com/...0/language-rankings-6-16

Купленный рейтинг. Вот этот правильный — www.tiobe.com/tiobe-index . Скала на 29 месте, гошечка — на 14.

> stackoverflow.com/...echnology-top-paying-tech

Тут соглашусь — из-за хайпа вокруг скалы до 2010 года многие вляпались в нее, потом не смогли асилить, а теперь надеются найти супер-программиста на скале за бешеные бабки, который бы вытянул их проект из глубокой задницы. Наивные. Лучше бы перешли на go, сэкономили деньги и остались на рынке.

Что именно куплено в рейтинге redomnk где по осям количество проектов на гитхабе и количество тем на SO?
Опиши по каким параметрам считается индекс Tiobe, и почему в топ 20 в нем scratch, 2 бейсика, assembly, sql и matlab???
Из всех рейтингов этот имхо самый неадекватный.

Что именно куплено в рейтинге redomnk где по осям количество проектов на гитхабе и количество тем на SO?
По количеству проектов на гитхабе go давно обогнал scala — 57К go-репозиториев против 26К scala-репозиториев.

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

Учитывайте что со скалой вы можете заниматься очень широким спектром задач, начиная от разработки фронтенда(scalajs) заканчивая bigdata data processing & mining.
Что кроме написания бекендов(серверов) и консольных утилит делают на го?

Вы так говорите про bigdata, как будто кроме Scala его больше нигде нет. Например, через наши сервисы на Go сейчас проходит до 170 миллиардов событий в сутки. Все события сохраняются в базу для дальнейшего анализа. Это можно считать bigdata?

А вообще на Go много чего разрабатывается — см. github.com/...-go/blob/master/README.md .

Серьезно?
>> round(170E9/24/60/60)
ans = 1967593
2 мильёна в секунду? Что за база такое потянет?

2 мильёна в секунду? Что за база такое потянет?
Мы из постгреса выжимали 500к insert’ов в секунду на один 12-ядерный комп. При этом этот же комп занимался агрегацией, ротированием, а также обслуживанием select’ов по этим данным. Но постгрес был слабоват по двум направлениям:

— по скорости сканирования сырых данных удавалось выжать только 3 миллиона строк в секунду на один поток.

— по объему занимаемой памяти в persistent storage — каждая строка сырых данных занимала 200 байт.

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

Теперь каждая строчка сырых данных из более 40 значений занимает 10 байт
это как — по 2 бита на значение?

Вангую, що там 16 біт малося на увазі :)

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

От мені цікаво, як ви тисячні частки біта зберігати зібралися...

8 тысяч значений даты со временем по 0.001 бита сохраняются в один байт. Что тут непонятного?

Так один байт зберігається, а не 8К значень. Ні? І приведіть приклад зберігання :)

Так один байт зберігається, а не 8К значень. Ні? І приведіть приклад зберігання :)

Например, в следующей строке закодировано почти 450К значений даты со временем. Каждое значение занимает 0.001 бита:

’Тут хранится 448К значений времени "2017-05-15 12:21:42"’

Лол. Наверное если тебя попросят сделать суппер быструю программу на Го, ты им напишешь — 2+2=4
и прокомментируешь на презентации — я могу посчитать результат ста триллионов операций и у меня это займет меньше нано секунды времени на Go.
Жмет и считает как никто ранее.

Шото я не догоняю — це жарт такий? Як вичитати всі ці таймстампи з приведеного рядка?

Ви точно програміст? о_О

Точно. Зеленый такой. Любит паттерн «мост» :)

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

Не знаю, но лекции по теории информации, в отличие от некоторых, не прогуливал — ru.m.wikipedia.org/wiki/Теория_информации

Та мені здається, що ви таки прогуляли їх. Перше, зберегти значення в тисячних біта в сучасних комп’ютерах неможливо. Друге. Ваш приклад наводить тільки те, що ви виконуєте процедуру конвертації даних в інший формат із можливістю зворотнього процесу. Так само я можу стверджувати, що можу зберігати всю інформацію гугла в одному біті. Його буде достатньо для посилання на весь той масив.
Третє. Ви забуваєте про те, що окрім ваших стиснутих даних треба ще й зберігати декомпрессор ;)

Перше, зберегти значення в тисячних біта в сучасних комп’ютерах неможливо.

В битах тоже уже лет десять как не хранят и тем не менее это никому не мешает выражать информацию в битах. Или тысячных бита если так удобней.

Так само я можу стверджувати, що можу зберігати всю інформацію гугла в одному біті.

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

В битах тоже уже лет десять как не хранят
А в чому? О_о
Или тысячных бита если так удобней.
Це дурня та маячня. Я ще не бачив жодної платформи, яка б оперувала тисячними біта.
Каждое значение занимает 0.001 бита
Если ты не переопределил понятие бита- то я не понимаю о чем ты говоришь. Если ты имел ввиду компрессию данных- то там говорят о % сжатия.

Что такое бит?

По вашей ссылке все написано:

If the two possible values of one bit of storage are not equally likely, that bit of storage will contain less than one bit of information. Indeed, if the value is completely predictable, then the reading of that value will provide no information at all (zero entropic bits, because no resolution of uncertainty and therefore no information).

Жаль, что вы не можете решить задачу для третьего класса: 448К значений даты со временем занимают 56 байт на диске. Какой объем данных занимает одно значение даты со временем?

Какой объем данных занимает одно значение даты со временем?
Ви в якому закладі навчалися? Скажу своїм, щоб з нього ніколи нікого не брали.
Я вас можу розчарувати, ваша школоло-математика не діє. Зробіть стискання однієї дати та дайте нарешті собі відповідь. А ще не забувайте про те, що програма-стискач має не нульову довжину, та теж займає місце на диску.

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

У нас есть сервисы на go, принимающие и собирающие статистику в реальном времени по 500к событий в секунду на один комп. При этом они грузят 1-2 ядра CPU из имеющихся 40 ядер. Т.е. в теории они могут обрабатывать до 20 миллионов событий в секунду на одном компе. К сожалению, мы не можем отказаться от шардинга на несколько компов, т.к. эти сервисы требуют много оперативной памяти.

Это опять нельзя считать бигдата?

Highload -да, bigdata — нет

А если эти сервисы обновляют в режиме реального времени десять миллиардов различных счетчиков? Все еще не бигдата? Тогда с какого числа начинается bigdata?

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

У нас есть таблица в базе с более 10 триллионов записей (триллионов, а не миллиардов). Запросы в таблицу делаются из PHP. Если даже PHP может работать с бигдата, зачем тут Scala?

Десь я це недавно читав... а, от же ж:
habrahabr.ru/post/322620
Воно ?


Дальше мы пошли к разработчикам, которые умеют разрабатывать для баз данных, знают SQL и все вот эти вещи. Они стали смотреть на ClickHouse. Они поняли, что в ClickHouse почти ничего нет:

Там нет транзакций, нет констрейнтов.
Там есть primary key, но это не primary key на самом деле, можно сказать это порядок физической сортировки.
Там нет Consistency, то есть Consistency никак не гарантируется.
Нет удалений и апдейта.
Нет NULLs, система к которой вообще нельзя Null записать.
Нет миллисекунд, то есть время с точностью до секунды, хотите миллисекунды — храните их по-своему, как Int64 или отдельным полем.
Нет автоматических приведения типов, то есть даже Int8 к Int16 надо приводить явно.
Нет нормального SQL, это понятно из всего предыдущего списка.
Нет произвольного партиционирования, партиционировать можно только по месяцам, то есть нельзя по дням или по неделям отпартиционировать или по произвольным ключам, нельзя и всё.
Нет средств управления кластером, то есть они, наверное, есть у самого Яндекса, но он их не смог настолько запаковать, чтобы это можно было увидеть в Open Source или не захотел.

Але вам, я так розумію, якраз підходить ?

Да, clickhouse отлично подходит нам по следующим причинам:

— clickhouse выполняет типичные select запросы в сотни раз быстрее по сравнению с типичными sql-базами. Т.е. там, где потребовался бы кластер из 100 серверов, мы обходимся одним сервером.

— clickhouse круто пакует данные на persistent storage. Например, сейчас наши данные пакуются в 15 раз по сравнению с размером сырых данных. Т.е. при использовании типичных sql-баз пришлось бы устанавливать в 15-30 раз больше persistent storage’а. Число 30 вылезло от того, что типичные sql-базы хранят в файлах дополнительную информацию кроме самих данных — размер каждого значения, размер одной строки, смещения, индексы и т.д. Очевидно, clickhouse тоже хранит все это, но в сжатом виде :)

— clickhouse прекрасно работает на обычных HDD с низкими iops’ами. Т.е. можно сэкономить на SSD в 5-6 раз.

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

— clickhouse поддерживает композитный индекс по нескольким колонкам, с помощью которого можно оптимизировать типичные select-запросы, в отличие от google BigQuery.

— clickhouse умеет делать бэкапы десятков терабайт данных за пару секунд. И эти бэкапы не занимают место на дисках :)

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

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

Чем это существенно отличаеться от пресловутой кассандры ?

Не знаю, но подозреваю, что в первую очередь повышенной эффективностью использования имеющихся ресурсов CPU, RAM и storage space.

Эм, так оно же на си++ написано, где тут заслуга го, я чет не понял.

Это печально. Надеюсь, они скоро перепишут все на Go, чтобы ускорить развитие и уменьшить количество багов в коде. Или это придется сделать кому-то другому )

У нас есть таблица в базе с более 10 триллионов записей (триллионов, а не миллиардов). Запросы в таблицу делаются из PHP.
А база мап редьюс всех трилионов записей сама делает ? Или пхп делает редьюс ? Или у вас просто записи, один ключ, и положить в ключь, взять из ключа ? Так это не биг дата, в современном смысле.
А база мап редьюс всех трилионов записей сама делает ?
да
Или пхп делает редьюс ?
нет. Пхп делает select-запросы с подсчетом различной статистики по одному набору колонок (aka metrics), фильтрацией по другому набору колонок (aka custom filters), группировкой по третьему набору колонок (aka dimensions).
Или у вас просто записи, один ключ, и положить в ключь, взять из ключа ?
нет

не агрись как школьник, я тебе просто сказал что ПРИНЯТО называть big data и про скалу и пхп вообще ничего не говорил ибо это все не при чем

По моему тебе надо немного успокоиться и начать читать что тебе отвечают.

Например, через наши сервисы на Go сейчас проходит до 170 миллиардов событий в сутки.
coubsecure-s.akamaihd.net/.../med_1406984469_image.jpg

Вы считаете, что 170 миллиардов событий в сутки не тянет на bigdata?

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

— Кстати, ваши цифри не очень впечатляют, вам нужно старатся лучше.
для примера martinfowler.com/articles/lmax.html :
The system is built on the JVM platform and centers on a Business Logic Processor that can handle 6 million orders per second on a single thread.
будет полезно почитать про LMAX Disruptor

— да и цифры www.techempower.com/benchmarks не очень красят гошечку

Можем все таки убрать усколобост , и понять что, так малелькая латенси, просто так не дается, и старадают другие параметры, такие как пропускная способность. Для вас есть чудесная статья
habrahabr.ru/...mpany/mailru/blog/318504 где все прекрасно описывается.

P.S Долго не хотел отвечать, даже на ваше предыдущие сообщение, но не выдержал к сожалению =(

— Кстати, ваши цифри не очень впечатляют, вам нужно старатся лучше.
для примера martinfowler.com/articles/lmax.html :
The system is built on the JVM platform and centers on a Business Logic Processor that can handle 6 million orders per second on a single thread.
будет полезно почитать про LMAX Disruptor

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

— да и цифры www.techempower.com/benchmarks не очень красят гошечку

www.techempower.com/...-r13&hw=ph&test=plaintext — гошечка в топе.

Можем все таки убрать усколобост , и понять что, так малелькая латенси, просто так не дается, и старадают другие параметры, такие как пропускная способность. Для вас есть чудесная статья
habrahabr.ru/...mpany/mailru/blog/318504 где все прекрасно описывается.

см. dou.ua/...rums/topic/16012/#1042597

Ну так на бенчмарках и наша система обрабатывает несколько миллионов событий на одном потоке. К сожалению, бенчмарки обычно далеки от продакшна. Также у нас не было задачи выжать максимум производительности любой ценой — текущая производительность получилась сама собой без особых усилий. Она нас полностью устроила, поэтому дальнейшими оптимизациями не стали заниматься.
А где вы увидели бенчмарк. Если там реальное приложение в продакшене.
www.techempower.com/...-r13&hw=ph&test=plaintext — гошечка в топе.
Go в топе, но где-то уступает, где-то выигрывает, но в топе и scala (вами не любимая) и java, но вы как-то забываете об этом упомянуть
см. dou.ua/...rums/topic/16012/#1042597
1) STW паузы в Go не превышают 100 микросекунд out of the box на любых размерах хипа, в то время как STW паузы в Java сильно зависят от настроек GC и размера хипа, и в общем случае держатся в районе 100 миллисекунд, т.е. в 1000 раз больше, чем в Go.
Ну hotspot gc’s и не тягаются с лоу-таненси системами, для этого есть имлементации Azul и Red Hat
Только вот я вам про одно, что чудес не бывает, и go gc это cms в hotspot без поколений, и выигрывая в одном параметре, проигрываем в другом. Но все упорно доказываете, что gc в go, это лучшее что есть на данный момент. Хотя для многих задач маленькие задержки , это не так важно, как пропускная способность. Но нет, вы пытаетесь везде сунуть go. На этом языке, написано чудесные инструменты: kubernetes, графана, докер и т.д. Язык занимает свою нишу, и кажется с нею справляется. Но каждый инструмент, решает определенные задачи. Но, кажется, вы пытаетесь всовывать его везде где только можно, и доказывать что другие инструменты не имеют взгляд на жизнь. Что довольно глупо
для примера martinfowler.com/articles/lmax.html :
The system is built on the JVM platform and centers on a Business Logic Processor that can handle 6 million orders per second on a single thread.
будет полезно почитать про LMAX Disruptor

Спасибо. Почерпнул оттуда парочку полезных идей:

In fact they ended up by doing all the business logic for their platform: all trades, from all customers, in all markets — on a single thread

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

Like the rest of the system, the disruptors are bounced overnight. This bounce is mainly done to wipe memory so that there is less chance of an expensive garbage collection event during trading.

Еще одна классаная идея — периодически перезагружать сервис из-за супер-навороченного gc, который «much more advanced than the simple GC in go». Или из-за нагромождения лишних абстракций с паттернами проектирования, которые так любит парить этот дядька? Мы перезагружаем наши сервисы на go только при деплое новых версий. Некоторые сервисы работают без перезагрузки месяцами.

В нужных местах на jvm языках используют память которая не под управлением gc. К примеру в Spark, Hbase, Drill и других проектах.

The system is built on the JVM platform ... that can handle 6 million orders per second on a single thread.

Для проца 3GHz это 500 тактов на запрос, если понимать буквально.

«170 миллиардов событий в сутки» это почти точно 2 million events per second.

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

Невнятные ответы джуна и стажера? Или хвалебные отзывы после перла и нодежс?
«Года три назад я увлёкся Erlang’ом (и ФП в целом), но понял, что зарабатывать на нём — да ещё столько же, сколько на C++, — я не смогу (сразу, а не через пять лет). По этой же причине отпала Scala (жаль, мне она показалась весьма интересной), этот язык подразумевает серьёзный бэкграунд на Java. Rust просто не понравился сразу. Go, кстати, тоже не понравился: после C++ мне многого в нём не хватает, в первую очередь гибкости.»
Ок, в мейлру не пишут на джаве, поэтому скалу протащить не получилось. Однако пишут на си, перле и js и протащили как-то го.

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

На сколько я знаю, в мэйл ру довольно много пишут на джаве.
На жаве пишут, а скалу ниасилили. Пришлось пересесть на гошечку :)

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

пока Go это то куда php обезьян гонят прикладами и пинками в красные ср#ки, что бы они попали хоть в какие то рамки и начали писать что то вменяемое
другой ниши пока нет ( но это не значит что язык плохой)

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

ага с котятами и scalaz доо
уж там то они покажут

Даже mail.ru

451 :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Це Ви не розумієте, що GC зовсім без пауз це задача рівня студента, але будь-які міри по зменшенню пауз збільшують відносну ціну всього збору сміття. Повний STW дешевле за все, і він продовжує займати свою нишу там, де сумарна робота важливіше за рівномірність. Тому, наприклад, звичайні GC в Яві не робляться так, щоб STW не було зовсім — це потрібно 0.1% користувачів, і ті краще сядуть на Azul.

Це Ви не розумієте, що GC зовсім без пауз це задача рівня студента,
Хм... навіть не знаю що вам на це сказати, з такою позицією. Можу придумати тільки попросити пару прикладів на Гітхабі таких студентських подєлок. :)
Кльовий світ у нас, ледачий, всякі гуглсамерсофкод проводять і на них жодного ГЦ такого і досі не написали!

На рахунок потрібності... ну ХЗ, комусь і швидкість не потрібна, он на Рубі скільки пишуть.

Боюсь що Azul не всім по карману буде. Інакше би всі нормальних розрабів наймали, як Гугл, а не збирали лоукост ресурси.

Кльовий світ у нас, ледачий, всякі гуглсамерсофкод проводять і на них жодного ГЦ такого і досі не написали!

Написали, тисячі їх. Але: поверх malloc (і явних списків) і без поколінь. Тому і не цікаві — затрати памʼяті в 2-3 рази більше, ніж у нестудентських.

От що саме в Go — можна подивитись. Якщо воно з поколіннями і на власному алокаторі — то це вже цікаво переглянути докладніше.

Боюсь що Azul не всім по карману буде.

Так. Але вже є (або скоро буде) Epsilon GC.

Інакше би всі нормальних розрабів наймали, як Гугл

Гм... боюсь, що політика Гугла більш дивна, ніж просто «нормальних».

Так. Але вже є (або скоро буде) Epsilon GC.
От до цього все, насправді, і зводиться. Всі ваші студентські подєлки насправді не далеко від Epsilon і втекли.

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

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

В Lua нема STW (якщо вщент не затюнити). А ціну за це я вже казав.

А всякі дурні ліплять костилі по типу смарт поінтерів чи бороу чекерів.

Так, Ви ще раз показали свою необізнаність в темі.

Всі ваші студентські подєлки насправді не далеко від Epsilon і втекли.

А в Києві дядько.

В Lua нема STW (якщо вщент не затюнити). А ціну за це я вже казав.
Невже ж це ціна? Пам’ять сьогодні не така вже й дорога, значно дешевше Азула то точно. :)
Про Луа щось так сходу не знайшов. В оф. докі пишуть що просто дроблять паузи на менші, що й G1 намагається робити.
Так, Ви ще раз показали свою необізнаність в темі.
Від необізнаного чую!
Невже ж це ціна? Пам’ять сьогодні не така вже й дорога, значно дешевше Азула то точно.

Ви такі навколо бірж не працювали. Деякі ставлять 2TB RAM в сервер, тільки що денний масив marketdata зберігати і обробляти. І ні, ніякі SSD або навіть Optane не пропонуйте — швидкості не вистачить. І розділяти на кластер серверів не можна — бо технології тупі, як сокира троглодита.
Я розумію, що все це вкрай маргінальне для більшості. Але тій більшості підходять і звичайні затримки від STW Яви (наприклад, чувак з Однокласників казав — все менше 0.2с(!) їх влаштовує).
Шлях Go вкрай дивний — вони зменшують затримки за рахунок всіх інших характеристик GC, при тому, що не мають таких обмежень, як Lua.

В оф. докі пишуть що просто дроблять паузи на менші, що й G1 намагається робити.

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

Про Луа щось так сходу не знайшов.

Просто в офіційній документації. В них на 1 запит до системи памʼяті додатково k/100 (в середньому) кроків розчистки існуючого. k можна міняти, в залежності від нагальних потреб. Але, вже казав, у іншому схема дуже примитивна. Боюсь, що в Go десь те ж саме.

Від необізнаного чую!

Я дійсно знаю не все :) але я про це знаю і маю на увазі :)

Ви такі навколо бірж не працювали. ... Але тій більшості підходять і звичайні затримки від STW Яви (наприклад, чувак з Однокласників казав — все менше 0.2с(!) їх влаштовує).
Такі навколо якихось працював. І на тих біржах що я бачив час оброби клієнтського запиту обмежувався 0.18 сек, хто не встигнув той апіздав. І такого вагон, не тільки на серйозних біржах, зараз половина проектів з рекламою пов’язані де до SLA вимоги досить високі.
Ваші слова мені нагадали про те що 640К вистачить усім і більше пам’яті і даром ніхто не хоче.
Шлях Go вкрай дивний — вони зменшують затримки за рахунок всіх інших характеристик GC, при тому, що не мають таких обмежень, як Lua.
Ясний-красний, прибавляючи в одному місці відбуває в іншому. Цей світ так влаштований.
G1 працює в умовах значно більш складних, ніж Lua. Там суттєво зменшувати паузи значить нелінійно збільшувати накладні витрати.
Про те й мова. Ви самі привели Луа в якості промислового прикладу, а потім кажете що він не потягне «складні» умови. Те що в Луа інкрементний колектор я зрозумів, я не зрозумів за рахунок чого там немає пауз (як ви стверджуєте). На скільки я зрозумів то паузи там є але просто їх більше і вони дрібніші.
обмежувався 0.18 сек

Це безглуздо багато, в інших задачах треба вже суб_мікро_секундні затримки.

аші слова мені нагадали про те що 640К вистачить усім

Це як же треба читати, щоб мої слова нагадали таке? 8-O

Про те й мова. Ви самі привели Луа в якості промислового прикладу, а потім кажете що він не потягне «складні» умови.

Так, він по-прежньому промисловий, і я не відмовлятимусь від цього. Складність буває різна.

за рахунок чого там немає пауз (як ви стверджуєте). На скільки я зрозумів то паузи там є але просто їх більше і вони дрібніші.

Затрати на GC _рівномірні_. Це і зветься «нема виділених пауз». А інакше взагалі нема сенсу розглядати, бо на рівні процесора кожне чекання cache miss це пауза.

Це безглуздо багато, в інших задачах треба вже суб_мікро_секундні затримки.
Я не мав на увазі що це рокетсайнс, а лише те що набагато більше ніж відсоток користувачів бажали би менші паузи в колекторі.
Затрати на GC _рівномірні_. Це і зветься «нема виділених пауз». А інакше взагалі нема сенсу розглядати, бо на рівні процесора кожне чекання cache miss це пауза.
Здається нарешті я зрозумів що ви маєте на увазі.
Я так розумію такої точки зору і термінології дотримуєтеся не лише ви?
Бо відмінність STW від промаху кеша, сискола чи іншого «тормоза» хоча би у тому що це відноситься до одного потоку, і не ставить всю систему на паузу.
Бо відмінність STW від промаху кеша, сискола чи іншого «тормоза» хоча би у тому що це відноситься до одного потоку, і не ставить всю систему на паузу.

Єдина нитка чи ні — це подальший розвиток питання про механізм GC, я не хотів одразу в це пірнати. В .NET, наприклад, зупиняються всі нитки заради створення пулу первісних посилань для GC. Але взагалі і це необовʼязкове: достатньо вести облік того, чи було посилання отримане після останного рескану конкретної нитки. Але форсування такого рескану може бути занадто дорогим або складним. Якщо допускається чекати і блокувати роботу, поки всі нитки відреагують, то задача спрощується в рази. Якщо ні — можна, наприклад, вести пул первісних посилань і виключати щось з нього тоді, коли жодна нитка 2 рази підряд не тримає посилання. Такий собі «консервативний» дизайн.

Я так розумію такої точки зору і термінології дотримуєтеся не лише ви?

Судячи по згадуванням в профільній літературі — так. «Stop the world» має два аспекти, які дещо конфліктують — «великий збір всього» у однонитковому сенсі, і одночасна зупинка різних ниток. Друге звичайно містить в собі перше (інакше зовсім дивна химера створюється). Але, в практичному сенсі оцінки затримки взаємодії, різниці нема: якщо нитка, що оброблює запит клієнта або активність локального користувача, заблокована, йому нема справи, зупинені інші нитки, чи ні.

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

Сферично в вакуумі — тобто відірвано від інших потреб — мабуть, так. Але, якщо порівняти дві реалізації — в першій паузи до, наприклад, 200мс, в другій — до 20мкс, але друга їсть в 3 рази більше памʼяті — виявляється, що таки 99% виберуть першу, і це покриє діапазон від звичайних десктопних застосунків до великого серверного навантаження. Тому основна оптимізація іде саме під них.

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

Сферично в вакуумі — тобто відірвано від інших потреб — мабуть, так. Але, якщо порівняти дві реалізації — в першій паузи до, наприклад, 200мс, в другій — до 20мкс, але друга їсть в 3 рази більше памʼяті — виявляється, що таки 99% виберуть першу, і це покриє діапазон від звичайних десктопних застосунків до великого серверного навантаження. Тому основна оптимізація іде саме під них.
Мені здається що це лише ваше бачення потреб ринку. Так у мене воно інше.
Шкода на ДОУ голосувалки немає, можна було би статистику зібрати чи потрібен такий колектор чи ні.
Я мав на увазі паралельний колектор, до якого прагне людство, який працює паралельно потокам основної програми, при цьому не зупиняючи їх.

Виділяти на нього окрему нитку? Були такі спроби. Наскільки я знаю, вже закінчились. Бо вельми недружні до кеша.

Мені здається що це лише ваше бачення потреб ринку.

І чомусь воно співпадає з баченням авторів оригінальних JVM і дотнета.

Шкода на ДОУ голосувалки немає, можна було би статистику зібрати чи потрібен такий колектор чи ні.

Так роблять голосувалки через Google Docs, регулярно.

Виділяти на нього окрему нитку? Були такі спроби. Наскільки я знаю, вже закінчились. Бо вельми недружні до кеша.
Да. Закінчилися бо це не так просто зробити як ви намагаєтеся показати.
І чомусь воно співпадає з баченням авторів оригінальних JVM і дотнета.
Не зовсім, тут вже ви підтасовуєте. Те що реалізації немає не обов’язково свідчить про те що вона непотрібна.
Да. Закінчилися бо це не так просто зробити як ви намагаєтеся показати.

Я намагаюсь? На окремій нитці? Мабуть, вам треба перерву на сон.

Те що реалізації немає не обов’язково свідчить про те що вона непотрібна.

Взагалі — так. Але супроводження десятків і сотень мільйонів установок товстими комерційними фірмами зводить імовірність такого практично до нуля.

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

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

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

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

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

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

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

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

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

Ви не повірите, але є люди для яких можливість писати без ІДЄ є достоїнством мови а не її недоліком.

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

В тому і діло що швидкість і зручність речі індивідуальні і багато залежить від мови (в тій же Java з одними імпортами справитися чого варте).

фича иде, не столько в помогании написании кода, сколько в помогании читания кода. Быстро понять что в данном куске кода откуда берется — многого стоит.

Да, я розумію. Особисто в мене бачення цього питання наступне. Програми на С/Go/Python/etc набагато простіше структуровані (ніж на тій же Java), і відповідно, навігація по ним набагато легша і в «блокноті». Я не кажу що IDE взагалі не потрібне, я лише хотів сказати те що вона там не настільки важлива. Є — круто, немає — не дуже сумно.

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

Хз, мне чет казалось что настояшим любителям vi скала гораздо предпочтительней чем С/Go/Python/etc.
Ибо то что в го нужно усердно пичтать 20 строк кода, в скале делается в одну строку.

Значит, под vim на go пишут графоманы :) А если серьезно, то код пишется один раз, а затем читается сотни раз во время расширения функционала, отладки ошибок или рефакторинга. В go для этих операций достаточно vim+ctags+grep. А вот для scala уже требуется мощная IDE.

Также при программировании на go без ide существенно выше продуктивность благодаря тому, что программы на go компилируются за секунду, в то время как аналогичные программы на scala — минимум за минуту. Без ide легче допустить различные описки, приводящие к ошибкам компиляции. Но на go они моментально выявляются во время быстрой компиляции.

Также при программировании на go без ide существенно выше продуктивность благодаря тому, что программы на go компилируются за секунду, в то время как аналогичные программы на scala — минимум за минуту. Без ide легче допустить различные описки, приводящие к ошибкам компиляции. Но на go они моментально выявляются во время быстрой компиляции.

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

В усіх (відомих мені) IDE немає нормального редактора. І це величезний їх недолік.

что такое «Нормальный редактор» ?

Це редактор з широким функціоналом, а не просто навігацією за допомогою стрілок і самим примітивним функціоналом типу Ctrl+Backspace. Всякі штуки типу маросів, регістрів, кілбаферів і т. п. Деякі штуки реалізовані в популярних IDE але, як це часто буває з копіями, якось по дибільному. Це редактор що настроюється і скриптується.
Для мене завжди було загадкою чому в це не вкладаються розробники IDE.

макросы понятно, что такое

регістрів, кілбаферів
понятия не имею.

www.gnu.org/...node/emacs/Registers.html
В регістри можна зберігати куски тексту (типу як багато іменованих буферів обміну), позиції і таке інше.
www.gnu.org/...node/emacs/Kill-Ring.html
Коли весь текст який ви видаляєте зберігається у історії і потім доступний для вставки.

Примітивні штуки, але я в свій час перепробував купу плагінів до Екліпса і жодним нормально користуватися не можна було. В IDEA використовую імакс мод (чи як вони його там називають) — там тільки що дефолтна карта гарячих клавіш від імакса і все.

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

буфер копи пейста

Один? В том и дело, что в emacs их неограниченно. Даже в vim их дофига (по количеству латинских букв). Реально я никогда более 2 одновременно не использовал, но 2 вместо 1 — это колоссальная прибавка к удобству.

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

типа скалу нельзя без иде писать.

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

У нас народ полноценно разрабатывает в vi/emacs/atom
Но лично я не особо понимаю этих людей.

Після років у vim, завчених моторних навичках для кількох швидких операцій, дуже тяжко без цього у інших IDE. З горем пополам є плагіни Vim для Atom та Idea.
А про Vim є стаття, яка оце от пояснила, чого ті придурки юзають Vim

www.viemu.com/a-why-vi-vim.html

і ще одна докладніша

Your problem with Vim is that you don’t grok vi.

stackoverflow.com/...-with-vim/1220118#1220118

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Из опыта:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

«Пирсинг примитивов» — я не понял, что это, но звучит мощно и внушительно.

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

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

Все им не так )

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

upd.

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

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

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

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

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

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

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

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

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

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

Тонко)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

а зачем?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ML: Python, OCaml, Haskell

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Очередной апдейт:

Go — 817 (+60)
Scala — 148 (+7)

Популярность Go растет с каждым днем и уже в 60/7=8.5 раз больше, чем у Scala.

Потрясающе!!! С таким мега-галактическим размахом роста, скоро сообщество Go-программистов будет рассматривать сообщество скалы в микроскоп!

Как и предсказывалось, в этом году 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
Б: забагато непов’язаних тверджень
А: це щоб кожен щось для себе знайшов
Б: це у вас проекція <— недоречне твердження

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

Ломай мєня по