Pull to refresh

Comments 14

Опрос про GC провокационный. (:


Я бы ответил "можно, если аккуратно": есть более приоритетные (на мой взгляд, разумеется) вещи, надо очень аккуратно интегрировать GC с имеющимися механизмами и не вызвать фрагментацию библиотек по этому признаку. Лучше никак, чем плохо в общем. Предложенные варианты несколько категоричны. В итоге воздержался.

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

Дык, я ж не спорю. Просто (для меня) опрос выглядит как "надо срочно добавить, иначе язык никуда не годится" или "ни в коем случае, это всё испортит".


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

Я проголосовал за "нужно" имея ввиду "нужно добавлять вдумчиво и не сейчас".

GC нужен в первую очередь для возможности эффективной реализации runtime других языков — что бы большенство таких реализаций могли использовать одно и то же.
Связывать GC с реализацией потоков по моему не стоит.
А как же случаи, когда нужно быстро написать прототип программы, но не хочется
работать с borrowck? По-моему, GC нужен для того, чтобы разработчик не работал с памятью вручную/не тратил время.

Опрос про GC не в тему, да — просто интересно мнение сообщества.
А как же случаи, когда нужно быстро написать прототип программы, но не хочется
работать с borrowck?

Rc?

Все равно проблема, теперь нужно думать, вокруг чего этот самый счетчик обернуть,
писать сигнатуры вида
fn func(var: Rc<RefCell< ... >>)

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

Мне кажется что большую часть времени как раз этого Rc<RefCell<...>> и хватит. Ну и по моему опыту, если хотя бы с пол года пописать на ржавчине, желание "не хочется работать с borrowck" в даже "быстрых прототипах" возникает не то что бы часто.


в Go все проще — создал структуру, посылай ее по значению или по ссылке, а runtime сам разберется, как ее утилизировать.

1) Мне сложно представить как такой же безшовный GC в уже существующий язык вообще можно вкрутить
2) Если таки это и можно сделать, то я на 100% уверен что это приведет к проблемам в crates.io экосистеме

Но в Gc тоже надо будет заворачивать, сборка мусора чужое не дожна бытаться собрать.
Для этого есть более простые языки — Haskell например :-).
Gc, конечно, вещь хорошая. Но сильно область применения она не расширит и популярность Rust не поднимит.
В прототипе неизменяемые данные можно дублировать в каждый поток. А изменяемые без контроля владения, даже в прототипе лучше не использовать.

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


fn foo(...) -> Future<ReturnType, ErrorType>

Нельзя вернуть Future, можно вернуть impl Future или Box<Future>. Подробнее читайте в официальной документации.

humbug, спасибо за замечание, не стоит так спешить.
Я перевел то, что было в оригинале. Не силен в Tokio, поэтому не стану ничего менять.
В оригинале кмк подразумевалось что это псевдокод. Т.е. было написано «теперь код может выглядеть примерно так».
Sign up to leave a comment.

Articles