Умные люди, подскажите - а чем концептуально сложно писать какой-нибудь

бэкенд на rust? Ведь пишут на go (там бывают утечки, иногда их очень тяжело отлавливать, особенно если были обрёртки над плюсами), пишут на java и scala (тоже типизация, правда с gc). И вроде в rust очень приятный drop, сильные типы, немного фп. Что именно вызывает такую боль, когда говорят про обычные web приложения на rust?

Нет GC

Так в 95% drop сделает сам ту же работу?

Вообще, не так уж мало людей пишут ржавые беки и в целом всем довольны как раз хотя бы на https://www.rust-lang.org/production/users посмотреть - там чуть ли не треть это какие-то веб беки

Не drop, а ownership, RAII

Так и в чём боль тогда без gc?

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

Принял, благодарю, это только бодрит 😏

Я пишу бек на Rust. Боли нет. Фронт, кстати, тоже пишу )

А фронт на yew или чистый wasm?

Если ты пишешь по канонам раста - ебешься с лайфтаймами. Если забиваешь и пишешь с Rc/Arc, получаешь версию гц, только без детектора островов и прочих прелестей нормального гц. А ещё еблю с шаред мутированием.

Мы бы с радостью, но с тредами без 'static не поиграешь

yew

У меня практически нет типов с лайфтаймами и Rc/Arc. Все работает. Что я делаю не так?

То есть вы везде всё передаете по значению? )

Нет. Почти везде все передается по ссылке.

Мои пять копеек: писать обычно приятно и не очень сложно, а вот поддерживать и сопровождать иногда больновато. Не весь тулинг доведён до ума, не все библиотеки нормально попользованы и вычищены от глупых багов, поэтому иногда, когда что-то ломается, мне, как человеку, избалованному JVM, бывает сложно быстро найти проблему и починить. Пример: задеплоили приложение, всё, вроде ок. Начали грузить load тестами — потекла память. Ну ок, идём смотреть на профайлеры: всё серьёзное только под Linux, анализируют только аллокации, поэтому проблему показывают примерно. Удалённо подключиться и потрекать память можно, но нужно менять немного сборку проекта, чтобы с кастомным аллокатором запуститься или ставить какие-нибудь доп. профайлеры и запускать ими. А потом перезапускать тест, ждать и анализировать многогигабайтные дампы. А в той же Java — подключился удалённо наживую к приложению (порт, конечно, нужно заранее открыть, но ставить или крутить дополнительно ничего не нужно) и сразу видишь всю кучу со всем графом, гуляй по жирным объектами смотри, что они себе в память понаписали, прямо сами данные посмотреть можно. Хоть дебажь так же, если совсем нужно. И так примерно со всем: на любой закидон приложения приходится тратить больше времени и сил, чем этого бы хотелось бы. Но и таких проблемных закидонов сильно меньше, как мне кажется.

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

С Го, наверное, так же, я не знаком. Но решил поделиться чутка наболевшим)

Здесь прост изначально с го сравнили

Благодарю, интересный опыт, буду иметь ввиду 👍