Имеет ли смысл использовать Rust для написания библиотеки?

Just for fun можно использовать что угодно.

Не будет ли проблем с интеропом

Об интеропе - у Rust должен быть беспроблемный C FFI в обе стороны.

Какой результирующий объём бинарников, необходимых для распространения?

Несколько месяцев назад статически влинкованный рантайм занимал около 2М.

Пробуй.

Какой результирующий объём бинарников, необходимых для распространения?

Если выкинуть весь std, то очень маленький. Смотри, что уже есть: http://zinc.rs/

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

Не считаю это проблемой, а, скорее, здравым подходом к разработке языка.

Об интеропе - у Rust должен быть беспроблемный C FFI в обе стороны.

А как вообще это происходит? Там же какие то штуки нестандартные в рантайме происходят - планировщик задач свой, потоки свои. Разве можно просто подгрузить (dlopen) библиотеку на расте, получить указатель на функцию (dlsym), вызвать её и всё заработает? Или надо инициализировать рантайм, возможно оно будет запускать какие то свои потоки и тд?

Рантаймов два, один из них - обычные системные нити, никакой зелени. Насчет того, что под капотом - в rust-dev@ была когда-то дискуссия, но цель именно в том, чтобы

можно просто подгрузить (dlopen) библиотеку на расте, получить указатель на функцию (dlsym), вызвать её и всё заработает

вот это всё.

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

А профит какой по сравнению с C{,++}? Стоит ли сейчас на нём заниматься велосипедингом разных мелких вещей?

В данный момент мне вполне удобно писать на C++, но — вдруг там (в Rust'е) что-то очень клёвое есть?

статически влинкованный рантайм занимал около 2М.

Ах да, оптимизация компоновки отсутствует? Или там реально весь рантайм втягивается?

А профит какой по сравнению с C{,++}?

Полноценная система типов вместо костылей, безопасная работа с памятью.

вместо костылей

У меня вбросодатчик активировался. В чём костыльность плюсовой системы типов в сравнении с таковой у Rust?

оёй, товарисч, провоцируете. Почитайте доку

Смотря на сколько just for fun. Если реально так поржать, ваяй. Если всё же хочется потом использовать я б не стал так поступать...

Смотря на сколько just for fun.

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

Если всё же хочется потом использовать я б не стал так поступать...

Почему?

Почему?

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

Стоит ли сейчас на нём заниматься велосипедингом разных мелких вещей?

Если нет цели освоить язык - нет, не стоит.

Ах да, оптимизация компоновки отсутствует?

Ты этим странным термином называешь LTO? Она есть.

Или там реально весь рантайм втягивается?

Зависит.

что-то очень клёвое есть

В отличие от сишечки и крестов там хотя бы есть модули

Ну можно НЕ использовать Night-версии. есть стабильные версии и они не каждую неделю меняются. а на сколько я помню 1,0 выйдет к концу етого года(не помню, давно не глядел)

Тема про Rust и ее не я создал, ух ты.

...на разных платформах. В частности важно, чтобы не было проблем на Windows. ...
... Готовы ли инструментальные средства для генерации DLL на всех платформах? ...

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

Не будет ли проблем с интеропом (C++, Python, Objective C)?

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

Вроде как можно выставить в С-шном стиле биндинги. Насколько это всё будет работать и удобно ли этим будет пользоваться? В биндингах помимо прочего будут callback-и, т.е. библиотека должна нормально дёргать переданные ей указатели на функции.

Тут, скорее всего, проблем быть не должно.

http://doc.rust-lang.org/guide-ffi.html

30 лет жили без модулей в C++ и еще столько же проживут. На киллер-фичу не тянет.

30 лет жили без модулей в C++

В Си++ есть namespace, который частично выполняет функцию модулей.

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

Мне кажется, что «переписывает» - преувеличение. Последние пару месяцев у меня в Мародере код ломается обычно раз-два в неделю и надо просто sed`ом переименовать пару вещей, минут 5-10 отнимает. Что бы семантика менялась и надо было осмысленно код переписать - такое, наверное, раз-другой в месяц бывает, но больше часа тоже не занимало.

Но я, конечно, использую возможности языка и станлартную библиотеку не на 100%, может какие-то модули чаще меняют.

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

А что за библиотека, если не секрет?

Нет, не LTO. Я говорю о выкидывании не использованных символов при статической компоновке.

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

Если это есть в линкере - это тоже есть. Но это копейки.

Ну можно НЕ использовать Night-версии. есть стабильные версии и они не каждую неделю меняются. а на сколько я помню 1,0 выйдет к концу етого года(не помню, давно не глядел)

До тех пор пока ЯП не проживёт в стабильной версии несколько лет, говорить о его использовании для чего-то кроме баловства нету смысла. Just for fun, можно побаловаться, а можно наваять что-то, что потом понадобится. Если второй вариант, rust не канает, это ИМХО.

Ну можно НЕ использовать Night-версии. есть стабильные версии и они не каждую неделю меняются.

Я не вижу особого смысла в использовании фиксированных версий, вместо ночных сборок. Фиксированные версии же пока никто специально не готовит, не стабилизирует, они вовсе не «стабильные». Просто берут какую-то рандомную версию и говорят, что это 0.n версия, ура-ура.

Я не вижу особого смысла в использовании фиксированных версий, вместо ночных сборок

А команда Servo видит (или видела раньше).

они вовсе не «стабильные»

Они именно «стабильные» в том смысле, что не меняются.

Просто берут какую-то рандомную версию и говорят, что это 0.n версия

Это не так.

Настоящие программисты не используют Паскаль, да

А команда Servo видит (или видела раньше).

Они, вроде, не реже раза в неделю централизованно обновляют версию, это не то же самое, что 0.* релизы. Надо бы погуглить, наверное.

Они именно «стабильные» в том смысле, что не меняются.

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

Это не так.

Я так понял, может и неправ, конечно. Сходу не гуглится, но я видел в реддите много рекомендаций использовать ночные сборки и rust-ci.

... не реже раза в неделю...

Хмм, судя по https://github.com/servo/servo/commits/master/src/compiler, я погорячился.

Имеет, если очень хочется, кто запретит то?

я имел в виду то, что у фиксированной версии есть цифры (0.11.0), т.е. уже можно в доке/ридми/прочее указать какой именно версия нужна чтобы собрать библиотеку. А дальше уже кто как хочет, кто подредактирует под новую версию компиля, кому проще скачать старую версию компилятора.

Тогда уж проще git-submodule юзать. Но это изврат, да — тянуть компилятор вместе с проектом =)

у фиксированной версии есть цифры (0.11.0)

$ rustc -v
rustc 0.12.0-pre-nightly (2224edcfe 2014-07-24 00:26:14 +0000)
$ cargo -V
cargo-nightly 0.1.0-pre (0759283 2014-07-24 19:44:41 +0000)

У ночных сборок (не только у ночных, само собой) есть гитовские хэши (2224edcfe и 0759283), их тоже можно везде указывать. Собственно, это не намного менее удобно, если вопрос только в этом.

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

Этот язык имеет все шансы так и остаться «вечно недоделанным». Когда уже зарелизять стабильную версию?

Этот язык имеет все шансы так и остаться «вечно недоделанным».

Я не вижу никаких предпосылок к этому. И как это связано с хешами и фиксированными версиями?

Когда уже зарелизять стабильную версию?

Даже в этой теме уже говорили. В конце этого/начале следующего года, ориентировочно.

Плюсовые шаблоны очень неудобны(это не костыль, но недостаток). Ссылочный тип сделан как костыль, поскольку не является полноценным типом.

Плюсовые шаблоны очень неудобны

Но они фактически уникальны по возможностям, которые дают. Ну в D еще постарались, но и там не без сюрпризов.

Ссылочный тип сделан как костыль, поскольку не является полноценным типом.

В чем костыльность? Он полноценный тип с дополнительными правилами. Кроме того, есть еще r-value ссылки &&, которые так же имеют свои особые правила. Это не делает их не-типами. Опять же, такого выбора семантики значений/ссылок нет в других языках.

Он полноценный тип с дополнительными правилами

И эти правила вида «невозможно сделать $X». Но полноценный тип, бгг.

А какие у них хорошие уникальные качества?

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

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

А как такие вещи внедряются?

На целевой машине будет только самодостаточная бинарная сборка библиотеки, и среда Rust будет только на инструментальной машине, для её сборки?

Вопрос постольку, поскольку не нашёл Rust в пакетах Debian.

Да, полноценный тип. С особыми правилами. Это нормально для практичного инструмента в реальной жизни.

Фактическая возможность управления генерацией кода, генерация только того, что необходимо, отложенная проверка и пр. и пр. Долго объяснять далекому от темы человеку.

Давайте на простом примере рассмотрим. Как мне сделать для некоторого dict<T> метод доступа к элементу(operator[] в случае C++) так, чтобы он сам создавал элемент, если такового нет, но при этом dict<T> мог бы успешно работать с типами, которые не имеют конструктор по умолчанию, просто данные метод для них бы не работал и выдавал ошибку времени компиляции при попытке его вызвать?

В C++ концептов не хватает вот только(не надо про trait'ы - это не совсем то). Если бы они были - был бы просто идеальный язык для обобщенного программирования.

А в каком еще языке я могу отличить обычный объект от временного и предусмотреть более оптимальную версию кода для последнего? В каком еще языке я могу для одного и того же типа обеспечить как семантику копирования, так и семантику перемещения, с широкой поддержкой со стороны языка?

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

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

А как такие вещи внедряются?

На целевой машине будет только самодостаточная бинарная сборка библиотеки, и среда Rust будет только на инструментальной машине, для её сборки?

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

Вопрос постольку, поскольку не нашёл Rust в пакетах Debian.

Ха, туда Ржавчине еще долго добираться)

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

В смысле, что этот «лучший язык» должен быть, кхмм, обратно совместим с С++?

Или нужен особый ffi для С++? Вообще, видел планы на подобный отвратительный, но полезный на практике костыль для Ржавчины: https://github.com/rust-lang/rust/issues/5853.