Презентация «Rust Me, I'm a Developer!»

Чего тут спорного, если тебя пользователи пошлют на куй вместе с твоей новой замечательной версией? Питон 3 и тот посылают...

Спорное тут то, что не очень понятно от чего больше проблем: от старого хлама в языке или от необходимости переписать часть кода под новую версию.

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

С питоном 3 и lua 5.2, как мне кажется, как раз этих новых штук и не хватает, мотивирующих людей к обновлению.

Потому, что тогда ты можешь изменить его структуру или удалить некоторые его части.

И что ссылка от этого станет невалидной? Методы объекта перестанут существовать? Изменится _состояние_ объекта, что, как бы, в задаче с конфигом и предлагалось.

Может выйти то же самое, что и с просто удалением всего объекта.

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

Я так понял основная предъява к с++ в том, что в нем ... думать надо, внимательность развивать, проектировать уметь ... а Rust данного недостатка лишен. Да и то, как показали тут примеры, и Rust можно отсарафанить себе ногу по самую голову. А значит ждем тонны говнокода на этом «safe by default» языке и бурление говн по поводу «это не язык плохой это руки из жопы».

И что ссылка от этого станет невалидной? Методы объекта перестанут существовать? Изменится _состояние_ объекта, что, как бы, в задаче с конфигом и предлагалось. ...

Так должно бы быть, на гарантировать это в С++ нельзя. Я написал, что если тебе все-таки хочется иметь немутабельные ссылки на изменяющийся объект и ты свято уверен, что ничего не сломается, то ты явно об этом говоришь, используя RefCell.

Еще раз: по-умолчанию используется безопасный подход, но ты можешь его обойти с _явным_указанием_ своего намерения. Мне это кажется очень разумным.

Я так понял основная предъява к с++ в том, что в нем ... думать надо, внимательность развивать, проектировать уметь ...

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

Да и то, как показали тут примеры, и Rust можно отсарафанить себе ногу по самую голову. А значит ждем тонны говнокода на этом «safe by default» языке и бурление говн по поводу «это не язык плохой это руки из жопы».

Мне еще раз написать, что суть в том, что по коду сразу видно о его опасности?

Если бы в самом языке не было unsafe секций, то ровно то же самое небезопасное делалось бы в отдельно компилируемых модулях на том же Си, системному языку без этого никак. Системный язык по определению не может быть на 100500% безопасным, но точно может быть безопаснее, чем Си или С++, вот.

Если бы в самом языке не было unsafe секций

Если бы у дедушки не было яиц, он был бы бабушкой. Иллюзия все это. Еще раз (4 уже за тему, на сколько вижу) Пока есть возможность отстрелить себе ноги, их будут отстреливать. И будет появляться тонны кода где

main( ) { unsafe {

}}

А потому что так ПРОЩЕ , млять, так «компелятор не ругается», а почитать доки - так это для слабаков. Именно так и пишутся все программы, что на Си/C++, что на D, что на Rust будут писаться. А человеку, умеющему проектировать, нафик не сдались safe/unsafe. Он думать умеет.

... Иллюзия все это. Еще раз (4 уже за тему, на сколько вижу) Пока есть возможность отстрелить себе ноги, их будут отстреливать. ...

Само собой, тех, кто напишет «fn main() {unsafe{}}» никакой язык не спасет, это я согласен.

А человеку, умеющему проектировать, нафик не сдались safe/unsafe. Он думать умеет.

А вот с этим я не могу согласиться. Надежнее переложить часть рутины на компилятор. Не зря столько народа возятся со статическими анализаторами, даже в С++.

суть в том, что по коду сразу видно о его опасности

Что-то у меня такое подозрение, что практически в любом крупном проекте будет намешано так много «опасного» кода, что эта метка попросту потеряет смысл.

что на Си/C++, что на D, что на Rust

Только в отличие от, для Rust есть утилита, которая показывает все unsafe-секции, и можно спросить «а почему ты используешь unsafe, если у тебя нет сертификата „вменяемый разработчик“». Или тупо запретить использовать unsafe и raw.

Что-то у меня такое подозрение, что практически в любом крупном проекте будет намешано так много «опасного» кода, что эта метка попросту потеряет смысл.

От говнокода ничто не спасет, очевидно. Но если в разработке участвуют более-менее адекватные люди, комиты проходят смотр перед заливкой и все такое, то зачем это там будет намешано много опасного кода? Опасный код выносится в отдельные объекты, прячется там и наружу выставляется безопасный интерфейс, как я уже говорил.

Больших проектов, сравнимых по размеру с компилятором языка и servo, написанных не авторами языка, я пока не знаю. Я могу только сказать, что в моем личном проектике весь unsafe там пока спрятан в обертках вокруг OpenGL, хотя у меня пока всего 3к строк, так что я даже на средний размер не претендую пока что :) .

... Или тупо запретить использовать unsafe и raw.

Если ты запретишь unsafe, то не сможешь разыменовать сырой указатель, так что отдельно сырые указатели запрещать вряд ли надо.

http://static.rust-lang.org/doc/master/guide-unsafe.html

http://static.rust-lang.org/doc/master/guide-unsafe.html#raw-pointers

http://static.rust-lang.org/doc/master/guide-unsafe.html#references-and-raw-p...