А для мертвого языка?

Мертвые языки ИТТ не обсуждают.

Для любой программы ускорение в стопицот процентов в каждом релизе это плохо.

А где ты видишь в каждом? В прошлом релизе они стараюсь стабилизировать всё по максимуму, поэтому местами «забили» на производительность/оптимизации. Сейчас вот наверстывают.

Лучше сесть и подумать, чем пилить лишбы успеть за 6 недель.

И почему ты считаешь, что они не думают?

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

Гуй уровня WPF это явно не к Rust

По-моему для этого новорожденного ЯП еще рано делать подобные заявления

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

Что за стереотипы?! Я 6 лет писал на С++, затем, последние 2,5 года на Java и, по моему, на С++ писать проще! Да, там надо помнить про используемую память и синтаксис чуть сложней, но в Java, чтобы считать себя хотя бы средним прогером, надо понимать как работает JVM и знать кучу сложных (и не очень) фреймворков!

Писать-то на С++ проще, отлаживать сложнее.

и знать кучу сложных (и не очень) фреймворков!

Свои библиотеки/фреймворки на каждом языке (да ещё и в зависимости от области) знать надо.

Я 6 лет писал на С++, затем, последние 2,5 года на Java и, по моему, на С++ писать проще!

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

Наследование запилят или и дальше будут подпирать костылями DOM в Servo?

Писать-то на С++ проще, отлаживать сложнее.

Чукча не читатель, Чукча - писатель?

Больше восклицательных знаков. Еще не всем очевидно, какой ты опытный и бывалый.

Более пригодная версия

Раст в версии 1.0 было невозможно использовать в окружении linux. «Окружение» сплошь написано на Си и наравит вернуть fd для грязной работы на стороне пользователя (epoll и другие утонченные извращения). А ради стабилизации операции с fd были в 1.0 скрыты. Хвала разработчикам: вытащили наружу создание оберток над сокетами, файлами из fd. Только этого недостаточно. Константы (флаги) так и осталась в Сишных заголовков под #define. Приходится тащить их к себе в пользовательский код. Как же недостает пакета linux. По типу того, что пилят под windows ( https://github.com/retep998/winapi-rs ).

https://crates.io/crates/libc же, не? Там libc и posix разных версий есть.

Ещё более пригодная версия

Ещё более пригодная версия впереди. 13 часов закрыли тикет про несовместимость выравнивания в Расте и Си/Си++ https://github.com/rust-lang/rust/issues/21611 . Будьте внимательны: используйте min_align_of_val уже сейчас.

Например, O_CLOEXEC там нет. Но очень бы хотелось. Линукс шире libc, posix и gnu расширений. Не нужно плодить лишние сущности, а лучше дайте мне полный доступ к первоисточнику. Я не собираюсь поддерживать bsd и производные. Мой проект основан на подсистемах линукса.

На systemd штоле?

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

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

Но очень бы хотелось.

что тебя останавливает от того чтобы сделать пул-реквест и получить те константы, которые нужны лично тебе?

Ну или самом определить ту константу, которая тебе нужна и пихать её в тот метод, который её ждет?

В этом плане, что плюсы, что жаба одно и то же.

Какбэ основная разница как раз тут - в плюсах ты получишь сегфолт или утечку в то время когда в жабе за тебя все соберет GC, а обратиться к невалидному указателю в принципе нельзя. Другое дело, что в жабе рантайм не избавляет от ошибок алиасинга, а rust избавляет, причем не в рантайме, а в компайл-тайме.

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

обратиться к невалидному указателю в принципе нельзя

Exception in thread "main" java.lang.NullPointerException

null - вполне валидное значение указателя, ищи еще.

что ты в двух местах в память пишешь, например

Я во втором предложении писал про алиасинг, думаешь это про что?

как там дела у мертвого, незыблемого? помню когда гошечка в 1.0 вошла на ней уже вовсю писали, а тут как с этим?

Какой там пёрл, brainfuck натуральный. Борщета в худшем виде. Фу такое на ЛОР тащить!

Софистика какая-то. Так и в C++ любое значение указателя валидное, просто некоторые приводят к UB при разыменовывании. В этом смысле null в Java мало чем от них отличается, и «обратиться к невалидному указателю в принципе нельзя» как разница между С++ и Java не имеет смысла.

помню когда гошечка в 1.0 вошла на ней уже вовсю писали, а тут как с этим?

А тут каждый релиз вызывает панические вопли «он же мертвый!!!111кококок».

Думаю, что логичнее было бы на расте накатать аналог WPF или QML просто. У гуя вообще очень специфические требования к ЯП.

А чего там с IDE сейчас? Есть уже плагин к IDEA или всё грустно?

UB/vs отсутствие UB - это и есть отличие. В джаве ты точно знаешь, что будет при разыменовывании указателя.

Думаю, что логичнее было бы на расте накатать аналог WPF или QML просто. У гуя вообще очень специфические требования к ЯП.

https://github.com/cyndis/qmlrs

Никаких тебе флагов, шаред локов и прочего fcntl?

extern crate libc;

Rust 53.4% C++ 40.4%

Вся суть C++ биндингов

А чего там с IDE сейчас? Есть уже плагин к IDEA или всё грустно?

Есть базовая поддержка в MS Visual Studio. Для последней версии Kate есть плагин с хорошим автокомплитом (вот только ему нужно скормить копию репозитория Rust на Github'e). Для Emacs есть rust-mode, для Vim'а — rust.vim

А идейка не нужна, да.

Любителям C/C++ тоже будет не ОК.
По началу rust вымораживает не по детски, особенно эти указатели lifetime'а.

Если уж что не нужно, так это MSVS, а так, кроме этого, не нужен ты, если думаешь, что IDE, это подсветка синтаксиса и дубовый автокомплит по списку слов.

Короче понятно, рефакторить его никто не умеет, умного автокомплита тоже пока в природе нет. Грустно... будем ждать.

А чего там вымораживаться? В прошлый раз же вроде установили, что эти указатели по сути то же самое, что и смарпоинтеры в C++11.

Зато когда раскуришь доставляет

Ну, vim + racer + rusty-tags вполне нормальное IDE для не слишком большого проекта. Причем, rusty-tags генерирует тег-файлы используя зависимости из Cargo.toml. Это очень и очень круто!

Меня угнетает сам Rust: - распространённость CellRef и вообще необходимость его использования. Метод как бы заявляет что он const, но в реале происходит изменение объекта внтури.. это же ахтунг! - циклические зависимости ребёнок-родитель нормально реализуется только через указатели и unsafe код. В документации пытаются посоветовать использовать Rc и RefCell (читай первый пункт) - проблема с тем, что код приходится пихать как можно ближе к данным, с которыми он работает, так как дважды на один и тот же мутируемый объякт при вызове функции не сослаться. Народ не заморачивается и пихает копирование где нужно и не нужно. Как результат: без жесткого профайлинга программы на расте всегда медленнее чем на других языках.

Вся суть C++ биндингов

Чем это плохо?

Любителям C/C++ тоже будет не ОК.

Ну хз, вот я «типа любитель С++», но не ощутил каких-либо заметных проблем с растовскими лайфтаймами.

Скорей бы уже раст вытеснил цепепе :-)

Мне это представляется так: чтобы сделать биндинг к ЦПП-шной библиотеке, сначала пишем программу, в которой всяческими извращенными способами превращаем классы и объекты в сишные функции и структуры. Спустя год выясняется, что автор чудо-биндинга забил на него, а API библиотеки поменялось.

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

Поэтому желательно чтобы у либы был свой сишный интерфейс. Либо чтобы либа была сишной

сишники не знают цпп

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

Жонглирование байтами не сделает тебя мастером темплейтов и бустА )

Жонглирование байтами не сделает тебя мастером темплейтов и бустА )

Иными словами, мастером лавировок и извращений :-)

а пользователи биндинга не знают ни си ни цпп

Не думаю, что это справедливо, мы ведь всё ещё про раст говорим. Но в целом идею понял. Хотя, честно говоря, страшной проблемы не вижу. Если либа реально востребована за пределами «С++ мира», то сишный интерфейс всё-таки будет. Да и подозреваю, что среди «писателей на расте» достаточно тех, кто знает С и С++.

Лучший гуй пишется на Tcl. Где там ООПня?

«Программисты», не умеющие без IDE - не нужны. Совсем.

Читаю mdn про DOM. Интерфейсы на интерфейсах и объектами погоняют. Тяжело представляется как это красиво реализовать без ООП с наследованием

Ты идиот, потому, что вопрос не в том, умеется или нет, а в производительности труда (скорости реализации спецификаций) и в удовольствии от процесса написания кода. Если ты никогда не рефакторил по-жесткому в IDEA, тебе не понять. А так, побрякушки я в vim пишу, и ничего, брат жив...