Здравствуйте, Aртём, Вы писали:
KP>>Ну, все изучать Rust!
Aё>Можно вкратце (списком) преимущества Rust перед Node.JS и Julia?
Честно говоря, не смогу ответить на твой вопрос, все же вообще не сталкивался с Node.JS или Julia. Да и выглядят они как узкоспециализированные решения, так что сравнивать вроде как и нечего
Общего между тремя как минимум использование LLVM и libuv для асинхронного ввода-вывода, поддержка функциональной парадигмы (функция как объект).
Вики о Rust:
Rust is a general purpose, multi-paradigm, compiled programming language... Known as rustc, it successfully compiled itself in 2011. The self-hosted compiler uses LLVM as its backend.
Со странички libuv:
libuv is a multi-platform support library with a focus on asynchronous I/O. It was primarily developed for use by Node.js, but it's also used by Mozilla's Rust language, Luvit, Julia, pyuv, and others.
Вики о Julia:
Julia is a high-level dynamic programming language designed to address the requirements of high-performance numerical and scientific computing while also being effective for general purpose programming. Julia's core is implemented in C and C++, its parser in Scheme, and the LLVM compiler framework is used for just-in-time generation of machine code. The standard library is implemented in Julia itself, using the Node.js's libuv library for efficient, platform-independent I/O.
Здравствуйте, Aртём, Вы писали:
Aё>Здравствуйте, kaa.python, Вы писали:
Aё>Общего между тремя как минимум использование LLVM и libuv для асинхронного ввода-вывода, поддержка функциональной парадигмы (функция как объект).
Мне кажется несколько неправильным сравнивать статически типизированный язык общего назначения с динамически типизированными языками разработанными под конкретные задачи. При этом я не вижу никакого превосходства со стороны Node.JS, но вот встроенная математика в Julia явно (особенно, когда допилят хотя бы до уровня Rust) посильнее (но, она в свою очередь проигрывает Python с библиотеками).
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, Aртём, Вы писали:
Aё>>Здравствуйте, kaa.python, Вы писали:
Aё>>Общего между тремя как минимум использование LLVM и libuv для асинхронного ввода-вывода, поддержка функциональной парадигмы (функция как объект).
KP>Мне кажется несколько неправильным сравнивать статически типизированный язык общего назначения с динамически типизированными языками разработанными под конкретные задачи. При этом я не вижу никакого превосходства со стороны Node.JS, но вот встроенная математика в Julia явно (особенно, когда допилят хотя бы до уровня Rust) посильнее (но, она в свою очередь проигрывает Python с библиотеками).
Джулия не заточена под одну задачу а JavaScript есть в каждом браузере.
Здравствуйте, Lazin, Вы писали:
L>Джулия не заточена под одну задачу а JavaScript есть в каждом браузере.
Если говорить о Julia, то сложно не согласиться с ее авторами "high-performance dynamic programming language for technical computing". В первую очередь это не язык общего назначения, а язык для мат. расчетов.
Что следует из наличия JavaScript в каждом бразузере я не очень понял. Особенно с учетом того, что это самый каждый браузер может на компьюетре и не стоять, или быть чем-то типа Links
Последнее время замечаю желания людей сравнить Rust с каким-либо языком. Совсем уж экзотических сравнений типа тех, что хотел бы видеть Артем (Rust с Julia и Node.JS
) у меня нет, а вот сравнение Rust с Go на прошлой неделе появилось.
Сам оценить качество этого сравнения я не могу в силу незнания Go, так что было бы интересно выслушать и замечания
Здравствуйте, kaa.python, Вы писали:
KP>Последнее время замечаю желания людей сравнить Rust с каким-либо языком. Совсем уж экзотических сравнений типа тех, что хотел бы видеть Артем (Rust с Julia и Node.JS
) у меня нет, а вот сравнение Rust с Go на прошлой неделе появилось.
А что экзотического в Node.JS который JScript на сервере, т.е. позволяет писать автономные и достаточно производительные приложения? Если Node.JS+Julia покрывает 100% гипотетических применений языка общего назначения Rust- почему бы не спросить сравнение?
Здравствуйте, Aртём, Вы писали:
Aё>А что экзотического в Node.JS который JScript на сервере, т.е. позволяет писать автономные и достаточно производительные приложения? Если Node.JS+Julia покрывает 100% гипотетических применений языка общего назначения Rust- почему бы не спросить сравнение?
Кстати Node.JS компилируемый или это какой-то особый интерпретатор без браузера? (Julia знаю что на llvm)
Я как-то привык что javascript это браузер. Какие у Node.JS библиотеки для работы, например, с оконными виджетами, графикой, файловой системой, сетью, мультимедиа, базами данных, низкоуровневыми API операционной системы, есть ли там интеграция с другими языками?
Здравствуйте, x-code, Вы писали:
XC>Кстати Node.JS компилируемый или это какой-то особый интерпретатор без браузера? (Julia знаю что на llvm)
JIT- не интерпретатор.
XC>Я как-то привык что javascript это браузер. Какие у Node.JS библиотеки для работы, например, с оконными виджетами, графикой, файловой системой, сетью, мультимедиа, базами данных, низкоуровневыми API операционной системы, есть ли там интеграция с другими языками?
Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, Lazin, Вы писали:
L>>Джулия не заточена под одну задачу а JavaScript есть в каждом браузере.
KP>Если говорить о Julia, то сложно не согласиться с ее авторами "high-performance dynamic programming language for technical computing". В первую очередь это не язык общего назначения, а язык для мат. расчетов.
We want something as usable for general programming as Python, as easy for statistics as R, as natural for string processing as Perl, as powerful for linear algebra as Matlab, as good at gluing programs together as the shell. Something that is dirt simple to learn, yet keeps the most serious hackers happy. We want it interactive and we want it compiled.
KP>Что следует из наличия JavaScript в каждом бразузере я не очень понял. Особенно с учетом того, что это самый каждый браузер может на компьюетре и не стоять, или быть чем-то типа Links
То, что JS есть в каждом браузере это превосходство. Огромное количество людей уже умеют программировать на нем, есть огромное количество инструментов и всего такого. Это язык будущего, несмотря на всю говнистость. А rust конечно крут, но он даже не начался еще и не факт что он станет чем-то большим, чем очередной язык программирования для энтузиастов.
L>We want something as usable for general programming as Python, as easy for statistics as R, as natural for string processing as Perl, as powerful for linear algebra as Matlab, as good at gluing programs together as the shell. Something that is dirt simple to learn, yet keeps the most serious hackers happy. We want it interactive and we want it compiled.
А ты сейчас используешь Julia для каких-нибудь задач? Если да, то для каких (предметная область, размер проектов, роль Julia в проекте)?
Мне интересно, до какого уровня язык уже поднялся, насколько можно на него полагаться.
Здравствуйте, Nuzhny, Вы писали:
N>А ты сейчас используешь Julia для каких-нибудь задач? Если да, то для каких (предметная область, размер проектов, роль Julia в проекте)? N>Мне интересно, до какого уровня язык уже поднялся, насколько можно на него полагаться.
я его только для экспериментов с ML пытался использовать, очень поверхностно
Здравствуйте, kaa.python, Вы писали:
KP>Вышла новая версия языка Rust с номером 0.3. Несмотря на то, что говорить о каком бы то ни было коммерческом использовании языка рано, он обретает все более и более четкие формы, появляется понимание куда же он движется. Лично меня то что я вижу очень и очень радует. KP>С официальным анонсом можно ознакомиться тут. Кроме того, я сделал перевод обзора основных нововведений несколько дополнив его, относительно официальной версии.
KP>P.S. в моем переводе есть пара мест, помеченных "(как это перевести?)". Буду очень благдарен за идеи как это лучше сделать
Сформулирую поажалуй, почему я не верю в успех rust. Несмотря на всю движуху, не видать ему ничего более примечательного, нежели статус нишевого языка для сетевых приложений или приложений, не требующих высокой производительности.
Причина №1 — модель памяти. Rust это data ownership, как и в erlang. Data ownership это хорошо, это когда каждый объект в памяти принадлежит определенному потоку, ну и может иногда менять хозяина. Проблема в том, что это совсем не соответствует тому, как работает железо. Там как раз нет никакого ownership-а и любой поток может обращаться к любому вирт. адресу. В этом нет проблемы, если модель памяти rust ложится на архитектуру приложения хорошо, а что если нет? Что, если например у вас есть хэш таблица, в которой лежат пользовательские сессии и вам нужно из разных потоков часто ее читать и обновлять? Положить ее в общую кучу, забирать по очереди, читать/писать и потом класть обратно? А что если один из потоков получил owned pointer и помер? А что если он получил owned pointer на таблицу сессий и был вытеснен? Чем это лучше обычного lock-а? На Си я могу написать хэш таблицу с fine-grained синхронизацией или взять готовую и все это будет быстро работать. В rust я наверное тоже это смогу, но мне придется обойти как-нибудь его модель памяти. Ну и с появлением hardware lock elision в процессорах с архитектурой haswell все становится еще интересней, так как мне больше не нужно заморачиваться, я могу просто взять и использовать coarse grained lock, просто завернуть свою хэш таблицу в крит. секцию и все будет работать также, как и с fine grained locking.
Причина №2 — сборка мусора. Я за сборку мусора или за то, чтобы ее небыло, но не за то, чтобы она была опциональной. Если я хочу, чтобы мое приложение на rust не использовало сборщик мусора, то я буду управлять памятью вручную, но при этом какая-нибудь библиотека может от него зависеть и в итоге, мой сетевой сервис будет периодически лагать. Я подозреваю что тут будет ситуация как с shared_ptr в С++, в том смысле, что все используют shared_ptr даже там, где он не нужен. Т.е. написать нетривиальный код не использующий GC будет крайне сложно. Помимо этого, я не нашел нигде инфы о том, какой GC там планируется. Тип GC очень сильно влияет на написание расширений на Си, вот скажем в Go прямо говорят, что там будет консервативный GC, который будет сканировать память, выделеную сишным кодом, поэтому можно спокойно передавать туда указатели. Ну а в D рекомендуется указтели pin-ить, перед тем как передавать во внешнюю среду.
Причина №3 — таски. Насколько я понял, rust позволяет использовать как обычные потоки, так и "зеленые", при этом, опять же, насколько я знаю, генератор кода ничерта не знает, где будет выполняться код ф-ии — в нормальном потоке или в зеленом таске. Это означает жопу со всякими Си-шными расширениями. Если Си-шный код использует TLS, то его нельзя исполнять в зеленом потоке, в этом случае Go, например, выполняет код в специально выделенном потоке, а таск ждет, когда этот код отработает. Я довольно долго читал их список рассылки и все это время они придерживались мнения, что это все забота программиста.
Здравствуйте, Lazin, Вы писали:
L>Причина №1 — модель памяти. Rust это data ownership, как и в erlang. Data ownership это хорошо, это когда каждый объект в памяти принадлежит определенному потоку, ну и может иногда менять хозяина. Проблема в том, что это совсем не соответствует тому, как работает железо. Там как раз нет никакого ownership-а и любой поток может обращаться к любому вирт. адресу.
Это давно не совсем так. Хотя бы из-за NUMA, проблем с разделением линий кэша и т.п. Ну и ещё можно вспомнить GPU, конечно же. На модель Rust оно вообще ложится идеально.
L>В этом нет проблемы, если модель памяти rust ложится на архитектуру приложения хорошо, а что если нет? Что, если например у вас есть хэш таблица, в которой лежат пользовательские сессии и вам нужно из разных потоков часто ее читать и обновлять?
Это больше из серии: "Доктор, у меня болит, когда я так делаю. Значит, не делайте так!". Классический вариант — это отдельная задача, которая работает сервером сессий. Остальные задачи посылают серверу задач запросы типа "взять элемент"/"положить элемент".
Ну и если очень хочется, то в Rust есть ARC: http://winningraceconditions.blogspot.ch/2012/09/rust-3-typesafe-shared-state.html
L>Причина №2 — сборка мусора. Я за сборку мусора или за то, чтобы ее небыло, но не за то, чтобы она была опциональной.
Как раз в Rust это будет скоро возможно.
L>Причина №3 — таски. Насколько я понял, rust позволяет использовать как обычные потоки, так и "зеленые", при этом, опять же, насколько я знаю, генератор кода ничерта не знает, где будет выполняться код ф-ии — в нормальном потоке или в зеленом таске.
Ну так и надо. TLS вообще должен умереть, как кривой хак.
Здравствуйте, Lazin, Вы писали:
L>Сформулирую поажалуй, почему я не верю в успех rust. Несмотря на всю движуху, не видать ему ничего более примечательного, нежели статус нишевого языка для сетевых приложений или приложений, не требующих высокой производительности.
Во многом согласен с приведенным ниже. Кстати, а что считать высокой производительностью? Выжимание всех резервов на чистом Си? Все же писать медленный код на C++ проще-простого.
L>Причина №1 — модель памяти. Rust это data ownership, как и в erlang. Data ownership это хорошо, это когда каждый объект в памяти принадлежит определенному потоку, ну и может иногда менять хозяина. Проблема в том, что это совсем не соответствует тому, как работает железо. Там как раз нет никакого ownership-а и любой поток может обращаться к любому вирт. адресу. В этом нет проблемы, если модель памяти rust ложится на архитектуру приложения хорошо, а что если нет?
Видимо в этом случае Rust не лучший выбор? Хотя, мне кажется, что в такой ситуации просто нужно проектировать архитектуру исходя из ограничений накладываемых языком, они же не с проста появились.
L>Что, если например у вас есть хэш таблица, в которой лежат пользовательские сессии и вам нужно из разных потоков часто ее читать и обновлять? Положить ее в общую кучу, забирать по очереди, читать/писать и потом класть обратно? А что если один из потоков получил owned pointer и помер?
Как вариант, ее можно положить в отдельный Таск и через него работать. Либо взять RWArc (или как там его сейчас звать) и получить классическую модель общей памяти. Пусть это и перечеркивает на корню идею с моделью памяти в Rust.
L>Причина №2 — сборка мусора. Я за сборку мусора или за то, чтобы ее небыло, но не за то, чтобы она была опциональной. Если я хочу, чтобы мое приложение на rust не использовало сборщик мусора, то я буду управлять памятью вручную, но при этом какая-нибудь библиотека может от него зависеть и в итоге, мой сетевой сервис будет периодически лагать. Я подозреваю что тут будет ситуация как с shared_ptr в С++, в том смысле, что все используют shared_ptr даже там, где он не нужен. Т.е. написать нетривиальный код не использующий GC будет крайне сложно.
Думаю, так и будет. Хотя если хочется полностью ручного управления памятью – то Rust не лучший выбор. Либо его стоит использовать как "более удобный Си" отрубив все, кроме std с собственными аллокаторами и GC (там это довольно элементарно делается).
L>Причина №3 — таски. Насколько я понял, rust позволяет использовать как обычные потоки, так и "зеленые", при этом, опять же, насколько я знаю, генератор кода ничерта не знает, где будет выполняться код ф-ии — в нормальном потоке или в зеленом таске. Это означает жопу со всякими Си-шными расширениями. Если Си-шный код использует TLS, то его нельзя исполнять в зеленом потоке, в этом случае Go, например, выполняет код в специально выделенном потоке, а таск ждет, когда этот код отработает. Я довольно долго читал их список рассылки и все это время они придерживались мнения, что это все забота программиста.
Да, это забора программиста. Но, казалось бы, программист при использовании низкоуровневого языка, зная такие аббревиатуры TLS должен умет выбрать между зелеными и обычными потоками? Если нет, то лучше использовать все в конфигурации "по умолчанию".
В целом, да, язык очень нишевый, сетевой направленности, написания сложной бизнес-логики критичной к производительности (не на столько, что бы микросекунды выжимать, но на уровне "среднего C++"), возможно язык для драйверов и другого низкоуровневого кода. Просто лично для меня, это именно то что нужно. Как раз нужные области, достаточная скорость, ограничение возможности подложить очень уж пакостную бомбу в Си/С++ стиле.
Здравствуйте, Cyberax, Вы писали:
L>>Причина №1 — модель памяти. Rust это data ownership, как и в erlang. Data ownership это хорошо, это когда каждый объект в памяти принадлежит определенному потоку, ну и может иногда менять хозяина. Проблема в том, что это совсем не соответствует тому, как работает железо. Там как раз нет никакого ownership-а и любой поток может обращаться к любому вирт. адресу. C>Это давно не совсем так. Хотя бы из-за NUMA, проблем с разделением линий кэша и т.п. Ну и ещё можно вспомнить GPU, конечно же. На модель Rust оно вообще ложится идеально.
Возникает несколько вопросов:
1. Планировщик задач в rust NUMA node aware? Я ни разу ни о чем подобном не слышал. Тут нужны аллокатор (из CRT например) и планировщик (планировщик ОС) знающие о NUMA нодах и соответствующая архитектура. Ни разу не слышал о том, что N:M модель упоминалась в контексте NUMA
C>Классический вариант — это отдельная задача, которая работает сервером сессий. Остальные задачи посылают серверу задач запросы типа "взять элемент"/"положить элемент".
Это будет медленнее чем самый обычный lock.
L>>Причина №2 — сборка мусора. Я за сборку мусора или за то, чтобы ее небыло, но не за то, чтобы она была опциональной. C>Как раз в Rust это будет скоро возможно.
А что если 3rd party код на rust, который использует мой код на rust использует GC, а мой код не использует? Опциональный GC это нифига не модульно.
C>Ну так и надо. TLS вообще должен умереть, как кривой хак.
Эм... это как раз не кривой хак, а необходимость, альтернатив нет. Где функции вроде errno должны хранить свое состояние? Очень часто всякие навороченные параллельные алгоритмы используют TLS.
Здравствуйте, Lazin, Вы писали:
L>1. Планировщик задач в rust NUMA node aware? Я ни разу ни о чем подобном не слышал. Тут нужны аллокатор (из CRT например) и планировщик (планировщик ОС) знающие о NUMA нодах и соответствующая архитектура. Ни разу не слышал о том, что N:M модель упоминалась в контексте NUMA
Речь идёт об изолировании данных. Нынче NUMA — все cache coherent, так что оно всё будет само работать, если к одним и тем же данным не будет обращений из разных NUMA-сегментов.
Более умный планировщик на уровне Rust помог бы, но не является обязательным.
C>>Классический вариант — это отдельная задача, которая работает сервером сессий. Остальные задачи посылают серверу задач запросы типа "взять элемент"/"положить элемент". L>Это будет медленнее чем самый обычный lock.
И не будет иметь никакого значения в типичном случае использования — в сетевых серверах, например.
C>>Как раз в Rust это будет скоро возможно. L>А что если 3rd party код на rust, который использует мой код на rust использует GC, а мой код не использует? Опциональный GC это нифига не модульно.
Должно работать. Ну и по идее, есть естественная граница — пределы задачи.
C>>Ну так и надо. TLS вообще должен умереть, как кривой хак. L>Эм... это как раз не кривой хак, а необходимость, альтернатив нет.
Есть.
L>Где функции вроде errno должны хранить свое состояние? Очень часто всякие навороченные параллельные алгоритмы используют TLS.
Функций вроде errno не должно быть. И какие навороченные алгоритмы используют TLS?
Здравствуйте, kaa.python, Вы писали:
KP>Видимо в этом случае Rust не лучший выбор? Хотя, мне кажется, что в такой ситуации просто нужно проектировать архитектуру исходя из ограничений накладываемых языком, они же не с проста появились.
Т.е. нужно делать все хорошо с самого начала? Ооооок
KP>Как вариант, ее можно положить в отдельный Таск и через него работать. Либо взять RWArc (или как там его сейчас звать) и получить классическую модель общей памяти. Пусть это и перечеркивает на корню идею с моделью памяти в Rust.
Отдельный таск это как lock только хуже. RWArc — это то о чем я говорил, когда писал о том, что придется обходить эту модель памяти в каждом нетривиальном случае.
KP>Да, это забора программиста. Но, казалось бы, программист при использовании низкоуровневого языка, зная такие аббревиатуры TLS должен умет выбрать между зелеными и обычными потоками? Если нет, то лучше использовать все в конфигурации "по умолчанию".
Проблема в том, что программист не знает заранее что использует TLS а что нет. Придется делать аудит всего стороннего кода, который может к тому же меняться. Многие программисты вообще не в курсе таких проблем и будут потом писать в интернете отчеты о том, какой этот rust глючный. Лучше бы делали что-то одно, либо как в Go — всегда зеленые потоки и при вызовах стороннего кода таск pin-ится, а весь рантайм, в том числе все I/O знает о планировщике (эдакий erlang с OTP), либо вообще ничего подобного в рантайме нет.
KP>В целом, да, язык очень нишевый, сетевой направленности, написания сложной бизнес-логики критичной к производительности (не на столько, что бы микросекунды выжимать, но на уровне "среднего C++"), возможно язык для драйверов и другого низкоуровневого кода. Просто лично для меня, это именно то что нужно. Как раз нужные области, достаточная скорость, ограничение возможности подложить очень уж пакостную бомбу в Си/С++ стиле.
Для того, чтобы "не подложить бомбу" a-la с++ достаточно отказаться от арифметики указателей в пользу slice-ов (a-la Go) и неявных преобразований типов, IMO. Вот это вот все — overengineering на мой неискушенный вкус. Ну и непонятно зачем сетевым сервисам настолько сложная бизнес логика, что без DST и type classes никуда
Здравствуйте, Lazin, Вы писали:
L>Отдельный таск это как lock только хуже. RWArc — это то о чем я говорил, когда писал о том, что придется обходить эту модель памяти в каждом нетривиальном случае.
Вообще-то, в теории task может быть соптимизирован до того же lock'а.
KP>>Да, это забора программиста. Но, казалось бы, программист при использовании низкоуровневого языка, зная такие аббревиатуры TLS должен умет выбрать между зелеными и обычными потоками? Если нет, то лучше использовать все в конфигурации "по умолчанию". L>Проблема в том, что программист не знает заранее что использует TLS а что нет.
А вообще, какие реальные библиотеки используют TLS?
L>Для того, чтобы "не подложить бомбу" a-la с++ достаточно отказаться от арифметики указателей в пользу slice-ов (a-la Go) и неявных преобразований типов, IMO.
Не хватит. Слайсы будут требовать обязательный GC, чтобы слайс не пережил его родителя. Ну и они не решают проблему с гонками — одна из основных фич Rust.
По поводу errno — можно конечно обойтись без TLS, но часто это усложняет архитектуру и перекладывает на программиста ответственность, так как состояние, вынесенное из TLS в переменную и которым теперь управляет программист — не должно передаваться от одного потока другому. Т.е. тут придется либо следить за дисциплиной, либо runtime checks, либо на уровне системы типов это контролировать, это все сложнее чем TLS и еще нужно посмотреть, что из перечисленного больший хак.
