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

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

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

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

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

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

Конкурент на Rust пока сливает по производительности в 6 раз.

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

Time series churn rate — это сколько старых рядов заменяется на новые в течение суток. В каждом временном ряду содержится много значений (строк) для разных timestamp’ов. Временной ряд идентифицируется его именем плюс набором его лейблов (aka тэги). Смена хотя бы одного лейбла приводит к созданию нового ряда.

Попробуйте сохранить в mariadb на одном компе 10 триллионов (именно триллионов, а не миллиардов) строк со скоростью вставки 1 миллион строк в секунду и потоком запросов на чтение в 100-200 запросов в секунду. Не получается? А у специализированной СУБД для временных рядов — спокойно получается — см. github.com/...​s/wiki/CaseStudies#wixcom

Почему не используете VictoriaMetrics? Она поддерживает прием данных по Influx протоколу, потребляет меньше ресурсов, сжимает лучше данные и предоставляет язык запросов MetricsQL, который основан на PromQL из Prometheus, и который намного лучше подходит для типичных запросов по time series данным. Кроме этого, у VictoriaMetrics есть бесплатная кластерная версия с открытыми исходниками. См. github.com/...​iaMetrics/VictoriaMetrics

Good luck

Легко — вынести данные и лямбды во внешний массив/список. И вместо этой простыни будет короткий цикл.

Спасибо за интересный вариант. Несколько вопросов:

1) Сколько строк удалится и добавится в коммите, меняющем первый вариант на второй?
2) Как изменится сложность понимания получившегося кода?
3) Как изменится сложность внесения изменений в получившийся код?

Мне казалось, что это очевидно даже для студента, ан нет...
1) если нужно изменить — то меняешь _один_ раз, а не _семь_
2) исключает тупые баги, типа поменял в 6 местах, а в одном забыл
3) намного проще смотреть pull-реквесты. Например, когда кто-то поменял, скажем в 3 местах, а остальные 4 провтыкал. И чтобы понять, что тут провтык, надо искать все вхождения...
4) в большинстве IDE легко получаешь список _ссылок_ на эту константу, что гораздо удобнее полнотекстового поиска, в котором будут и комментарии, и документация

Спасибо за пояснения. Есть несколько вопросов по ним:

1) Как изменится сложность понимания кода, где вместо строковых литералов используются именованные константы, во время его изучения на github, gitlab или подобных инструментах? Например, что легче понять:

case "/api/v1/write": ...

Или

case constants.PrometheusWriteApiPath: ...

2) Вспомните последний раз, когда вам приходилось менять значение строковых литералов, спрятанных за именованными константами. Как часто приходилось это делать?
3) Как узнать, что в pull request’е используется корректная именованная константа, которая давно определена где-то в другом месте, которое не было затронуто данным pull request’ом?
4) Как определить, что pull request не создает новую именованную константу для уже существующего строкового литерала?
5) Насколько сложно вам было отыскать все вхождения строкового литерала «/api/v1/write» через поиск на github? Насколько изменилась бы сложность поиска по имени константы?

функция длиной в 360 строк — что это как не классический гуанокод?)

Предложите лучший способ реализовать эту функцию.

там же море select-ов по литералам вместо констант

Объясните, чем селекты по константам лучше селектов по строковым литералам?

Можете даже не верить моему 20 летнему опыту....

У вас 20-летний опыт работы с Go или Rust?

Тогда придется перейти на С или сделать форк Go без дженериков )

Когда я открыл code review, там было больше 40 страниц, из которых куча кода выглядело как библиотечный

Может, это был код сторонних зависимостей из папки vendor? К сожалению, код сторонних зависимостей редко ревьювают :(

Зато его можно успешно скопипастить.

Не понял — зачем копипастить говнокод из Rust, C++, Scala и Java в программу, написанную на Go?

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

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

Или Го не умеет в версии зависимостей?

Умеет — см. github.com/...​etrics/blob/master/go.mod

А еще можно пойти и самому пофиксить баг в зависимости и заапстримить его. Гоферы не умеют в опенсорс?

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

Это одно из главных преимуществ Go — код на Go не только легко писать, но и легко читать, т.к. в нем пока нет всякого матана и zero-cost abstractions, как в Scala, C++ или Rust. К сожалению, это может измениться через пару лет, если в Go добавят дженерики — blog.golang.org/generics-next-step . Такое развитие событий меня не очень радует :(

А как потом этот гуанокод саппортить?

Прикол в том, что на Go невозможно написать говнокод, в отличие от Rust, C++, Scala и Java.

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

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

При таком подходе эти баги придется фиксить руками.

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

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

Куча бессмысленной херни — это 99% кода из всяких абстракций на Rust, C++, Scala и Java. Что касается Go, то там 99% кода имеет ясное практическое назначение.