mayton2019

Тебе не нужно никакое кольцо. Ищи просто lock-free очереди. Если будет кольцо
- то тебе не хватит памяти и нужно будет придумывать механизм выхода из
ситуации (хопа привет блокировка).

Несколько мыслей. Первое. Скорее всего утилита зависает здесь
TcpStream::connect(&ip)
но ты должен это сам проверить и доказать во время подачи вопроса в хабр. Логгированием или профилированием неважно. Короче приходи - чуть более подготовленным чем просто с зависающей программой.

Второе. Сам по себе TCP протокол не бесплатный. Каждый новый сокет аллоцирует память в виде буфера
для отработки опций протокола (восстановление стрима с учетом потерянных пакетов) и этот буфер
где-то регулируется. Поищи. Проверь также скорость работы твоего приложения. Как быстро он отрабатывает
ответ от молчаливых портов которые ничего не отвечают. Это - тоже протокольная ситуация и ее надо как-то
обработать. Грубо говоря не доверять дефолтным таймингам.

Третье. Возможно некоторые промышленные утилиты-сканеры такие как nmap не используют создание
сокетов. Они могут работать на уровне IP протокола просто посылая SYN-пакеты и обрабатывая ответы
асинхронно. Это такая хитрость которая позволяет создать сокет без буфера. Это не честно с точки
зрения полноценного протокола но достаточно чтобы проверить что ACK пришел. Вот почитай какие
возможности у RUST есть в части IP-программирования.

На codewars есть опция выбора языка. Можно взять Rust. И там можно решать задачи разной сложности. И после решения сравнить свой исходник с другими (более успешными обычно).

Я могу распараллелить процесс на несколько файлов

Разпараллеливание записи на несколько файлов не имеет смысла для обычных десктопных дисков.
Это только в серверных системах хранения где RAID - такая оптимизация имела-бы смысл.

Чтоб оптимизировать запись (развязать ожидания рабочих потоков от потока записи) можно
создать кольцевой буфер записи и поручить его сброс отдельному потоку. Размер этого
кольца можно выбрать экспериментально. Я не очень понимаю зачем тебе нужен набор
буферов (больших и малых) это возможно часть алгоритма. Но я-бы избавился от ненужных
копирований внутри памяти если есть возможность.

Можно еще посмотреть какие возможности в Rust есть в части асинхронного I/O но я здесь не специалист
в расте насколько глубоко чтоб знать где это и как называется.

Докину 5 коп.

Я думаю что никто такую задачу вобщем-то не ставит. И никогда не поставит. Тут не то что Java
а я прошу прощения Cobol не могут никак заменить. Языку - уде более 50 лет возраста.
И хотя проблема касается в основном США, но это просто пример того что код живет очень долго.
У джунов уже седые бороды отрасли :)

Язык Rust вобщем-то создавалася как язых обще-системного программирования с правильным
механизмом управления памятью. И уже если ему и где-то конкурировать - так это там где нужен
отклик (игры или реал-тайм приложения).

Сильные стороны Java сегодня - это большой репозитарий библиотек на все случаи жизни.
Статистика по maven https://mvnrepository.com/ заявляет что 35 миллионов артифактов
имеется в наличии. Можно наверное найти любой драйвер или парсер или любую
либу поддержки сетевых протоколов. Большая часть из них проверена временем.
Production ready. Можно ли говорить о production-ready для Rust - библиотек я не знаю.
Пускай знающие отпишут.

Java - машина с развитым рантаймом. Рефлексия позволяет делать позднее инстанциирование
компонентов через конфиги. И этим очень сильно пользуются во фреймворках. Фактически
если проводить сравнительные анализы Rust и Java - мы встанем перед дилеммой - чем заменить
механику рефлексии в Rust? Создавать рантайм? Но это противоречит идеям системного программирования
или все таки принять как факт что Spring и ему подобные фреймворки принципиально нельзя
воспроизвести в языке статической компилляции таком как Rust.

Если-бы я сравнивал этот язык (Rust) - то ставил бы ему в одну весовую категорию Nim, Zig и прочие
языки "пост-плюсового" периода. И в качестве задач я-бы ставил - разработку игр и драйверов
для операционок. Вот там и тестируйте.

Самому финтеху не всегда нужен рилтайм. Иногда - даже вообще не нужен. В батч-джобах биг-даты
и python нормально работает. Специфика своя там. А критичные части бигдаты (Apache Arrow, Databricks Photon)
- и так переписаны на сях чтобы быстринько search + join работал. В стриминге биг-даты - тоже вобщем-то
CPU не сильно критичен. Там и Node и C# тоже годится в качестве языков. Вобщем задачи - I/O bounded.

В топике непонятно что автор имеет в виду под превосходством.

Я думаю что если заказать статьи разным техно-писателям то они напишут каждый про свое. Один
может писать про удобство процесса разработки (и это важно). Другой напишет про безопасность
по memory safety. Третий может напишет про ФП и обобщенное программирование и может
быть про автоматическое доказательство каких-то свойств которые есть у софта.

Могу констатировать в живых примерах что ядро линукс уже содержит 55 исходников на rust (по состоянию
на 5/13/2023) и следовательно кому-то это надо. Кто-то заказал внедрение нового компиллятора.
Видимо язык С уже не устраивал. Я пытался просмотреть эти сорцы но моих знаний Rust и Linux kernel
разработки пока не хватает чтобы дать хоть какой-то внятный комментарий по поводу. Ну раз коммитеры
вкоммитили значит все таки было очень нужно.

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

Про Mozilla тоже можно посмотреть. Возможно там найдуться примеры где было на С++ и стало на Rust.
Ведь это по сути была главная причина возникновения самого языка Rust.

Какое состояние у языка Rust на текущий момент?

Я несколько лет наблюдаю за долей Rust исходников в браузере Mozilla.
По состоянию на 2022 год там была такая пропорция С/C++/Rust 0.19 : 0.39 : 0.42
(При этом я игнорировал прочие типы файлов). И эта доля Rust кода практически
не меняется несколько лет. Тоесть видимо те цели которые ставили Mozilla/Microsoft
были достигнуты. Они переписали что хотели и успокоились.

Любитель пингвинов и нелюбитель NVidia тоже обещал затащить Rust в исходники
linux-ядра, но я не собирал сведенья по линуксу и не знаю что там сейчас. Кто
знает? Поделитесь.

Можно ли уже полностью отказаться от C++ в пользу Rust, в низкоуровневых вещах

Скорее всего нет. Потому что есть потребность в безшовной интеграции с вызовами kernell и библиотек.
В Rust скорее всего потребуется сильная адаптация кода чтобы он был пригодным для ABI например.

Понятно, что нет полноценной IDE

Забавное наблюдение. Я слушаю блоги хаскелистов. Душкина. Брагилевского. Вершилова.
И практически все они хором поют одну и ту-же вещь.. дескыть им IDE не нужна а им
достаточно vim или блокнот. Я с ними не до конца согласен. Но что-то есть в этом. Получается
что математически совершенному языку незачем иметь обязательноую IDE. И вообще
с каких пор мы язык должны рассматривать в комплекте с IDE? Неужели язык без
этого инструмента неполноценен? Можем ли мы рассматривать "зрелость" языка просто
как языка?

В документации по Rust есть раздел Iterator Loops https://doc.rust-lang.org/reference/expressions/lo...

Исключения I/O - одни из самых сложных п принятии решения. Это связано с тем что сеть - это часть внешнего мира. Того на который ты не влияешь. В чем может быть причина? На каждый класс ошибок и на каждый источник данных должна быть таблица принятия решений. Например ты знаешь что в каждый четверг данный rest сервис имеет возможный регламент обновлений. Выдавай на UI плитку с сообщением о регламенте и проси повторить через какое то время. А другий рест сервис просто висит на слабом канале. И к нему надо применять RetryLogic. Молча. Просто другого выхода нет.

Общих рекомендаций нет.