_>>1) Пока нормальных исключений не завезут — к индустриальной разработке не годен. Сейчас исключений как-бы нет, но они немножко есть на донышке. В плане надёжности получилось худшее из двух миров, кмк. TB>По остальному в целом согласен, но тут-то что не так?
"Не так" хотя-бы то что я вынужден выписывать иногда однотипный, иногда нет, код обработки ошибок. Пусть даже с одним лишь значком "?" в простейших случаях, но я должен это сделать.
И при этом я же, одновременно с выписыванием обработки ошибок, должен держать в уме что есть ситуации когда может и panic стрельнуть. Тот же RefCell<> при неосторожном использовании может кинуть паником в рантайме.
В итоге вместо обещанного светлого будущего в котором ошибок так мало, что их все можно отловить if-ами, я должен держать в уме сразу оба подхода, и регулярно почитывать статейки типа "How to Design For Panic Resilience in Rust". А используя библиотечный код — как узнать что его авторы читали те же статьи? Заглядывать внутрь в надежде оценить "как там сделали обработку ошибок-то, нормально, или она мне всю прогу повалит?".
Для тех кто далёк от rust: Показателен пример с делением на 0. Что-бы в панику не свалилась функция которая что-то делит: сначала я должен проверить аргумент на 0 и придумать как выйти с ошибкой, потом его ещё проверит компилятор (что-бы бросить мне панику которой я так стараюсь избежать). В то время как в C#/java/и т.п. я могу сделать пару десятков потенциально проблемных операций вообще не думая о последствиях, обернуть их по-быстрому в один try/catch, вывести окошко или написать в лог "не шмогла, попробуйте другую функцию программы", и забить до моментка пока пользователи жаловаться не начнут "что-то часто не может". И, что показательно, надёжность вот такого "слепил за 15 минут, TODO сделать нормально", оказывается ничуть не меньше — все варианты ошибок, кроме stackoverflow и oom будут отловлены ничуть не хуже чем в rust. Ну и ради чего превозмогаем-то?
Здравствуйте, varenikAA, Вы писали:
AA>Смотрю неплохой ЯП сделали.
эту ссанину пора закапывать, она уже даже для попиломных стартапов не годится, а ты вдруг смотреть решил, учи английский, или, на крайняк, sql, всяко больше пригодится.
SP>а можно немного больше аргументации?
Я там чуть выше по ветке написал что сейчас получилось что rust одной ногой в исключениях, другой ногой в кодах ошибок, а программисту в итоге стало ещё больше о чём думать. И в go тоже от исключений никуда не убежали.
Если хочется максимум аргументации по теме "исключения это хорошо или плохо", то пик обсуждений пришёлся на 70-е, и немножко 80-е годы прошлого века. Всё что я смогу намалякать в рамках форума — будет в десятки раз слабее.
Если следить за предками: Деды программирования начинали без всяких исключений. Спутники в космос пускали и ядерные реакции моделировали. И они реально бились за каждый такт своих компьютеров, которые по нашим меркам давно уже микроконтроллеры. Cъев собаку на кодах ошибок, и постоянных проблемах в больших программах с кодами ошибок, они за идею исключений ухватились так сильно, что с 70-х все языки выходили с исключениями. Включая языки которые сразу позиционировались как "для особо надёжных программ", типа Ады.
Ну а если за авторитетами не следить — типичная современная задача — набрать данных побольше, и скормить в какую-то библиотку для обработки. И допустим из-за ошибки в тех данных случится внутри библиотеки необработанный выход за границу массива. Какую реакцию даст программа с исключениями? — да типовую "у нас там выход за границу массива, дайте другие данные и повторим". Rust сразу же попытается завалить твою программу в panic, а ты там колдуй над catch_unwind (и то я даже не напрягался проверять сработает ли перехват на out of bounds).
SP>Мне наоборот кажется, что от исключений надо уходить. Сейчас часто фикшу код, который или слишком много исключений бросает (их не обрабатывают), либо слишком мало (где-то выше по стеку словили и умолчали ошибку).
Плохо написанный код это плохо написанный код. Представь как тебе "полегчает", если враги будут проглатывать коды ошибок и возвращать тебе Option(None), или Result(Error) без всяких опознавательных знаков. Станет сложнее или легче?
P.S. Я помно времена когда в rust со скрипом отказывались от исключений. Это было сделано исключительно из-за того что никак не получалось подружить с исключениями borrow checker. Уже ближе к релизу авторы переобулись и начали заливать про то что исключения медленные и плохие, а коды ошибок быстрые и хорошие.
Здравствуйте, T4r4sB, Вы писали:
TB>Ты объём кодобазы видел? Или потроллить пришёл? Давай ещё всё мировое ПО перепишем на Раст, потому что некий онаним из интернетика решил, что это должно доказать практичность.
Ну вообще-то очень многие языки генерируют машинный код сами. Тот же Go из современных. llvm сделан для C++ в первую очередь. Я понятия не имею, насколько это ограничивает Rust, но я точно знаю, что работа llvm занимает львиную долю во времени компиляции, а время компиляции это одна из важных претензий к Rust. Да и с оптимизациями, скорей всего, не всё идеально.
Переписывать llvm, конечно, смысла нет, а вот заменить его в компиляторе Rust может быть и было бы неплохо. llvm хорош на первом этапе разработки компилятора, когда хочется сконцентрироваться на разработке языка и получить ряд оптимизаций на халяву.
Здравствуйте, vsb, Вы писали:
vsb>Переписывать llvm, конечно, смысла нет, а вот заменить его в компиляторе Rust может быть и было бы неплохо. llvm хорош на первом этапе разработки компилятора, когда хочется сконцентрироваться на разработке языка и получить ряд оптимизаций на халяву.
Здравствуйте, kaa.python, Вы писали:
KP>Практичный, интересный, потенциально полезный. Если не знаешь C++ — стоит смотреть. Если знаешь C++ Если уровень знания C++ достаточен для коммерческого применения — не стоит смотреть.
А по каким критериям определяется уровень знания С++ для коммерческого применения?
Вот если человек годами пишет на Qt, но на чистом с++/STL не сможет аллокатор написать, ибо весь его опыт завязан на архитекруру и идеологию, диктуемую фреймворком, где даже STL не используется — это считается достаточным знанием с++?
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>UPD: пишут, что таки да, но у меня сомнения. Вроде же говорили, что он компилирует через llvm, ЭФ>а она-то написана не на rust. Поэтому не считается.
Есть https://github.com/bytecodealliance/wasmtime/tree/main/cranelift (в девичестве Cranelift), который написан на Rust. Уже почти работает.
Здравствуйте, T4r4sB, Вы писали:
ЭФ>>Вроде же говорили, что он компилирует через llvm, ЭФ>>а она-то написана не на rust. Поэтому не считается. TB>Переписать ллвм на раст? Делать вообще нехрен?
Вообще, примерно это уже делается в wasmtime. Немного для другой цели — для быстрой JIT-компиляции WASM, для которой LLVM не очень подходит. В качестве побочного продукта — они планируют использовать это в качестве backend'а для Rust.
Здравствуйте, Михaил, Вы писали:
М>А по каким критериям определяется уровень знания С++ для коммерческого применения?
А по каким критериям такое обычно измеряют? Вариант "платят за написание кода на C++, при необходимости смены работы уровня владения зыком хватит для успешного прохождения собеседования" вполне достаточен как мне кажется, если и дальше не продолжать придираться к формулировке конечно.
Здравствуйте, fmiracle, Вы писали:
F>if( null ){ F>// а что null-то? F>[/cs]
Ну тут понятно, что ЕСЛИ никогда не выполнится.
Вчера в статье цитату увидел, примерно звучит так "чем меньше кода, тем быстрее пишется программа.".
C# в этом плане аки джава. "бесконечные иф а равно равно нал", "попытка сделать что-то ждем ошибку если поймали ее делаем что-то другое".
Столько лишнего кода, боже мой.
А насчет раст`а заметил, что он копирует в основнах go, теже обяхательные скобки после ифа и т.п. плюс добавляет то чего ждут в го — дженерики, ну и куча всяких типов.
методы для структур 1-1 — гоу.
тут был холивар про отступы в питоне, что по скобкам легче в иде прыгать. так лиспах аналогично очень легко прыгать.
Насчет оптимизаций наверно тоже инфа устарела. ведь вся динамика и вообще все вм-языки проходит минимум две стадии — компиляция в промежуточный код и потом еще через джит проходит.
ну да просадки во время сборки мусора возможны, но разве в расте и си не нужно мусор убирать?
Запутался в общем
Здравствуйте, sergii.p, Вы писали:
SP>а можно немного больше аргументации? Мне наоборот кажется, что от исключений надо уходить. Сейчас часто фикшу код, который или слишком много исключений бросает (их не обрабатывают), либо слишком мало (где-то выше по стеку словили и умолчали ошибку).
Есть неплохой оратор на ютубе Антон Молдаван.
У него этот момент хорошо описан.
Т.е. задачу описывает доменная модель
в которой лежат известные ошибки
type PaymentError =
| NoMoney
| NoConnect
..................
И только если случается какая-то неизвестная ошибка
она попадает в исключения.
Ну и по логам сразу видно, что какой-то кейс не учли.
в PaymentError добавляется новая ошибка и софт улучшается.
Но да, есть любители возвращать void особенно в C# а внутри try catch finally даже без WriteLine(exc);
с появлением кортежей стало проще return (true, "ништяк") улучшил читаемость кода.
Здравствуйте, kaa.python, Вы писали:
DM>>Они сейчас делают альтернативный кодеген, на самом Расте. DM>>https://github.com/bjorn3/rustc_codegen_cranelift DM>>А то тормознутость ЛЛВМ всех достала.
KP>И в году так 2030 они его может быть смогут довести по качеству генерируемого кода до LLVM образца 2020, судя по интенсивности коммитов.
А там нет задачи заменить ЛЛВМ и догнать его по качеству. Есть задача сделать нечто, что будет компилировать быстро, пока разрабатываешь и тестируешь. А как надо релиз собрать — включаешь опять ЛЛВМ и делаешь уже долгую но качественную сборку.
Подозреваю, что такая дихотомия неизбежна — борьба за последние проценты производительности сгенеренного кода требует долгой компиляции, так что либо компилируешь быстро, либо код быстрый.
У меня основной язык C++. Опыт 15 лет. Но приходилось писать в том числе на Java, Go, Python, JavaScript в коммерческих проектах. Все эти языки плюс-минус норм, отторжения не вызывают (ну кроме подергивания глаз от нюансов JS
И вот решил я попробовать Rust. Он мне вообще не зашел. Вроде идеи есть интересные, но мне он показался сложным, перемудреным и сложно читаемым Разного вида скобок еще больше, чем в самых свежих плюсах. Кроме того, я не вижу преимуществ (кроме хайпа вокруг него), который мне дает Раст в сравнении с плюсами.
После этого начал изучать и юзать Swift — вообще отлично зашел. Очень простой и удобный язык. Go в свое время тоже очень гладко зашел — просто начинаешь писать код и все. Да и сторонние сорцы читаются легко.
Почему писал про свой плюсовый опыт? Потому что у меня складывается ощущение, что у плюсовиков скорее негативно-настороженное отношение к Расту, а у людей с языками вроде JS, PHP и т.д., условно "вебовых", наоборот — восторженное отношение.
Здравствуйте, DiPaolo, Вы писали:
DP>Почему писал про свой плюсовый опыт? Потому что у меня складывается ощущение, что у плюсовиков скорее негативно-настороженное отношение к Расту, а у людей с языками вроде JS, PHP и т.д., условно "вебовых", наоборот — восторженное отношение.
У меня тоже основной язык C++ и опыт лет на пять больше. Но мне раст понравился, не сказать что я от него в восторге, но во многом (но далеко не во всем) лучше чем С++.
У раста большая проблема в том что у него очень высокий порог входа и опыт в C++ (C#, Java) его преодолеть никак ни помогает, в этом он на тот же хаскель очень похож. Но порог этот хоть и крутой но вполне преодолимый, это гораздо проще чем изучить хаскель или даже OCaml.
У меня был очень тяжелый опыт по изучению OCaml'а, удалось только после нескольких попыток, сильно мешал как раз "императивный" С++ опыт, но после изучения, это очень простой и понятный язык. А вот раст уже с базой С++ + OCaml зашел не сказать что легко, но вполне нормально, поскрипеть мозгами конечно заставил, но это всегда полезно.
Раст — замечательный язык! Это очень красивый язык, который вобрал в себя многое из языков Haskell, Ocaml, C, C++. Многие замечают, что на расте написать быстро работающий код проще, чем написать эквивалентный на C++. При прочих равных, программирование на C++ таит в себе огромное количество ловушек, особенно в вопросах производительности кода, чего в расте практически не наблюдается. Безусловно, С++ требует большего мастерства, больших знаний. Раст, скорее, непривычен для тех, кто мало знаком с миром функционального программирования. Те же, кто хорошо знаком, обычно очень высоко оценивают сам язык раст, часто считая его чуть ли не самым лучшим языком на свете! И даже отсутствие исключений в языке, скорее, плюс, чем минус.
Например, чтобы написать свою версию std::vector на С++, нужно очень многое знать, особенно про безопасность относительно исключений. Вообще, исключения в C++ проходят красной линией по всему языку. Они повлияли на весь дизайн языка. Думая о C++, нужно всегда думать об исключениях.
В случае же раста многое становится проще, много проще. И написать свой аналог Vec тоже безусловно проще, где даже unsafe не так страшен. На самом деле, исключения в расте тоже есть — это паника. Однако, здесь достаточно выдержать базовый уровень безопасности относительно исключений, что много проще, чем, скажем, гарантировать, что все объекты сохранят свое состояние, как было бы в случае C++. Правда, это расслабляет при написании на языке раст, и я допускаю, что кто-то может не знать или пропустить такие вещи, но много ли программистов на С++ задумываются о безопасности относительно исключений?!
А перекочевавшая из Haskell в раст троица из трейтов, генериков и ограничений — это, вообще, шедевр, классика жанра. Растоманы, конечно, взяли готовые и проверенные идеи из мира Haskell, но никто больше это и не реализовывал в таком виде. Муки с шаблонами C++ тут и рядом не стояли. Однако, шаблоны позволяют реализовать более сложные, более хитрые вещи, но часто ли это нужно? Может быть, эта троица покрывает большинство вариантов использования?
Теперь ложка дегтя, или даже больше. В раст в настоящее время нет стабильного ABI. Если вам не повезет, и вы захотите создать закрытую библиотеку на языке раст, то ваши наполеоновские планы быстро разрушатся, потому что все кишки вашей библиотеки будут видны наружу. Единственное, что вы можете попытаться сделать, так это какую-то часть утащить в код, который можно оформить как независимую библиотеку со сишным ABI, но это часто не работает, потому что многие высокоуровневые вещи из языка раст туда просто не переносятся, хотя вот замыкания простые или клонирование, к слову, можно перенести ценой написания кучи бойлерплейта.
Как альтернатива, С++ предлагает открывать на всеобщее обозрение заголовочные файлы, а основную логику можно спрятать в статической либе, скажем. На юниксах либа эта будет набором объектных файлов. Это будет работать в рамках линейки компилятора C++. И тогда вашим конкурентам станет намного сложнее украсть ваши идеи.
Другими словами, раст очень красивый язык, но есть детали, о которые могут разбиться ваши планы, и придётся вам писать снова на С++...
Здесь чувствуется, что законодатели моды в расте сильно подвержены идеям опенсорса. Допускаю мысль, что отсутствие ABI могло быть даже намеренным. Остается только грустить, вспоминая о том, что в языке Ада, например, есть ключевое слово separate специально для таких целей. И в языках C и C++ очень хорошо проработали этот момент, где ощущается опыт поколений, живших не только одним опенсорсом насущным. Однако, раст задал очень высокую планку для языков программирования, и я надеюсь, что в будущем нас ждут еще большие открытия в мире программирования.
Здравствуйте, kaa.python, Вы писали:
KP>Что-то большое, на хотя бы пару сотен KLOC этом чудо языке поддерживал и развивал?
Задело за живое, что пошли переходы на личности вопросы о личном опыте? Ну-ну. Всегда принципиально оставляю такие вопросы без ответа, хотя есть чем ответить
Здравствуйте, dsorokin, Вы писали:
D>Здравствуйте, kaa.python, Вы писали:
KP>>Что-то большое, на хотя бы пару сотен KLOC этом чудо языке поддерживал и развивал?
D>Задело за живое, что пошли переходы на личности вопросы о личном опыте? Ну-ну. Всегда принципиально оставляю такие вопросы без ответа, хотя есть чем ответить
Ни чуть, чем меня может задеть утверждение что язык прекрасен? По моим наблюдениям активнее всего Rust-ом восхищаются те, кто на нем ничего реального не писал. А вот когда человек что-то на нем реально писал
всё, внезапно, оказывается не так уж и радужно. Единороги превращаются в пони, радуга в разливы бензина на воде...
Посему вопрос о личном опыте более чем закономерен. Где же это переход на личности? Это попытка понять ни очередной ли продавец розовых пони единорогов к нам наведался.
