Здравствуйте, ELazin, Вы писали:
KP>>В общем случае – да. В то же время, Rust дает тебе возможность получить такую гарантию в условных 90% случаев, в отличие от C++, который не дает такой гарантии никогда. Думаю, выбор довольно очевиден EL>Я правильно понял, что если Rust дает такие гарантии, то С++ автоматически перестает давать вообще любые гарантии корректности? Мне кажется что lifetime analysis в Rust очень специфичен. Он позволяет например взять внутренний буфер строки и перелопатить его и не бояться что этот буфер переживет строку. Но этот (и аналогичные ему) кейсы, они же странные. Любой С++ программист это все в голове умеет анализировать. Это все просто.
Человек, насколько профессионален он бы не был, неспособен контролировать абсолютно все аспекты создаваемого кода, поэтому там всегда будут баги. В статье про Dangling pointer приведены вполне реальные примеры, плюс указано, что все современные статические анализаторы занимаются поиском подобных багов, что как-то не вяжется с утверждением, что "Любой С++ программист это все в голове умеет анализировать", согласитесь? Ну и в компанию можно добавить знаменитое Null References: The Billion Dollar Mistake и прочие.
В любом языке можно написать библиотеки, более-менее гарантирующие безопасную работу с памятью, но никто не может заставить программистов использовать их и только их, в этом вся проблема. Заслуга Rust'а в том, что он первый из неакадемических языков, кто попытался разделить ответственности: программист пишет алгоритм, компилятор проверяет, что код работает корректно в обозначенных областях. Это минимизация вклада человеческого фактора в корректность кода и за этим будущее, так как тенденция показывает, что код все более и более усложняется со временем.
Современный C++ слишком монструозен и сложен, что сильно удорожает как подготовку нормальных специалистов, так и сам процесс написания.
Здравствуйте, kaa.python, Вы писали:
KP>Я могу сказать только одно. Можно и дальше "молиться" на C++ и надеяться что "вот уж со следующим стандартом жизнь наладится", а можно просто посмотреть по сторонам. C++ слишком тяжел, сложен и обладает очень громоздким наследием. Его не просто так теснят все кому не попадя, начиная от JMV-языков, заканчивая Go. Если есть два варианта решения одной и той же задачи с одним и тем же уровнем эффективности, никто, кроме как из "религиозных" соображений, не возьмет более сложный инструмент.
Кстати, очень характерно взглянуть на этой же страничке на цифры для D, Rust и Swift (как пример того, как выглядит новый язык, который всё же взлетел).
Здравствуйте, ELazin, Вы писали:
R>>1) Статические анализаторы в комплекте с С++ не идут. В стандарте не написано: "Вы должны использовать статический анализатор, чтобы не использовать одну из многих любезно предоставленных нами возможностей выстрелить себе в ногу". EL>По крайней мере они там есть. В ногу можно выстрелить везде. В том же Rust строки — мутабельные. Язык, появившийся в 2015-м году имеет мутабельные строки в своей стандартной библиотеке. Жизнь людей ничему не учит.
В Rust'е базовый строковой тип — str, он содержит иммутабельные строки. String же представляет строковый мутабельный буфер. С этой позиции Rust ничем не отличается от других мейнстримных языков.
Здравствуйте, kaa.python, Вы писали:
KP>Да никто его полностью не заменит, нужно же кучу копролита мамонта поддерживать, дорабатывать, развивать.
"Копролит мамонта" говоришь? )Ну вот смотри. Допустим я хочу начать сейчас новый проект в области IoT (одно из самых модных сейчас направлений). И соответственно мне там придётся работать с процессорами Cortex-M0. Вопрос: какой язык мне выбрать для этого нового проекта? )
В>В Rust'е базовый строковой тип — str, он содержит иммутабельные строки. String же представляет строковый мутабельный буфер. С этой позиции Rust ничем не отличается от других мейнстримных языков.
Базовый строковый тип &str в расте это примерно то же самое, что и const char* на статическую строку в С++ (было бы странно, если бы живущая в сегменте данных строка была изменяемой). Поскольку все строки в приложении не могут быть статическими, я все же склоняюсь к тому, чтобы считать базовым строковым типом String. А изменяемый строковый тип, это то от чего современное программирование постепенно уходит. В большинстве современных ЯП строки неизменяемы (python, java, c#, go и тд).
Здравствуйте, kaa.python, Вы писали:
EP>>Подозрительные тесты, например нет -DNDEBUG. В общем нужно проверять. KP>Хорошие тесты, уже лет 10 как единственный сравнительно объективный способ узнать скорость выполнения кода на том или ином языке.
Здравствуйте, red75, Вы писали:
EL>>О да! Параллельный код, который вручную создает потоки и вручную делит массив на thread_cnt частей. So solid, so 2016 R>Я параллельное программирование в контексте С++ вообще не упоминал. Понятно почему? Потому что там с этим полная Ж с большой буквы. Ваша позиция понятна: "Настоящий программист напишет что угодно на чём угодно. И я знаю этого программиста". Особо спорить не о чем.
В>В любом языке можно написать библиотеки, более-менее гарантирующие безопасную работу с памятью, но никто не может заставить программистов использовать их и только их, в этом вся проблема. Заслуга Rust'а в том, что он первый из неакадемических языков, кто попытался разделить ответственности: программист пишет алгоритм, компилятор проверяет, что код работает корректно в обозначенных областях. Это минимизация вклада человеческого фактора в корректность кода и за этим будущее, так как тенденция показывает, что код все более и более усложняется со временем.
Ну вот опять забыли java/C# и кучу других языков с GC. До Rust-а конечно же об этих проблемах никто не думал и не решал их, ага. Самый проверенный временем подход к решению проблемы memory safety это языки с GC (memory safety through garbage collection). При этом компилятор Java, например, умеет вставлять код, который проверяет выход за границы массивов, но оптимизатор hotspot умеет этот код убирать, если он избыточен. И при этом, в отличии от Rust, в Java в принципе невозможно испортить память или уронить приложение по segfault (если нет нативного кода). При этом там стандартная библиотека не напичкана unsafe блоками, в отличии от. И все это очень здорово минимизирует возможный негативный вклад человеческого фактора. Опять же туллинг, книжки, программисты настоящие есть. Вы уж определитесь, если нужно писать низкоуровневый быстрый код, для всяких узких задач, то тут Rust-у явно не место. Он слишком высокоуровневый, как тут уже писали, на нем даже нельзя OOM обработать. А там где раст будет хорошо работать, java и C# будут работать еще лучше. Даже Go будет работать лучше, потому что там нет лишней когнитивной нагрузки, связанной с lifetimes, при этом ногу себе отстрелить сложно.
В>Современный C++ слишком монструозен и сложен, что сильно удорожает как подготовку нормальных специалистов, так и сам процесс написания.
Практика показывает, что дорого и сложно — пытаться писать идеальные системы, которые by design не могут содержать ошибок (как тут кое-кто хотел типами инварианты доказывать). Реальный код слишком быстро меняется а бюджет времени на разработку не так велик.
Здравствуйте, ELazin, Вы писали:
В>>В Rust'е базовый строковой тип — str, он содержит иммутабельные строки. String же представляет строковый мутабельный буфер. С этой позиции Rust ничем не отличается от других мейнстримных языков.
EL>Базовый строковый тип &str в расте это примерно то же самое, что и const char* на статическую строку в С++ (было бы странно, если бы живущая в сегменте данных строка была изменяемой). Поскольку все строки в приложении не могут быть статическими, я все же склоняюсь к тому, чтобы считать базовым строковым типом String. А изменяемый строковый тип, это то от чего современное программирование постепенно уходит. В большинстве современных ЯП строки неизменяемы (python, java, c#, go и тд).
Нет, это не так. &str указывает на валидную неизменяюмую последовательность UTF-8 символов безотносительно того, где она находится. Это может быть статическая строка, это может быть содержимое другого буфера.
Статичность данных задается только через лайфтаймы и не имеет никакого отношения к типам (&'static str будет указывать на статическую строку).
Небольшой пример:
// Так как мы не знаем какой длины будет строка, то используем String, который будет динамически выделять память по мере необходимостиlet mut input = String::new();
io::stdin().read_line(&mut input); // Читаем данныеlet s = &input; // s имеет тип &str и указывает на прочитанную строку, хранящуюся в input. Rust гарантирует, что никто больше не сможет изменить input, пока "аренда" строки через s не закончитсяlet static_str = "abcde"; // А здесь static_str имеет тип &'static str и указывает на статическую строку.
Здравствуйте, ELazin, Вы писали:
В>>В любом языке можно написать библиотеки, более-менее гарантирующие безопасную работу с памятью, но никто не может заставить программистов использовать их и только их, в этом вся проблема. Заслуга Rust'а в том, что он первый из неакадемических языков, кто попытался разделить ответственности: программист пишет алгоритм, компилятор проверяет, что код работает корректно в обозначенных областях. Это минимизация вклада человеческого фактора в корректность кода и за этим будущее, так как тенденция показывает, что код все более и более усложняется со временем.
EL>Ну вот опять забыли java/C# и кучу других языков с GC. До Rust-а конечно же об этих проблемах никто не думал и не решал их, ага. Самый проверенный временем подход к решению проблемы memory safety это языки с GC (memory safety through garbage collection). При этом компилятор Java, например, умеет вставлять код, который проверяет выход за границы массивов, но оптимизатор hotspot умеет этот код убирать, если он избыточен. И при этом, в отличии от Rust, в Java в принципе невозможно испортить память или уронить приложение по segfault (если нет нативного кода). При этом там стандартная библиотека не напичкана unsafe блоками, в отличии от. И все это очень здорово минимизирует возможный негативный вклад человеческого фактора. Опять же туллинг, книжки, программисты настоящие есть. Вы уж определитесь, если нужно писать низкоуровневый быстрый код, для всяких узких задач, то тут Rust-у явно не место. Он слишком высокоуровневый, как тут уже писали, на нем даже нельзя OOM обработать. А там где раст будет хорошо работать, java и C# будут работать еще лучше. Даже Go будет работать лучше, потому что там нет лишней когнитивной нагрузки, связанной с lifetimes, при этом ногу себе отстрелить сложно.
Эти утверждение в большей части или некорректны, или не подтверждаются практикой. Проблема Java/C# в том, что безопасное программирование в них дается за счет значительного увеличения накладных расходов, а именно расходов на сборку мусора, подход же Rust'а заключается в том, чтобы дать нужные гарантии по возможности за счет компайлтайма, а не рантайма, что очень хорошо скажется на скорости выполнения и размере требуемой памяти. Я персонально могу гарантировать, что аналогичная программа на Rust работает практически всегда "лучше", чем аналогичные на java/C#, так как наблюдаю это на практике.
Rust весьма хорош и для написания быстрого низкоуровневого кода. Отсутствие обработки OOM не делает его высокоуровневым, так как это ограничение его библиотеки (не путаем язык и библиотеку). Сам язык позволяет, при необходимости, обрабатывать OOM. Rust умеет убирать проверки на выход за границы массивов, там где они не нужны. Rust слишком молод, и пока не имеет хорошего инструментария, что компенсируется в будущем.
В>>Современный C++ слишком монструозен и сложен, что сильно удорожает как подготовку нормальных специалистов, так и сам процесс написания. EL>Практика показывает, что дорого и сложно — пытаться писать идеальные системы, которые by design не могут содержать ошибок (как тут кое-кто хотел типами инварианты доказывать). Реальный код слишком быстро меняется а бюджет времени на разработку не так велик.
Это никак не связано с Rust'ом, писать на нем достаточно комфортно и быстро, при условии знания языка. У меня есть проекты игрушечных ОС, написанных на C++ и Rust'е: по моим персональным ощущениям скорость написания кода на Rust'е была весьма выше, в то же время процент багов заметно ниже. Очень положительное впечатление оставила продуманность libcore: при отсутствии стандартной библиотеки практически весь необходимый функционал (a-la printf, форматирование произвольных структур, stack unwinding, etc) реализуется за считанные часы. Сам код по качеству сравним с аналогичным сишным. Собственно это и послужило стартом моего интереса к языку. Я рекомендую вам тоже попытаться поработать с ним, что даст вам возможно новые впечатления. Пока, судя по замечаниям о языке в других сообщениях, вы спорите о предмете который не знаете.
Никто как бы и не говорит, что C++ плох, мы говорим о том, что в наше время развития информационных технологий надо искать новые методы облегчения труда программистов. Мы прошли через эру Java и C#: облегчение — да, но за счет ресурсов, что не везде применимо. Следующий этап — Rust и гарантии безопасности во время компиляции. Что будет дальше, приживется ли Rust, появится ли другой язык — я не знаю, но я рад, что вещи движутся в нужном и правильном направлении.
Здравствуйте, alex_public, Вы писали:
_>http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html — что-то как-то странно они его теснят. )))
_>Кстати, очень характерно взглянуть на этой же страничке на цифры для D, Rust и Swift (как пример того, как выглядит новый язык, который всё же взлетел).
А чего цифры?
D 1.015
Objective-C 1.074
Swift 1.363
JavaScript 2.565
Со взлетелостью Objective-C никто спорить не станет, я думаю, а судя по этим цифрам D тогда тоже неплохо взлетел. Вот Расту там в 5 раз меньше дали рейтинг, и по-моему это очень странные цифры, очень странные. Судя по бурлениям интернетов в последние год-два и статистике всяких гитхабов, Раст должен опережать Ди, а не отставать так сильно. Кароч, я б не стал с серьезным лицом на этот рейтинг ссылаться.
Здравствуйте, D. Mon, Вы писали:
_>>http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html — что-то как-то странно они его теснят. ))) _>>Кстати, очень характерно взглянуть на этой же страничке на цифры для D, Rust и Swift (как пример того, как выглядит новый язык, который всё же взлетел). DM>А чего цифры? DM>
DM>Со взлетелостью Objective-C никто спорить не станет, я думаю, а судя по этим цифрам D тогда тоже неплохо взлетел. Вот Расту там в 5 раз меньше дали рейтинг, и по-моему это очень странные цифры, очень странные. Судя по бурлениям интернетов в последние год-два и статистике всяких гитхабов, Раст должен опережать Ди, а не отставать так сильно. Кароч, я б не стал с серьезным лицом на этот рейтинг ссылаться.
Нуу D действительно постепенно пытается выбраться из зоны маргинальных языков. Однако надо учесть, что это уже лет 10 происходит и результат трудно назвать реальным успехом. Swift же явно смог всего за год (и думаю в будущем его процент будет заметно выше). Что касается Objective-C то тут обратная ситуация. Даже до выхода Swift'a это был откровенно унылый язык, который держался на плаву только из-за его особой поддержке на одной из платформ, переживающей краткий пик популярности (я про айфоны). Теперь же, после появления даже на этой уже не самой популярной платформе другого главного языка, Objective-C является однозначным трупом (http://www.tiobe.com/index.php/content/paperinfo/tpci/Objective_C.html тут это отлично видно).
Что касается Rust, то почему ты думаешь, что цифры не верны? Да, обсуждали (и надеялись) многие, и я в том числе. Только вот какой процент из них начал использовать данный язык в реальных проектах? Подозреваю что у Rust'а ситуация в точности такая же, как и у D в первые годы его появления. И соответственно прогнозы могут быть такие же неутешительные — невыход из маргинальной зоны в ближайшее десятилетие.
Здравствуйте, LaPerouse, Вы писали:
В>>Паттерн-матчинг; В>>Алгебраические типы данных;
LP>Эти два пункта скорее минус, чем плюс, так как провоцируют написание г-нокода.
Но есть ли нормальная замена union-типам? Все делать на классах?
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, LaPerouse, Вы писали:
В>>>Паттерн-матчинг; В>>>Алгебраические типы данных;
LP>>Эти два пункта скорее минус, чем плюс, так как провоцируют написание г-нокода.
ARK>Но есть ли нормальная замена union-типам? Все делать на классах?
А им требуется замена? По мне, это в чистом виде антипаттерн, к которому следует относится с большой осторожностью. Потеря абстракции и завязка на реализацию в обмен на сомнительное удобство обращения к переменным. Добавил одно поле — и надо править еще N классов и модулей, где этот тип используется, такого ада даже в языке С двадцать лет назад в эпоху расцвета процедурного программирования не было.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
ARK>>Но есть ли нормальная замена union-типам? Все делать на классах?
LP>А им требуется замена? По мне, это в чистом виде антипаттерн, к которому следует относится с большой осторожностью.
Ну, например, возврат из функции — ошибки либо нормального результата.
LP>Добавил одно поле — и надо править еще N классов и модулей, где этот тип используется, такого ада даже в языке С двадцать лет назад в эпоху расцвета процедурного программирования не было.
Это как раз преимущество — не забудешь, где еще не исправил. Юнионы — закрытые иерархии, а классы — наоборот открытые.
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, LaPerouse, Вы писали:
ARK>>>Но есть ли нормальная замена union-типам? Все делать на классах?
LP>>А им требуется замена? По мне, это в чистом виде антипаттерн, к которому следует относится с большой осторожностью. ARK>Ну, например, возврат из функции — ошибки либо нормального результата.
Возвращать код ошибки — это прошлый век. Для ошибок есть исключения.
LP>>Добавил одно поле — и надо править еще N классов и модулей, где этот тип используется, такого ада даже в языке С двадцать лет назад в эпоху расцвета процедурного программирования не было. ARK>Это как раз преимущество — не забудешь, где еще не исправил.
foo (Foo val1 val2) = val1 + val2
Добавляем в Foo третье поле val3. Конкретно в функции foo это поле НЕ используется. Но мы должны ее изменить
foo (Foo val1 val2 val3) = val1 + val2
И таких функций по всему коду — море, в разных модулях и классах.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, Васильич, Вы писали:
В>И при все этом приятный синтаксис (за исключением, пожалуй, генериков).
Как по мне, дженерики ещё нормальные, а вот макросы выглядят как-то неприятно. Ну и лайфтаймы, разумеется, усложняют код.
Здравствуйте, AlexRK, Вы писали:
ARK>Чувак хочет обрабатывать нехватку памяти, а Rust ему не дает — все аллокации производятся неявно и в случае нехватки памяти делается аборт всего процесса. Хотя, как я понимаю, это больше ограничение существующих библиотек. Можно ведь и самому написать выделитель с проверкой результата. Но потом под него придется все остальное переписывать.
Аллокаторами они занимаются, вроде. По крайней мере, это есть в планах на текущий год. А с ними переписывать, по идее, придётся меньше.
Здравствуйте, LaPerouse, Вы писали:
LP>Возвращать код ошибки — это прошлый век.
Код ошибки — да, прошлый век.
Алгебраический тип — нет.
LP>Для ошибок есть исключения.
В требовательном к надежности коде исключения неприемлемы. В таких случаях что взять в качестве альтернативы union-типам?
(Хотя лично мое мнение — исключения вообще не нужны, но это уже к теме не относится.)
Ну или другой пример — передача в функции нуллабельных ссылок. Здесь какие варианты? Хардкод особого "нулла" в компиляторе, без контроля разыменования, как сейчас везде сделано?
LP>foo (Foo val1 val2) = val1 + val2 LP>foo (Foo val1 val2 val3) = val1 + val2 LP>Добавляем в Foo третье поле val3. Конкретно в функции foo это поле НЕ используется. Но мы должны ее изменить
Разумеется, мы должны ее изменить. Потому что сейчас не используется, а через месяц будет использоваться. Это уже деталь реализации — что используется, а что нет.
LP>И таких функций по всему коду — море, в разных модулях и классах.
Ну и что?
Когда мы добавляем параметр функции, у нас тоже море вызовов по всему коду, которые надо изменить.
