Crystal является frontend-компилятором для LLVM, который сам по себе является высококачественной инфраструктурой для компиляции и исполнения. Ресурсов в качество работы LLVM вложено очень много.

Для сборки мусора используется консервативный сборщик мусора BoehmGC, который достаточно неплохо себя зарекомендовал (хотя появляются интересные конкуренты — https://github.com/crystal-lang/crystal/issues/5271) .

Собственно, максимальный профит по производительности мы получаем от LLVM.

Плюс постоянная оптимизация stdlib (и она, и сам компилятор, написаны на Crystal, что резко уменьшает стоимость владения).

в процессе, для IO-bound пока некритично.

Хорошее начало. Кстати, мне в свое время понравилось почитать исходники компилятора Crystal, там работа с LLVM сделана очень читаемо. https://github.com/crystal-lang/crystal/blob/master/src/compiler/crystal/codegen/codegen.cr

увы, ужас непонят. все читаемо.

Ну вообще-то компиляция Crystal под Windows все еще в процессе разработки.

Так что проще пока удалить результаты Crystal под Windows, ибо они совершенно не отражают положения дел (все-таки другие ЯП уже имеют готовый Windows target).

блоки в Crystal можно оформлять и в фигурных скобках, это принято для однострочников.

5.times { |i| puts i }

yo = -> { puts "yo" }
yo.call

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

В времена оны сообщество Golang было в России отнюдь не на порядок сильнее сообщества Rust. И уж тем более сообщества C++11(14, 17).

Вообще, сейчас современный C++ идеален (не ущербен по сравнению с Go).

не все так просто )

лайк за второй пункт.

я изначально и написал читаемый пример на Crystal, а страдать уйней не стал )

Что? по мне так Go самый нечитаемый и клавиатурно набивательно ориентированный язык.

Строки, полученные при раскрытии макроса, далее преобразуются в AST, и продолжается уже разбор подставленного поддерева.

Ну как раз в Crystal макросы — на AST.

Без гигиены — писать комментарии, не прочитав о самом объекте обсуждения.

Жесткого плана нет (есть карта).

Ранее была амбициозная цель к 2018 году создать Crystal 1.0, готовый к промышленной эксплуатации.

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

Мне вот не хватает только иногопоточности для некоторых применений.

более корректно код писать как:

def iors
  Random.rand > 0.5 ? 5 : "s"
end

r = iors
if r.is_a?(String)
  puts "wow #{r}"
end

Нет, метод может вернуть type union Int64 | String.

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

def iors : Int64 | String
  Math.rand > 0.5 ? 5 : "s"
end

r = iors
if r.is_a?(String)
  puts "wow #{r}"
end

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

пока желательно только для инфраструктуры внутренней.

наружу раньше февраля не стоит.

Ну на деле Kemal, — это просто первая ласточка, сейчас есть и иные каркасы, типа https://ambercr.io

Во-вторых, да, async/await — прекрасная концепция.

А в остальном, — Crystal надежнее и удобнее в силу своей статической типизации, тут его ближайший конкурент все-таки — tsnode Golang.

в 98% случаях не взлетит, потребует хотя бы рихтовки напильником.

Crystal просто основан на некоторых идеях из Ruby.

Но вообще это статически-типизируемый язык с type unions, редкая штука.

То есть тип Int32 — не может быть nilable, а Int32 | Nil может (другая запись — Int32?).

И это очень сильно и удобно (и да, можно Int64 | String, например, но вообще типы он сам выведет при компиляции, если явно не писать).