форумы  правила/FAQ  поиск  регистрация  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Язык Crystal пытается совместить производительность Си и удо..."	+/–
Сообщение от opennews (??) on 08-Авг-16, 22:40
В рамках проекта 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
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Язык Crystal пытается совместить производительность Си и удо..."	+/–
Сообщение от Аноним (??) on 08-Авг-16, 22:40
напомнило кассио и эмуляцио HP
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Язык Crystal пытается совместить производительность Си и удо..."	+/–
Сообщение от Онаним on 08-Авг-16, 23:00
Есть же Elixir - и на Ruby похож, и производительность и прочие ништяки от Erlang-а.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	10. "Язык Crystal пытается совместить производительность Си и удо..."	+8 +/–
	Сообщение от Crazy Alex (ok) on 09-Авг-16, 02:07
	Производительность эрланга... Хорошая шутка для тех, кто в курсе, угу
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	14. "Язык Crystal пытается совместить производительность Си и удо..."	+5 +/–
	Сообщение от Аноним (??) on 09-Авг-16, 02:31
	Типа "её нет, но вы держитесь там"?
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	16. "Язык Crystal пытается совместить производительность Си и удо..."	+2 +/–
	Сообщение от Crazy Alex (ok) on 09-Авг-16, 03:06
	Она есть местами, но упоминать его как эталон скорости смешно. Эрланг - вообще не о том. В обработке данных, особенно не укладывающихся в жёсткий паттерн (строки те же) - производительность не фонтан. Плюс иммутабельность - когда на неё хорошо логика ложится, а когда и нет. В архитектуре - с OTP и приложением мозгов нормально, но ничего сверхъестественного. Эрланг берёт надёжностью и целостностью платформы - единственное, с чем можно сравнить в плане поддержки всех фаз жизни софта - Java EE (хотя это всё же очень натянутая аналогия). А скорость... если нужна где-то скорость, то для эрланга самое верное решение - запихнуть в эту точку сишное расширение, подо что он заточен очень хорошо.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	53. "Язык Crystal пытается совместить производительность Си и удо..."	+/–
	Сообщение от rob pike on 09-Авг-16, 16:02
	Под сишные расширения он заточен очень хорошо? С FFI по "удобству" сравнимому только с PerlXS? C NIF, которые блокируют scheduler на сколько хотят и когда хотят? С NIF, которые крашатся, унося с собой всю эрланговскую VM? Да, dirty scheduler помогает отчасти - но когда оно появилось?
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	59. "Язык Crystal пытается совместить производительность Си и удо..."	+/–
	Сообщение от Crazy Alex (ok) on 09-Авг-16, 16:56
	А что не так с Perl XS? Вполне рабочая штука
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	65. "Язык Crystal пытается совместить производительность Си и удо..."	+/–
	Сообщение от Аноним (??) on 09-Авг-16, 18:45
	http://slonik-v-domene.livejournal.com/31403.html Я сомневаюсь в его компетенции сравнить с остальными языками, возмоожно там ещё больший треш и угар, а у сабжа застарелая детская травма. Но вот из личного опыта - с c+lua как-то работать не в пример проще (смотрел на примере движка одной игрушки и rspamd).
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	76. "Язык Crystal пытается совместить производительность Си и удо..."	–1 +/–
	Сообщение от Аноним (??) on 10-Авг-16, 13:09
	> http://slonik-v-domene.livejournal.com/31403.html > Я сомневаюсь в его компетенции сравнить с остальными языками, возмоожно там ещё > больший треш и угар, а у сабжа застарелая детская травма. Но > вот из личного опыта - с c+lua как-то работать не в > пример проще (смотрел на примере движка одной игрушки и rspamd). Нашли с чем сравнивать. Lua — в первую очередь встраиваемый язык (на всякий случай: это ни разу не упрёк, язык хороший), поэтому интеграция с Си в нём, разумеется, на высоте.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	79. "Язык Crystal пытается совместить производительность Си и удо..."	+/–
	Сообщение от rob pike on 10-Авг-16, 16:40
	С LuaJIT еще проще.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	78. "Язык Crystal пытается совместить производительность Си и удо..."	–1 +/–
	Сообщение от rob pike on 10-Авг-16, 16:39
	ASN.1 и HLASM - тоже очень рабочие штуки. Тем не менее, перловый XS остается одним из канонических примеров наиболее сложных и неудобных FFI c почти вертикальной learning curve.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	25. "Язык Crystal пытается совместить производительность Си и удо..."	+/–
	Сообщение от Аноним (??) on 09-Авг-16, 08:20
	а вы использовали elixir для написания  приложений уровня ROR или так по теоретизировать решили? жду с нетерпением бенчарков.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	58. "Язык Crystal пытается совместить производительность Си и удо..."	+1 +/–
	Сообщение от Crazy Alex (ok) on 09-Авг-16, 16:55
	Даже смотреть не стану. Работа со строками и подобным в BEAM быстрой в жизни не была. Ну либо сишными сильно подпёрли, конечно - но тогда нужен либо набор расширений, сравнимый с питоновским, либо сишник в проекте, либо регулярно будете налетать на что-то нештатное, что просаживает производительность. Опять же - я от вебни далёк ежу лет пять как, и даже смотреть в её сторону не собираюсь. Впрочем, помню, что быстрее ROR быть - не велика заслуга.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	89. "Язык Crystal пытается совместить производительность Си и удо..."	+/–
	Сообщение от Аноним (??) on 11-Авг-16, 19:21
	ну в принципе да, что руби что эрланг и эликсир - корнями частично  уходят к ванильному прологу, который весьма труЪ в этом плане.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

3. "Язык Crystal пытается совместить производительность Си и удо..."	+1 +/–
Сообщение от Аноним (??) on 08-Авг-16, 23:12
никогда не писал на ruby, вот от чего дискомфорт
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	24. "Язык Crystal пытается совместить производительность Си и удо..."	+2 +/–
	Сообщение от 12de on 09-Авг-16, 08:16
	начинай, не пожалеешь
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	27. "Язык Crystal пытается совместить производительность Си и удо..."	+/–
	Сообщение от Очень злой и закадровый смех on 09-Авг-16, 08:25
	Начал. Пожалел. Where is your god now?
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	31. "Язык Crystal пытается совместить производительность Си и удо..."	+/–
	Сообщение от Michael Shigorin (ok) on 09-Авг-16, 09:04
	> Начал. Пожалел. О чём именно, кстати?
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	75. "Язык Crystal пытается совместить производительность Си и удо..."	–1 +/–
	Сообщение от Пингвино (ok) on 10-Авг-16, 12:14
	Скорее всего о том, что родился.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

4. "Язык Crystal пытается совместить производительность Си и удо..."	–6 +/–
Сообщение от Xasd (ok) on 08-Авг-16, 23:18
> процессе разработки удобно использовать команду "crystal play" которая формирует web-интерфейс (по умолчанию localhost:8080) для интерактивного выполнения кода на языке Crystal. всё больше и больше плодят тупых дыр (про которые раньше люди и не мыслили).. ..и ведь только недавно идиоты из Intellij Idea писали в своём блоге про их открытый socket-порт -- https://blog.jetbrains.com/blog/2016/05/11/security-update-f.../ ды перестаньиы вы уже плодить без надобности сервера! в том месте там где они не нужны.. хипсторы чёртовы
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	32. "Язык Crystal пытается совместить производительность Си и удо..."	–2 +/–
	Сообщение от Michael Shigorin (ok) on 09-Авг-16, 09:05
	>> процессе разработки > ды перестаньиы вы уже плодить без надобности сервера! Вы опять неправы.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

5. "Язык Crystal пытается совместить производительность Си и удо..."	+2 +/–
Сообщение от YetAnotherOnanym (ok) on 08-Авг-16, 23:24
А на руби удобно писать? Чёрт, жизнь прошла мимо...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	6. "Язык Crystal пытается совместить производительность Си и удо..."	+4 +/–
	Сообщение от Павел (??) on 09-Авг-16, 00:46
	По многим параметрам на Ruby даже приятнее писать чем на Python
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	13. "Язык Crystal пытается совместить производительность Си и удо..."	+5 +/–
	Сообщение от Аноним (??) on 09-Авг-16, 02:31
	Марсианину - несомненно ©
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	33. "Язык Crystal пытается совместить производительность Си и удо..."	+2 +/–
	Сообщение от Michael Shigorin (ok) on 09-Авг-16, 09:06
	> Марсианину - несомненно © А что, венерианская логика уже окончательно решила вопрос с табиками и пробельчиками? :)
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	43. "Язык Crystal пытается совместить производительность Си и удо..."	+6 +/–
	Сообщение от Snm on 09-Авг-16, 11:25
	Да даже чиорт с ними с табами-пробелами, к этому в конце концов привыкаешь со временем. Вот что действительно раздражает - так это встроенные функции, особенно вперемешку с методами классов. Непонятно откуда читать выражение в итоге.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	64. "Язык Crystal пытается совместить производительность Си и удо..."	–1 +/–
	Сообщение от _ (??) on 09-Авг-16, 17:10
	Гугли PEP8 Стандарт между прочим.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	91. "Язык Crystal пытается совместить производительность Си и удо..."	+/–
	Сообщение от Аноним (??) on 12-Авг-16, 23:42
	> Марсианину - несомненно © Фанаты бэйсиков рубаются.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	36. "Язык Crystal пытается совместить производительность Си и удо..."	–1 +/–
	Сообщение от robux (ok) on 09-Авг-16, 09:13
	> По многим параметрам на Ruby даже приятнее писать чем на Python Сравнил тоже! Это как сравнивать советский мопед "Рига" (пистон) и фольксваген "Туарег" (руби). Нет, мопед конечно тоже неплохой, но уровень эргономики несопоставим.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	63. "Язык Crystal пытается совместить производительность Си и удо..."	–2 +/–
	Сообщение от _ (??) on 09-Авг-16, 17:06
	>Это как сравнивать советский мопед "Рига" (пистон) и фольксваген "Туарег" (руби). ... ну ты держись там, Туарег :))))
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	92. "Язык Crystal пытается совместить производительность Си и удо..."	+1 +/–
	Сообщение от Аноним (??) on 12-Авг-16, 23:43
	> Это как сравнивать советский мопед "Рига" (пистон) и фольксваген "Туарег" (руби). Это как сравнивать советский мопед и стремный китайский мотороллер. Ездят конечно оба, но оба медленные и с рядом проблем. Главной из которых является ездок, пытающийся доказать что круче него только яйца.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

7. "Язык Crystal пытается совместить производительность Си и удо..."	+9 +/–
Сообщение от Аноним (??) on 09-Авг-16, 01:18
> удобный как Ruby > быстрый как Си Как они до такого догадались? До них все пытались сделать ровно наоброт.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

8. "Язык Crystal пытается совместить производительность Си и удо..."	+17 +/–
Сообщение от angra (ok) on 09-Авг-16, 01:22
Я так понимаю, что сравнительные бенчмарки с С или Go решили не приводить только из скромности. И вообще джентельмены верят на слово, сказали "производительность Си", значит так и есть.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	9. "Язык Crystal пытается совместить производительность Си и удо..."	–6 +/–
	Сообщение от vdevrvtgrb on 09-Авг-16, 01:46
	Вы так говорите как будто у 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....
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	15. "Язык Crystal пытается совместить производительность Си и удо..."	+1 +/–
	Сообщение от chinarulezzz (ok) on 09-Авг-16, 02:43
	> 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. фикс.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	93. "Язык Crystal пытается совместить производительность Си и удо..."	+1 +/–
	Сообщение от Аноним (??) on 12-Авг-16, 23:45
	>> 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
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	17. "Язык Crystal пытается совместить производительность Си и удо..."	+1 +/–
	Сообщение от Аноним (??) on 09-Авг-16, 04:44
	Если "official implementation" подразумевает эталонность, то эталонность обычно подразумевает правильность работы и никак не быстродействие.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	22. "Язык Crystal пытается совместить производительность Си и удо..."	+/–
	Сообщение от Аноним (??) on 09-Авг-16, 06:33
	> эталонность обычно подразумевает правильность работы и никак не быстродействие. одно другому никак не мешает.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	19. "Язык Crystal пытается совместить производительность Си и удо..."	+2 +/–
	Сообщение от angra (ok) on 09-Авг-16, 05:24
	> Вы так говорите как будто у Go производительность на уровне С... Не я так говорю, а вы так интерпретируете мои слова. Go был упомянут по совсем другой причине - он решает схожую задачу, но для питона. Это не было целью его создания, но так получилось, что основная масса программистов в Go приходит с питона. При этом замечу, что производительность Go конечно выше питона, но все же раза в три уступает C. И это при семилетнем возрасте, ресурсах гугла, именитых авторах и без камня на шее в виде попыток сохранить совместимость с каким либо языком на уровне синтаксиса. Так что на этом фоне заявления авторов кристалла про скорость как у С(даже не плюсов, а голого С) как минимум вызывают скептическую усмешку. > Единственный язык который достиг цели быть высокоуровневым и иметь производительность на уровне С это Swift. Ну вот зачем этот маркетоидный булщит? Про жабу точно такие песни были.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	56. "Язык Crystal пытается совместить производительность Си и удо..."	–2 +/–
	Сообщение от Аноним (??) on 09-Авг-16, 16:47
	> Ну вот зачем этот маркетоидный булщит? Про жабу точно такие песни были. При этом Java (с JIT, разумеется) довольно близко подходит к C по производительности.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	11. "Язык Crystal пытается совместить производительность Си и удо..."	+1 +/–
	Сообщение от Crazy Alex (ok) on 09-Авг-16, 02:09
	какое, на фиг, тестирование производительности у суровой альфы? Хоть где-то показывает хороший результат - и то хорошо
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	18. "Язык Crystal пытается совместить производительность Си и удо..."	+3 +/–
	Сообщение от angra (ok) on 09-Авг-16, 05:11
	Если ставишь задачей производительность, то она должна быть уже в альфе. А то создатели rakkudo(реализация perl6) тоже рассказывали "сначала все фичи, а потом оптимизация", "это же только бета, к релизу всё будет тип-топ со скоростью", но пять лет прошло, релиз первой версии в прошлом году состоялся, а оно до сих пор неюзабельно по причине крайне низкой производительности и перспектив ее улучшения не видно. Ну и как заметили выше, никто не делает языки с целью быть медленными, все хотят максимально возможной производительности при одновременном достижении других задач. Авторы Ruby не исключение и оптимизировали свое детище насколько это было для них возможно. А если авторы кристалла громогласно заявляют, что собираются сделать язык максимально приближенный к рубину, но при этом на порядок более быстрый, значит у них должны быть идеи как это сделать и эти идеи должны быть видны уже в альфе, иначе это не идеи, а пустые обещания.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	21. "Язык Crystal пытается совместить производительность Си и удо..."	+5 +/–
	Сообщение от Аноним (??) on 09-Авг-16, 06:29
	> rakkudo(реализация perl6) Там его пилят какие-то аутисты, ушибленные рубями. Добавили ещё столько же операторов (причём ОЧЕНЬ специализированных), убили простые типы, сломали совместимость, завязались на jvm. Хотя казалось бы, вектор развития (в рамках perl6) очевиден: * use strict/use warnings по дефолту, * сделать синтаксис однозначно разбираемым (пусть и ценой частичной потери совместимости), * стандартизировать объектную систему (чтобы положить конец её переизобретению в виде Moo/Moose/Mouse и пр.), * признать RPerl официальным подмножеством (как cpython), * выкинуть из базы всё legacy типа CGI, DB_File и прочий шлак.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	41. "Язык Crystal пытается совместить производительность Си и удо..."	+/–
	Сообщение от Аномсис on 09-Авг-16, 10:40
	> Если ставишь задачей производительность, то она должна быть уже в альфе. Не должна, т.к. в первой альфе намного важнее совсем другое. Ну и да, производительность уже видна, судя по новости, т.к. где-то опережает Руби в 40 раз, но так же, где-то и отстаёт от него -- ну а вы ждали от самой первой альфы сразу реализации всех их планов ? > Ну и как заметили выше, никто не делает языки с целью быть медленными, все хотят максимально возможной производительности при одновременном достижении других задач. Конечно ни у кого нет цели делать медленный язык, но так же не у всех целью является сделать быстрый язык. > Авторы Ruby не исключение и оптимизировали свое детище насколько это было для них возможно. И как раз авторы Питона и Руби не стремились к созданию быстрого языка, а стремились к созданию удобного, гибкого и ни к чему не привязанного языка. Поэтому они создали интерпретаторы своих языков, что никак не сочетается с быстродействием. И конечно по возможности они стали их ускорять, но они понимали, что уровня Си им никогда не добиться, они даже к этому не стремились. > А если авторы кристалла громогласно заявляют, что собираются сделать язык максимально приближенный к рубину, но при этом на порядок более быстрый, значит у них должны быть идеи как это сделать и эти идеи должны быть видны уже в альфе, иначе это не идеи, а пустые обещания. В самой первой альфа версии обычно пытаются сделать, чтобы просто работало, а для производительности нужна ещё сильная оптимизация. Ну а если они заявляют, то идеи у них скорее всего есть, но для их реализации нужно время. Ну а может это просто их мечта, без идей, но со стремлением добиться своей цели по ходу работы. > иначе это не идеи, а пустые обещания. Я не заметил, чтобы они что-то кому-то обещали.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	45. "Язык Crystal пытается совместить производительность Си и удо..."	+/–
	Сообщение от angra (ok) on 09-Авг-16, 11:56
	Вообще-то первая альфа была зарелизена два года назад, развитие началось четыре года назад. Ну и для очередного выходца из криокамеры сообщаю, что разница в скорости на основе "интерпретатор или компилятор" осталась в далеком прошлом, есть куда более серьезные факторы, ограничивающие производительность. И этот язык тоже никогда не будет равен С по скорости.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	55. "Язык Crystal пытается совместить производительность Си и удо..."	–1 +/–
	Сообщение от Crazy Alex (ok) on 09-Авг-16, 16:42
	Вообще-то далеко не все хотят максимально возможной производительности, ей часто жертвуют ради каких-то ещё фич. Тот же питон взять - приоритеты совсем другие. И если у этих товарищей желаемый баланс другой - логично, что и диапазон возможного будет другим. А что до кристала - ну так кое-где там и виден прирост. Но требовать от альфы, чтобы она была быстрее везде - чересчур. Это даже для первого релиза чересчур, собственно. А отломать динамическую типизацию, отказавшись от фич, которые от неё зависят - вкупе с нормальной компиляцией - вполне нормальная заявка на победу, вагон их таких - те же HipHop и Cython вспоминаются сходу.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	39. "Язык Crystal пытается совместить производительность Си и удо..."	+2 +/–
	Сообщение от Аномсис on 09-Авг-16, 10:16
	> Я так понимаю, что сравнительные бенчмарки с С или Go решили не приводить только из скромности. И вообще джентельмены верят на слово, сказали "производительность Си", значит так и есть. Читать надо внимательней. Там не написано, что у него производительность, как у Си, а написано лишь то, что такая производительность является целью авторов языка. Не факт, что они добьются своей цели. И уж тем более они не продемонстрируют приближённые к цели результаты в альфа версии, т.к. это является очень сложной задачей и её реализация растянется на годы.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

12. "Язык Crystal пытается совместить производительность Си и удо..."	+3 +/–
Сообщение от Аноним (??) on 09-Авг-16, 02:29
> на текущей альфа-стадии развития в одних тестах Crystal опережает Ruby в 40 раз это называется "эффект низкой базы". Сравните с cpython или go и получите свои  (минус?) полтора-два раза.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

20. "Язык Crystal пытается совместить производительность Си и удо..."	–2 +/–
Сообщение от skybon (ok) on 09-Авг-16, 05:56
Тем временем, уже есть GI-привязки: https://github.com/jhass/crystal-gobject Молодой язык, а гномовские либы можно использовать на полную катушку.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

23. "Язык Crystal пытается совместить производительность Си и удо..."	–2 +/–
Сообщение от _KUL (ok) on 09-Авг-16, 06:39
Логика бессмысленная - язык Ruby удобен, но не быстр. С быстр, но не удобен. Нужно создать язык "Crystal" который будет иметь удобство Ruby и скорость С. ВОПРОС - почему нельзя просто Ruby сделать быстрым как С и всё???
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	28. "Язык Crystal пытается совместить производительность Си и удо..."	+1 +/–
	Сообщение от 12de on 09-Авг-16, 08:25
	> Логика бессмысленная - язык Ruby удобен, но не быстр. С быстр, но > не удобен. Нужно создать язык "Crystal" который будет иметь удобство Ruby > и скорость С. > ВОПРОС - почему нельзя просто Ruby сделать быстрым как С и всё??? потому что философия языка позволяет все сделать как тебе удобно, 100500 способами. Ну и конечно GC не хитрый. Попробуй, например, с помощью Net::HTTP из stdlib скачать какой нибудь относительно большой файл с сети, или пропарсить несколько тысяч xml тем же Builder. С extenstions наше все. Узкие места подпереть придется.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	29. "Язык Crystal пытается совместить производительность Си и удо..."	+/–
	Сообщение от Аноним (??) on 09-Авг-16, 08:27
	потомучто там: - идеология бредовая - "Все есть объект" - возможность манкипатчить в рантайме и может чтото еще, что мешает - не особо использовал руби
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	48. "Язык Crystal пытается совместить производительность Си и удо..."	–2 +/–
	Сообщение от Аноним (??) on 09-Авг-16, 12:54
	> - идеология бредовая - "Все есть объект" чем плохо иметь простую и регулярную модель языка, в которой всё предельно понятно и сведено к единственной сущности - объект? > - возможность манкипатчить в рантайме манкипатчить технически можно где угодно на любых языках (иногда со вставками "станного кода") и везде это плохо. Но вот чем плохо иметь возможность в динамике переопределять методы объектов и классов?
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	50. "Язык Crystal пытается совместить производительность Си и удо..."	+1 +/–
	Сообщение от Аноним84701 on 09-Авг-16, 14:35
	>> почему нельзя просто 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 особенно когда считать придется действительно много. Ваш Кэп
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	94. "Язык Crystal пытается совместить производительность Си и удо..."	+/–
	Сообщение от Аноним (??) on 12-Авг-16, 23:48
	Еще бы питонисты и рубисты понимали что ты написал :)
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	98. "Язык Crystal пытается совместить производительность Си и удо..."	+/–
	Сообщение от Аноним (??) on 17-Авг-16, 07:43
	А как вы собрались это делать без JIT?
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	69. "Язык Crystal пытается совместить производительность Си и удо..."	+/–
	Сообщение от Аноним (??) on 09-Авг-16, 23:09
	> Но вот чем плохо иметь возможность в динамике переопределять методы объектов и классов? Динамика и производительность/скорость сочетаются чуть лучше, чем никак.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	80. "Язык Crystal пытается совместить производительность Си и удо..."	+/–
	Сообщение от rob pike on 10-Авг-16, 16:46
	В LuaJIT почему-то сочетаются замечательно.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	81. "Язык Crystal пытается совместить производительность Си и удо..."	–2 +/–
	Сообщение от Аноним (??) on 10-Авг-16, 18:02
	> В LuaJIT почему-то сочетаются замечательно. http://benchmarksgame.alioth.debian.org/u64q/lua.html Непохоже. Проигрывает той же жабе.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	83. "Язык Crystal пытается совместить производительность Си и удо..."	+/–
	Сообщение от ОШИБКА Отсутствуют данные в поле on 10-Авг-16, 22:28
	смотрели бы то на что ссылаетесь >Lua 5.3.0 Copyright (C) 1994-2015 Lua.org, PUC-Rio
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	34. "Язык Crystal пытается совместить производительность Си и удо..."	–2 +/–
	Сообщение от robux (ok) on 09-Авг-16, 09:09
	> ВОПРОС - почему нельзя просто Ruby сделать быстрым как С и всё??? ОТВЕТ: потому что Ruby - интерпретатор, а Си - компилятор. А интерпретатор никогда по скорости не догонит компилятор. Объяснять почему? Потому что у интерпретатора при выполнении добавляется промежуточная операция - преобразование текста или байт-кода в машинный код. А компилятор выдаёт сразу машинный код. Ну а по теме: авторы Crystal пытаются написать Vala :) Вот зачем они это делают, когда есть Vala - не очень понятно :-)
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	40. "Язык Crystal пытается совместить производительность Си и удо..."	–3 +/–
	Сообщение от angra (ok) on 09-Авг-16, 10:22
	А если стадия jit занимает доли процента от времени выполнения? А если jit еще и позволяет сгенерировать при этом чуть более эффективный код, который будет выполняться достаточно долго, чтобы перекрыть время затраченное на однократный jit? На самом деле разница в производительности совсем в другом месте. Но ничего, ты со временем наверстаешь пропущенное за десятилетия в криокамере.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	42. "Язык Crystal пытается совместить производительность Си и удо..."	+2 +/–
	Сообщение от freehck (ok) on 09-Авг-16, 10:56
	Это решает скорее проблему распространения, нежели проблемы производительности. То, что jit откладывает до рантайма можно было бы сделать на этапе компиляции, тем самым обеспечив себе высокую производительность сразу же после запуска программы, минуя фазу jit. Так не делают лишь потому, что скомпилированные под некоторую архитектуру программы надо распространять по машинам данной архитектуры, некоторые из которых поддерживают одни расширения набора команд, некоторые - другие... Вот и берут некоторое общее подмножество, чтобы добиться работы на всех машинах данной архитектуры. Ничто не мешает вам пересобрать пакет с либой, чтобы добиться в компилируемых языках более высокой производительности. Вон в Debian это делается в пол-пинка. Gentoo изначально под это заточен. Бери - не хочу. Единственная проблема в том, что фанатам Java и адептам Jit банально лень. Хочется людям ничего не делать, ни о чём не думать, но чтобы оно всё само заработало и показало хорошие результаты.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	44. "Язык Crystal пытается совместить производительность Си и удо..."	–2 +/–
	Сообщение от angra (ok) on 09-Авг-16, 11:44
	Ну давай на этапе компиляции определи мне размер переменной, которая будет считана из конфига или получена иным путем во время выполнения. А ведь в случае иммутабельности после получения инициирующего значения можно сразу определить, можно ли ограничится одним из нативных типов процессора или надо будет оборачивать в какой-нибудь bignum.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	51. "Язык Crystal пытается совместить производительность Си и удо..."	+/–
	Сообщение от freehck (ok) on 09-Авг-16, 15:50
	> Ну давай на этапе компиляции определи мне размер переменной, которая будет считана > из конфига или получена иным путем во время выполнения. А ведь > в случае иммутабельности после получения инициирующего значения можно сразу определить, > можно ли ограничится одним из нативных типов процессора или надо будет > оборачивать в какой-нибудь bignum. Вряд ли. Раз мы говорим о jit, значит мы говорим о демоне, ибо иначе jit не окупится. Если мы говорим о демоне, то он скорее всего он регулярно перечитывает конфиг, и какая тогда иммутабельность? Короче, сложно представить такую ситуацию. Мысль конечно интересная, но я не думаю, что мы когда-то столкнёмся с подобным на практике.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	62. "Язык Crystal пытается совместить производительность Си и удо..."	+/–
	Сообщение от Аноним (??) on 09-Авг-16, 17:04
	> Раз мы говорим о jit, значит мы говорим о демоне, ибо иначе jit не окупится. Еще как окупится! > Если мы говорим о демоне, то он скорее всего он регулярно перечитывает конфиг, и какая тогда иммутабельность? Иммутабельность не JIT-а, а переменной в программе, которую JIT оптимизирует. Если мы прочитали число, которое влезает в int и процессор имеет команды для работы с int-ами, то JIT сгенерирует нативный код с такими командами, а если нет, то будет работать обёртка (которая тоже может быть оптимизирована JIT-ом, но уже не так эффективно).
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	70. "Язык Crystal пытается совместить производительность Си и удо..."	+/–
	Сообщение от freehck (ok) on 10-Авг-16, 00:26
	> Иммутабельность не JIT-а, а переменной в программе, которую JIT оптимизирует. Мне право же трудно понять, что Вы подразумевали под "(им)мутабельностью JIT-а". :)
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	57. "Язык Crystal пытается совместить производительность Си и удо..."	+/–
	Сообщение от Crazy Alex (ok) on 09-Авг-16, 16:48
	Ну вот на практике в 99.9% случаев можно заранее предсказать (и ограничить) осмысленный диапазон, который будет вполне эффективно реализован. В результате bignum не будет вообще.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	99. "Язык Crystal пытается совместить производительность Си и удо..."	+/–
	Сообщение от Akzhan on 19-Май-17, 13:45
	Все просто, разница между статической типизацией и динамической типизацией в скомпилированном коде составляет не менее трех раз по производительности и около 3-10 раз по памяти. Crystal - статически типизированный язык.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

26. "Язык Crystal пытается совместить производительность Си и удо..."	+/–
Сообщение от Аноним (??) on 09-Авг-16, 08:24
не нужно. т.к. для масшабируемых высокопроизводительных приложений есть elixir на базе стабильного и нажежного erlang vm. ну а для всяко типовой фигни и ruby (ROR) сойдет - хоть и медленно но зато более менее привычно и есть много готовых гемов.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	47. "Язык Crystal пытается совместить производительность Си и удо..."	+/–
	Сообщение от Аноним (??) on 09-Авг-16, 12:24
	Нет никакого erlang vm. Есть BEAM -- но это другое :)
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

30. "Язык Crystal пытается совместить производительность Си и удо..."	+/–
Сообщение от Аноним (??) on 09-Авг-16, 09:00
> удобный как Ruby при разработке Ребят, может не надо?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	35. "Язык Crystal пытается совместить производительность Си и удо..."	+2 +/–
	Сообщение от Michael Shigorin (ok) on 09-Авг-16, 09:10
	>> удобный как Ruby при разработке > Ребят, может не надо? ?
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

37. "Язык Crystal пытается совместить производительность Си и удо..."	+/–
Сообщение от Аноним (??) on 09-Авг-16, 09:22
Они изобретают golang?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	61. "Язык Crystal пытается совместить производительность Си и удо..."	–1 +/–
	Сообщение от Crazy Alex (ok) on 09-Авг-16, 16:57
	надеюсь, что нет - убогих полуязыков и так уже многовато
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

38. "Язык Crystal пытается совместить производительность Си и удо..."	+/–
Сообщение от Demo (??) on 09-Авг-16, 09:26
> Crystal развивается новый язык программирования, > разработчики которого намерены создать язык > удобный как Ruby при разработке, но быстрый как Си при выполнении А как же Smalltalk? o_O
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	60. "Язык Crystal пытается совместить производительность Си и удо..."	+/–
	Сообщение от Crazy Alex (ok) on 09-Авг-16, 16:57
	У которого ни удобства, ни скорости?
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	73. "Язык Crystal пытается совместить производительность Си и удо..."	+/–
	Сообщение от Demo (??) on 10-Авг-16, 08:53
	«Наша   информационная   среда    (LPE) приобрела  свою  мощность,  дружественный интерфейс   и   расширяемость   благодаря использованию  Smalltalk  —  самой  передо­- вой  системы  для  разработки  пользователь­- ских интерфейсов на сегодняшний день.» http://old-dos.ru/books/4/e/9/ComputerPress-1992-04.pdf
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

46. "Язык Crystal пытается совместить производительность Си и удо..."	+/–
Сообщение от Аноним (??) on 09-Авг-16, 12:22
Интересно было бы увидеть синтаксические отличия от руби. Статическая типизация с параметрическим полиморфизмом, и возможность компиляции -- весьма недурно.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

49. "Язык Crystal пытается совместить производительность Си и удо..."	–2 +/–
Сообщение от Аноним (??) on 09-Авг-16, 13:40
Ещё одна Scala.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	54. "Язык Crystal пытается совместить производительность Си и удо..."	+/–
	Сообщение от rob pike on 09-Авг-16, 16:08
	Совсем не Scala. Но перспектив никаких.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	77. "Язык Crystal пытается совместить производительность Си и удо..."	+/–
	Сообщение от Аноним (??) on 10-Авг-16, 13:58
	> Ещё одна Scala. По своей идеологии скорее Rust.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	82. "Язык Crystal пытается совместить производительность Си и удо..."	–1 +/–
	Сообщение от Аноним84701 on 10-Авг-16, 18:14
	>> Ещё одна Scala. > По своей идеологии скорее Rust. У раста, справедливости ради, в "идеологии" много внимания уделяется управлению памятью. И оно по умолчанию "ручное" (с поддержкой компилятора и прочими плюшками). Ну и "классического" OOП в расте нет.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

52. "Язык Crystal пытается совместить производительность Си и удо..."	+1 +/–
Сообщение от Аноним (??) on 09-Авг-16, 15:53
Где реклама Kotlin?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

66. "Язык Crystal пытается совместить производительность Си и удо..."	+/–
Сообщение от Аноним (??) on 09-Авг-16, 19:58
Хочу си как ява как паскаль!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	88. "Язык Crystal пытается совместить производительность Си и удо..."	+/–
	Сообщение от вввв on 11-Авг-16, 14:38
	ява и так как с, только урезана и объектно ориентированна
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	95. "Язык Crystal пытается совместить производительность Си и удо..."	+/–
	Сообщение от Аноним (??) on 12-Авг-16, 23:51
	> ява и так как с, только урезана и объектно ориентированна Нифига себе урезана - рантайма на 100 метров. А оопешные фичи это здорово. Но только не когда у тебя работа со строками окажется в 100 раз медленнее чем ты ожидал и не когда gc начнет тормозить и лагать именно там где этого меньше всего хотелось.
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

90. "Язык Crystal пытается совместить производительность Си и удо..."	–1 +/–
Сообщение от Аноним (??) on 11-Авг-16, 19:22
"производительность С" доставило :) когда он в 1-й тройке-пятерке семых шустрых был? :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	96. "Язык Crystal пытается совместить производительность Си и удо..."	+1 +/–
	Сообщение от Аноним (??) on 12-Авг-16, 23:53
	> когда он в 1-й тройке-пятерке семых шустрых был? :) Он обычно второй в очереди - сразу после ассемблера. Это, конечно, зависит от, но критичные к скорости вещи не зря пишут на си + ассемблерные вставки. Но ты можешь показать нам чудо - перепиши какой-нибудь декодер H.264 на своем любимом ЯП и покажи как малохольный компьютер без аппаратного ускорителя вдруг заиграет мажорское FullHD. Тебе сразу толпа юзерей памятник поставит при жизни.
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	97. "Язык Crystal пытается совместить производительность Си и удо..."	+/–
	Сообщение от КО on 16-Авг-16, 17:07
	>Он обычно второй в очереди - сразу после ассемблера. Так вот с им родимым и сравнивают, когда особо пропиариться хотят. Даже Оракул с Явой в этом был замечен. :) Некоторые, из ныне забытых, были даже быстрее оного. :) P.S. Язык (компьютерный) сам по себе не быстрый и не медленный. Если безотносительно его реализации и программиста рассматривать. :)
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема