Ржавчина (Rust)

В раст нет гц, спецы такие спецы, ой хоспаде прости.

 

Так скоро появится же. Чем больше компилятор помогает командному девелоперу за зарплату, тем лучше же

 

млин, сколько десятков лет проходит и эта деццкая задача постоянно вылезает ну-напиши на си сохранение адресов возврата и перед возвратом функи проверяй валидность адреса возврата или напиши функу, коя будет контролировать размер данных помещаемых в буфер.

ох, не надо рассказывать == тот же gcc выкидывает портянку предупреждений например, int b; u64 a; b = a; вызовет предупреждение компиля. а, вообще, компиль не может эффективно отлавливать логические ошибки, пч..

1. они обычно образуются в динамике и помимо внутренних ошибок кода есть куча внешних.
2. чтобы отлавливать ЛО, их надо чётко сформулировать в виде тех же юнит тестов.
3. ЛО могут накапливаться, тч их отлов автоматикой зачастую имеет большую ресурсоёмкость.

возвращать указатель на локальную переменную -- это далеко не самая мутная ошибка, куда забавней удаление шаровых ресурсов во много-потоке Вообще, прогер должен чётко знать, что Абсолютно Надёжных Кодов нет и быть не может. Тч прогер должен не гнаться за невозможным, а просто уметь описать пределы устойчивости своего кода. А разрабы супер-пупер яп-ов не могут воткнуть тот простой ФАКтЪЪЪ, что, отбросив всю мишуру их супер-пупер фич, остаётся схема древняя акь Х@ФЪ№о мамонта == прогер → яп → компиль → линкёр → бинарь. для реального же развития нужно == прогер → (полуавтомат) → яп → полуавтомат → бинарь, то бишь нужна не очередная жалкая поделка с лейблом "супер-пупер яп", а ЭКОСИСТЕМА разработки с максимальной автоматизацией рутинных процессов. для решения этой задачи яп должен быть ОДИН и с/с++ тут наилучший кандидат, пч базовые коды в основном на с/с++.

 

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

 

Является ржавчина ЯП с zero runtime?

 

Зависит от того, что ты подразумеваешь под этим термином. По-умолчанию Rust зависит от своей и от сишной стандартной библиотеки. Можно использовать специальный режим no_std, при использовании которого можно генерировать независимый ни от каких рантаймов код.

 

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

 

То есть, полноценно раст никак не может заменить С/С++? Ну и тем более ассемблер.

 

Intro,
Ну, заменить-то он может, но ты можешь посмотреть, как на расте выглядит гуевый софт на винапи и сразу станет очевидно, надо ли оно тебе

 

Почему не может?

 

https://lwn.net/Articles/849849/

 

https://www.zdnet.com/article/linus-torvalds-on-where-rust-will-fit-into-linux/

 

Вообще Линус - знатный спецовый цешник, очень странно от него это слышать.

 

Тут столкнулся со смешным багом в менеджере 4G LTE модем, если за сессию скачиваешь больше 4 гигабайт, то график траффика и объем уже не отображается, на лицо детский баг о переполнении dword'а. Вот может ли этот раст такие баги упреждать. Хотя вроде как тут сам погромист накосячел, баг реально совершенно детский.

 

Так как вы пишите, "...4 гигабайт... dword..." напрашивается беззнаковое целое, со всей, вряд ли учитываемой в языках высокого уровня, спецификой работы, т.е. про-гавнисту надо объявлять аналог Int8 или float4.
Соотв. баг, начиная с 2Г, должен бы фиксироваться языком.

 

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