Прийшов час осідлати справжнього Буцефала🏇🏻Приборкай норовливого коня разом з Newxel🏇🏻Умови на сайті
×Закрыть

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

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

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

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

LinkedIn

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

По прошествии пяти лет, Go оказался востребованным и полезным языком, а Scala так и осталась уделом душных фриков.

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

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

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

Самый важный плюс Go это его читаемость и единый стиль. Когда открываешь любой проект на гитхабе написанный на голанге, его ОЧЕНЬ легко понять и вьехать что там происходит, и уже через денек можно контрибьютат. В то время как каждый проект на Scala, да и на Java, надо сидеть долго и упорно разибраться что там происходит и какой там код-стайл. Особенно в скалке, где на каждом маломальски большом проекте — свой субдиалект языка. Отсюда и продуктивность Go, программист концентрируется на задаче, а не думает как бы ему написать тот или иной кусок кода.

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

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

Servo — браузерный движок от Mozilla, частично написанный на Rust — выкинули на помойку — см. www.linuxfoundation.org/...​sted-at-linux-foundation . Rust сдает и без того слабые позиции, в то время как Go уверенно движется к званию самого распространенного языка программирования.

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

То же самое касается самого Rust

Мозила передает проекты, которые она начала, в комьюнити

Ну то есть, сливает другими словами.

Rust чувствует себя прекрасно. На подходе уже const generics

Mozilla вже показала що може робити хороші проекти, JavaScript-ом й зараз активно користуються (розробник Netscape Communications Corporation, Mozilla Foundation), і Rust стане популярним коли звикнуть

Mozilla вже показала що може робити хороші проекти, JavaScript-ом й зараз активно користуються

js — это хороший проект? Что, серьёзно? Его еле из говна за уши вытянули последними стандартами.

Валялкин, где обещанное виски?

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

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

Скажите еще, что не пользовались docker’ом c kubernetes (которые написаны на Go) в 2018 году :) Так что виски от вас.

Скажите еще, что не пользовались docker’ом c kubernetes (которые написаны на Go) в 2018 году :) Так что виски от вас.

Что не пользовался, я уже год назад ответил. И повторюсь: у нас были другие средства (vagrant, virtualbox, lxc).

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

По прошествии пяти лет, Go оказался востребованным и полезным языком, а Scala так и осталась уделом душных фриков.

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

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

За живе і до сліз

Найбільш оплачуваними спеціалістами є Scala та Go-розробники у Києві — їхня зарплата становить $4000.

DOU, літо 2020 року

Цілком можливо що Golang дійсно стане мовою для швидкої розробки і будуть прирівнювати до PHP чи JavaScript.

Але зараз на Golang переходять спеціалісти із-за цікавих проектів з високим rps, переходять компетентні, а слабокомпетентні ймовірніше рідше змінюють технології з якими працюють.

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

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

Какую отрасль представляет Scala? Отрасль монадирующих матанщиков-теоретиков с отрицательным коммерческим потенциалом?

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

Навалом кода на Scala в финансах компаниях в Лондоне

Странно, что эти компании до сих пор не обанкротились

В twitter и в linkedin уже 1000 раз пожалели, что связались со scala — см. en.m.wikipedia.org/...​mming_language)#Criticism . Вполне возможно, из-за этого они никак не могут выйти в прибыль в течение последних 10 лет.

Невже Скала складна навіть для інженірів ФААНГ?

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

плз, можешь детальнее прокомментировать этот коммент?
dou.ua/...​/?from=fpcomments#1989882

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

из сырых окопов Скалы виднее, чем со стороны ))

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

бетонная стена

яхту примерно так и назвали — скалА.

youtu.be/wj-V-F9dfrE?t=23

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

а стОит ли оно реально того, чтобы из неё высекать энтепрайз?

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

твитер продолжает активно нанимать людей на скалу

А что им остается делать? Кто-то же должен заниматься поддержкой говно-Scala-кода.

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

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

твитер продолжает активно нанимать людей на скалу

вероятно, у них специфика продукта (и доходы) позволяют юзать ФП

Доходы twitter явно свидетельствуют о правильном выборе Scala :) Operating income за три квартала 2020 года — минус 84 миллиона долларов. finance.yahoo.com/...​te/TWTR/financials?p=TWTR .

Да просто твиттер, сам по себе, нафиг никому уже не уперся. Имхо конечно, но твиттер мчится к закату.

Зараз шукають гофера в Києві на проект «конкурент Twitter», в LinkedIn активно гоферам розсилають пропозиції

Использовал скалу пару лет, на Go пишу этот год, Go таки гораздо проще и легче. Но для нагрузочного тестирования Scala все годится, потому что Gatling. Хотя там, конечно, глубоко вникать не надо.

Новость мирового масштаба: самая быстрая база данных для временных рядов — VictoriaMetrics — написана на Go! Ждем появления конкурентов на Scala и Rust.

InffluxDB IOx на Rust работает в 6 раз медленне, чем VictoriaMetrics на Go — medium.com/...​toriametrics-e590f847935b

А ви швидко відреагували, вітаю з найшвидшою TSDB, плануєш додавати в статтю на вікіпедії Time series database?

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

Припущення що редактори мають відношення до InfluxDB або іншої БД, тому й маніпулюють

Така ситуація для Вікіпедії трапляється часто в політичних темах, в ІТ мабуть рідкість але буду вважати за прецедент

Буде ефективніше якщо створиш тему на DOU, щоб допомогли додати VictoriaMetrics до статті Time series database

А через рік-два можна буде написати нове порівняння

Желательно, чтобы бенчмарк делал не сам автор)

Так в чем проблема? Проведите свой бенчмарк и опубликуйте результаты!

будет более подходящий юзкейс — сделаю

Не слышал о VictoriaMetrics, взял на заметку

Теперь ждем новости, что ее переписывают на Rust))
/* пошел за попкорном */

Я тут посмотрел твой github.com/VictoriaMetrics/fastcache, и вот интересен вопрос. Если надо кэшировать контент файлов вместе с их MIME-типом, и что-нибудь ещё, как ты это делаешь? И ещё по какому принципу удаляются записи из кэша — самые старые, или самые редко используемые, или как-то ещё?

Если надо кэшировать контент файлов вместе с их MIME-типом, и что-нибудь ещё, как ты это делаешь?

Пишу функции Marshal и Unmarshal для составных типов и записываю в кэш сериализованный байт слайс.

по какому принципу удаляются записи из кэша — самые старые, или самые редко используемые, или как-то ещё?

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

Пишу функции Marshal и Unmarshal

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

Данные хранятся в циклическом буфере.

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

в этом случае реаллоцируется лишний слайс размером как минимум с файл + данные

Слайс можно переиспользовать при следующей сигнатуре функции:

// Marshal appends marshaled data to dst and returns the resulting byte slice.
func Marshal(dst []byte) []byte
просто бывают такие кейсы, что частота использования разных записей сильно отличается

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

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

Вернёмся опять-таки к кэшу :)

Вот у тебя общая идея основана на bigcache, а там в апи есть Append, которая решает вышеуказанную задачу эффективным путём. Кроме того, там есть итератор, чтоб просмотреть содержимое кэша, хотябы по ключам, а у тебя его почему-то нет. Зато есть запись каша в файл, сугубо частная задача.

Насчёт dst []byte. В случае если читать серию записей подряд в одной горутине, то такой подход вполне оправдан. Но если записи читаются из кэша по одной, тогда держать такие буфера — это неэффективное расходование памяти, которое может привести к свапу страниц в файл подкачки.

Если в fastcache чего-то нет, значит, оно не понадобилось в VictoriaMetrics. Зачем добавлять функциональность, которую ты не используешь? Ведь потом ее не выпилишь (т.к. пользователи будут недовольны) и придется заниматься ее поддержкой.

Насчет dst []byte — забыл дописать еще одно требование для кэша внутри вм — размер сохраняемых в него значений ограничен 64кб. С течением времени в некоторых местах потребовалось хранить более длинные значения, поэтому была добавлена надстройка (костыль) для этого.

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

Для решения этой проблемы есть sync.Pool .

Цікава таблиця
«Do you plan to adopt or migrate to other languages in the next 12 months?»
Scala — аутсайдер...
Ось так вимірюється справжній рейтинг вподобань;))

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

Крім переходу, ще мається на увазі й опановування нових... додаткого до основного стеку...

котлин как раз не удивляет
удивляет, что кто-то еще предпочитает java

„For which platforms do you develop?”

А де фулстьок?!

„Which platforms do you target with your projects?”

Ідея з відсотками взята з російських виборів?

Тим, хто дуже чекав... покращення)))

The Next Step for Generics
blog.golang.org/generics-next-step

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

Ті, хто так висловлюватиметься — не є православним)) гофером...;))

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

Человечества. За всю историю человечества.

кстати в java в свое время хейтили введение стрим апи, мол это следование моде и хайповым тенденциям.

В джава ввели Stream API? Збс, надо заценить!

А що то за історія з джавистами і лямбдами? Чому не могли вжитися?

Продолжение той же ветки:
— I’ve never had such feedback. All devs who discover this fall crazy in love with it and don’t stop (over)using it
— Yes, that’s what it looks like AFTER we make a big change. Before, when we’re talking about making a big change, we get an army of angry villagers with pitchforks and torches, with dire predictions of „you’re going to destroy Java.” It was very much this way with lambdas.

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

Contracts — Draft Design: July 31, 2019 (...this version of the design draft is similar to the one presented on August 27, 2018...)
Type Parameters — Draft Design: June 16, 2020

«А там или ишак помрет, или падишах...» :)

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

Гоубои мометом перекрасились, теперь генерики это наше все :)

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

Становится всё меньше аргументации для критики.

Хай запостять на Доу. Тот докинуть критики так, що концепт не вийде ніколи.

go.googlesource.com/...​2draft-type-parameters.md
Вот новая версия драфта, где концепт генериков на контрактах изменён на концепт генериков на интерфейсах. То есть, в целом этот концепт хорошо интегрируется и дополняет существующий концепт эмуляции генериков с работой на интерфейсах и утиной типизации.

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

Пока @Aliaksandr Valialkin молчит, сам подброшу: www.youtube.com/watch?v=Dq0WFigax_c ....

... whereas generics in Java are defined via erasure, in Go we use monomorphisation

думаю, він у прострації, бо у го з’явився страшний матан

Го комюніті має тримати оборону, і спалювати всіх невірних хто тягне страшні диявольські речі в Го!

Самый важный плюс Go это его читаемость и единый стиль. Когда открываешь любой проект на гитхабе написанный на голанге, его ОЧЕНЬ легко понять и вьехать что там происходит, и уже через денек можно контрибьютат. В то время как каждый проект на Scala, да и на Java, надо сидеть долго и упорно разибраться что там происходит и какой там код-стайл. Особенно в скалке, где на каждом маломальски большом проекте — свой субдиалект языка. Отсюда и продуктивность Go, программист концентрируется на задаче, а не думает как бы ему написать тот или иной кусок кода.

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

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

Ну... Это скорее зависит от сложности самого проекта. Попробуй быстро разобраться в коде Ethereum, Tendermint или Ethermint. Тут скорее вопрос в том, что обычно Go выбирают для решения более простых задач, поэтому и разбираться в них проще.

Якщо дивитись далі то Scala-розробники мають вищу винагороду ніж Golang-розробники

What Languages Are Associated with the Highest Salaries Worldwide?:

  • Scala $150k
  • Golang $140k

Вибирай що більше подобається:

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

На 7% больше? Это может быть в рамках погрешости опроса.

Там є цікавіші порівняння:

  • Perl $130k
  • Bash/Shell/PowerShell $120k
  • C# $110k
  • HTML/CSS $110k
  • PHP $100k

Вброс не засчитан, поскольку то статья для девочек (hr если код пишут и строят инфраструктуру):

If programmer does nothing to exploit multi-coring in her program, both golang and Node.js are single-threaded. However, if programmer does want to go multicore, she has to use goroutines (in Golang) , or cluster module (in Node).
both golang and Node.js are single-threaded

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

nodejs.org/...​ont-block-the-event-loop

Node.js uses a small number of threads to handle many clients

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

опять эти сектанты, свидетели языка без языка

Ви про яких саме сектантів? І тяжко зрозуміти про що ви

язык без языка

Він зі святої інквізиції. Шукає фанатиків на вогнище.

В то время, как размеры скомпилированных программ на java продолжают расти семимильными шагами (java-программисты считают нормальным иметь jar-ники в сотни мегабайт), скомпилированные программы на go в версии 1.15 будут занимать до 30% меньше места — mobile.twitter.com/...​tatus/1256348714198654976 . Это еще сильнее увеличит и без того огромный разрыв (10 и более раз) между scala (java, cotlin) и go в размерах бинарников, docker-контейнеров и объеме памяти, используемой работающими программами.

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

В итоге получая конечный native binary или докер-образ в мегабайты, не потеряв преимуществ JVM

Это как-то не православно, docker написан на Go, вам нужно замутить какое-то альтернативное решение не потеряв преимуществ JVM.

В go все работает искаропки, а в scala (java, cotlin) нужны танцы с бубном вроде тех, что вы перечислили в своем сообщении, чтобы хоть как-то работала программа.

Но вы продолжайте приходить и сравнивать golang binary, делающий в консоль фыр-фыр-фыр с JVM-based-приложением энтерпрайз-уровня, с сотнями библиотек внутри и тысячами человеко-часов разработки

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

Наверное, потому, что «стомегабайтные зависимости» — это нечто более сложное, чем условные 100 строчек кода?

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

Наверное, потому, что «стомегабайтные зависимости» — это нечто более сложное, чем условные 100 строчек кода?

Да, зависимости обычно более сложные, но обычно проще написать 100 строчек кода, чем тянуть зависимость. К сожалению, программисты предпочитают тянуть 100-мб зависимость :(

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

когда вы работаете в одиночку.

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

К сожалению, программисты предпочитают тянуть 100-мб зависимость :(

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

тебе 100 строчек в других ЯП религия не позволяет копипастить? или это исключительно уникальная фича го-шников?

тебе 100 строчек в других ЯП религия не позволяет копипастить? или это исключительно уникальная фича го-шников?

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

ты только мокнул го в го и написал

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

одним постом. хз о чем тут спорить...

ты только мокнул го в го

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

Мало кто знает, что Go настолько самодостаточен, что компилятор и рантайм Go написаны на Go — см. github.com/golang/go . Это вам не scala с java, написанные на Си.

Не було нічого, і був лише Го. І зробив Го компілятор Го і рантайм Го. І побачив Го що це добре.

В go все работает искаропки, а

что там уже reduce/filter можно сделать даже из коробки без рефлексии и бойлерплейта?

Ни разу не видел кода на Go, который бы сильно выиграл в читабельности или поддерживаемости, если бы в Go была поддержка reduce/filter.

для „hello world” можно и без reduce/filter, да

Первые 3 страницы, там почти ни одного потенциального продукта который мог бы быть написан на java или scala, мб кроме баз данных. какие-то прокси и системные утилиты которые писались бы на С. Не понимаю к чему сравнение с scala или java.

Что и показывает ту нишу, где применение Go вполне оправдано. Но некоторые фанаты Go не унимаются и при каждом удобном случае пытаются пиарить Go как one language to rule them all.

Я, если что, недавно сам маленький http сервер делал на go, потому что функционал там примитивный, а скорость и потребление памяти важны. Так что, меня сложно отнести к хейтерам языка — скорее, я сторонник подхода «каждой задаче — свой инструмент»

потому что Go — это «bash» для написания микросервисов. ну может быть иногда и макро- :)

Я так понимаю потому Пайк и сотоварищи сопротивляются введению дженериков.
Зачем в bash’е дженерики? Ах понадобились — так значит вам нужен другой инструмент. либо вы не умеете проектировать системы как — микросервисные системы.

Первые 3 страницы, там почти ни одного потенциального продукта который мог бы быть написан на java или scala

Это еще раз наглядно показывает ущербность scala и java по сравнению с великим Go!

Так нечего сравнивать. Видимо твое го несравнимое.

Більшість гоферів дивляться та порівнюють з Rust, ще пару років тому вже був такий тренд Kyiv Go Meetup January 2018

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

Вот хорошая цитата про ООП в java и scala:

You wanted a banana but what you got was a gorilla holding the banana and the entire jungle

Давай, расскажи нам, как эту проблему решает «расово верное» ООП в golang?

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

Ctrl+C-Ctrl+V oriented development.

Не согласен, development удобнее вести методом Ctrl+Intert-Shift+Insert.

Тим часом що на тіобі що на pypl javascript має або 0% росту, або невеликий мінус. Хайп скінчився, можна видихати? Ще цікаво що по відсоткам share джава в рази вище за джаваскрипт, тобто щоб джс обійшов джаву, тепер джава має конкретно просідати, а не на 2% в рік а сильно більше. На тіобе он джава навіть приріст отримала 2.9%.

Напевно добре знати декілька різних мов, щоб адекватно оцінювати ситуацію і не бути фанатиком.

Кроме Go не нужно ничего знать. Там даже в версии 1.14 добавили принудительное переключение между горутинами — см. medium.com/...​s-preemption-b5194227371c . Это уменьшает максимальные задержки в garbage collector’е до 10мс, что в 20 раз лучше, чем в Java.

P.s. Средние задержки в гошном gc и так были в районе десятка микросекунд еще с древних времен, что в 1000 раз лучше, чем в java.

Кроме Go не нужно ничего знать

Амінь.

P.s. Средние задержки в гошном gc и так были в районе десятка микросекунд еще с древних времен, что в 1000 раз лучше, чем в java.

Це прекрасно, але так пхпшників не загітувати. Краще про те що на го пишеться в 10 разів швидше.

Я раніше розробляв на PHP, зараз на Go, підтверджую розробляти на Go швидше, а в скільки разів це вже індивідуально

Там даже в версии 1.14 добавили принудительное переключение между горутинами

Ага, при этом внеся так незаметненько огромный breaking change:

A consequence of the implementation of preemption is that on Unix systems, including Linux and macOS systems, programs built with Go 1.14 will receive more signals than programs built with earlier releases. This means that programs that use packages like syscall or golang.org/x/sys/unix will see more slow system calls fail with EINTR errors. Those programs will have to handle those errors in some way, most likely looping to try the system call again.

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

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

Зато подобные фортели очень наглядно показывают отношение авторов golang к обратной совместимости. Нормальные люди сделали бы эту возможность опциональной, сознательно включаемой каким-нибудь флагом при компиляции. И вот тогда уже было бы логично ожидать от разработчика, сознательно включившего этот флаг, правильной обработки EINTR везде, где только можно.

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

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

А что, есть какая-то потребность пересаживаться с венды на линукс? Зачем?

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

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

оценил как сложный, а значит не мейнстримовый.

Scala это как
ru.wikipedia.org/wiki/Ифкуиль
см Пример грамматической конструкции

ну или «С++» для JVM

потом уже были истории с поломками совместимости

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

Основной аргумент: количество проектов на GitHub с более 1000 звездочек:

Вывод очевиден — Scala мертва, учите Go.

Go — 1407 звезд

за 5 лет так и не обошел java и даже близко не приблизился к js

JavaScript — 5,084 repository results
Java — 2,371 repository results

кто-то тут даже коньяк на это ставил — походу темпы роста го такие же медленные, как и язык. so sad

за 5 лет так и не обошел java и даже близко не приблизился к js

Так java за 5 лет не только что не приблизилась к js, но даже наоборот только отдаляется, с сокращением объёма разработки на джаве. Если аппроксимировать эту тенденцию, Go в дальнейшем обгонит java даже без развития языка и комьюнити.

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

Чего ж ещё не обогнал?

Зато за последние 5 лет Go обогнал следующие языки программирования по количеству популярных проектов на GitHub: C++, PHP, C, ObjectiveC, Ruby, TypeScript.

Go уже обогнал Java по количеству активных популярных проектов в текущем месяце: 336 проектов на Go против 332 проекта на Java.

-В джаве есть уже лямбды, оптионал, добавили вары итд. Ейвсе еще очень далеко до всех фишек скалы, но некоторые базовые вещи можна пилить.
-В джаве, как по мне уже устоявшийся костяк набора либ, фреимворков, и альтернатив фреимворков, более мение подруженных между собою. В скале какойто полный зоопарк всего и вся, плохосовместимого, и с кучей депенденси на непонятно что.
-разные версии компилятора, плохо совместимого между собой, что в купе с предедущим пунктом доставляет.
-sbt — no comments.
-в скале можна писать кучей разных стилей, используя разные подходы и наборы фичь языка. Еслиодин проект пишеться в разных стилях — черт потом ногу сломит. Для успеха требуеться оч жосские код конвеншены, суровый ревью итд, и даже оно — не помагает :-)
-не осиляторство. Народ тут не в состоянии разобраться с парочкой простых ооп паттернов, и кричит что ооп не нужно. Но на деле фп на порядок сложнее ооп. Куда проще кричать что Го крутой языг итд.

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

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

нафіг там наслідувати єнота від собаки з мавпою.

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

Вертайся в сім’ю, в той топік.

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

Причём тут ФП vs ООП, Go сочетает все подходы, а не фокусируется только на каком-то одном. Поскольку при разработке языка учтён практический опыт программирования на других языках, это результат эволюционного развития. Тем более, что разработан язык не какими-то 23-летними синьорами, а людьми имеющими в этом опыт. В языке убрали всё лишнее, и собрали все сливки.

В языке убрали всё лишнее

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

В нас в проекті є мікросервіс для збереження статистики, який отримує дані через gRPC, зберігає в slice-буфери та пачками по 10 000 зберігає в ClickHouse, написаний на Go і ось ці всі slice-буфери під кожну proto-структуру це copy-paste

Copy-paste для contains чи інших простих алгоритмів це прикро, але й рідко таке пишу, я б з радістю перейшов на Rust, але вже звик що на Go швидко проходять тести та build проекту

Відповідно є можливість розробляти малими ітераціями та швидким запуском тестів, і інколи робити copy-paste, що для мене переважає над довгим запуском тестів який в Rust чи C#

Причём тут ФП vs ООП, Go сочетает все подходы

В Go уже завезли каррирование без костылей? Дженерики туда тоже всё никак не завезут, кстати, а без них даже элементарные map / filter / reduce требуют извращений с кодогенерацией под каждый тип, на котором нужно реализовать эти операции.

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

о дааа

моя улюблена історія, як Пол Грем наваяв Yahoo Stores на Lisp
а потім то треба було саппортити, коли їх вже не було, та й переписали то все нахрін на C++

а потім то треба було саппортити, коли їх вже не було, та й переписали то все нахрін на C++

То просто купили неосилятори.

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

Прошу помочь окончательно развеять мимолетное, так ни во что не вылившееся и уже ни к чему не обязывающее очарование, указав на 1-3 основных аргументов почему этот ЯП «уже не торт». :)

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

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

blog.usejournal.com/...​reads-part-2-52611217340a

Go: 732.204 total requests over 5 min, 2,439.9 r/s
Node (cluster module): 1,116,477 total requests over 5 min, 3,720.65 r/s
Node (worker threads): 1,105,513 total requests over 5 min, 3,683.90 r/s

Я считаю, топик можно закрывать.

ключевая фраза всей статьи там в самом конце:

I’d like to point out that I am not a professional benchmarker

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

Та ну... То треба бути «професійним» задротом, щоб комусь щось доводити... ))))

Т.е. чтоб показать, что Го не сосет у ноды нещадно, вам надо какой-то специальный эксперт по бенчмаркам? :)

Суть сравнения сводится к скорости интерпретации V8 против исполнения откомпиленного Go-кода. Что ещё там сравнивать?

После того как откомпиленный Go слился интерпретатору JavaScript, я не знаю что еще можно сравнивать :)

в инете много тестов
результат этого — нетипичный для Go vs Node.js

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

Все просто, Node.js зміг розпізнати патерни і оптимізувати код і алгоритми, а Go як побачив так і виконав, і є відмінності в коді

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

Go хейтер не смог даже нормальных тестов написать. Допустил ошибку в bubble sort и не выделил память под возвращаемые массивы. В итоге бенчмарк показал, что js умеет немного быстрее ресайзить массивы по сравнению с Go. Также стоит обратить внимание на экпоненциально возрастающую сложность кода в nodejs с увеличением его размеров. И это мы еще не добрались до ахилессовой пяты nodejs — callback hell’а при работе с БД и сетью.

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

И это мы еще не добрались до ахилессовой пяты nodejs — callback hell’а при работе с БД и сетью.

Да, еще есть люди, которые не раздуплились как готовить async/await в ноде, но это прийдет со временем.

Боюсь, что процент людей, способных правильно использовать async/await, примерно равен проценту людей, способных правильно использовать callback’и и писать на Rust. Т.е. он стремится к нулю, в отличие от 100% людей, которые умеют правильно использовать горутины в Go.

journal.stuffwithstuff.com/...​t-color-is-your-function

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

посмотрел код, никак не оформлен толком и сам http server неправильно заюзан, чтоб реквесты конкуррентно обрабатывать, формошлепы с ноды не осилили нормально бенчмарк написать по концепциям Го

Бачу, є люд, яким абичим помірятися... вдавляться за 10мс )))

Так між ними багато спільного, видимість на рівні пакету, вбудовані тести та автоформатування коду, передача error та panic, відсутність OOP

Кто не читал, общая суть в том, что у чуваков внезапно возникла попаболь из-за работы GC в Go. К слову, та же попоболь у них возникла бы и в любом другом языке, где есть GC, и всё равно как ни крути, от сборки мусора не избавиться. И поэтому они кардинально решили проблему с GC путём перехода на Rust. Ну а то, что там нет встроенной многопоточности — ну и что, не возвращаться же обратно на Go.

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

ребята уточнили, что аллоцировали минимально и размер heap у них почти не менялся в рантайме, а в go gc такой тупой, что каждый 2 минуты сканил весь хип и вешал апишку и это нельзя было никак поменять. В других языках Gc тригерит загрузка памяти, поэтому такой проблемы бы не было.

Я тут посмотрел один сервис, которые без особой нагрузки работает ровно 2 дня, совокупное время работы GC за всю сессию составляет около 37 миллисекунд — это всё что требуется для 1460 таких сканов.

Дай угадаю — ты посмотрел это для stateless сервиса vs statefull описанный в статье. :) статью наверняка тоже внимательно не читал.

Ребята еще уточнили, что успользовали древнюю версию Go, где GC был не так хорош, но забыли уточнить, чем им не подошла последняя версия Go с намного лучшим GC. В это же время им ничто не помешало использовать bleeding edge версию Rust в проде, которая даже еще не релизнулась.

medium.com/...​6ecbd62a4b/responses/show
Якщо подивитись уважніше коментарі, то вони мова про go1.9 трьох річної давнини, баг з смітников виправили/

в ленте не могу коментить, поэтому оставлю здесь
imgur.com/a/03KQGOY

Вставлю свои 5 копеек по поводу годных языков программирования
Как по мне для сервера самый крутой выбор на сегодня «с запасом» — Kotlin, Python ну Node.JS для микросервисов
www.youtube.com/watch?v=ShX4KFvhiX0

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

Валялкин, когда обещанное отдадите?

Или адепты «вяликого» Go на самом деле настолько нищие, что не могут одну бутылку купить?

Приходь на Go мітап, там таке питання задасте

Приходь
задасте

Щось тут не стикається.

Приходь на Go мітап

Побачу хоч одну цікаву доповідь в планах — подумаю.
Поки що шансів замало.

Самое удивительное, что у Dart почему-то получился большой рост, несмотря на то, что Google на него положила болт, и не встроила виртуальную машину в chrome. Ну а Go уже на 4-м месте, что вполне ожидаемый результат.

А потім дивимося на вакансії, а там дуля. Зате зірок багато в гітхабі!

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

Самое удивительное, что у Dart почему-то получился большой рост

тому що flutter

несмотря на то, что Google на него положила болт

Если бы гугл на него положила болт, то не было бы Dart 2 и Flutter’а, а виртуальная машина дарта в хроме ИМХО нафиг не нужна, ибо зачем, если дарт вполне компилиться в джаваскрипт.

а виртуальная машина дарта в хроме ИМХО нафиг не нужна, ибо зачем, если дарт вполне компилиться в джаваскрипт

Так смысл Дарта изначально был в виртуальной машине. А если его компилить в js, то лучше сразу просто писать на js. Или на ts.

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

Дейсвитейльно)) А то понаписывают разных языков, компилируемых в js — github.com/...​guages-that-compile-to-JS — вместо того, чтобы сразу писать на js)

Или на ts.

Так ts тоже лишний получается, ибо «лучше сразу писать на js». :-)

github.com/...​guages-that-compile-to-JS

Я в этом списке даже Go нашёл. Причём самый впечатляющий вариант — TARDISgo, компилящий golang в Haxe, а с него в js. Впрочем, с Haxe можно отомпилить ещё в C++ и php например, не только в js, а потом другими тулзами обратно в Go. И так по кругу.

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