Comments 58
Вообще non_exhaustive легко делается при помощи unit поля в структуре или варианта в енаме. Хотя в последнем случае это плохо тем что он виден.
Видел я плач ярославны на реддите, что это якобы плохая фича.
Ну мое мнение что фича действительно не очень. Раньше если мы получали при добавлении варианта ошибку компиляции, то теперь мы обязаны написать еще одну ветку в матче. Которая (вангую) в 99% будет либо паникой либо молчаливым проглатыванием варианта с возвратом какого-то дефолта.
В некотором смысле фича абсолютно противоположена философии раста.
Я тоже с этой фичей не сразу смирился, ещё в описании релиза приводят atomic::Ordering — да, мало какой "пользовательский" код будет этот enum матчить, но я плохо представляю какую логику можно воткнуть в _. Ну кроме паники, что несколько портит всю идею. Лучше бы про io::ErrorKind сказали.
В общем, фича иногда полезная, но позволяет переносить проблемы из библиотеки в пользовательский код. Буду надеяться, что её будут использовать аккуратно.
Ну вы просто знаете C и имеете опыт программирования на нем, но не знаете Rust и не имеете опыта программирования на нем. Конечно, в таком случае для вас С предпочтительней. А вот для меня — наоборот ) Я программировал и на том, и на другом, и Раст для меня предпочтительнее, особенно если нужно что-то "быстрое и на коленке", как ни странно.
Еще как пытается. Я вообще убежден, что Rust займет место Java в перспективе. Потому что в нем достигается лучшее соотношение безопасность/производительность. Да и развитая система типов с бесплатными абстракциями многого стоит в крупных проектах с большими командами разработчиков.
Ну и что? Почему вы решили, что это вообще составляет проблему? )
Я вот работал с несколькими крупными веб-приложениями, написанными на Rust, и в них Box и RefCell практически не использовались совсем (!), а там, где все-таки использовались — в единичных местах — никаких проблем и затруднений они не вызывали. Что же касается Arc и Mutex — так это вообще благо, ибо КОРРЕКТНЫЙ многопоточный код на Rust пишется в разы проще, чем на Java.
Я часто слышу, как люди, которые особого опыта-то и не имеют в enterprise, пытаются априори отгородить его от Rust. Зачем вы это делаете? Я использую Rust в проектах enterprise-уровня и доволен. Не доволен пока только слабо развитой экосистемой, но к самому языку претензий нет. Тот уровень выразительности и безопасности для кодирования бизнесс-логики, который обеспечивает система типов Rust, с лихвой окупает небольшие неприятности, связанные с эпизодической ручной работой с умными указателями. И то, часто появление таких проблем — это свидетельство того, что нужно остановиться и подумать над общей архитектурой хранения данных и об ответственности за владение объектами в системе.
это ООП язык с GC и возможностями формальной верификации программ системой типов как в Idris
Фигасе вы загнули ) Вряд ли возможна система типов "как в Idris", совместимая с ООП.
Ну, ваш взгляд имеет право на существование. Но я подозреваю, что вы либо мало работали с Rust и он вам просто непривычен, либо какой-то неправильный энтерпрайз у вас был на Java ) Без ада с NPE.
Концепция владения тоже, ИМХО, ненужна в языке для прикладных задач.
Есть гипотеза, что концепция владения способствует созданию лучшей архитектуры. Во всяком случае я уже себе плохо представляю, как бы я мог писать производительный код не задумываясь о владении. И да, я считаю что контроль за потребляемыми ресурсами — это важная часть прикладной разработки сегодня.
В языке с GC такой проблемы бы не возникло вообще.
В итоге там возникла бы другая проблема — гонка данных. Так что эта простота оказывает медвежью услугу: она создает видимость, что можно вот так просто взять и расшарить объект между потоками, не задумываясь о владении. Поэтому в той же Java многопоточное программирование — это совсем отдельное минное поле, требующее специальной подготовки джависта. А в Rust это вписывается очень органично — разок напрягся в самом начале, и дальше просто переиспользуешь уже имеющийся опыт )
Я имел ввиду, что рано или поздно гонка придет. И станет все очень сложно, хотя казалось изначально иначе.
Смотря что под ООП понимать, и что под ФП. У всех ведь разные определения в голове на этот счёт)
Наличие сабтайпинга, думаю, для ООП важно, а оно много чего ломает в системах типов в языках типа идриса.
Есть такие понимания, в которых не важно. Более того, оно не было важно в изначальной трактовке термина от Алана Кея(если уж занудствовать).
(Поэтому я за то чтобы выкинуть термин ООП за неоднозначность и взять что-нибудь конкретное и не дискредетировавшее себя).
Я склоняюсь в определению "ООП это как в Java".
А ООП по Кею в наши дни называется "акторная модель".
Я склоняюсь в определению «ООП это как в Java».
А что значит «как в Java»? В Java, много чего есть.
Если про «3 Кита» — ну, ничего хорошего скрывающегося под этим определением я не видел. Мало этого что-бы внятную разницу иметь между процедурным програмированием и ООП.
Без наследования, которое выше обсуждалось, жить точно можно и думаю лучше чем с ним, при удобной композиции, делегатах и т.п.
Да и есть мысль что большая часть кода на Джаве(да и любом другом мейнстрим-языке) это, в силу старых привычек, легаси и старых стандартов, скорее процедурный код(с классами, да). Люди до сих пор делают сущности из геттеров/сеттеров, и выносят логику в сервисы.
Черт, смотрю я на Rust, он становится все сложнее и сложнее
Давайте посмотрим на этот выпуск — что поменялось? Переименовали unimplemented -> todo, ок. Добавили новый атрибут в стд — ок. Функционал который задперикейтили год назад и сыпали варнингами теперь окончательно выпилили — ок. Ну и пачку тривиальных функций добавили.
Вы видите в этом особое усложнение?
может дешевле работать на сырых указателях C++ (просто аккуратно) а для больших приложений взять какую-нибудь Scala?
Если вы можете взять скалу — то берите скалу, ни раст, ни плюсы в этом случае вам не нужны. Раст нужно брать для ситуации, где вы хотели бы взять плюсы, но вы не программист с 15 годами опыта изучения гцц, а приложение написать надо. Ну или вы такой программист, но хотите чуть более продуктивно работать и не писать свои строки и векторы.
А писать на плюсах аккуратно имхо невозможно, как из раза в раз доказывают всевозможные отчеты разных компаний.
Скала сильно переусложнена ИМХО, Раст там и рядом не стоял в аспекте "когнитивной нагрузки", которую зачастую требует скалистый код.
Скала сложнее только если смотреть на плотность информации на строчку кода. Если смотреть в абсолютных величинах, то она получается попроще.
Вторая проблема — неидиоматичность. Неидиоматичный раст написать тяжело потому что в половине случаев такой код просто не соберется, и придется спрашивать у сообщества как делать, в половине соберется, но придет клиппи и скажет как заменить. В скале же если не получается сделать правильно можно налепить что-то в стиле "Беттер джавы" и получить все те же проблемы, но только теперь со странным синтаксисом.
Насчет типов — раст намного лучше мейнстрим языков, но все же ощутимо уступает более продвинутым системам. Тот же многопоток который одна из киллер фич раста писать на STM на порядок проще и приятнее, чем обмазываться арками и мьютексами. Если можно себе позволить гц и вам не жалко 50-100% производительности и x2-x10 памяти, то можно брать языки с более сильными системами типов и гц.
Как хаскелист говорю, что скала переусложнена (и вообще в uncanny valley).
- Есть мнение, что в скале синтаксис попроще будет хаскелля. Если тупо сравнить количество синтаксических конструкций и сложность написания парсера
- Скала интересна тем что это жвм, эрго 100 миллионов библиотек на любой вкус. На хаскелле — чуть в сторону от проторенной тропинки и всё.
Хотя мне лично ML синтаксис нравится больше. Но сейчас дотти ведь выходит, там и синтаксис подкрутили, и крутые штуки вроде частичных вычислений. В хаскелле такого нет.
Лично у меня от этого бесконечного [_] рябит в глазах и начинает болеть голова.
Ну, ML синтаксис вроде поприятнее выглядит, тут ничего не скажешь
Ну вот, например, описание всех возможных экспрешонов: http://hackage.haskell.org/package/template-haskell-2.15.0.0/docs/Language-Haskell-TH-Syntax.html#t:Exp, включая некоторые расширения. А как бы оно выглядело для скалы?
Корова не моя, у меня знакомый очень много на скале и хаскелле пишет. Могу переадресовать вопрос, но тогда придется подождать ответ.
А как, кстати, ненативные и неидиоматичные для скалы библиотеки в ней ощущаются? Удобно ли с ними работать?
Не очень, но удобнее чем писать их самому.
О, а это любопытно. Гуглится какая-то ерунда, правда, так что можете вкратце рассказать, что за частичные вычисления?
Ну вот например:
https://scastie.scala-lang.org/bR8NNUdQS5a2fen1T8LVFw
На FPure были неплохие доклады про успехи на этом поприще, впрочем я думаю вы про проекции Футамуры и так в курсе. Ну и там же всякие штуки про автоматическую оптимизацию наивной функции let y = sqr(x, 5) в let xx = x*x; let y = xx*xx*x
Как вам такая когнитивная нагрузка?
И нет, в скале даже близко так сложно бы не вышло.
В данном примере асинк-авейт по некоторым причинам нельзя использовать (он еще не со всем хорошо работает), поэтому вот так.
Это не мой код, который я специально написал чтобы запугать, это человек реально такое запилил в своем проекте, попытавшись запихнуть сайд эффекты в стрим.
В общем, мораль в том что раст это офигенный язык, но нужно понимать его трейдофы, и не всовывать квадрат в круглое отверстие.
Когда сообщения об ошибках разрывают поток кода — совершенно невозможно ничего понять (тому кто видит этот код впервые). Так что да, в таком оформлении — нагрузка высока. Но лично я так не программирую на Rust.
Я люблю Rust, но его zero cost совсем небесплатен для мозга программиста…
ИМХО, "просто аккуратно" пользоваться C++ — вещь ещё более "небесплатная".
Эмм… Я вот программирую на Расте каждый день и уже устаю ждать некоторых фич, которые очень хочется иметь в языке и которые все пилятся и пилятся. Где вы увидели усложнение языка? Кроме async/await в последнее время вообще небыло никаких принципиальных нововведений.
Узкая ниша для неперемещаемых в рантайме данных.
Любой асинк код — это не узкая ниша.
Любому асинк коду неперемещаемые данные не нужны как раз. Очень малое его подмножество требует статического положения данных, которое не зависит от изменения и смены стека.
Любой борровинг локальных переменных ниже авейта — это пин. И шаг влево, шаг вправо — и этот пин вылезает и требует о нем знать. Вот не хотел я его знать, но потребовалось чуть-чуть отойти от протореной дорожки — написать рекурсивную асинк функцию — и тут же мне и боксы понадобились ручные, и пины, и всё остальное.
Дык, все живые языки развиваются. Даже в го, киллер фичей которого считаю простоту освоения, дженерики завезти хотят.
И с другой стороны: столько нужных фич в расте ещё не сделаны! (:
Выпуск Rust 1.40.0: #[non_exhaustive], усовершенствования макросов и прочие улучшения