В рамках проекта Crystal (https://crystal-lang.org/) развивается (https://blog.codeship.com/an-introduction-to-crystal-fast-as.../) новый язык программирования, разработчики которого намерены создать язык удобный как Ruby при разработке, но быстрый как Си при выполнении приложений. Код компилятора написан на языке Crystal и распространяется (https://github.com/crystal-lang/crystal) под лицензией Apache 2.0.
Синтаксис Crystal очень близок к языку Ruby (без переработки выполняются некоторые ruby-программы), но разработчики не ставят целью обеспечение полной совместимости. В языке применяется статическая проверка типов, но без необходимости явного указания типов переменных и аргументов методов в коде. Программы на Crystal компилируются в исполняемые файлы, с вычислением макросов и генерацией кода во время компиляции. С производительностью не всё однозначно: на текущей альфа-стадии развития в одних тестах Crystal опережает Ruby в 40 раз, но в отдельных тестах в 4-5 раз проигрывает (https://crystal-lang.org/2016/07/15/fibonacci-benchmark.html) по скорости выполнения.
В программах на языке Crystal допускается подключение биндингов, написанных на языке Си. Распараллеливание выполнения кода осуществляется при помощи ключевого слова spawn, которое позволяет запустить фоновую задачу в асинхронном режиме, не блокируя основной поток, в виде легковесных потоков, именуемых фибрами (Fiber).Стандартная библиотека предоставляет большой набор типовых функций, в том числе средства для обработки CSV, YAML, и JSON, компоненты для создания HTTP-серверов и поддержки WebSocket. В процессе разработки удобно использовать команду "crystal play" которая формирует web-интерфейс (https://play.crystal-lang.org/) (по умолчанию localhost:8080) для интерактивного выполнения кода на языке Crystal.
URL: https://blog.codeship.com/an-introduction-to-crystal-fast-as.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=44930
напомнило кассио и эмуляцио HP
Есть же Elixir - и на Ruby похож, и производительность и прочие ништяки от Erlang-а.
Производительность эрланга... Хорошая шутка для тех, кто в курсе, угу
Типа "её нет, но вы держитесь там"?
Она есть местами, но упоминать его как эталон скорости смешно. Эрланг - вообще не о том.В обработке данных, особенно не укладывающихся в жёсткий паттерн (строки те же) - производительность не фонтан. Плюс иммутабельность - когда на неё хорошо логика ложится, а когда и нет. В архитектуре - с OTP и приложением мозгов нормально, но ничего сверхъестественного. Эрланг берёт надёжностью и целостностью платформы - единственное, с чем можно сравнить в плане поддержки всех фаз жизни софта - Java EE (хотя это всё же очень натянутая аналогия). А скорость... если нужна где-то скорость, то для эрланга самое верное решение - запихнуть в эту точку сишное расширение, подо что он заточен очень хорошо.
Под сишные расширения он заточен очень хорошо? С FFI по "удобству" сравнимому только с PerlXS? C NIF, которые блокируют scheduler на сколько хотят и когда хотят? С NIF, которые крашатся, унося с собой всю эрланговскую VM?
Да, dirty scheduler помогает отчасти - но когда оно появилось?
А что не так с Perl XS? Вполне рабочая штука
http://slonik-v-domene.livejournal.com/31403.htmlЯ сомневаюсь в его компетенции сравнить с остальными языками, возмоожно там ещё больший треш и угар, а у сабжа застарелая детская травма. Но вот из личного опыта - с c+lua как-то работать не в пример проще (смотрел на примере движка одной игрушки и rspamd).
> http://slonik-v-domene.livejournal.com/31403.html
> Я сомневаюсь в его компетенции сравнить с остальными языками, возмоожно там ещё
> больший треш и угар, а у сабжа застарелая детская травма. Но
> вот из личного опыта - с c+lua как-то работать не в
> пример проще (смотрел на примере движка одной игрушки и rspamd).Нашли с чем сравнивать. Lua — в первую очередь встраиваемый язык (на всякий случай: это ни разу не упрёк, язык хороший), поэтому интеграция с Си в нём, разумеется, на высоте.
С LuaJIT еще проще.
ASN.1 и HLASM - тоже очень рабочие штуки.
Тем не менее, перловый XS остается одним из канонических примеров наиболее сложных и неудобных FFI c почти вертикальной learning curve.
а вы использовали elixir для написания приложений уровня ROR или так по теоретизировать решили?
жду с нетерпением бенчарков.
Даже смотреть не стану. Работа со строками и подобным в BEAM быстрой в жизни не была. Ну либо сишными сильно подпёрли, конечно - но тогда нужен либо набор расширений, сравнимый с питоновским, либо сишник в проекте, либо регулярно будете налетать на что-то нештатное, что просаживает производительность.Опять же - я от вебни далёк ежу лет пять как, и даже смотреть в её сторону не собираюсь. Впрочем, помню, что быстрее ROR быть - не велика заслуга.
ну в принципе да, что руби что эрланг и эликсир - корнями частично уходят к ванильному прологу, который весьма труЪ в этом плане.
никогда не писал на ruby, вот от чего дискомфорт
начинай, не пожалеешь
Начал. Пожалел. Where is your god now?
> Начал. Пожалел.О чём именно, кстати?
Скорее всего о том, что родился.
> процессе разработки удобно использовать команду "crystal play" которая формирует web-интерфейс (по умолчанию localhost:8080) для интерактивного выполнения кода на языке Crystal.всё больше и больше плодят тупых дыр (про которые раньше люди и не мыслили)..
..и ведь только недавно идиоты из Intellij Idea писали в своём блоге про их открытый socket-порт -- https://blog.jetbrains.com/blog/2016/05/11/security-update-f.../
ды перестаньиы вы уже плодить без надобности сервера! в том месте там где они не нужны.. хипсторы чёртовы
>> процессе разработки
> ды перестаньиы вы уже плодить без надобности сервера!Вы опять неправы.
А на руби удобно писать? Чёрт, жизнь прошла мимо...
По многим параметрам на Ruby даже приятнее писать чем на Python
Марсианину - несомненно ©
> Марсианину - несомненно ©А что, венерианская логика уже окончательно решила вопрос с табиками и пробельчиками? :)
Да даже чиорт с ними с табами-пробелами, к этому в конце концов привыкаешь со временем.
Вот что действительно раздражает - так это встроенные функции, особенно вперемешку с методами классов. Непонятно откуда читать выражение в итоге.
Гугли PEP8
Стандарт между прочим.
> Марсианину - несомненно ©Фанаты бэйсиков рубаются.
> По многим параметрам на Ruby даже приятнее писать чем на PythonСравнил тоже!
Это как сравнивать советский мопед "Рига" (пистон) и фольксваген "Туарег" (руби).Нет, мопед конечно тоже неплохой, но уровень эргономики несопоставим.
>Это как сравнивать советский мопед "Рига" (пистон) и фольксваген "Туарег" (руби).... ну ты держись там, Туарег :))))
> Это как сравнивать советский мопед "Рига" (пистон) и фольксваген "Туарег" (руби).Это как сравнивать советский мопед и стремный китайский мотороллер. Ездят конечно оба, но оба медленные и с рядом проблем. Главной из которых является ездок, пытающийся доказать что круче него только яйца.
> удобный как Ruby
> быстрый как СиКак они до такого догадались? До них все пытались сделать ровно наоброт.
Я так понимаю, что сравнительные бенчмарки с С или Go решили не приводить только из скромности. И вообще джентельмены верят на слово, сказали "производительность Си", значит так и есть.
Вы так говорите как будто у Go производительность на уровне С... Единственный язык который достиг цели быть высокоуровневым и иметь производительность на уровне С это Swift."As an aside, my Swift implementation of the Mersenne Twister ended up 20% faster than the official mt19937-64.c implementation. Curious to understand what I had done, I ended up “fixing” the C version to be just as fast as the Swift version. Yes, it’s true: with a little tuning, C can be just as fast as Swift.
Welcome to C with love." - http://www.cocoawithlove.com/blog/2016/05/19/random-numbers....
> Getting C-level performance in Swift for numerical algorithms is quirky but not particularly difficult. If you limit yourself to value types (no classes or existentials), use unsafe pointers and tuples instead of arrays, use overflow discarding operators &+/&-/&* instead of normal +/-/*, use while or repeat/while for your loops, then Swift and clang C will generally compile to identical instructions.Так что
>Единственный язык который достиг цели быть высокоуровневым и иметь производительность на уровне С это Lisaac.
фикс.
>> Getting C-level performance in Swift for numerical algorithms is quirky but not
>> particularly difficult. If you limit yourself to value types (no classes or existentials)В результате пока сишник просто пишет код, адепт Новых Модных Языков получает знатный брейнфак с заучиванием всех интимных особенностей своего 100-мегабайтного рантайма и где он может стормозить и лагнуть невовремя.
Как там у жабистов говорится? Write once, profile everywhere? :D
Если "official implementation" подразумевает эталонность, то эталонность обычно подразумевает правильность работы и никак не быстродействие.
> эталонность обычно подразумевает правильность работы и никак не быстродействие.одно другому никак не мешает.
> Вы так говорите как будто у Go производительность на уровне С...Не я так говорю, а вы так интерпретируете мои слова. Go был упомянут по совсем другой причине - он решает схожую задачу, но для питона. Это не было целью его создания, но так получилось, что основная масса программистов в Go приходит с питона. При этом замечу, что производительность Go конечно выше питона, но все же раза в три уступает C. И это при семилетнем возрасте, ресурсах гугла, именитых авторах и без камня на шее в виде попыток сохранить совместимость с каким либо языком на уровне синтаксиса. Так что на этом фоне заявления авторов кристалла про скорость как у С(даже не плюсов, а голого С) как минимум вызывают скептическую усмешку.
> Единственный язык который достиг цели быть высокоуровневым и иметь производительность на уровне С это Swift.
Ну вот зачем этот маркетоидный булщит? Про жабу точно такие песни были.
> Ну вот зачем этот маркетоидный булщит? Про жабу точно такие песни были.При этом Java (с JIT, разумеется) довольно близко подходит к C по производительности.
какое, на фиг, тестирование производительности у суровой альфы? Хоть где-то показывает хороший результат - и то хорошо
Если ставишь задачей производительность, то она должна быть уже в альфе. А то создатели rakkudo(реализация perl6) тоже рассказывали "сначала все фичи, а потом оптимизация", "это же только бета, к релизу всё будет тип-топ со скоростью", но пять лет прошло, релиз первой версии в прошлом году состоялся, а оно до сих пор неюзабельно по причине крайне низкой производительности и перспектив ее улучшения не видно.
Ну и как заметили выше, никто не делает языки с целью быть медленными, все хотят максимально возможной производительности при одновременном достижении других задач. Авторы Ruby не исключение и оптимизировали свое детище насколько это было для них возможно. А если авторы кристалла громогласно заявляют, что собираются сделать язык максимально приближенный к рубину, но при этом на порядок более быстрый, значит у них должны быть идеи как это сделать и эти идеи должны быть видны уже в альфе, иначе это не идеи, а пустые обещания.
> rakkudo(реализация perl6)Там его пилят какие-то аутисты, ушибленные рубями. Добавили ещё столько же операторов (причём ОЧЕНЬ специализированных), убили простые типы, сломали совместимость, завязались на jvm.
Хотя казалось бы, вектор развития (в рамках perl6) очевиден:
* use strict/use warnings по дефолту,
* сделать синтаксис однозначно разбираемым (пусть и ценой частичной потери совместимости),
* стандартизировать объектную систему (чтобы положить конец её переизобретению в виде Moo/Moose/Mouse и пр.),
* признать RPerl официальным подмножеством (как cpython),
* выкинуть из базы всё legacy типа CGI, DB_File и прочий шлак.
> Если ставишь задачей производительность, то она должна быть уже в альфе.Не должна, т.к. в первой альфе намного важнее совсем другое.
Ну и да, производительность уже видна, судя по новости, т.к. где-то опережает Руби в 40 раз, но так же, где-то и отстаёт от него -- ну а вы ждали от самой первой альфы сразу реализации всех их планов ?> Ну и как заметили выше, никто не делает языки с целью быть медленными, все хотят максимально возможной производительности при одновременном достижении других задач.
Конечно ни у кого нет цели делать медленный язык, но так же не у всех целью является сделать быстрый язык.
> Авторы Ruby не исключение и оптимизировали свое детище насколько это было для них возможно.
И как раз авторы Питона и Руби не стремились к созданию быстрого языка, а стремились к созданию удобного, гибкого и ни к чему не привязанного языка. Поэтому они создали интерпретаторы своих языков, что никак не сочетается с быстродействием. И конечно по возможности они стали их ускорять, но они понимали, что уровня Си им никогда не добиться, они даже к этому не стремились.
> А если авторы кристалла громогласно заявляют, что собираются сделать язык максимально приближенный к рубину, но при этом на порядок более быстрый, значит у них должны быть идеи как это сделать и эти идеи должны быть видны уже в альфе, иначе это не идеи, а пустые обещания.
В самой первой альфа версии обычно пытаются сделать, чтобы просто работало, а для производительности нужна ещё сильная оптимизация.
Ну а если они заявляют, то идеи у них скорее всего есть, но для их реализации нужно время. Ну а может это просто их мечта, без идей, но со стремлением добиться своей цели по ходу работы.> иначе это не идеи, а пустые обещания.
Я не заметил, чтобы они что-то кому-то обещали.
Вообще-то первая альфа была зарелизена два года назад, развитие началось четыре года назад. Ну и для очередного выходца из криокамеры сообщаю, что разница в скорости на основе "интерпретатор или компилятор" осталась в далеком прошлом, есть куда более серьезные факторы, ограничивающие производительность. И этот язык тоже никогда не будет равен С по скорости.
Вообще-то далеко не все хотят максимально возможной производительности, ей часто жертвуют ради каких-то ещё фич. Тот же питон взять - приоритеты совсем другие. И если у этих товарищей желаемый баланс другой - логично, что и диапазон возможного будет другим.А что до кристала - ну так кое-где там и виден прирост. Но требовать от альфы, чтобы она была быстрее везде - чересчур. Это даже для первого релиза чересчур, собственно.
А отломать динамическую типизацию, отказавшись от фич, которые от неё зависят - вкупе с нормальной компиляцией - вполне нормальная заявка на победу, вагон их таких - те же HipHop и Cython вспоминаются сходу.
> Я так понимаю, что сравнительные бенчмарки с С или Go решили не приводить только из скромности. И вообще джентельмены верят на слово, сказали "производительность Си", значит так и есть.Читать надо внимательней.
Там не написано, что у него производительность, как у Си, а написано лишь то, что такая производительность является целью авторов языка.
Не факт, что они добьются своей цели.
И уж тем более они не продемонстрируют приближённые к цели результаты в альфа версии, т.к. это является очень сложной задачей и её реализация растянется на годы.
> на текущей альфа-стадии развития в одних тестах Crystal опережает Ruby в 40 разэто называется "эффект низкой базы". Сравните с cpython или go и получите свои (минус?) полтора-два раза.
Тем временем, уже есть GI-привязки:https://github.com/jhass/crystal-gobject
Молодой язык, а гномовские либы можно использовать на полную катушку.
Логика бессмысленная - язык Ruby удобен, но не быстр. С быстр, но не удобен. Нужно создать язык "Crystal" который будет иметь удобство Ruby и скорость С.
ВОПРОС - почему нельзя просто Ruby сделать быстрым как С и всё???
> Логика бессмысленная - язык Ruby удобен, но не быстр. С быстр, но
> не удобен. Нужно создать язык "Crystal" который будет иметь удобство Ruby
> и скорость С.
> ВОПРОС - почему нельзя просто Ruby сделать быстрым как С и всё???потому что философия языка позволяет все сделать как тебе удобно, 100500 способами. Ну и конечно GC не хитрый. Попробуй, например, с помощью Net::HTTP из stdlib скачать какой нибудь относительно большой файл с сети, или пропарсить несколько тысяч xml тем же Builder. С extenstions наше все. Узкие места подпереть придется.
потомучто там:- идеология бредовая - "Все есть объект"
- возможность манкипатчить в рантаймеи может чтото еще, что мешает - не особо использовал руби
> - идеология бредовая - "Все есть объект"чем плохо иметь простую и регулярную модель языка, в которой всё предельно понятно и сведено к единственной сущности - объект?
> - возможность манкипатчить в рантайме
манкипатчить технически можно где угодно на любых языках (иногда со вставками "станного кода") и везде это плохо.
Но вот чем плохо иметь возможность в динамике переопределять методы объектов и классов?
>> почему нельзя просто Ruby сделать быстрым как С и всё???
> Но вот чем плохо иметь возможность в динамике переопределять методы объектов и
> классов?Оптимизация-с сэр.
Вы не поверите, но вызывать нужный метод каждый раз через таблицу может оказаться ощутимо медленне прямого вызова или инлайна. А уж тем более, тот же простой ADD REG1, REG2 будет куда быстрее какого-нибудь универсального
PUSH REG1
PUSH REG2
CALL [METHOD_TABLE + ADD_METHOD]
...
ADD_METHOD:
stackframe creation
MOV REG, [STACKREG-4]
ADD REG, [STACKREG-8]
RET
особенно когда считать придется действительно много.Ваш Кэп
Еще бы питонисты и рубисты понимали что ты написал :)
А как вы собрались это делать без JIT?
> Но вот чем плохо иметь возможность в динамике переопределять методы объектов и классов?Динамика и производительность/скорость сочетаются чуть лучше, чем никак.
В LuaJIT почему-то сочетаются замечательно.
> В LuaJIT почему-то сочетаются замечательно.http://benchmarksgame.alioth.debian.org/u64q/lua.html
Непохоже. Проигрывает той же жабе.
смотрели бы то на что ссылаетесь
>Lua 5.3.0 Copyright (C) 1994-2015 Lua.org, PUC-Rio
> ВОПРОС - почему нельзя просто Ruby сделать быстрым как С и всё???ОТВЕТ: потому что Ruby - интерпретатор, а Си - компилятор. А интерпретатор никогда по скорости не догонит компилятор. Объяснять почему?
Потому что у интерпретатора при выполнении добавляется промежуточная операция - преобразование текста или байт-кода в машинный код. А компилятор выдаёт сразу машинный код.
Ну а по теме: авторы Crystal пытаются написать Vala :)
Вот зачем они это делают, когда есть Vala - не очень понятно :-)
А если стадия jit занимает доли процента от времени выполнения? А если jit еще и позволяет сгенерировать при этом чуть более эффективный код, который будет выполняться достаточно долго, чтобы перекрыть время затраченное на однократный jit?На самом деле разница в производительности совсем в другом месте. Но ничего, ты со временем наверстаешь пропущенное за десятилетия в криокамере.
Это решает скорее проблему распространения, нежели проблемы производительности.
То, что jit откладывает до рантайма можно было бы сделать на этапе компиляции, тем самым обеспечив себе высокую производительность сразу же после запуска программы, минуя фазу jit. Так не делают лишь потому, что скомпилированные под некоторую архитектуру программы надо распространять по машинам данной архитектуры, некоторые из которых поддерживают одни расширения набора команд, некоторые - другие... Вот и берут некоторое общее подмножество, чтобы добиться работы на всех машинах данной архитектуры.
Ничто не мешает вам пересобрать пакет с либой, чтобы добиться в компилируемых языках более высокой производительности. Вон в Debian это делается в пол-пинка. Gentoo изначально под это заточен. Бери - не хочу.
Единственная проблема в том, что фанатам Java и адептам Jit банально лень. Хочется людям ничего не делать, ни о чём не думать, но чтобы оно всё само заработало и показало хорошие результаты.
Ну давай на этапе компиляции определи мне размер переменной, которая будет считана из конфига или получена иным путем во время выполнения. А ведь в случае иммутабельности после получения инициирующего значения можно сразу определить, можно ли ограничится одним из нативных типов процессора или надо будет оборачивать в какой-нибудь bignum.
> Ну давай на этапе компиляции определи мне размер переменной, которая будет считана
> из конфига или получена иным путем во время выполнения. А ведь
> в случае иммутабельности после получения инициирующего значения можно сразу определить,
> можно ли ограничится одним из нативных типов процессора или надо будет
> оборачивать в какой-нибудь bignum.Вряд ли. Раз мы говорим о jit, значит мы говорим о демоне, ибо иначе
jit не окупится. Если мы говорим о демоне, то он скорее всего он
регулярно перечитывает конфиг, и какая тогда иммутабельность?Короче, сложно представить такую ситуацию. Мысль конечно интересная,
но я не думаю, что мы когда-то столкнёмся с подобным на практике.
> Раз мы говорим о jit, значит мы говорим о демоне, ибо иначе jit не окупится.Еще как окупится!
> Если мы говорим о демоне, то он скорее всего он регулярно перечитывает конфиг, и какая тогда иммутабельность?
Иммутабельность не JIT-а, а переменной в программе, которую JIT оптимизирует. Если мы прочитали число, которое влезает в int и процессор имеет команды для работы с int-ами, то JIT сгенерирует нативный код с такими командами, а если нет, то будет работать обёртка (которая тоже может быть оптимизирована JIT-ом, но уже не так эффективно).
> Иммутабельность не JIT-а, а переменной в программе, которую JIT оптимизирует.Мне право же трудно понять, что Вы подразумевали под "(им)мутабельностью JIT-а". :)
Ну вот на практике в 99.9% случаев можно заранее предсказать (и ограничить) осмысленный диапазон, который будет вполне эффективно реализован. В результате bignum не будет вообще.
Все просто, разница между статической типизацией и динамической типизацией в скомпилированном коде составляет не менее трех раз по производительности и около 3-10 раз по памяти.Crystal - статически типизированный язык.
не нужно.
т.к. для масшабируемых высокопроизводительных приложений есть elixir на базе стабильного и нажежного erlang vm.ну а для всяко типовой фигни и ruby (ROR) сойдет - хоть и медленно но зато более менее привычно и есть много готовых гемов.
Нет никакого erlang vm. Есть BEAM -- но это другое :)
> удобный как Ruby при разработкеРебят, может не надо?
>> удобный как Ruby при разработке
> Ребят, может не надо??
Они изобретают golang?
надеюсь, что нет - убогих полуязыков и так уже многовато
> Crystal развивается новый язык программирования,
> разработчики которого намерены создать язык
> удобный как Ruby при разработке, но быстрый как Си при выполненииА как же Smalltalk? o_O
У которого ни удобства, ни скорости?
«Наша информационная среда (LPE)
приобрела свою мощность, дружественный
интерфейс и расширяемость благодаря
использованию Smalltalk — самой передо-
вой системы для разработки пользователь-
ских интерфейсов на сегодняшний день.»
Интересно было бы увидеть синтаксические отличия от руби. Статическая типизация с параметрическим полиморфизмом, и возможность компиляции -- весьма недурно.
Ещё одна Scala.
Совсем не Scala. Но перспектив никаких.
> Ещё одна Scala.По своей идеологии скорее Rust.
>> Ещё одна Scala.
> По своей идеологии скорее Rust.У раста, справедливости ради, в "идеологии" много внимания уделяется управлению памятью. И оно по умолчанию "ручное" (с поддержкой компилятора и прочими плюшками).
Ну и "классического" OOП в расте нет.
Где реклама Kotlin?
Хочу си как ява как паскаль!
ява и так как с, только урезана и объектно ориентированна
> ява и так как с, только урезана и объектно ориентированнаНифига себе урезана - рантайма на 100 метров. А оопешные фичи это здорово. Но только не когда у тебя работа со строками окажется в 100 раз медленнее чем ты ожидал и не когда gc начнет тормозить и лагать именно там где этого меньше всего хотелось.
"производительность С" доставило :)
когда он в 1-й тройке-пятерке семых шустрых был? :)
> когда он в 1-й тройке-пятерке семых шустрых был? :)Он обычно второй в очереди - сразу после ассемблера. Это, конечно, зависит от, но критичные к скорости вещи не зря пишут на си + ассемблерные вставки. Но ты можешь показать нам чудо - перепиши какой-нибудь декодер H.264 на своем любимом ЯП и покажи как малохольный компьютер без аппаратного ускорителя вдруг заиграет мажорское FullHD. Тебе сразу толпа юзерей памятник поставит при жизни.
>Он обычно второй в очереди - сразу после ассемблера.Так вот с им родимым и сравнивают, когда особо пропиариться хотят.
Даже Оракул с Явой в этом был замечен. :)
Некоторые, из ныне забытых, были даже быстрее оного. :)P.S. Язык (компьютерный) сам по себе не быстрый и не медленный. Если безотносительно его реализации и программиста рассматривать. :)