LINUX.ORG.RU

О бедном Crystal замолвите слово

 , , ,


2

7

Рассматриваю варианты на замену Go для личного проекта. Сообществом Crystal высказывается мнение, что он то как раз на эту роль и годится, во всём превосходит первый и незаслуженно обделён вниманием (это же слышу от апологетов Nim). Go, конечно, куц и по возможности я бы предпочёл не популяризировать посредственный ЯП, если есть варианты. На Ruby никогда не писал, но после беглого ознакомления некоторые элементы заходят. Кто заглядывал под хвосткапот этому Crystal? Там всё серъёзно или я-его-сварила-из-того-что-было, как в V?



Последнее исправление: Rabinovich (всего исправлений: 1)

Чё за параша с синтаксисом? Какие ещё end-end-end-end в 2023 году?

# Fragment of the BigInt implementation that uses GMP
@[Link("gmp")]
lib LibGMP
  alias Int = LibC::Int
  alias ULong = LibC::ULong

  struct MPZ
    _mp_alloc : Int32
    _mp_size : Int32
    _mp_d : ULong*
  end

  fun init_set_str = __gmpz_init_set_str(rop : MPZ*, str : UInt8*, base : Int) : Int
  fun cmp = __gmpz_cmp(op1 : MPZ*, op2 : MPZ*) : Int
end

struct BigInt < Int
  def initialize(str : String, base = 10)
    err = LibGMP.init_set_str(out @mpz, str, base)
    raise ArgumentError.new("invalid BigInt: #{str}") if err == -1
  end

  def <=>(other : BigInt)
    LibGMP.cmp(mpz, other)
  end
end
EXL ★★★★★
()

Возьми лучше Julia:

function mandelbrot(a)
    z = 0
    for i=1:50
        z = z^2 + a
    end
    return z
end

for y=1.0:-0.05:-1.0
    for x=-2.0:0.0315:0.5
        abs(mandelbrot(complex(x, y))) < 2 ? print("*") : print(" ")
    end
    println()
end

Я лишь один раз попробовал и до сих пор глаз дергается.

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

Чё за параша с синтаксисом?

Влияние Ruby.

Какие ещё end-end-end-end в 2023 году?

Это сильно лучше, чем endif()-ы из CMake, а CMake многие сейчас жрут с причмокиванием и других заставляют.

А вообще доколупывание до синтаксиса в 2023-ем году выглядит странно, мягко говоря.

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

Это сильно лучше, чем endif()-ы из CMake, а CMake многие сейчас жрут с причмокиванием и других заставляют.

Тут соглашусь на 100%, более идиотского синтаксиса чем у CMake в приниципе не существует. Почему в IT всегда становится негласным стандартом самое всратое решение? Уж C++-программисты могли себе сделать нормальную систему сборки, а сделали угрёбищный CMake…

А вообще доколупывание до синтаксиса в 2023-ем году выглядит странно, мягко говоря.

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

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

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

Тут, к сожалению, все очень субъективно. Для меня, например, синтаксис Ruby и Eiffel является, пожалуй, самым удобным и для чтения, и для написания. Си-подобный норм, да и привык уже, хотя в варианте Rust-а это страх и ужос-ужос :))). Тогда как основанный на отступах Python-овский – пожалуй, самый всратый. Про Lisp-ы ничего не могу сказать, бохмиловал, как говорится :)

Но вообще я к тому, что как бы и время толерастии за окном, как-то кидаться говном в тех, кто не похожи на тебя, уже не принято. Да и за время развития языков программирования (а это уже порядка 70 лет, если не ошибаюсь) столько всего появилось и умерло, что к выжившим образцам невольно проникаешься уважением. Раз уж кому-то пригодилось, значит что-то в этом точно есть. Пусть и не для всех (но здесь см. выше про толерастию).

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

Это образец C-binding’а, в Go он делается вообще с помощью комментов и импорта:

/*
#include "hello.c"
#include "sum.c"
*/
import "C"

А потом вызовов C.Hello(), C.int(a) и т.д. Верх грации, если подумать. Всегда мечтал, чтобы ЯП при манипуляции C объектами давал железные гарантии уровня PHP шаблонизатора.

Rabinovich
() автор топика

Вообщем спасибо тебе ТС, где бы я еще узнал что есть компилируемый Руби на LLVM + Boehm GC с практически полностью совпадающим синтаксисом, куда народ активно портирует гемы.

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

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

народ активно портирует гемы

Это громко сказано. На самом деле с этим всё грустно, и активность давно заглохла. Лет 5 назад сабж казался перспективным, но получилась очередная хипстерская игрушка. Табличка конечно забавная, учитывая что lucky похож на рельсы примерно никак. До поры это был самый живой проект, но тоже как-то сдулся. Amber сдулся уже давно, это чуть больше похоже на рельсы (версий 0.x). Сейчас там новый фаворит - https://martenframework.com/. До рельсов им всем по-прежнему как до луны.

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

Следующий шаг это определение всех переменных в отдельной секции и ключевое слово procedure.

Не, синтаксис то в рубях скорее сишный (не знаю хорошо это или плохо), просто скобки заменили на end зачем-то. Вот питон намного больше мозг выносит.

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

во всём превосходит

Ха-ха! Ну попробуйте, потом нам расскажете об ощущениях. Я лично очень быстро сломался на медленной компиляции. Зависать на компилянии это совсем не то, что ожидаешь при написании вебни.

bread
()

Бери популярный, будет гораздо удобнее. Go, python, Haskell, java/kotlin в зависимости от области и личных предпочтений. Зачем искать дополнительные приключения себе на ж?

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

Красиво! Словно птички летят.

Много «птичек»: Луа, регулярные выражения и переменные (комментарий)

Та же логика, но мало вложенных «птичек: Луа, регулярные выражения и переменные (комментарий)

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

Ruby просто подкупил синтаксисом. После этого писать на пхп, перле и питоне - боль и унижение.

yu-boot ★★★★
()
Последнее исправление: yu-boot (всего исправлений: 1)
Ответ на: комментарий от EXL

приятный синтаксис должен радовать глаз, а эти end-end-end убивают всю лакончиность

У вас один синдром утёнка, у кого-то другой. Мне и, как мы видим, многим другим в этом топике синтаксис Ruby радует глаз. И не только в этом топике, раз появились Crystal и Elixir.

Не говоря уже о четырёх активно сопровождающися реализациях самого Ruby - MRI, JRuby, TruffleRuby, mruby (и ещё столько же заброшенных).

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

Чето вы продешевили

Вы бы хоть как-то свои претензии к синтаксису Ruby в слова облекли бы. А то уже не в первый раз залупаетесь, но как-то без огонька аргументации.

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

Я не Луговский,но попробую объяснить:

(1..10).each { |i| puts i }

.each это не ключевое слово как например for в Си, это метод приделанный к объекту самого языка. Поэтому работает вот такое:

my_hash = {min: 2, max: 5}
my_hash.each { |key, value| puts "k: #{key}, v: #{value}" }

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

The general convention is to use do..end for multi-line blocks and curly braces for single line blocks, but there is also a difference between the two that can be illustrated with this example:

puts [1,2,3].map{ |k| k+1 }
2
3
4
=> nil
puts [1,2,3].map do |k| k+1; end
#<Enumerator:0x0000010a06d140>
=> nil

Ключевое это вот:

This means that {} has a higher precedence than do..end, so keep that in mind when deciding what you want to use.

Всем срачем можно насладиться тут.

Теперь про вертикальные черточки, символ «|»:

It’s for the parameters that are being passed to your block

Это отдельный синтаксический костыль, придуманный для задачи передачи параметров в блок. При этом | как символ сравнения никуда не девается.

Вообщем суть нормального синтаксиса это его непротиворечивость и однозначность. Нахер не надо 101 способ сделать тоже самое, вот честно.

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

Я не Луговский,но

Для вас еще и Луговский авторитет? Поздравляю, с такой аргументацией да еще и с Луговским в авторитетах вы просто сказочный.

.each это не ключевое слово как например for в Си, это метод приделанный к объекту самого языка. Поэтому работает вот такое:

Вы так говорите, как будто это что-то плохое.

Ключевое это вот:

This means that {} has a higher precedence than do..end, so keep that in mind when deciding what you want to use.

Да, здесь получилось такое себе. К счастью, на практике это встречается не часто.

Это отдельный синтаксический костыль, придуманный для задачи передачи параметров в блок. При этом | как символ сравнения никуда не девается.

Ну усё! C++, Java, C#, Rust можно закапывать, т.к. < и > задействованы и в операциях сравнения, и для выделения параметров шаблонов/генериков.

PS. Давненько не доводилось видеть на LOR-е настолько упоротых клоунов, верной дорогой, однако.

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

Ну понятно, по делу ответить нечего

Я вот, бл_дь, честно не могу понять, как по делу можно ответить на претензии вида «each не оператор, а метод» и «какого х_я выбрали | для выделения блоков параметров в лямбде». Вам не нравится? ОК, нет проблем, кому-то нравится арбуз, а кому-то свинной хрящик. Но выдавать собственные половые предпочтения за недостатки языка, да еще требовать аргументированных возражений… Вы бы к врачу сходили, голову бы проверили.

eao197 ★★★★★
()

По-моему в Crystal нет многопоточности и дебаггера нормального, ничего серьезного с этим не напишешь. Плюс малый коммьюнити, мало ответов на StackOverflow, многие вещи делаются значительно дольше чем на мейнстримовом языке

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

Есть, но сложно сказать насчет нормальности.

Ну и не будет сюрпризом:

To achieve concurrency, Crystal has fibers. A fiber is in a way similar to an operating system thread except that it’s much more lightweight and its execution is managed internally by the process. So, a program will spawn multiple fibers and Crystal will make sure to execute them when the time is right.

Тут все упирается в практику, как это будет в реальности работать.

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

Вообщем суть нормального синтаксиса это его непротиворечивость и однозначность. Нахер не надо 101 способ сделать тоже самое, вот честно.

Автор вдохновлялся перлом, так что всё нормально. Без этих синтаксических мозголомок перловиков бы не удалось заманить. Тем не менее блок это по-моему удачная находка, гораздо лучше того безобразия, что творится в js. Но конечно {} это шляпа (и уступка любителям скобочек и однострочников), а вот do end норм.

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

Суть же в том что либо {} либо do.. end , но смешивать? Это ведь два лагеря были когда-то: Cи-подобные языки с фигурными скобками и Pascal-образные, где begin..end.

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

Вообщем Руби в плане синтаксиса абсолютно точно не эталон. Инструмент - да, но это другой вопрос.

alex0x08 ★★★
()
Последнее исправление: alex0x08 (всего исправлений: 1)

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

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

Ну, с такими вкусами многие вопросы в вашем отношении снимаются. Быть одновременно недовольным синтаксисами Раста и Питона нужно уметь. А, наверное, «эндов» нет, больше связи не нахожу между довольно перегруженным одним и лайтовым другим.

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

Автор вдохновлялся перлом, так что всё нормально.

Автор вдохновлялся тяжелыми веществами, так что всё нормально.
Автор вдохновлялся сатанинскими оргиями, так что всё нормально.

и т.д.

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

Не получится отсидеться в каком-то одном языке (если это только не Си), придется изучать разные концепции и подходы (помимо самого синтаксиса) чтобы работать за деньги.

alex0x08 ★★★
()

Проблема таких узконишевых языков «улучшалок», как Crystal и Nim, в том, что они не предлагают радикального улучшения родителя, при этом, как правило, теряют удобный интероп и соответственно зоопарк наработок библиотек. Вот и держатся еле на плаву. Лучше бы они силы вложили в улучшение/переписывание исходного языка, пусть и с частичным ломанием совместимости имхо

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

Ну, с такими вкусами многие вопросы в вашем отношении снимаются.

Полегчало, надеюсь?

Быть одновременно недовольным синтаксисами Раста и Питона нужно уметь.

Ну хоть что-то да умею.

А, наверное, «эндов» нет, больше связи не нахожу между довольно перегруженным одним и лайтовым другим.

Я бы еще понял если бы связь искали в том, что нравится. Но когда связь ищут в том, что не нравится… Не нравится же могут совершенно разные факторы, какие-то есть в одном языке, какие-то в другом.

В Python-е, например, основная идея синтаксиса – это определение логики количеством пробелов. Так себе идея, как по мне. Но ведь это еще нужно было усугубить кастрированными однострочными лямбдами и обязательной ручной передачей self в качестве первого параметра для методов.

В Rust-е же, такое впечатление, основная идея – это экономия символов. impl, fn, i32, () для пустого тупла… Еще и апостроф, который не то, чтобы самый заметный символ, для обозначения лайфтайма. Как будто чем меньше символов занимает код, тем лучше.

Как бы пользоваться можно и тем, и другим. Но на фоне того, с чем приходилось знакомиться, это все (на мой сугубо примитивный вкус) выглядит далеко не лучшим образом. Хотя, конечно, всратость CMake переплюнуть может разве что Perl :)))

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

они не предлагают радикального улучшения родителя,

Это примерно как «радикальное улучшение английского». Или русского. Получится красивый но мертвый «эсперанто» - выверенный, правильный и очень простой. Но не работает.

Поэтому все и вертится в рамках скобочек, логических операторов и знака «равно».

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

Такое не всегда возможно, у «исходного языка» есть определенный концепт, есть авторы, сформировавшиеся стандарты и план развития. Поэтому нельзя так просто влезть в процесс разработки например OpenJDK со своими исправлениями - пошлют даже с деньгами.

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

теряют удобный интероп и соответственно зоопарк наработок библиотек. Вот и держатся еле на плаву. Лучше бы они силы вложили в улучшение/переписывание исходного языка

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

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

Автор вдохновлялся тяжелыми веществами, так что всё нормально.

Это про раст. Впрочем, каждый второй дизайнер ЯП ими вдохновлялся. Или каждый первый. Кроме Вирта конечно.

bread
()