Язык программирования Crystal обзавёлся интерактивным интерпретатором

Как-то я смотрел видосики от разработчика из GitLab и он поделился как там борются с утечками памяти, и сейчас нашел статью про это: https://habr.com/ru/company/Voximplant/blog/270227/

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

Что еще бросается в глаза при изучении этого лога: рабочий процесс обработал всего 23 запроса, прежде чем завершиться из-за утечек памяти. На данный момент это является нормой для gitlab.com

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

это прекрасная новость, если оно и правда работает, у ruby внезапно появился compile-time, и даже метапрограммирование можно покрыть типами. Если ещё и generic завезли. Может ещё и библиотеки покрыли типами и можно точно знать что откуда возвращается. Но мне слабо верится что это впринципе возможно, скорее всего легкий костыль для примитивных случаев. В таком случае сравнивать с TS некорректно, наверное, с PHP более правильно (не знаю php, но там тоже аннотации добавили).

Стандартная библиотека почти вся покрыта типами и это уже активно используется для анализа и подсказок некоторыми IDE, я уже упоминал RubyMine от JetBrains.

Можете посмотреть с картинками тут: https://www.jetbrains.com/help/ruby/rbs.html#rbs_type_signatures

Сторонние библиотеки тоже потихоньку подтягиваются, благо что под это дело запилили и автоматический анализатор типов под названием TypeProf. Можно натравить его на проект или файл и он сам сгенерирует структуру и сигнатуры и 80% всех аннотаций типов, а всё что пока не может проанализировать автоматически – можно дописать руками. Это очень удобно и можно писать 100% покрытый типами код.

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

«Если мы добавим типы в язык, то их сложно будет убрать их из него в будущем, когда вывод типов будет полностью автоматическим» (с) Matz. Т.е. светлые идеалы, которыми грезили учёные мужи в 80-х, никуда не делись, просто отложились на неопределённый срок в виду того, что реализация забуксовала :)

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

Ну и вишенкой на торте может стать то, что значительная часть core-team это японцы и они стоят немного в сторонке от всей этой Сancel culture и sjw-вакханалии, которая на сегодняшний день атаковала общественную жизнь в США и Западной Европе, и с которыми, как мне кажется, уже перегибают палку, и в рубишном комьюнити всё это меньше чувствуется и влияет на разработчиков.

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

Если не нравится Сбер, как пример, то «VK Работа» (вроде как с их собственных слов, третий по количеству пользователей сервис по поиску работы в РФ с интеграцией со всеми остальными сервисами VK и mail.ru) полтора года назад вышел и стремительно набирает популярность и в качестве основы для они бэка выбрали микросервисы на Ruby.

Как-то я смотрел видосики от разработчика из GitLab и он поделился как там борются с утечками памяти, и сейчас нашел статью про это: https://habr.com/ru/company/Voximplant/blog/270227/

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

Это было давно и сейчас Unicorn никто не использует. Эта проблема с распуханием не столько в Ruby VM была, а сколько в реализации данного конкретного сервера приложений, про который остались лишь шутки. Сейчас в продакшене используется это: https://puma.io/ Там есть график Memory Usage Comparison.

Лол, нормальная такая отговорка про аннотации, я сразу и не представил что их отдельными сделали. Только зачем вообще код писать, скоро нас ИИ заменит :)

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

Хорошо что это кто-то понимает.

Статическая типизация переоценена. Выгоднее в динамическом языке сделать нормальный вывод типов, или опциональные аннотации к ним. Как в JSDoc или Clojure/Type, например.

Я вот потихононьку в исследовательских и практических целях, планирую написать AOT компилятор JS, чтобы собирать Node.JS приложения, или может Scheme. Для этого мне нужно вывод типов попутно сделать.

Я не вижу в этом ничего невозможного. Ведь уже есть неплохие подвижки в эту сторону PyType.

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

Что значит «сборка»? Это не часть стандарта языка, поэтому JS чуть более опасный, т.к. это язык с динамической и слабой типизацией, в отличие от Ruby, языка с динамической, но строго типизацией. Где тут сборка?

$ irb
3.0.3 :001 > 1 + "1"
(irb):1:in `+': String can't be coerced into Integer (TypeError)

$ node
Welcome to Node.js v14.18.2.
> 1 + "1"
'11'

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

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

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

Хорошо что это кто-то понимает.

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

Я немного кодил на кристале, так вот аннотации там ну очень редко нужны. По ощущениям это ничем не отличается от кодинга на руби, только метапрограммирование там на макросах. Так что коммунизм уже почти наступил, а люди радуются, что теперь можно на питоне писать как на жабе из 90-х. Хорошо хоть японцы не стали спешить, а посмотрели на пыху с питоном, и сделали нормально.

Я немного кодил на кристале, так вот аннотации там ну очень редко нужны.

В современных языках так и делают, например, rust, go, TS. Когда компилятор сам может вывести то выводит, когда нет - то просит писателя кода это сделать. Писать типы руками звучит как пытка для тех кто не пробовал, но на самом деле они делают код понятнее. С чего вы взяли что в rust, go, crystal и других эту фичу просто недоделали потому что дурачки или ленивые, а вот гениальный Matz говорит сто проц скоро вообще любой кейс будет автоматически распознаваться.

Следующий параграф если коротко «как вы представляете угадать рантайм тип умным компилятором?»

Пользователь в рантайме присылает данные, тип этих данных этот гениальный компилятор как узнает? Грузим что-то с third-party, как тип данных узнает «автоматически»? Аргумент метода утиной типизацией проверяется if arg.is_a?(Duck), сам разработчик тут не уверен что пришлют как автоматом узнает? JSON файл с диска прочитали и распарсили, как тип узнать?

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

Или ещё пример, была колонка в базе string, стала integer, я вообще не представляю как в легаси проекте на руби кто-то осмелится на такое. Как умный компилятор без аннотаций узнает что оно теперь integer?