Когда сообщения об ошибках разрывают поток кода — совершенно невозможно ничего понять (тому кто видит этот код впервые). Так что да, в таком оформлении — нагрузка высока. Но лично я так не программирую на Rust.
это ООП язык с GC и возможностями формальной верификации программ системой типов как в Idris
Фигасе вы загнули ) Вряд ли возможна система типов "как в Idris", совместимая с ООП.
Ну, ваш взгляд имеет право на существование. Но я подозреваю, что вы либо мало работали с Rust и он вам просто непривычен, либо какой-то неправильный энтерпрайз у вас был на Java ) Без ада с NPE.
Концепция владения тоже, ИМХО, ненужна в языке для прикладных задач.
Есть гипотеза, что концепция владения способствует созданию лучшей архитектуры. Во всяком случае я уже себе плохо представляю, как бы я мог писать производительный код не задумываясь о владении. И да, я считаю что контроль за потребляемыми ресурсами — это важная часть прикладной разработки сегодня.
В языке с GC такой проблемы бы не возникло вообще.
В итоге там возникла бы другая проблема — гонка данных. Так что эта простота оказывает медвежью услугу: она создает видимость, что можно вот так просто взять и расшарить объект между потоками, не задумываясь о владении. Поэтому в той же Java многопоточное программирование — это совсем отдельное минное поле, требующее специальной подготовки джависта. А в Rust это вписывается очень органично — разок напрягся в самом начале, и дальше просто переиспользуешь уже имеющийся опыт )
Обычно структуры используются не сильно большие, чтобы их упаковывать, чаще всего они — Copy-типы. Ну а коллекции — в них упаковка скрыта от пользователя. RefCell же полезен в связке с Rc, а когда у вас шаренных объектов и так мало, то еще меньшему числу нужна шаренная мутабельность. )
Ну и что? Почему вы решили, что это вообще составляет проблему? )
Я вот работал с несколькими крупными веб-приложениями, написанными на Rust, и в них Box и RefCell практически не использовались совсем (!), а там, где все-таки использовались — в единичных местах — никаких проблем и затруднений они не вызывали. Что же касается Arc и Mutex — так это вообще благо, ибо КОРРЕКТНЫЙ многопоточный код на Rust пишется в разы проще, чем на Java.
Я часто слышу, как люди, которые особого опыта-то и не имеют в enterprise, пытаются априори отгородить его от Rust. Зачем вы это делаете? Я использую Rust в проектах enterprise-уровня и доволен. Не доволен пока только слабо развитой экосистемой, но к самому языку претензий нет. Тот уровень выразительности и безопасности для кодирования бизнесс-логики, который обеспечивает система типов Rust, с лихвой окупает небольшие неприятности, связанные с эпизодической ручной работой с умными указателями. И то, часто появление таких проблем — это свидетельство того, что нужно остановиться и подумать над общей архитектурой хранения данных и об ответственности за владение объектами в системе.
Почему же сразу религиозный? Я вроде бы вполне рациональные доводы привел. Может быть вы недостаточно повидали «кровавого enterprise» и не в курсе, чем он болен и каково лекарство )
Доля везения — существенна, но как я понимаю, основное — это связи и то, что происходит за кулисами. Просто так вбухнуть миллионы в непойми кого — это как в рулетку сыграть, а дать деньги компании твоего хорошего знакомого — это уже совершенно другая история.
Ну вы просто знаете C и имеете опыт программирования на нем, но не знаете Rust и не имеете опыта программирования на нем. Конечно, в таком случае для вас С предпочтительней. А вот для меня — наоборот ) Я программировал и на том, и на другом, и Раст для меня предпочтительнее, особенно если нужно что-то "быстрое и на коленке", как ни странно.
Эмм… Я вот программирую на Расте каждый день и уже устаю ждать некоторых фич, которые очень хочется иметь в языке и которые все пилятся и пилятся. Где вы увидели усложнение языка? Кроме async/await в последнее время вообще небыло никаких принципиальных нововведений.
Еще как пытается. Я вообще убежден, что Rust займет место Java в перспективе. Потому что в нем достигается лучшее соотношение безопасность/производительность. Да и развитая система типов с бесплатными абстракциями многого стоит в крупных проектах с большими командами разработчиков.
Как сторонники свободного неконтролируемого рынка, типа либертарианцев, называют капитализмом нечто другое, не то, что мы имеем теперь (ибо у нас имеются монополии), точно также и сторонники социализма говорят о другом социализме, не о том, который был в СССР.
И это нормально, просто спор идет о будущем строе, а не о выборе лучшего из прошлых. Самое интересное тут разворачивается в дискуссиях об обосновании того или иного строя и о движущих силах к его воплощению.
Ну а от возможного гадостного результата не застрахован никто.
Советский социализм существовал в услових жесткой блокады извне и вынужден был использовать сильные протекционистские методы. Сегодня, в период кризиса мировой кап. системы, мы получим протекционизм еще похлеще, чем тот, что был в СССР, но уже в капиталистических странах.
Опять же, зависит от того, о каком именно социализме речь. В западных странах вполне себе развивались социалистические элементы после второй мировой войны, пока не был принят курс на неолиберальные реформы. До сих пор и у нас в стране, и во многих европейских странах сохраняются элементы социализма.
А кто должен выступать гарантом этой честности? Кто сильнее, у кого больше ресурсов — тот и устанавливает правила. Рынок, сам по себе, никак не ограничивает методы конкурентной борьбы.
Когда сообщения об ошибках разрывают поток кода — совершенно невозможно ничего понять (тому кто видит этот код впервые). Так что да, в таком оформлении — нагрузка высока. Но лично я так не программирую на Rust.
Так ведь спор пока и идет насчет ширины этого отверстия.
Фигасе вы загнули ) Вряд ли возможна система типов "как в Idris", совместимая с ООП.
Ну, ваш взгляд имеет право на существование. Но я подозреваю, что вы либо мало работали с Rust и он вам просто непривычен, либо какой-то неправильный энтерпрайз у вас был на Java ) Без ада с NPE.
Есть гипотеза, что концепция владения способствует созданию лучшей архитектуры. Во всяком случае я уже себе плохо представляю, как бы я мог писать производительный код не задумываясь о владении. И да, я считаю что контроль за потребляемыми ресурсами — это важная часть прикладной разработки сегодня.
В итоге там возникла бы другая проблема — гонка данных. Так что эта простота оказывает медвежью услугу: она создает видимость, что можно вот так просто взять и расшарить объект между потоками, не задумываясь о владении. Поэтому в той же Java многопоточное программирование — это совсем отдельное минное поле, требующее специальной подготовки джависта. А в Rust это вписывается очень органично — разок напрягся в самом начале, и дальше просто переиспользуешь уже имеющийся опыт )
Обычно структуры используются не сильно большие, чтобы их упаковывать, чаще всего они —
Copy-типы. Ну а коллекции — в них упаковка скрыта от пользователя.RefCellже полезен в связке сRc, а когда у вас шаренных объектов и так мало, то еще меньшему числу нужна шаренная мутабельность. )Лучшая типобезопасность — вот причина, почему Kotlin зашел. У Scala тоже был шанс, но она сама в себе запуталась, оказалась слишком сложной.
Ну и что? Почему вы решили, что это вообще составляет проблему? )
Я вот работал с несколькими крупными веб-приложениями, написанными на Rust, и в них
BoxиRefCellпрактически не использовались совсем (!), а там, где все-таки использовались — в единичных местах — никаких проблем и затруднений они не вызывали. Что же касаетсяArcиMutex— так это вообще благо, ибо КОРРЕКТНЫЙ многопоточный код на Rust пишется в разы проще, чем на Java.Я часто слышу, как люди, которые особого опыта-то и не имеют в enterprise, пытаются априори отгородить его от Rust. Зачем вы это делаете? Я использую Rust в проектах enterprise-уровня и доволен. Не доволен пока только слабо развитой экосистемой, но к самому языку претензий нет. Тот уровень выразительности и безопасности для кодирования бизнесс-логики, который обеспечивает система типов Rust, с лихвой окупает небольшие неприятности, связанные с эпизодической ручной работой с умными указателями. И то, часто появление таких проблем — это свидетельство того, что нужно остановиться и подумать над общей архитектурой хранения данных и об ответственности за владение объектами в системе.
Почему же сразу религиозный? Я вроде бы вполне рациональные доводы привел. Может быть вы недостаточно повидали «кровавого enterprise» и не в курсе, чем он болен и каково лекарство )
Доля везения — существенна, но как я понимаю, основное — это связи и то, что происходит за кулисами. Просто так вбухнуть миллионы в непойми кого — это как в рулетку сыграть, а дать деньги компании твоего хорошего знакомого — это уже совершенно другая история.
Скала сильно переусложнена ИМХО, Раст там и рядом не стоял в аспекте "когнитивной нагрузки", которую зачастую требует скалистый код.
Ну вы просто знаете C и имеете опыт программирования на нем, но не знаете Rust и не имеете опыта программирования на нем. Конечно, в таком случае для вас С предпочтительней. А вот для меня — наоборот ) Я программировал и на том, и на другом, и Раст для меня предпочтительнее, особенно если нужно что-то "быстрое и на коленке", как ни странно.
Эмм… Я вот программирую на Расте каждый день и уже устаю ждать некоторых фич, которые очень хочется иметь в языке и которые все пилятся и пилятся. Где вы увидели усложнение языка? Кроме async/await в последнее время вообще небыло никаких принципиальных нововведений.
Еще как пытается. Я вообще убежден, что Rust займет место Java в перспективе. Потому что в нем достигается лучшее соотношение безопасность/производительность. Да и развитая система типов с бесплатными абстракциями многого стоит в крупных проектах с большими командами разработчиков.
Ох, не хочется произносить нецензурных слов, но система комментариев и уведомлений на Хабре — та ещё :)
Скажите, а вы вообще следите за тем, что происходит в индустрии вокруг криптовалют? То есть какой ваш уровень информированности?
Это очень интересный момент.
Как сторонники свободного неконтролируемого рынка, типа либертарианцев, называют капитализмом нечто другое, не то, что мы имеем теперь (ибо у нас имеются монополии), точно также и сторонники социализма говорят о другом социализме, не о том, который был в СССР.
И это нормально, просто спор идет о будущем строе, а не о выборе лучшего из прошлых. Самое интересное тут разворачивается в дискуссиях об обосновании того или иного строя и о движущих силах к его воплощению.
Ну а от возможного гадостного результата не застрахован никто.
Советский социализм существовал в услових жесткой блокады извне и вынужден был использовать сильные протекционистские методы. Сегодня, в период кризиса мировой кап. системы, мы получим протекционизм еще похлеще, чем тот, что был в СССР, но уже в капиталистических странах.
Опять же, зависит от того, о каком именно социализме речь. В западных странах вполне себе развивались социалистические элементы после второй мировой войны, пока не был принят курс на неолиберальные реформы. До сих пор и у нас в стране, и во многих европейских странах сохраняются элементы социализма.
А кто должен выступать гарантом этой честности? Кто сильнее, у кого больше ресурсов — тот и устанавливает правила. Рынок, сам по себе, никак не ограничивает методы конкурентной борьбы.
Этот вопрос адресован Clasen01
А можно было написать просто: