LINUX.ORG.RU

Crystal 0.16.0

 ,


0

3

Состоялся релиз языка программирования Crystal 0.16.0.

Цели языка:

  • Синтаксис, похожий на Ruby (но совместимость с ним не является целью).
  • Статическая типизация (но без необходимости явного указания типов переменных и аргументов методов).
  • Вызов кода на Си с помощью биндингов, написанных на Crystal.
  • Исполнение и генерация кода во время компиляции (макросы).
  • Трансляция в эффективный нативный код.

Текущее состояние:

  • Проект находится в стадии alpha: язык и стандартная библиотека всё ещё подвергаются значительным изменениям.
  • Компилятор написан на Crystal.

Этот релиз содержит значительное изменение, ломающее обратную совместимость, о котором было объявлено несколько месяцев назад. Также был внесён ряд других незначительных изменений и множество новых вкусностей.

Новый алгоритм вывода типов

Ранее типы переменных выводились путем анализа всех видов использования. Например:

class Some
  def initialize(@var)
  end
end

Some.new(1)

В примере выше типом @var будет являться Int32. Если вы сделаете так:

Some.new(1)
Some.new("hello")

Тогда типом являлся бы Int32 | String (union). И даже в следующем коде тип останется таким же:

class Some
  def initialize(@var)
  end

  def var=(value)
    @var = value
  end
end

some = Some.new(1)
some.var = "hello"

Приведённые выше примеры больше не будут компилироваться, так как теперь компилятор должен знать тип @var наверняка. Например, предположим, что предназначенный тип для @var — Int32, тогда мы могли бы написать:

class Some
  # Так как конструктор принимает только Int32, типом @var будет Int32
  def initialize(@var : Int32)
  end
end

Вывод типов используя литералы и конструкторы:

class Some
  def initialize
    @int = 0            # Int32
    @string = "hello"   # String
    @bools = [] of Bool # Array(Bool)
    @time = Time.new    # Time
  end
end

Обратите внимание, что указание типов для аргументов методов необязательно и никогда не будет обязательным.

Это изменение в будущем позволит реализовать инкрементальную компиляцию и уменьшить общее время компиляции и использование памяти. Прямо сейчас больших проектов на Crystal не много. Возможно, самый большой проект — это сам компилятор, и его компиляция с нуля занимает 16 секунд и 1 GB памяти. Но появятся более крупные проекты, и даже несмотря на то, что компьютер программиста должен быть быстрым и иметь много памяти, нет никаких причин ждать или расходовать CPU и память.

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

Добавлена поддержка FreeBSD и musl libc

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

Именованные аргументы везде

Ранее именованные аргументы могли быть применимы только к тем аргументам, которые имели значение по умолчанию:

def method(x, y = 1)
  x + y
end

method 10           # OK
method 10, y: 20    # OK
method x: 10        # Error
method y: 20, x: 10 # Error

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

Прочие изменения

  • В Array и Range добавлена возможность бинарного поиска.
  • Добавлены типы BigFloat и BigRational.
  • Упрощён маппинг перечислений, BigInt и BigFloat в JSON и YAML.

С более полным списком изменений можно ознакомиться в примечаниях к выпуску.

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

★★★★★

Проверено: Shaman007 ()
Последнее исправление: Wizard_ (всего исправлений: 7)

Ответ на: комментарий от bs1988

Раз уж на то пошло

«На то» — это на что?

то все языки - баян

И какой практический вывод из этого следует сделать?

Ибо есть FORTRAN и LISP. Все остальное - производное от них.

Есть основания подозревать, что не все так однозначно: https://www.levenez.com/lang/

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

На гитхабе давно были? Почти каждый новый проект начинают писать на rust/swift/go

Думаю, тут нужна _аккуратная_статистика_, а не досужие домыслы. Кроме того, вот посмотри: есть Линукс, есть море софта под него. Почему хотя бы базовые вещи не переписать на Расте? Надоело уже слышать про очередное говно мамонта, в котором нашли ошибку, не фикшеную с 1990 года! Все эти ls, awk, bash, всё это можно запилить на безопасном языке. Но не делает никто! Тогда смысл от новоиспечённых проектов, если база - всё то же дырявое «сипипи»? Вот тебе и отличие «популярности» от «используемости». Какой-нибудь superedit на расте запустят десяток любопытных, а ls'ом пользуются миллионы!

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

а компиляция в байт-код - это к какой категории относится? :)

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

Вывод: байт-код используют интерпретируемые языки.

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

А то что берется от фанаря точка отсчета в середине временного отрезка на любом удобном месте.

Хочу добавить. Так называемые «люди от Web», которые вошли в IT буквально вчера, пропустив львиный кусок истории развития, вообще живут в своем аквариуме. Для них точка отсчета началась с сегодня. Для них любой новый язык, который отличается парочкой операторов - откровенье Божье. Лично у меня перед глазами кода тексты от FORTRAN и до Swift. И еще эзотерика вроде брейнфака.

Когда держишь это все в голове. То для тебя Dart, Go, JS, Scala - одно и тоже. ЧЕМ! Чем, например, сравнивать брейнфак с каноничным лиспом и сишкой - разница ощутима.

Если раньше хотя б новые операторы появлялись, по другому называлось. То сегодня уже мы видим эти 'let', 'var', 'for' и кучу всего. Если в жемчужинке мы видим некие редкие символы '@' и '$'. То в новых ЯП их не наблюдается.

Т.е. все начали косить под Си. Такой же набор символов. Фигурные скобки. if, for, while блоки. Несмотря на то, что в старых языках были begin и end. Или тупо сплошные круглые скобочки как в лиспе.

Новизная моя закончилась на питончике. Дальше пошел дикий плагиат. Ничего кардинального нового. А мочить меня функциональщиной из JS не надо. Это все и так было во всяких схемах и хаскелях.

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

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

Хорошо тогда вот тебе мой тест, объясни мне понятие «срезки». Из какого этого языка из вышеперечисленных? И что это значит?

И вообще, ты пытаешься меня дескредитировать? Может ты еще на личности перейдешь?

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

Так называемые «люди от Web», которые вошли в IT буквально вчера, пропустив львиный кусок истории развития, вообще живут в своем аквариуме.

Судя вот по этому:

То для тебя Dart, Go, JS, Scala - одно и тоже.

и вот по этому

Если раньше хотя б новые операторы появлялись, по другому называлось. То сегодня уже мы видим эти 'let', 'var', 'for' и кучу всего. Если в жемчужинке мы видим некие редкие символы '@' и '$'. То в новых ЯП их не наблюдается.

вы ничем от них не отличаетесь. Раздутое самомнение, иллюзия наличия кругозора, неспособность внятно сформулировать свою мысль... Весеннее обострение, а лекарство закончилось или забыли вовремя принять?

eao197 ★★★★★
()

Требование к разработчику языка программирования

1. Не должен иметь бороду!

Покажите мне того у кого нет бороды!

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

Не каждый день доводится читать насколько феерический поток сознания. Взять, например, вот это:

Когда держишь это все в голове. То для тебя Dart, Go, JS, Scala - одно и тоже. ЧЕМ! Чем, например, сравнивать брейнфак с каноничным лиспом и сишкой - разница ощутима.

Это вообще что было? Первые два предложения во что-то стройное укладываются. Но вот дальше... Вы это зачем вообще выплеснули?

eao197 ★★★★★
()

tcl/tk rulezz!!!

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

А здесь банят за «феерический поток сознания» или за «переход ни личности»?

Хм... интересно! А вопрос то риторический!

Может ли человек родившийся в 1970-е годы считать «человеком», другого человека, который был рождён в 1988 году.

А ведь человек родившийся 1970-х годах видел Советский Союз, очереди и талоны. А человек родившийся 1988 году видел покемонов и Диснеевские мультики.

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

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

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

С этим пускай модераторы разбираются.

Я хотел понять, насколько ваше мнение, высказанное в данной теме, можно воспринимать всерьез. Пока видно что вы: не очень разбираетесь в истории развития языков программирования; не очень представляете, чем они друг от друга отличаются; не знаете важных вещей из языка, знакомство с которым декларируете; не берете на себя труд внятно сформулировать свою мысль.

Пока получается, что все, что вы высказали выше по треду можно множить на ноль.

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

Вывод: байт-код используют интерпретируемые языки.

А если байт-код используется как промежуточный?

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

Вероятно, потому, что где-то в это время этот поциент влез в IT.

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

Ничего нового. Я встречал нечто подобное в VHDL и Verilog. Там тоже было несколько типов assignemnt operations. В COBOL есть ссылки и значения и есть оператор MOVE.

И это все плохой пример.

Оператор копирования/оператор присваивания в С++. Делается перегрузкой операторов. Мало того. В новых стандартах пытаются(!) запилить эту фитчу как синтаксически(появляется rvalue), так и библиотечно(std::move). Семантика перемещение уже была давно. Просто у нее были проблемы с временными объектами. rvalue - это вот затычка. И ссылки в С++ есть и немутабельные объекты. И даже mutable, чтобы сделать незменяемое изменяемым. И время жизни. И даже некоторые компиляторы могут вставлять garbage collector. И еще хотелось бы вспомнить С++/CLI как попытка сделать из С++ управляемый язык. И так как D наследует своего предшествинника, там тоже такое возможно. Причем D c уклоном на ссылки и сборщик муссора. Ну типа из C++ сделать C#.

Все это уже давно есть, просто в Rust появляется синтаксический сахарок. Массивы, указатели, мутабельный/немутабельный, типы, автотипы(auto), срез массивов, ссылки, safe/unsafe. Все это уже мы видели в предыдущих языках. Тупо заменили copy ref на move ref - охренеть новшество.

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

И даже некоторые компиляторы могут вставлять garbage collector

И даже кое-кто походу не понял, в чем «фишка» раста …

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

В новых стандартах пытаются(!) запилить эту фитчу как синтаксически(появляется rvalue), так и библиотечно(std::move).

Можно с примерами?

Семантика перемещение уже была давно.

Да, 2011-й — это уже давно. Или она была еще до C++11?

Тупо заменили copy ref на move ref - охренеть новшество.

Вы уверены, что поняли, ссылку на что вам дали?

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

Дальше ты будешь преводить «заимствования», «упаковка», «счетчик ссылок» и все это выглядит уже не так красиво, типа «Box::new». И что мешает в плюсах написать Box::new? Или сделать свои «умные указатели». Boost тебе в помощь. Потом ты будешь на «типы» ссылаться. Потом будешь тащить сюда анонимные функции, кортежи(которые есть везде). Потом тащить range для массивов(хотя этого достаточно, даже он в Haskell есть подобное).

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

Контроль памяти и включения/отключения есть и D. И че? В C# есть unsafe. И че?

Почему я должен пересаживаться на раст, объясни мне!?

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

Так ты мне обьясни в чем фишка раста. Это ж ты защищаешь данную позицию. Вот и объясни. От тебя контраргументов я не услышал. Какая это ссылка расказывающая на владение объектами. Типа в джаве нет ссылок и нет понятие владение объектов. Типа там нет ключевого слова final, которое позволяет запретить перепресваивание, но при этом разрешает изменять сам объект.

Ты хоть сам понимаешь что ты приводишь?

Типа ты хочешь сказать что в расте мегаиновационная модель памяти. Типа соединили safe и unsafe - теперь это суперкруто и ни у кого такого нет?

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

Не знаю о чём вы, но rust в десятки раз безопаснее C++.

Я пишу на плюсах последние лет 5 и знаю множество примеров как выстрелить себе в ногу. При том, что компилятор промолчит, в отличии от rust.

С++, clang

    vector<int> vec{ 1, 2, 3 };
    const int &ref = vec.at(1);
    cout << ref << endl;
    vec.erase(vec.begin() + 1);
    cout << ref << endl;
2
3

rust

    let mut vec = vec![1, 2, 3];
    let r = &vec[1];
    println!("{:?}", r);
    vec.remove(1);
    println!("{:?}", r);
src/main.rs:38:5: 38:8 error: cannot borrow `vec` as mutable because it is also borrowed as immutable [E0502]
src/main.rs:38     vec.remove(1);
                   ^~~
src/main.rs:36:14: 36:17 note: previous borrow of `vec` occurs here; the immutable borrow prevents subsequent moves or mutable borrows of `vec
` until the borrow ends
src/main.rs:36     let r = &vec[1];
                            ^~~

src/main.rs:45:2: 45:2 note: previous borrow ends here
src/main.rs:21 fn main() {
...
src/main.rs:45 }
               ^
error: aborting due to previous error

А если в C++ еще и очистить вектор, то будет вообще segfault.

Так что не надо рассказывать о том, что все фичи раста можно повторить в плюсах.

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

Или сделать свои «умные указатели». Boost тебе в помощь.

Вылазим из криокамеры, smart pointers уже давно в стандарте.

Почему я должен пересаживаться на раст, объясни мне!?

А вы и должны. Такие неадекваты должны держаться подальше от нормальных языков, а то и их испоганят.

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

Так ты мне обьясни в чем фишка раста. Это ж ты защищаешь данную позицию.

Вы что-то спутали. Я вам задал вполне конкретные вопросы по поводу ваших высказываний о языке C++. Ответьте на них, пожалуйста, а то я сильно заинтригован.

Ты хоть сам понимаешь что ты приводишь?

Если что, ссылку на доку по Rust-у давал не я. Но я понимаю, о чем там речь и чем именно Rust отличается от других мейнстримовых языков.

А вот вы в очередной раз демонстрируете воинствущую безграмотность.

PS. И да, контраргументы были.

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

Что мешает реализовать Vector как список и тогда то, что ты написал выше будет прекрасно работать? В Qt QVector и QList примерно тоже самое.

Это фишка разработчиков, а не особенность языка. Тебе ничто не мешает перегрузить все операторы в vector и сделать его безопасным. Разница между std::list и std::vector для пользователя будет в наличи оператора [] только.

Что тебе мешает хранить в памяти кучу копий одного и того же массива?? «Нельзя узнать когда унчитожить объект?». Так ты используешь указатели. И все объекты удаляються только при удаление оригинального объекта vector. Не будет сборщика муссора. Ну ок.

И вообще в D есть динамические массивы! Что мешает???

И вообще, то что ты показал противоречит принципам ООП, нельзя менять объект не через посылку сообщения. Это противоречит принципам инкапсуляции. Если у тебя есть объект и ты меняешь его свойства через указатель - то это значит что ты пишешь не ООП. Да, представь себе, std vector противорчит этой концепции. И использовать его нерекомендуется.

В C++ золотое правило: НИКОГДА не возвращай не-const указатель на внутрение переменные-члены класса. Второе правило: не должно быть public перменных. Иначе это не ООП а черти что.

Как у раста с ООП? Если там оно плохо сделано, тогда нафиг он нужен? Очередной безопасный Си?!

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

Снова переход на личности?

Так почему твой нормальный язык до сих пор не стал мейнстримным? Со времени создания прошло уже 6 лет. C#, Scala, Go и то быстрее набирали обороты в продакшене.

Почему не писать на более чистом Haskell сайтики, а не использовать извращение функциональщины в JS?

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

Это фишка разработчиков, а не особенность языка.

Шта?! Это std. Основа языка.

Факт остаётся фактом - выстрелить можно. Ясное дело этого можно избежать, и опытный программист на такие грабли не наступит. В то же время, раст запрещает это в принципе.

Тебе ничто не мешает перегрузить все операторы в vector и сделать его безопасным.

Если я буду возвращать копию объекта, то потеряю в производительности, а в rust - нет.

И вообще, то что ты показал противоречит принципам ООП, нельзя менять объект не через посылку сообщения. Это противоречит принципам инкапсуляции.

Что за феерический бред? Какие еще принципы? Я взял и написал. Никто меня не останавливает.

И использовать его нерекомендуется.

Не рекомендуется использовать самый основной контейнер стандартной библиотеки языка? Ну ок. Зачем тогда вообще std? Я конечно согласен, что stdc++ говно, но это не в вашу пользу.

В C++ золотое правило

Золотые правила должны быть в компиляторе, а не в головах.

Иначе это не ООП а черти что.

При чем тут ООП?! Речь вообще о небезопасной работе с памятью.

Как у раста с ООП?

Норм, если у вас не ООП головного мозга.

Очередной безопасный Си?!

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

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

Т.е. не знаешь, но мнение имеешь? Или зачем ты привёл в качестве аргумента GC?
Нет в (core) расте GC и счётчики ссылок тоже, как бы, опциональны. А вот указатели можно не только в unsafe использовать, так что сравнения с жабами и прочими питонами совсем мимо.

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

Со времени создания прошло уже 6 лет.
The first «stable» version of the Rust, version 1.0.0, was released in May 2015.

Почему не писать на более чистом Haskell сайтики, а не использовать извращение функциональщины в JS?

Это проблемы вебмакак и разрабов браузеров.

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

Это слабые контраргументы. Ради одной-двух фич переходить на другой язык, у которого нет даже библиотек еще. Завтра мне поставят задачу реализовать еще один сервер для работы с CDMA. Я буду писать целый месяц байдинга на твой раст, а потом еще писать на самом расте. Как новая модель памяти организуется со старым кодом на Си?! Я должен мучаться так и тратить время ради пару фич в языке по твоему??. А если мне драйвер надо написать под ядро linux, как мне быть в этой ситуации. Использовать unsafe подмножество?! Тогда зачем эти новые фичи, если язык позиционирует себя убийцей С++.

Ребята, любите ссылки вот вам http://eax.me/cpp-will-never-die/

А вот я вспомнил про Vala. Как я мог забыть. Язык с очень похожим подходом. Тоже убийца C++. Попытка сделать контролируемую сборку мусора. Ссылочки. Попытка решить проблемы C++.

Вот тебе ссылка на ваши любимые http://www.vala-project.org/doc/vala-draft/concepts.html#ownership

Надо было изначально про нее вспомнить. Тогда бы мы сократили диалог.

Ничего нового.

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

Т.е. ты привел какой-то редкий оператор и особенность языка и теперь считаешь

Нет. Вот после этого пассажа:

bs1988> Думал изучить Rust. Только начинаю вникать. Елки-палки снова тоже самое, что видел раньше

Очень интересно знать, где ты раньше видел такую основополагающую вешь Rust, как lifetimes. Видеть ее раньше ты мог под именем regions, отсюда и вопрос.

Хорошо тогда вот тебе мой тест, объясни мне понятие «срезки». Из какого этого языка из вышеперечисленных?

Не из какого. Это из рассказа Шукшина «Срезал».

И что это значит?

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

И вообще, ты пытаешься меня дескредитировать?

Нет. Мне это незачем, да ты и вряд ли здесь задержишься.

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

А если мне драйвер надо написать под ядро linux, как мне быть в этой ситуации.

Брать и писать? https://github.com/tsgates/rust.ko

Ребята, любите ссылки вот вам

Наглая копипаста http://www.viva64.com/en/b/0324/ , авторов C++ анализатора. Им конечно виднее.

Vala
Тоже убийца C++.
Попытка решить проблемы C++.

Нет. Он не больше, чем удобная замена gtkmm для разрабов Gnome, который даже там неохотно используют.

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

Молодой человек, на LOR-е (как и на других профильных ресурсах) принято следить за тем, что и кому вы отвечаете.

Я не агитирую вас за Rust. Мне сразу стало понятно, что вы не знаете, в чем отличие Rust-а от C, C++, D, Go, Vala и пр. Поэтому, пожалуйста, не просите меня в чем-то вас убеждать по поводу Rust-а, вы обращаетесь не по адресу.

Однако, по поводу C++ вы позволили высказаться следующим образом: «Оператор копирования/оператор присваивания в С++. Делается перегрузкой операторов. Мало того. В новых стандартах пытаются(!) запилить эту фитчу как синтаксически(появляется rvalue), так и библиотечно(std::move). Семантика перемещение уже была давно.»

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

И, если позволите, личный вопрос: скажите, пожалуйста, вы программированием себе на жизнь зарабатываете?

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

Ты снова хочешь перейти на личности?

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

Ну с этим-то более-менее понятно. На вопросы по C++ ответить сможете?

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

А вот я еще не понял. Но очень похоже, что ты прав.

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

А что ты про GCC GIMPLE скажешь, ламерок?

anonymous
()

Мнение Юкихиро Мацумото о Crystal, которое он высказал на Rubyconf India 2016 https://youtu.be/e4HwanYNkhY?t=2489. Если в двух словах, то: он ожидает многого от этого языка и ему интересно наблюдать за его развитием.

Another0s
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.