Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 58
Ну мое мнение что фича действительно не очень. Раньше если мы получали при добавлении варианта ошибку компиляции, то теперь мы обязаны написать еще одну ветку в матче. Которая (вангую) в 99% будет либо паникой либо молчаливым проглатыванием варианта с возвратом какого-то дефолта.
В некотором смысле фича абсолютно противоположена философии раста.
Я тоже с этой фичей не сразу смирился, ещё в описании релиза приводят atomic::Ordering — да, мало какой "пользовательский" код будет этот enum матчить, но я плохо представляю какую логику можно воткнуть в _. Ну кроме паники, что несколько портит всю идею. Лучше бы про io::ErrorKind сказали.
В общем, фича иногда полезная, но позволяет переносить проблемы из библиотеки в пользовательский код. Буду надеяться, что её будут использовать аккуратно.
Мне кажется что все равно в текущей модели, уровень когнитивных нагрузок совсем другой. Сейчас комфортно пользоваться всеми прелестями С++ можно только если ты уже программируешь лет 15-20 и научился обходить все подводные камни. Или же можно писать используя где-то 3-5% языка С++ (или даже регрессировать на С) и в принципе все будет более менее, особенно если ты делаешь что-то приземленное вроде numerical computing. Если нужен «кровавый enterprise» то конечно можно взять или C# или Kotlin, им Rust не конкурент и не пытается им быть.
Ну вы просто знаете 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], усовершенствования макросов и прочие улучшения