Comments 41
Crystal выглядит привлекательно, но скудная поддержка со стороны ide и редакторов кода портит всю картину. Если выбирать между этими двумя, то, без вариантов, go, в противном случае, есть и другие языки, даже C/C++ тут выглядит очень неплохо.
Так есть же LSP для него. Плохо работает?
Так если разработчики не будут выбирать crystal, то и авторам ide нет резона тратить ресурсы на его поддержку. В JetBrains есть плагин, но уже давно заброшен.
PS. Вот даже тут нет хаба crystal (наверное, поэтому автор закинул статью в хаб elixir).
Пробовал Crystal ещё в 2016 году. Задумка языка весьма интересная. И классно, что ребята продолжают активную разработку, несмотря на отсутствие финансирования от крупных компаний. Уже и с конкурентностью, похоже, дела наладились.
def validate
raise "Name cannot be empty" if name.empty?
raise "Email cannot be empty" if email.empty?
endБуду придираться. Процитированное — плохой код. Почему? Потому что если система большая, цикл сборки и деплоя большой (например, билды раз в неделю, апдейт сервисов на машинах волнами и очень постепенно), то, исправив ошибку с пустым name, мы только, например, через месяц поймаем ошибку с email в том же месте. А зачем делать интерфейс вида «вас много, а я одна»? Почему не провалидировать сразу всё и выдать разом все ошибки, которые встретились в объекте?
Скажете, тесты. Ок, но тогда, получается, сам этот метод и не нужен в проде, это всего лишь хелпер для тестов. А что он тогда делает здесь, почему он не в тестировочном пакете? Наверное, тесты тестами, но всякое бывает: внешняя интеграция, которую тестами не покрыть (остается только валидировать входящие значения), тесткейс, который забыли обновить. Тогда возвращаемся к первому абзацу.
Ну и напоследок: какой смысл в исключении здесь? Почему нельзя вернуть тапл (Bool, List<String>?), содержащий результат валидации и список ошибок, если они есть?
Для меня Crystal это язык мечты. Да, сборщик мусора, да, маленькое сообщество, да, есть несколько проблем которые вряд ли решаемы с текущим уровнем финансирования (инкрементальная компиляция, наследование генериков, может еще пара штук).
Но я все равно использую его в геймдеве, в эмбеддеде, везде где могу дотянуться. Потому что мне заходит и синтаксис руби и скорость си и даже "низкоуровневость" (когда я в целом могу понять во что скомпилируется этот код, без всей этой магии "заменил 0 на константу и for на while и код ускорился на порядок потому что внутри виртуальной машины тут оказывается выделялся массив").
Использование памяти: Go использует сборку мусора; Crystal использует подсчёт ссылок с обнаружением циклов
Вот тут ошибка. В Crystal тоже сборщик мусора. Причем у Go он специально написанный для Го (как я понимаю, оптимизирован на минимальное время остановки мира), а у Кристалла - сторонний (Boehm GC).
Правда на кристалле можно имея некоторую дисциплину писать так чтобы не выделять память, но думаю это и на Go возможно.
А что у него со сторонними библиотеками? Qt какое-нибудь реально прикрутить? А то, может, поковырял бы, но писать очередные хэллоуворлды уныло, а всем моим пет-проектам обычно бывает нужен десктопный гуй.
Для GTK4 есть: https://hugopl.github.io/gtk4.cr/
Под Qt тоже есть, но в каком-то заброшенном состоянии. Кажется, для разработки GUI этот язык всё-таки нечасто используется. В основном, для бекенда.
Понятно, что, при такой "популярности", там готового не будет ничего, и то в каком-то заброшенном состоянии. Вопрос, наверное, скорее, в том, насколько просто/возможно/невозможно подцеплять готовые C++ные библиотеки.
сишные библиотеки подключаются легко. C++ - сложнее, есть генератор (https://github.com/Papierkorb/bindgen), либо самому сделать обертку превращающую C++ библиотеку в C API.
В целом гуи сложная тема, я для себя сделал обертку над LCL но она далека от идеала.
есть генератор (...), либо самому сделать
Т. е., генератор толком не работает?
обертку превращающую C++ библиотеку в C API.
Вручную пересодомизировать всё Qt - это, наверное, выйдет посильнее "Фауста" Гёте...
Т. е., генератор толком не работает?
может и работает. Мне вариант с генерацией не нравится тем что если она с очередной версией кристалла или qT сломается, я вряд ли смогу его починить. Из-за этого мой подход (если бы мне нужен был Qt) - один раз найти условия при которых генератор работает, сгенерить байндинги и дальше просто использовать то что сгенерилось исправляя по необходимости.
Вручную пересодомизировать всё Qt
я не уверен что вам нужно прям всё Qt, мне бы хватило десятка классов или около того.
Да я, может, наоборот, уверен, что мне не нужно прям всё Qt, а хватило бы десятка классов, только поди ж знай заранее, что войдёт в этот десяток, а что нет, да ещё для разных проектов это могут быть разные десятки, да ещё там и один-то класс может быть такого размера, что раньше выйдешь на пенсию по ментальной инвалидности. Недавно для мелкого домашнего проекта на wxPython четыре штуки разных виджетов перепробовал для одной и той же задачи - там то не так, тут это не эдак, а что, если попробовать функцию такую, а что, если функцию сякую, флаги, параметры, вот это вот всё. А это, получается, то ли ещё перед каждой попыткой идти байндинг ковырять, добавлять там эти функции, то ли параллельно тащить тот же проект на C++, чтобы там понять, что работает, и уже только это тащить в байндинг - оба варианта какие-то, как нынче говорят, "такие себе". Когда-то давно я писал себе ограниченный недо-байндинг 3D-библиотеки VTK для Haskell, но там мне от неё нужно было буквально несколько возможностей, которые я заранее чётко представлял, ну вот только их туда и закорячил. С гуй-библиотекой, боюсь, не прокатит.
Ну, для GTK биндинги в рабочем состоянии.
Во всяком случае, примеры запускаются.
Непонятно чем это лучше rust
К тому же если уж искать работу то надо выбирать что-то более менее используемое... Тут перевес явно у go, сам я пишу на расте и не понимаю этих компромиссов, когда можно вообще без gc обойтись, но работу не найти конечно)
Rust и монолит тоже нравится больше чем го и микросервисы. Особенно там где сложная и ответственная бизнес логика. Причём, понимаю, что в микросервисы только палец сунь, вся рука пропала. Но хрен объяснишь менеджерам
Rust и монолит тоже нравится больше чем го и микросервисы
Нравится не нравится но раст сложнее чем go, а микросервисы более востребованы в больших проектах, где важна масштабируемость и отказоустойчивость.
Масштабируемость и отказоустойчивость микросервисов ну очень специфическая. Одно лечим, другое калечим.
Исключительно из-за этих целей если, то я бы не стал с ними связываться.
Тем более, что C++/Rust app можно вертикально масштабировать ого-го, а Go/C#/Java нет из-за проблем GC при большом количестве памяти и потоков. Максимум 8 vcpu рекомендуется для них.
Rust для любителей функциональщины, Crystal для любителей ООП.
Фунциональщина это строгость и гарантии математики. ООП это вайбкодинг на авось, без гарантий, следуя за "лучшими практиками" на всех стадиях, начиная с обследования и проектирования.
Вайб в смысле отсутствие гарантий и много граблей особенно на многопоточности
да, и есть те кому нравится не строгость и матан, а накидать по-быстрому код и сразу результат. Настолько что даже от раста отказываются в пользу юнити. Есть и промежуточные варианты - например когда пишешь будто на динамическом языке, но при этом компилятор проверяет все типы, компилируется в нативный код и компайл-тайм макрос при желании тоже можно накидать. Или когда ты не борешься с бороу-чекером и не пользуешься индексами вместо указателей чтобы сделать двусвязный список, ценой меньшей безопасности от гонок, просто потому что твое приложение все равно однопоточное и юли в нем ровно один кусок параллельного кода для которого модели горутин болеечем достаточно. Или когда код выглядит и читается как английский текст, а не апострофы и угловые скобки в каждой строчке.
Какие гарантии раст дает? Лика памяти и ресурсов при дропе фьючерса или дедлока на цикличиских Arc<Mutex>?
Гарантии непредставимости невалидных данных, правдивости сигнатур функций. Это делает проектирование в разы удобней для моих задач из кровавого энтерпрайза.
А по вашим вопросам какого-то специфического решения в Rust нет, но есть красивые варианты
// Порядок захвата!
let locks = vec![mutex1, mutex2].sort_by_key(|m| m.as_ptr());
// Всегда в одном порядке = нет дедлокаНапример
нет такого метода as_ptr у Arc или Mutex, это не слайс, но даже если бы он был, то ему бы пришлось в unsafe возвращать usize, потому что sort_by_key F: FnMut(&T) -> K(старая ошибка дизайна), так что ключ всегда должен иметь лайфтайм выше лайфтайм всех элементов, иначе будет ошибка комплияции типа такого. А все это не тянет на красивое решение.
Всем, от времени компиляции, до читабельности кода и удобства использования.
Когда уже на Хабре появится значок - нейростатья?.. Хотя бы для удобства чтения и восприятия. Пусть живут такие статьи, на здоровье, потому что минорная ценность все же есть, но легко отделять оригинальную авторскую мысль от очередного пересказа все же очень хотелось бы!
Зачем, когда есть Dlang
Я кстати был фанатом DLang лет 10 назад. Но потом перешел сначала на Ruby, а потом на Crystal, потому что понял что в D все-таки для меня многовато острых углов - вместо того чтобы написать код и он просто работает ты думаешь о шаблонах и преобразованиях. Это вкусовщина конечно, так-то язык неплохой.
Но в crystal, например, если хочешь удалить элемент из массива по значению, то пишешь array.remove(item). А в D ты вместо этого листаешь algorithm, убеждаешься что такой функции не завезли в стдлибу и пишешь свою.
Спасибо за статью! Наконец-то о чем то красивом и хорошем.
Для меня go это гениальный маркетинг. Уверен что выпусти google не go, а crystal, сейчас бы восхищались crystal-ом.
Да, массово перевести кодеров с простых языков типа PHP это надо уметь. А вот переходить с C++ или Java на Go тут я бы не спешил.
Не соглашусь. Мне нравится Go по причине своей простоты и элегантности. Для меня Go - это, по сути, современная версия C++. С современной поддержкой библиотек, и прекрасной документацией (в том числе и сторонних библиотек, благодаря go doc).Синтаксис Ruby же, для меня, ни разу не пример элегантности. Как и синтаксис Python
Запарили ИИ-генерированные статьи на Хабре!! Вот честно, эти вылизанные, нейтральные по стилю, хорошенькие текстики с рубриками и буллит-списками, эти Введения и Выводы, как по школьной методичке, эти абсолютно невыразительные обороты без индивидуальных черт... Я намеренно не говорю про само техническое содержание, оно, быть может, бывает неплохим. Но где напряг человека? Написать промптик? Честно??
Когда тема нормальная, но в статье слишком гладко стелят, просто идите сразу в комментарии, там всё будет: «Да ваш Go — говно! — Нет, ваш Crystal — говно! — Да всё говно, один Rust — не говно!»
Полностью согласен.
Но где напряг человека? Написать промптик?
Вполне достаточно тогда публиковать только этот самый промптик. Правда это уже на статью не потянет.
Go vs Crystal: выбираем между двумя современными языками программирования