LINUX.ORG.RU

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

 ,


0

1

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

Зачем нужен интерпретатор?

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

Почему экспериментальную технологию сразу добавили в общее дерево кода?

  • Чтобы как можно скорее выявить и исправить баги и недочёты.

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

Для получения новой возможности нужно произвести сборку crystal compiler с ключом interpreter=1 для make. После чего будет возможно использовать ключ i для исполнения в режиме интерпретации crystal i file.cr или просто crystal i для интерактивного режима.

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

>>> Подробности

★★★★★

Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 11)
Ответ на: комментарий от saahriktu

Просто некоторые измеряют живость языков программирования по вакансиям с хорошей зарплатой.

Странно, что мертвый руби по-прежнему в первой десятке по активности на гитхабе. Что они там с ним делают, некрофилы чертовы? Кстати, модный раст ниже перла. Это какой-то лол.

https://madnight.github.io/githut/#/pushes/2021/3

bread
()
Последнее исправление: bread (всего исправлений: 1)
Ответ на: комментарий от bread

Кстати, модный раст ниже перла. Это какой-то лол.

По этому рейту надо вообще на шелл переходить и на баше строгать проекты. Скрытый лидер!

Virtuos86 ★★★★★
()
Ответ на: комментарий от Virtuos86

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

bread
()
Ответ на: комментарий от bread

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

Top Programming Languages of 2021 Included SQL

Dice Insights назвал 8 языков программирования, которые больше всего искали американские работодатели за минувший год. Данные предоставлены компанией Burning Glass, которая агрегирует и анализирует миллионы вакансий на рынке труда США.

https://insights.dice.com/2022/01/03/top-programming-languages-of-2021-included-sql-java/

OSBuster
()
Ответ на: комментарий от bread

SQL божит как всегда. Фантазии про всесильный ORM и nosql такие фантазии. Но где же модные го и раст?

Так на там же Go при всём хайпе, деньгах и маркетинге до сих пор нет вменяемого ORM, который будет покрывать хотя бы 90% тривиальных задач. И полтора веб-фреймворка (Beego и Gobuffalo) фактически загнулись и не нужны никому, потому что писать сложную бизнес-логику выливается в монструозные и сложно поддерживаемые портянки процедурного бойлерплейта, рассыпающиеся при сколь-нибудь серьёзном рефакторинге или изменении. Поэтому Go это три с половиной корпорации пилящие эти ваши кубернетесы и прочие системные обвязки, а мелкому и среднему бизнесу Go нужен, чтоб спорадически выносить какую-то простую логику в микросервис и это разумеется не будет создавать тысячи вакансий на долгие месяцы разработки. Поэтому все эти наши Laravel/Django/Rails никуда не денутся в ближайшее десятилетия и не умрут, потому что принципиального иного и сильно лучшего-то ничего и нет.

Вот Сбер даже переучивает людей: «Все дороги ведут к Ruby: как мы переучиваем разработчиков с других языков» https://habr.com/en/company/sbermarket/blog/592819/

OSBuster
()
Последнее исправление: OSBuster (всего исправлений: 2)
Ответ на: комментарий от OSBuster

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

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

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

Romaboy
()
Последнее исправление: Romaboy (всего исправлений: 1)
Ответ на: комментарий от Romaboy

Язык не только самый медленный

Самый медленный из чего? Медленным он был 10 лет назад, а сейчас вполне себе как Python, в чём-то быстрее, в чём-то медленее, где-то ест больше памяти, а где-то меньше.

Бенчмарк: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/ruby-python3.html

А в версии, которая вышла две недели назад GitHub и Shopify запилили новый JIT и прибавку к 30% производительности без какого-либо изменения кода:

Бенчмарк: https://speed.yjit.org/

Тот кто познал легаси на руби никогда не вернется обратно.

Куда обратно? Я познал много легаси на Ruby и всё в порядке со мной. Есть и линтеры, код-стайлы и профилировщики. Если брать фреймворки и стандартную библиотеку, то наоборот часто выгодно проапгрейдить проект, потому что из коробки получаешь новые плюшки и синтаксический сахар к ним и можно выкинуть старые костыли и хаки да ещё и получить единообразный и всем понятный вид кодовой базы.

А метапрограммирование это фича, а не недостаток. Именно по этому Ruby так любят выбирать для написания различных DSL. А так-то можно и водой упиться до смерти.

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

Основная проблема Ruby это то, что в свое время он долго варился в Японии, а потом выстрелил в США и сразу в бизнес, без томления в. международной академической среде и у него нет и не было покровителя из гигантской корпорации, которая бы маркетингом и кучей литературы его продвигала за свой счёт. Отсюда и малое количество переводной литературы и в пост-совке, где с английским туго, особенно у джунов, у которых ещё всё впереди, выбор Ruby, как первого языка обычно не возникает. Потому что есть тонны литературы по JS/Python/PHP и сосед Вася может в любой момент подсказать и помочь. И как ответвление этой проблемы - долгое время отсутствие версии для Windows, да и появившийсяя порт тянет за собой много nix-багажа, включая MinGW. Сейчас, с появлением Докера и WSL эта проблема не сильно актуальна, но поезд ушёл и для абсолютных новичков тоже всё ещё проблема для быстрого старта.

самый багоопасный ввиду вышесказанного

Что-то как-то много превосходных степеней сравнения в одном сообщении. Не багоопасней любого другого языка с динамической, но строгой типизацией а-ля Python. В этом плане он менее багоопасный JS, у которого типизация слабая. Так что точно не самый. Да, есть TypeScript, но и в Ruby больше года как есть аннотации типов (и минимум IDE от JetBrains отлично их поддерживают из коробки), можно оптипизироваться до смерти, в дополнение к TDD/BDD, если есть желание и/или потребность и свести какую-то «багоопасность» в вакууме до минимума.

из этого ещё и лепят функциональщину,

Словно что-то плохое. А где не лепят? Что может быть плохого в условном паттерн-матчинге? Везде лепят, потому что в некоторых моментах это сильно упрощает жизнь. Но суть всё-таки в том, что для того, чтобы Ruby не казался этим вот всем, чем он кажется вам, нужно очень хорошо знать именно ООП (хороша или плоха эта парадигма это уже отдельный вопрос и не относится только к Ruby), причём не в его классической и слегка извращённой C++/Java/C# ипостаси, а Smalltalk-овой, тогда всё логично и понятно и элегантно, а не весь этот набор страхов, стереотипов и ужасов, который вас преследует.

OSBuster
()
Последнее исправление: OSBuster (всего исправлений: 7)
Ответ на: комментарий от OSBuster

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

всегда считал, что хейтеры с++ вот примерно отсюда же и берутся

xperious ★★
()
Ответ на: комментарий от OSBuster

нужно очень хорошо знать именно ООП

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

bread
()
Ответ на: комментарий от bread

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

Smalltalk (Pharo), но это вообще новичкам не зайдёт, думаю, и точно не мейнстрим, хотя для поковыряться с целью расширения кругозора – штука отличная.

В любом случае, в виду специфического порога входа (боль при использовании чего-то сложнее, чем «Hello, world» на Windows, небольшое кол-во переводной литературы и хорошее знание ООП на старте), Ruby это редко у кого первый язык, а самыми одержимыми крикунами и фанбоями обычно движет синдром утёнка, поэтому и на этом поприще большого пиара ему никто не сделает :)

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

OSBuster
()
Ответ на: комментарий от OSBuster

Я и правда 2-3 года как не трогал Руби и рад что он развивается.

То что он догоняет второй самый медленный в мире ЯП Python это хорошо, значит Руби уже не самый, а хотя бы делит первенство.

вам не зашло или вы не разобрались

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

Есть и линтеры, код-стайлы и профилировщики

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

Ruby больше года как есть аннотации типов

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

Не багоопасней любого другого языка с динамической, но строгой типизацией а-ля Python.

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

Словно что-то плохое. А где не лепят?

В функциональщине много хорошего, спору нет, вопрос на какой глобус эту сову натягивают. Вот в руби функция это класс который принимает аргументы в конструкоре и дает метод call. Писать на порядок больше кода чем это выглядело бы в другом языке - это противоречит самой философии Ruby. Я знаю что есть и lambda, и proc, но их не выйдет на глобальный уровень вытащить, можно в константу, но это тоже странно как-то. По умолчанию все методы иммутабельные, это конечно здорово и по FP, да только труъ FP языки под это оптимизированны, а в руби копировать массивы-объекты далеко не бесплатно, если помнить что он делит первенство по слоупочности.

Но суть всё-таки в том, что для того, чтобы Ruby не казался этим вот всем, чем он кажется вам

Есть за что любить руби, для меня это красота кода, ActiveRecord, множество готовых действительно качественных библиотек, культура тестирования. Окей, может показалось, я всего лет 5 на Ruby работал, может неправильно все понял и там сплошные розочки-цветочки. Зачем я делюсь страхами-ужасами? Да не знаю, может и не нужно, тем-более что тема про Crystal

Romaboy
()
Ответ на: комментарий от OSBuster

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

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

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

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

Romaboy
()
Ответ на: комментарий от Romaboy

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

OSBuster
()
Ответ на: комментарий от Romaboy

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

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

OSBuster
()
Ответ на: комментарий от Romaboy

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

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

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

OSBuster
()
Последнее исправление: OSBuster (всего исправлений: 2)
Ответ на: комментарий от OSBuster

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

Romaboy
()
Ответ на: комментарий от OSBuster

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

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

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

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

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

anonymous
()
Ответ на: комментарий от Romaboy

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'
OSBuster
()
Последнее исправление: OSBuster (всего исправлений: 1)
Ответ на: комментарий от Romaboy

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

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

OSBuster
()
Последнее исправление: OSBuster (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

OSBuster
()
Ответ на: комментарий от OSBuster

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

bread
()
Ответ на: комментарий от bread

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

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

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

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

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

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

Romaboy
()
Последнее исправление: Romaboy (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.