> Оказалось, что в Си нет проблем для того, чтобы работать с этим и особых знаний для реализации не требуется.Требуется.
1. Люди до сих пор верят в превосходство списков по скорости, например. Когда берут бенчмарки, очень удивляются. Чтобы писать хорошие программы, надо очень хорошо понимать происходящее, и мало для этого прочитать Кнута.
2. Около двух третей багов, которые находят в программах -- это тупые сишные баги, которых rust позволяет легко избежать, так что "особых знаний не требуется" -- это иллюзия. Не требуется знаний, чтобы написать бажную реализацию. А вот чтобы безбажную... Вон, тут намедни была новость о том, что аудит ~400 патчей в ядро выявил, что ~40 из этих патчей было бажными. Хехе. "Не требуется знаний", ага, угу. Точно-точно. Интересно, сколько багов они пропустили в процессе этого аудита.
> Оказалось, что в rust в лоб такие вещи решаются плохо и требуются нетривиальные знания, которые сложно нагуглить, их нет в примерах и даже скорее непонятно как искать.
rustonomicon, и "rust with entirely too many linked lists". Или тебе хочется исключительно safe-кодом? Но safe-кодом, ковыряя какие-то заморочные алгоритмы, ты скорее всего утонешь в Rc, RefCell, и Option, которые будут многократно вкладываться друг в друга. Оно можно, конечно, но если твоя цель понять что такое rust, и как им пользоваться, то ты не забывай: когда ты многократно вкладываешь Rc, RefCell и Option друг в друга, ты пользуешься им не так, как им следует пользоваться. Это может быть и полезно для учебных целей, но есть другие, более простые способы освоить раст, чем писать код, который ты через две недели выкинешь, потому что поймёшь, что он бред.
Я б лучше порекомендовал, взять и написать что-нибудь, опираясь на библиотеки. Никаких unsafe'ов, никаких "статических данных" (в смысле никаких глобальных переменных, только константы, и то, только когда очень нужно). А потом, когда борроу-чекер въестся в мозги, и ты не запуская компиляции будешь предсказывать где и на что борроу-чекер начнёт ругаться, вот тогда, ты сможешь в документации к какой-нибудь знакомой библиотеке тыкнуть на ссылку src, возле функции/типа, которые делают что-то, что тебе непонятно как делать, и посмотреть как другие делают. В частности, это очень хорошо работает с std, я очень люблю читать её код, он очень поучителен. Это гораздо образовательнее, чем изобретать свои велосипеды.
Опыт C плохо ложится на rust, потому как impedance mismatch. Например, в C, работая со строками, ты будешь жонглировать ими как массивами байтов, и потом, в самых внезапных местах, ты будешь сталкиваться с тем, что не любой массив байт является валидной utf8-строкой, и тебе надо будет с этим как-то жить. В rust'е, массив байт преобразовывается в &str (ну или в String) где-то возле того места, где этот массив байт читается из файла, и именно там будут вылетать Utf8 ошибки, и именно там ты будешь их обрабатывать. Во всех остальных местах программы ни ты, ни std даже париться не будете о том, чтобы проверить валидность utf8: они гарантированно валидны, потому что проверены. Причём это будет касаться и подстрок тоже: любая подстрока будет гарантированно начинатся и заканчиваться на границах символов.
То же самое работает с указателями: в C ты указатель проверяешь на NULL в рандомных местах программы -- иногда при получении этого указателя от внешних API, иногда перед разадресацией, иногда совсем ни к селу, ни к городу, -- в rust'е ты проверяешь raw-указатель на NULL перед преобразованием его к нормальному указателю, что происходит скорее всего где-то возле того места, где ты получил этот raw-указатель. Во всех остальных местах проверки на NULL оказываются не нужными. Причём не только явные проверки не нужны, но и неявные тоже. Всё это довольно странно меняет ситуацию, и лучшего описания этому, чем impedance mismatch, я не знаю. Поэтому, пока ты мыслишь сями, ты будешь спотыкаться в rust'е на каждом шагу и борроу-чекер будет твоим врагом, а не другом.
То же самое работает в любой другой ситуации: любой объект валиден, потому что валидность его была проверена при создании. И каждое изменение объекта производится таким образом, чтобы не нарушить валидность. В то время как в C, объект может быть невалидным (просто куском неинициализированной памяти, например), и он может "внезапно" терять валидность. Внезапно для тебя, потому что, например, ты где-то недостаточно хорошо понял API, которым пользуешься. Отсутствие таких требований в C упрощает написание программы, которая скомпилируется, упрощает до того уровня, что реально никакой квалификации не надо, чтобы написать. Но с другой стороны, это резко усложняет написание программы, которая корректно работает.
И поэтому, лучше начинать не с реализации алгоритмов и структур данных из учебника, а с высокого уровня, когда ты пользуешься уже готовыми реализациями этих алгоритмов и структур данных. Вот когда ты свой импеданс подтянешь под rust'овый, когда ты поймёшь, что borrow-checker тебе не двусвязный список мешает сделать, а ругается на то, что ты потерял информацию о владельце объекта, или на то, что сейчас ты создаёшь две мутабельные ссылки на объект, открывая простор для data race, вот тогда.... вот тогда можно и своими структурами данных заняться.
