Python conf in Kharkiv, Nov 16 with Intel, Elastic engineering leaders. Prices go up 21.10

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

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

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

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

LinkedIn

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

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

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

А ведь раздача файликов по сети это собственно то, ради чего 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

Why Generics?
blog.golang.org/why-generics

ПС Дженерікам — бути... але це не точно..;))

My Reasons to Consider Go Coming from Java
preslav.me/...​ider-go-coming-from-java

P.S. Let’s get ready to rumble)))

Я знаю спеціалістів які перейшли з PHP на Go, з Python на Go, Java, Ruby, DevOps, але жодного хто перейшов з C#, такі взагалі є? (читав коментарі в цій темі по C#)

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

Исправить не пробовали нейминги в команде? Или код на го хороший даже если он с запахами?

Так налаштовано же. Там все по стандартам окрім кількох маленьких але досить баттертних відхилень :-)

Всі звикли, тому припікає переважно лише у мене. А кодобаза огого, щоб все міняти.

PHP на Go, з Python на Go, Java, Ruby, DevOps

вот это и есть примерно целевая аудитория

2% идентифицируют себя как neurodiverse, это интересно как?

Grab переходит со spark’а на go — engineering.grab.com/...​ormation-product-insights . Выводы — spark никому не нужен, spark тормозит разработку, spark тормозит в продакшн, spark постоянно глючит, scala — мертва. Да здравствует Go!

After revamping the system, the elapsed time for a single event to travel from the gateway to our dashboard is about 1 minute. We also fixed the data loss issue. Finally, we significantly reduced our on-call workload by removing Spark Streaming.

Spark не нужен там , где его не используют

After completing the MVP phase development, we noticed the Spark Streaming functionality we actually used was relatively trivial.

Было бы там что-то сложней 2+2 ,а именно какой-то СЕP, boilerplate язык по типу го никто не рассматривал даже.

Лучше выяснить кому нужен язык, где надо ждать major релиза, что бы добавили функцию sort slice. Spark он собрался покорять.

Ти таким повідомленням вирішив підняти рейтинг Go? після малого падіння із-за теми Продам книги по GO

Це не тільки я вперше почув про компанію Grab?

Апну-ка я темку следующим:

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

github.com/odin-lang/Odin — оффициальный репозиторий
odin.handmade.network — оффициальный сайт сего чуда, с туториалом odin.handmade.network/wiki/3329-odin_tutorial

Интересно, как оценят гоферы (и им сочувствующие), ну и анти-гоферы соответственно сие творение рук программерских)

Прочитал 2/3 тюториала, было стойкое впечатление, что это форк с Go, но потом выяснилось, что никакой не форк, поскольку нет многих ключевых вещей из Go. Прежде всего нет концепта параллельного программирования с горотинами, а вместе с этим отсутствует и смысл использования этого языка. Нет интерфейсов и утиной типизации. Нет вообще какого-либо концепта ООП. Нет GC, судя по всему память управляется только вручную. Тема замыканий и передачи контекста — проигнорирована. В целом синтаксис удобный, но проект явно сырой, чтобы на нём что-то реально делать.

Так а что страшного то в тех строчках которые приводят в той статье? Обычное же ФП без особой жути — монады и монад трансформеры, higher kinds. На самом деле в ФП гораздо больше злой дичи, чем там написано.

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

Scala — первый мой язык промышленного програмирования, и мне потребовалось всего месяц чтобы осилить стрелочки-карлючки и import cats.data.cokhrenoid и научится понимать базовые ФП-концепции, которых достаточно для чтения кода.

На самом деле, скала предоставляет множество плюшек для безопасности, структурирования и упрощения и повышение читаемости кода, но только если её не использовать как джаву с синтаксом скалы и не спамить всеми модными фичами(в особенности имплиситами).

Соблюдение базовых концепций (типа прочь вары и мьютабл коллекции, мапы/флатмапы/фолды вместо циклов, айзер/трай-монада для обработки ошибок вместо тысячи траев ифов и кетчей, возвращаемое значение функции вместо throw execpetion, скальные библиотеки вместо джавных(спринг, EE, и всё остальное), применение неявных(implicit parameters) только по назначению(реализация тайп-классов, пробрасывание «контекста» в функцию), жёсткая разбивка функции-преобразования над данными и собственно сами данные) делает код гораздо чище, проще, прозрачнее и короче чем джавный и традиционный ооп-шный способ писать код.

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

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

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

Scala — первый мой язык промышленного програмирования, и мне потребовалось всего месяц чтобы осилить стрелочки-карлючки и import cats.data.cokhrenoid и научится понимать базовые ФП-концепции, которых достаточно для чтения кода.

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

ООП с паттернами головного мозга, а всё остальное ересь"(те самые которые опшенел используют только для того чтобы проверить его на isEmpty, и на коллекциях вместо мапов используют циклы, траи кетчи во все поля) и начинают пилить декоракторы абстрактных фабрик бинов, а когда встречают ОФП

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

Здорово, теперь меньше времени осталось ждать до выхода Go 2. Ещё только 1.13 обещали выпустить.

Та я вже, навіть, не знаю, чи дуже чекаю я на Go 2.0...))))
Мене там все влаштовує для моїх потреб...
Так що спостерігаю, шоб не «покращили» ..))

Не можу не погодитись...
„Go, the Programming Language of the Cloud”
thenewstack.io/...​ng-language-of-the-cloud

Признавайтесь, чей вопрос на quora про scala и go? www.quora.com/...​mplex-language-like-Scala

Не признаються...
Навіщо їм такий камінгаут?! ;))

отлично сказано: „I feel like an idiot when programming in Golang ”

Все не так, як Вам хочеться бачити..;))
Цікаво, що пан/пані з Quora не скаржиться на функціонал та можливості Go... а саме на свої відчуття..)
Це певно когнітивний дисонанс: думаю, він має можливість робити те ж саме, але з меншою кількістю померлих нервових клітин..;))

И ниодного ответа от тру-скалиста.

Какой инструмент — такие и задачи.

Не напружуйтесь так...
Це тільки для справжніх поціновувачів..))

ти кажеш

Читати всім уважно

а потім

Не напружуйтесь так...

нє надо так
www.netlore.ru/...​b2hbe1tk0h4717ujsc3u.jpeg

«не напружуйтесь» — це зовсім не образа... це, скоріше, турбота..)))

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

свежеизобретенных велосипедов подвалило

К счастью, не подвезли. Будем надеяться, что никогда не подвезут. Иначе придется пересесть на какой-нибудь Crystal

придется пересесть на какой-нибудь Crystal

oy gevalt!
crystal-lang.org/...​d_semantics/generics.html

такі може колись до вас дійде, що дженеріки — це інструмент для спрощення життя програміста, а не культ карго «аби було»

Дженерики — зло, т.к. они усложняют понимание кода. И они реально карго культ. jmoiron.net/...​n-the-go2-generics-draft

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

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

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

Не правда. То не вы, не ваш оппонент, не видели языков, где генерализация вшита в компилятор по умолчанию.

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

не видели языков, где генерализация вшита в компилятор по умолчанию

наприклад?
дійсно цікаво

Мабуть дженеріки з ексепшинами підвезли.
К счастью, не подвезли. Будем надеяться, что никогда не подвезут. Иначе придется пересесть на какой-нибудь Crystal

.
(Щоб не загубити цей діалог. xD )

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

Что там та Java, вон обошли PaaS и rabbit mq программистов даже — это определенно вершина мира.

Оригінал тут — marketing.dice.com/...​_TechSalaryReport2019.pdf. Варто зауважити що там нічого нема про Go-програмістів. Натомість мова йде про skills серед яких golang популярний запит у роботодавців на Dice. Серед інших популярних Kafka, амазодновські БД і таке інше.

Поздно оправдываться — пора смириться и переучиваться с your_language_here на Go, а не то будет поздно.

переучиваться с your_language_here на Go

Для чого переучуватися якщо можна просто знати/вміти Go на додачу до інших скілів? Чи у гошників знання чогось за межами Го це щось нечуване?

Go опередил Elixir и Node.js — stressgrid.com/...​ing_go_vs_node_vs_elixir . Scala не участвовала, т.к. очевидно, что она бы заняла последнее место.

В 2019 году программисты больше всего хотят изучать Go — zdnet3.cbsistatic.com/...​019-01-29-at-11-25-51.png .

не в чем, а в ком — в программистах

Я б написав так: «В 2019 році й надалі...» ;))

А де про саме опитування — хто, коли, де, кого?

Ага, тобто 35 тис. користувачів HackerRank заповнили форму з якої і склали ці діаграмки.

Ура! В go1.13 добавят три супер-крутые фичи! Go станет еще совершеннее, а у хейтеров большне не останется аргументов против Go!

Тобто, ти визнаєш, що поточна реалізація далека від ідеалу?

Єдність і боротьба протилежностей — ідеальна мова без недоліків та проблем недоліки та проблеми якої будуть виправлені у наступній версії.

Це зовсім не те що Java чи С++ якісь де все і так не ідеально, а нові версії та стандарти потрібні щоб зробити все ще менш ідеально.

Это збс! Добавляют дженерики и исключения. Через несколько мажорных версий дотянет до C# 2.0 по функционалу.

Ти ж розумієш що цим себе тільки підставляєш? :)

Вышел короткий нескучный драфт по Go 2.0
www.youtube.com/watch?v=U84zvGbk_CY
ждём релиза в следующем году

Классная страничка про свитчеров с разных языков программирования на Go — github.com/golang/go/wiki/FromXToGo .

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

Что значит переходят с Go обратно? Те, кто туда попадает, обратно уже не возвращаются.

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

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

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

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

Пошкодження необоротні і надій на зцілення нема?

Go уверенно движется вверх как танк. Уже на третьем месте и скоро обгонит Java. Scala пробила дно и продолжает копать вглубь.

По-перше, на четвертому. А, по-друге, це статистика по проектах на github.

По-перше, на четвертому.

Значит, скоро будет на третьем месте.

А, по-друге, це статистика по проектах на github.

Что еще кроме github можете порекомендовать для репрезентативной статистики?

Значит, скоро будет на третьем месте.

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

Что ... можете порекомендовать для репрезентативной статистики?

www.tiobe.com/tiobe-index

tiobe — купленный индекс. Там vb.net на первых местах.

tiobe — купленный индекс.

Ким, для чого?

Мелкомягкими)) Бейсик продвигать — очевидно же. :D

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

tiobe — купленный индекс

нагадаю — ще рік тому він був не такий вже і куплений :)
dou.ua/...​rums/topic/16012/#1145324

В этом году гугл выделил меньше денег на раскрутку Go, вот и не получилось купить первое место в tiobe индексе

Так а для чого ж там купляти місця? Може я щось роблю не так в своєму житті і мені теж треба там місце прикупити?

любителей goвнокодить все больше и больше

Любители говнокодить преходят со Scala на другие эзотерические языки программирования типа Rust и C++.

Вы привели в пример рейтинг «звёздности». Что он отражает? Хайповость технологии?
Если посмотреть на количество доставленного кода
madnight.github.io/githut/#/pushes/2018/3 то не всё так радужно для Go

Вы привели в пример рейтинг «звёздности». Что он отражает? Хайповость технологии?

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

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

Ничего не имею против go, но слишком «сладко».

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

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

У go малое количество git push’ей, т.к. хороший код на нем получается с первого раза, в отличие от остальных языков программирования, опередивших Go в этом рейтинге.

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

На будь-якій мові гарний код виходить з першого разу. Ви тільки його нікому не показуйте.

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

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

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

Понимаете, есть вещи плохие, есть хорошие. А есть идеальные в своём совершенстве, и думаю излишне будет напоминать, что речь идёт тут о Go.

хотів уточнити: ми все ще говоримо про інструмент із назвою Go, який використовується для написання програм?

хотів уточнити: ми все ще говоримо про інструмент із назвою Go, який використовується для написання програм?

Конечно. Не об игре же Go, хотя она тоже может примазаться на фоне популярности к великой славе golang.

Мені якось goto більш досконалим здається ніж go.

Мені якось goto більш досконалим здається ніж go.

Go в два раза короче, чем goto, а краткость — сестра таланта.

краткость — сестра нашего брата ©

Go підтримує goto, так що все необхідне у ньому є.

Всьо, переписую термінову все на го!

У go малое количество git push’ей, т.к.

никто не может довести код до состояния, когда его не стыдно пушнуть

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

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

Я конечно понимаю, что в силу природной скромности, вы не можете открыто и честно написать, что гордитесь комьюнити Go, поскольку и сами в него входите. Но не нужно перегибать палку в этом, мы ведь и так всё понимаем. Лучше честно и объективно написать всю правду, какой бы она ни была, что комьюнити Go самое продвинутое, самое достойное, куда входят лучшие представители хайтека.

А говорили, что никогда в жизни не перейдете со Scala на Go, что Go — никудышный язык программирования. Этот топик даже открыли, чтобы поглумиться над ниасилившими Scala. А теперь сами на Go пишете :) Epic fail!

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

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

— в го — всратые пионеры верящие что го лучший язык со времен каменного топора

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

а скіфські кам’яні баби — це, насправді, намагання наших предків увіковічнити Go Gopher-а!

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

а шо каже тьобе?

www.tiobe.com/tiobe-index
Jan 2019 Jan 2018 Change Programming Language Ratings Change
1 1 Java 16.904% +2.69%
2 2 C 13.337% +2.30%
3 4 change Python 8.294% +3.62%
4 3 change C++ 8.158% +2.55%
...
16 19 change Go 1.115% -0.45%

кстати Го обогнали почти во всех кейсов джава www.techempower.com/benchmarks
единственное исключение это plaintext — что как по мне даже не должно быть там ибо в жизни оно никому не надо.

Сильно просела на TIOBE. Нишевый язык в нише с высокой конкуренцией.

У нашей галеры позиций больше тоже нет. Back to springhebirnate.

Ну це просто у Вашій галері Scala «всьо». А в Spark-спільності й області сучасних рішень для Big Data планів міняти пріоритетну мову зі Scala на щось інше ніби нема. :-)

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

Дата сайентисты с удовольствием используют pyspark

PySpark это примерно как Javascript после Java, замечу я вам.

Хм.

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

Я допустил двусмысленность, сорри. В оригинале имелось ввиду, что при всём удобстве для не-дата инженеров, PySpark после Scala Spark API выглядит ограниченным для самих дата инженеров

У Data Science все зрозуміло: research, вибір моделей, навчання, валідація не залишають часу, щоб ще вчити складну мову програмування.

Збираюся через місяць на Spark+AI Summit Europe 2018 у Лондон. Переглянув на днях відео деяких доповідей із Spark+AI Summit 2018, який був у Сан-Франциско — шматків коду на слайдах майже нема, але там, де вдалося знайти, є Scala. Наприклад, доповідач з Google.

Я думаю, що там, де треба швидко набирати багато Big Data програмістів і вже писати код, будуть старатися використовувати Java. Як і в компаніях, які просто не можуть дозволити собі найняти досвідчених розробників з фінансових причин. В інших випадках писати Big Data проект на Scala ніби має більше переваг, ніж на Java. Що не заперечує, що в деяких інших областях Java є кращим вибором.

але там, де вдалося знайти, є Scala. Наприклад, доповідач з Google.

И где там скала ? О том как ранить спарк на кубернейтсе (довольно полезная в своей области тема).

В інших випадках писати Big Data проект на Scala ніби має більше переваг, ніж на Java.

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

Якщо подивитеся на відкриту web-сторінку, яка є у тому відео, то побачите ALS.scala і MovieLensALS.scala. ;-)

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

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

Spark’ом пользуются только две группы людей:

1) у кого мало данных и им пофиг, с помощью чего их обрабатывать
2) у кого мало мозгов, но много денег, чтобы тратить over $9000 на тормозное и жрущее память решение задачи на spark вместо того, чтобы решить эту задачу за $10 с помощью go + clickhouse

решить эту задачу за $10 с помощью go + clickhouse

Тепер я розумію Богдана в якого від вас підгорає! :)

Кто такой Богдан и почему у меня от него подгорает?

Вот выдержка из интересной статьи, сравнивающей производительность clickhouse vs spark:

Yandex ClickHouse is an absolute winner in this benchmark: it shows both better performance (>10x) and better compression than Apache Spark
Кто такой Богдан

автор джава-дайджестів

почему у меня от него подгорает?

не у вас від нього, а у нього—від вас.

clickhouse

Контраргумент від Фелікса:
felixit.blog/...​2/clickhouse-ne-segodnia

Феликс попытался использовать кликхаес не по назначению, после чего сделал верный вывод:

Что в итоге? ClickHouse для big data, где big начинается с миллиардов строк и сотен гигабайтов. С этой планки вас начинают интересовать уже другие запросы (и они в ClickHouse отлично работают)

Ахахаха.

Только упоротые гошники на полном серьезе могут сравнивать базу данных со спарком. Еще и большую статью написать.

Так статья не от гошников, а от Percona — спецов по базам данных

Не дивно, що SQL-запити до стовпцево-орієнтованого сховища ColumnStore напряму виконуються швидше, ніж SQL-запити до Parquet чи ORC через прокладку у вигляді Spark. Що і демонструється у статті. LOL.

Можна ще було для даних, які зберігаються у ClickHouse, порівняти час виконання SQL-запитів напряму і через clickhouse spark connector у Spark. Думаю, що напряму буде все ще швидше. :-D

По-перше, ClickHouse може працювати тільки зі структурованими даними, а в реальних задачах дані можуть бути різні; Spark RDD дозволяє працювати і з неструктурованими даними.

По-друге, дані у ClickHouse спочатку треба покласти; для Spark ж вже є багато конекторів.

По-третє, у випадку потокових даних, наскільки я розумію, у ClickHouse нема можливості задавати, що коли скидається на диск, а що ще зберігається в пам’яті, а якщо робити це вручну на Go, підозрюю, що реалізація більш-менш складної логіки буде дорогою і довгою; Spark Streaming розв’язує проблему.

По-четверте, незрозуміло, як вирішувати за допомогою Go + ClickHouse задачі, які вирішують Spark ML, GraphX.

До речі, навіть Yandex вирішує деякі зі своїх задач за допомогою Spark. А чомусь не зв’язки Go + Yandex ClickHouse. ;-)

Новый рейтинг языков TIOBE Index for September 2018

Как и предполагалось, Java/C/Python впереди планеты всей и укрепляют позиции. Go предсказуемо лоснул тунца.

Не зрозуміло ніфіга, чому така шалена популярність стала в Сі? Та куди дівся Objective-C? На ньому проектів менше стали клепати?

Та куди дівся Objective-C? На ньому проектів менше стали клепати?

ObjectiveC -> Swift

Та куди дівся Objective-C?

Он (судя по TIOBE) за год поднялся с 18-го места на 10-е.

ObjectiveC -> Swift

А Swift наоборот — опустился 13-го места на 15-е.
Почему? — хз.

Не зрозуміло ніфіга, чому така шалена популярність стала в Сі?

Embedded & Automotive

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

VB.NET смотрю внезапно на строчку выше сишарпа. :)

TIOBE показує рейтинг пошуків. Що вони шукають, без найменшої уяви. Так можна накрутити рейтинг зробивши щось, про що ніхто ще не здогадується.
Нічого дивного що VB.NET пішов вверх. Як на ньому нормально писати в теперішніх реаліях я не здогадуюсь, скоріше пошуки зводяться до використання LINQ.

Теперь программы на php могут быть загружены в Go — github.com/z7zmey/php-parser

Если вы имеете ввиду создание транспиллера PHP -> Golang, то мне кажется это невыполнимая задача.
Для начала нужно определиться:
— что делать с нестрогой динамической типизацией PHP?
— что делать с наследованием методов? (в Go нет класического ООП и метод родительской структуры не будет вызывать переопеределенный метод из дочерней)

Ну и главный вопрос зачем?
Если стоит выбор на чем писть Go или PHP, Go выбирают там где нужна многопоточность или большая производительность чем PHP. Транспиллер не решит эти проблемы.

Есть тип interface{}, и через reflect можно добраться до его методов. Зачем?

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

Да про interface{} я не подумал.
Касательно рефлексии — это не лучшее решение если важна скорость.
И прежде чем думать о реализации, стоит задаться парой вопросов:
— есть ли реальная необхдимость портировать код?
— можно ли решить это более легким способом?

К примеру можно использовать github.com/deuill/go-php.

PS: Я был не прав когда сказал что это невыполнимая задача, это мега сложная задача.

Прошла инфа что один из создателей golang начал разработку нового языка на базе scheme, обещает что перформанс на таких же задачах будет как минимум 3x по сравнению с go — за счет более продвинутой системы потоков и ускоренного сборщика мусора.

один из создателей golang начал разработку нового языка на базе scheme

если это таки правда, то будет интересно глянуть его, когда зарелизят. :)

перформанс на таких же задачах будет как минимум 3x по сравнению с go — за счет более продвинутой системы потоков и ускоренного сборщика мусора

Интересные планы. Это значит, что перфоманс вместе с планировщиком потоков и сборщиком мусора будет такой же, как у C++, поскольку перфоманс самого Go примерно так и отличается.

Это про github.com/google/wuffs ? Там нет потоков и сборщика мусора

Почему Go одержал сокрушительную победу над Scala? Потому что он против бесполезных абстракций и монадирующих программистов. тут подробности

Аутсайдер виграв у іншого аутсайдера? Яка «цікава» новина...

madnight.github.io/...​ut/#/pull_requests/2018/1
уже 4ое место на гитхабе, сразу после жавы — хорош аутсайдер

смотря какими пиписьками меряться. Если по PR — то 4ое, хотя pushи вроде как более честно. Хотя по пушам, там вообще shell рванул вверх, вот уж не ожидали :)

То есть dry, solid (даже не в контексте ООП) это приводит к понижению поддерживаемости, а их ликвидация к повышению?
Интересно это выпускник шага или гоит...

А никто не поделится ссылка разницы Scala vs Go. Лично никогда Scala не видел и даже не сидел рядом с программистом, который на ней писал.

Ну это как добираться в Одессу на современной октавии (Go).
Или на боинге (Scala). Только на боинге также надо самому пилотировать (по книжечке выучить боинг за 21 день), самому платить за керосин, итд итп. Пока выучишь как пилотировать боинг не разбившсь на посадке, и насобираешь денег на керосин — на октавии можно весь мир проехать несколько раз. Зато на боинге можно летать...

А может Go это самопилотруемый одноместный самолет :))

самопилотруемый одноместный самолет

Ага, охренеть какой самопилутруемый qph.ec.quoracdn.net/...​c72b058b85774ee804a521165

Да нормальный самолет — я же сказал, что маленький и быстрый. Ну вот нафига вам ташить Min/Max значение всех констант если можно сделать скажем так

const (
MaxUint = ^uint(0)
MinUint = 0
MaxInt = int(MaxUint >> 1)
MinInt = -MaxInt — 1
)

Или обьявить их: golang.org/ref/spec#Numeric_types

Все равно это никак не доказывает, что Go лучше Scala или наоборот. Я так посмотрел на Scala и мне показалось, что если вам хочется скажем дженериков или больше всякого синтаксического сахара, то есть тот же Rust. Вот что я могу сделать в Scala, что не могу в Go или скажем могу сделать значительно быстрее. Опять же, Scala это все-таки интепретируемый язык (хоть он и собирается в байт код), но все равно требует JVM для своего выполнения.

Scala это все-таки интепретируемый язык

А джава тогда что ? А найдите для начала 10 отличий между пхп и джава. Иначе чего вы вообще сюда пришли ?

вам хочется скажем дженериков или больше всякого синтаксического сахара, то есть тот же Rust.

А есть с++, зачем дебелы вообще какието новые языки пр идумуют, тот же Го, если есть с++ ??? И с дженериками и с поинтерами. Я вот тоже не понимаю. Дебилы.

Ну вот нафига вам ташить Min/Max значение всех констант если можно сделать скажем так

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

А джава тогда что ? А найдите для начала 10 отличий между пхп и джава. Иначе чего вы вообще сюда пришли ?

А VB.NET что ? А С# ? Все компилирует — там в байт-код, там MSIL и дальше уже процессится средой выполнения и компируется в машинный код. Я вас удивлю, но все в конечно счет переходит в машинный код :)) Как это все доказывает, что Go хуже или лучше Java ???

Мы уходит в дискуссию кто дурак. Предлагаю написать какие-то две программы на Go и Scala и сравнить.

Как это все доказывает, что Go хуже или лучше Java ???

Дак это вы утверждаете что жвм интерпретируеться.

Предлагаю написать какие-то две программы на Go и Scala и сравнить.

Во первых, Валиалкин уже все написал, читайте тему.

Во вторых, что вы сравнивать собрались ? Количество строк кода ? Количество открытых коннекшенов ?

Go разгромил Java, Kotlin (и, соответственно, Scala) на AWS Lambda — blog.travelex.io/...​o-and-lambda-d30d95290f28 . Сервисы, написанные на Go, обходятся в 10 раз дешевле аналогичных сервисов на Java-подобных языках на AWS Lambda. Go, только вперед!!!!

Сервисы, написанные на Go, обходятся в 10 раз дешевле аналогичных сервисов на Java-подобных языках на AWS Lambda

Звідки такі данні? У статті нічого про вартість розробки і підтримки наче нема.

Да, про стоимость разработки и поддержки там ни слова. Зато в статье приведены графики, сравнивающие стоимость работы идентичных сервисов, написанных на Go и на Kotlin. И там Go экономнее Kotlin’а в 10 раз. Что выгоднее — платить $10k в месяц за сервис на Kotlin’е или $1k в месяц за аналогичный сервис на Go?

$10К теж ніде не бачу за наведеним лінком.

Значит, и зарплаты в $10к никогда не видать :(

Так, на зменшення зп я навряд чи погоджуся.

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

В статье написано, что Go уделал Kotlin как при холодном старте, так и при прогретом сервисе.

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

те кому нравиться страдать идут в Rust

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

так що може люди і виростуть, буде хороша альтернатива c/c++

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

наприклад?
бо поки офіційну книжечку читаю — там такого нема

Если не изменяет память: «UNIX System V ABI» и компанию. В мире системного программирования где царит С, и куда уже какое десятиление ползет C++ это маст. Таже Ада его соблюдает и поэтому вполне альтернатива С во всех смыслах.

попробував нагуглити «rust unix system v abi», знайшов проблеми 2011 року — так, тоді могли бути проблеми, бо rust стабілізувався довго і нудно

тому все, що раніше 2016 року — зараз можна забути, поки не вийшла версія 1
а свіжі дані є? цікаво було б почитати і пощщупати

а свіжі дані є? цікаво було б почитати і пощщупати

По моей информации нет и не планируется. Раздел документации ffi, или как он там назывался, по факту это взаимно-исключающая альтернатива «UNIX System V ABI»

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

як написати однотредний сервер, або де мій select (2)
esr.ibiblio.org/?p=7294

Да всё в порядке, всё идёт своим чередом, выпущена версия 1.9.2, код разрабатывается легко, над ненужными 3-этажными конструкциями как в C++ париться не нужно, никаких особых подводных камней там нет. Так что слухи о скатывании в небытие несколько преувеличены.

Уже и 1.10 на подходе. А с чем связаны очередные похороны Go ?

А вы не смотрите на рейтинги — язык нужно любить не за рейтинг, а за то, насколько вам на нем удобно программировать или нет. Вот на stackoverflow Go третий по Most Loved, Dreaded, and Wanted Languages и что ?

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

Я просто хочу показать, что рейтинги — это всего лишь рейтинги и не более того. Go отличный язык с довольно понятной конкурентной моделью работы. Я хочу еще посмотреть на Rust — может мое мнение изменится, потому что там уже есть generic, атрибуты и все остальное, но пока для своих задача Gо довольно не плохо. Ну и вы правы — Google конечно сильный аргумент :))

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

Непонтяно чем пыхтеров жабаскрипт неустраивает.

так на go только выебщики идут, обычне пхпшники на жабаскрипт поперелезли уже и не жужат

Уже писали 100 раз, что пыхеры — это не целевая аудитория для Go, они проходят мимо. Там концепт кардинально другой: строгая статическая типизация, многопоточность, ну и в целом код компилируемый, который крутится постоянно. Go в основном юзают те, кто раньше писал на C++ и Пайтоне.

Все самые активные го неадекваты что я знаю-
Пехапешники
Про концепции и реали sv я в курсе, но тут на доу своя атмосфера

Я не PHP-шник. Пишу на .NET, немного на Swift. Перешел на Go после того, как посмотрел в сторону Ruby и потому Elixir. Ничего не понравилось и правильно говорит @schwarzlichtbezirk — там для PHP-никого совсем другая концепция.

А як же явасценаристи які з незрозумілих мені причин хочуть вчити Go?

то не js девелоперы, а хипстеры

Откуда вы узнали, что я раньше был пхп-разработчиком? Следите за мной?

бгг нет, с х** бы
с тобой угадал чисто по уровню рассуждений о gc( очень похожих на одного другого чувака на которого я натыкался)
При том что против го я ничего не имею, но твои усилия откровенно не помагают построить не токсичное русскоязычное go lang комунити

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

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

кто раньше не осилил C++ и Пайтон

пофиксил

писали писали такие и думают дай деградирую лет на 40 до 70тых

Go разработан как раз корифеями программирования, которые создали в своё время unix и C. И является естественным развитием лучших практик программирования, даже более того, Go во многом опережает своё время. Здесь очевидно сопоставление с эволюцией в животном мире: сначала животный мир развивался в сторону увеличения массы и размеров особей, появились динозавры, тиранозавры и прочие. Это продолжалось до тех пор, пока изменения внешних факторов окружающей среды не доказало неэффективность такой стратегии. После чего появились млекопитающие, которые на первый взгляд никак не сопоставимы по силе и размерам с динозаврами, но тем не менее стоят на более высокой ступени эволюции.

Что вы там с Валиалкиным курите ?

Мы не курим, а несём тут свет прозрения. Роберт Пайк после того как разработал C 40 лет назад, словно как Моисей водил человечество по пустыне, пока наконец не привёл в землю обетованную, в программирование на Go.

Роберт Пайк ... разработал C 40 лет назад

Неправда.

как Моисей водил человечество по пустыне

Крім UNIX він був співучасником чи автором таких проектів як:
— ОС Plan 9
— OC Inferno
— Мова програмування Limbo
— Мова програмування Sawzal — теж зроблена для гугла
— Графічний термінал Blit
— Текстовий редактор sam
— Текстовий редактор acme
— Співавтор UTF-8
— Співавтор двох книг з Керніганом

привёл в землю обетованную, в программирование на Go

Тільки мало хто це відчув та помітив?

Крім UNIX він був співучасником чи автором таких проектів як:
— ОС Plan 9
— OC Inferno
— Мова програмування Limbo
— Мова програмування Sawzal — теж зроблена для гугла
— Графічний термінал Blit
— Текстовий редактор sam
— Текстовий редактор acme
— Співавтор UTF-8
— Співавтор двох книг з Керніганом

Это только подчёркивает долгий и тернистый путь к Go, как к венцу его творения.

Тільки мало хто це відчув та помітив?

Картины великих мастеров тоже сначала были недооценёнными.

на жабаскрипт поперелезли уже и не жужат

Я так понял пару лет назад жужали, но сейчас это не модно уже :-)

Очевидно же, что будущее за недавно вышедшим go 1.10. В нем полно новых фич, которые никого не оставят равнодушным.

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

То есть ламбды не появились. Дженерики хоть запилили?

Дженерики не нужны. Для особо упоротых есть github.com/ncw/gotemplate . Только почему-то дальше парочки стандартных структур (list, ring, set, heap) и алгоритмов (sort) дело не пошло. Причем необходимость list и ring высосана из пальца:
— вместо list проще и эффективнее использовать стандартный слайс
— ring используется чуть меньше, чем в одном проекте на миллион, где проще написать один раз реализацию этого ring под конкретный тип в 10 строчек.

Set тоже легко заменяется стандартной map[key]struct{}, хотя синтаксический сахарок тут уже поприятнее.

Остается лишь дженерики для heap и sort, которые необходимы лишь в небольшом проценте оптимизированных по скорости программ, где стандартные heap и sort на интерфейсах не подходят из-за накладных расходов на вызов интерфейсных функций.

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

Как по мне вот так пишут упоротые люди.

	people := []struct {
		Name string
		Age  int
	}{
		{"Gopher", 7},
		{"Alice", 55},
		{"Vera", 24},
		{"Bob", 75},
	}

	sort.Slice(people, func(i, j int) bool { return people[i].Age < people[j].Age })
}

Нормальные делают тоже самое вот так

people.Sort(p => p.Age)
Если бы у Go были генерики он бы тоже так мог.

Если очень надо, можно определить метод для слайса:

func (self *[]People) Sort() {
	sort.Slice(self, func(i, j int) bool { return self[i].Age < self[j].Age })
}
и дальше вызывать вообще без параметров: people.Sort(). С чего вдруг на каждый чих должен быть встроенный метод.
Лямбды — это полуфабрикат замыканий

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

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

Кака разница, как это называется? Кому-то нравится название «лямбда», кому-то «замыкание», кому-то «анонимная функция», альтернативно одаренные называют это «лАмбда». Главное, что в Go это есть.

Кака разница, как это называется?

Видимо така разница что как это таки две разные сущности и принципа и функции не?

Главное, что в Go это есть.

Ну х.з. если честно я полагаю сабжевая речь об том что

Лямбды — это полуфабрикат замыканий

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

std::function<int()> l;
{
	int a = 10;
	l = [&]() { return a; };
}
int b = l();

а если?

auto a  = std::make_shared<int>(10);

l = [=](){ return *a;}

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

Это какие-то новые наркотики? На стенках видел только фен в телеге.

В нем полно новых фич
There are no significant changes to the language specification

вот и стагнация наметилась, Go больше не может ничего нового предложить хипстерам

А как же вот это?

the compilers have been updated to allow the index expression x[1.0 << s] where s is an untyped constant
The grammar for method expressions has been updated to relax the syntax to allow any type expression as a receiver

Также go 1.10 может:
— быстрее управляться с миллионом таймеров и/или одновременных подключений — github.com/golang/go/issues/15133
— быстрее конвертировать строки в числа — github.com/golang/go/issues/20557

быстрее конвертировать строки в числа

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

от якби вони конвертували їх в валюту

Валюту в строках зберігати? о_О
Оце взагалі перемога перемог!

топ 10 лучших языков программирования. :) Go как и Swift перспективные языки medium.com/...​earn-in-2018-2d6cbc5ffc2a

а де там Go?
там навіть його назва не згадується...

C на 2м месте, Го на 19м в январьском Tiobe

C успешно эмбедидся в коде на Go, так что низкоуровневое API можно успешно писать на C в рамках Go-проекта.

Вот именно этим и объясняется востребованность C. Врядли кто-нибудь на сегодняшний день начнёт писать с нуля полностью на чистом C какую-нибудь крупную систему. На сегодняшний день C, как и Asm, правильнее поставить в отдельную категорию.

Если на проэкте ликвидировать всех Agile-одаренных то мало какой язык сможет радикально дать фору С. 50% в лучшем случае.

Чистый С это уж слишком на любителя. Но «C с классами» (и шаблонами) ... :)

В Го все, включая С, эмбэдится очень хреново и именно это его убьет.

У Go нету будущего. Go это просто удачный студентческий эксперимент. Скорее всего в будущем разделит судьбу lua.

а що не так із долею Lua?
поцікався — вона доволі популярна серед розробників ігор, на ній пишеться доволі багато внутрішньої логіки

Узкая специализация и нишевость.

ну, це, м’яко кажучи, неправда

Узкая специализация и нишевость

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

Недавно наткнулся ziglang.org, вполне годная альтернатива lua когда зарелизят 1.0
Кстати, основной разраб какой-то геймдев.

відкрив приклади — савсем не пахож на lua

скорше схожий на rust, але rust вже версії 1.27 і набирає обертів

Скорее продвинутый C, всё-таки основная фишка rust это вывод типов и статическая гарантия отсутствия race condition через механизмы владения. Тут этого нет, при этом создаётся впечатление, что код 1:1 можно перевести на C, только выделены наиболее часто встречающиеся шаблоны.

Альтернатива не значит схожесть синтаксисом. Я не писал игр используя луа, не знаю как он встраивается, но подозреваю что он компилируется в байткод или просто скрипты хранятся в ресурсах. CFFI в Zig примерно такое же простое, как в Go, но для Go приходится писать враперы для C++ а-ля [code]#ifdef __cplusplus[/code]. Во-вторых, Zig транслируется в С. Ну и не похож он на Rust от слова вообще, не понимаю где ты там схожесть заметил. Скорее C++ или D.

у будь-якому випадку, це не альтернатива lua

може я погано виразився, але місце lua у цій системі — це власне «високорівневе» написання скріптів — логіки, ботів, плагінів — ніхто на lua числодробілки не пише

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

один з прикладів неігрового використання lua — OpenResty
ну і, думаю, є багато інших, оскільки, по словах людей (я свого досвіду не маю), вона реально легко ембеддиться, вплоть до того, що на ній реалізовують конфіг парсери

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

Насчет числодробилок, на lua+C написан torch7. Выбор, имхо, странный, тот же питон вписался бы лучше, но проект взлетел и это факт.

Но вернемся к Zig, вот что пишет сам автор про мотивацию (предупреждаю я не геймдев и не обладаю знаниями в предметной области):
```
The motivation for this design philosophy is to enable users to write any manner of custom allocator strategy they find necessary, instead of forcing them or even encouraging them into a particular strategy that may not suitable for their needs. For example, Rust seems to encourage a single global allocator strategy, which is not suitable for many usecases such as OS development and high-performance game development. Zig is taking cues from Jai’s stance on allocators, since that language is being developed by a high-performance game designer for the usecase of high-performance games.
```
github.com/...​-Already-CPP,-D,-and-Rust

В Rust есть unsafe, и создатели языка прямым текстом пишут, что unsafe это просто помощи системе вывода типов там, где она это сделать не может. И если возникают ошибки при работе с памятью (SEGFAULT, race condition), то они сконцентрированы в блоках unsafe.

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

А насчет embedding — lua выбирают потому что интерпретатор компилируется в бинарник размером ~300kb. При том lua тьюринг полный. Тут еще можно вспомнить про terralang.org

Go снова отличился!
Google’s DeepMind team has already advanced its AlphaGo AI to dominate Go without human input

Кто еще сомневался что за Go будущее?

Щоб Гугл не забив на нього, як він це робить зі своїми сервісами.

Куда ж забивать, если Go на четвертом месте по популярности на github после Javascript, Python и Java? Скоро догонит и перегонит Java. Что касается недоразумения в виде Javascript, то его можно игнорировать, т.к. его в основном используют люди, далекие от программирования.

На четвертому місці по кількості проектів на github. Варто створити кілька сот тисяч hello world на Basic щоб вивести його в лідери на github.

Go снова в десятке, а Scala — аутсайдер — octoverse.github.com

Go в десятке, а Scala — на 30 месте — www.tiobe.com/tiobe-index :

The Go programming language continues to rise. This month it is at an all time high and enters the top 10. This is an important landmark for the Go programming language, but it also makes you wonder what’s next. Is Go really able to join the big stars in the programming language world and leave languages such as JavaScript and Python behind? We will see. The hipster programming languages Kotlin, Elixir and Hack didn’t progress much this month. Kotlin lost 5 positions, Hack lost 6 positions and Elixir is still not in the top 50 losing also 5 positions.
Go в десятке,

пал ниже delphi в этом году, хипстеры видать набивились этим куском дерьма

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

скорее ктото забашлял им меньше в этом году

На самом деле — tiobe что=то странное почти всегда показывает. Реальность совсем другая (на следующей неделе опубликую опрос по языкам c неожиданностями )

Как сделать бэкенд многопользовательской игры на 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, сидят и спокойно копипастят ссылки, так что примеров нет.

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

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

~:{)

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

Все, приехали — автор node.js перешел на Go — www.mappingthejourney.com/...​n-dahl-creator-of-nodejs

Yeah, I think it’s... for a particular class of application, which is like, if you’re building a server, I can’t imagine using anything other than Go.

I think Node is not the best system to build a massive server web. I would use Go for that. And honestly, that’s the reason why I left Node. It was the realization that: oh, actually, this is not the best server-side system ever.

If you’re building a massively distributed DNS server, I would not choose Node.

RIP node.js. Мы будем помнить о тебе (в страшных снах) :)

Он практически сразу перешел на сторону Go, осознав свою ошибку и какого Франкейнштейна он сотворил :)

Чувак пилит новый рантайм, лишенный недостатков ноды
github.com/denoland/deno

А большая часть его репо — это с++, тс и питон
Так что, можно сказать, никуда он не перешел

бгг, показово — порівну rust та c++ :)
сподіваємось, чим далі доля rust буде збільшуватись...

Доля rust увеличится за счет доли C++, т.к. C++ стал настолько сложным и запутанным, что проще есть кактус с меньшими иголками в виде rust’овых memory ownership/safety и «zero-cost abstractions», которые на самом деле совсем не бесплатные в процессе написания кода. Надеюсь, автор deno скоро осознает свою ошибку и вернется обратно на go.

rust також не проста мова, я б навіть сказав, що на рівні з c++, просто складні фішки розкидані по-іншому, а ще у нього крива навчання набагато крутіша за c++.
Просто rust багато просить спочатку і багато дає взамін потім — це не тільки параноя при роботі з пам’яттю, але й макроси, модулі, виведення типів, зрозумілі повідомлення про помилки, і дуже зручний cargo.

думаю, що rust повторяє шлях Scala

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

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

будуть переписувать гігатонни легаці кода?

Будут создавать гигатонны нового говнокода, в котором хрен разберешься

Спробуйте підвищити свій професійний рівень...

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

цікаво, чи буде тема схожа на
dou.ua/forums/topic/25288
«Чому ми не бачимо збільшення кількості Rust розробників якщо їм платять більше ніж іншим?»

Не будет, т.к. ответ очевиден — среди программистов мало извращенцев с мазохистскими наклонностями, которым бы понравилось решать ребусы с borrow checking и zero cost abstractions в rust. Тут подойдут только приплюснутые, которым нравится разбираться в стострочных ошибках компилятора при неверном использовании stl или boost шаблонов

Я би не казав так,
Все ж Rust дає можливість писати високо абстрактний код, використовуючи ітератори і замикання, з одного боку, і з іншого компілювати це в швидкий код, і це без GC.
Я чим далі читаю документацію по ньому, тим більше він подобається.
А до С++ в мене неприязнь давно, так як те що і як пишуть приплюснуті в ембеддеді, потім приходиться або переписувати на С, або закривати проект.

А якщо люди хоть трохи розібралися із сементикою move, що появилася із С++11, то задовільняти borrow checker, думаю це не буде для них проблемою

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

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

ну чего еще ожидать от Goвношлепов

Кто такие goвношлепы и какое отношение они имеют к с++ с rust?

в том то и дело, что никакого, но амбиций выше крыши

Там дипломатично, без лишнего троллинга намекают, что пора 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. Глядя на них, для всех выбор становится очевидным.

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

Всё так, только некоторые заблудшие овцы всё ещё пишут на скале, в то время как сам автор языка уже выискивает подходы, каким способом побыстрее перейти на 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 сотоны)

лично знаю людей которым нравиться и они это выбрали базовой технологией в 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 миллионов событий в секунду на одном компе. К сожалению, мы не можем отказаться от шардинга на несколько компов, т.к. эти сервисы требуют много оперативной памяти.

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

А если эти сервисы обновляют в режиме реального времени десять миллиардов различных счетчиков? Все еще не бигдата? Тогда с какого числа начинается 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 доо
уж там то они покажут

Сенсация!!! Вышел релиз новой версии 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

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

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

В 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 :-)

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

Я посмотрел эту штуку 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).

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

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

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

Мне вот странно почему 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: 1177 (+420)
Scala: 191 (+50)

Счет 420:50 в пользу Go. Опережение в 8.4 раза. Scala окончательно и бесповоротно осталась на задворках истории.

Scala окончательно и бесповоротно осталась на задворках истории

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

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

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

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.