KP>Мы недавно на практике узнали как же это выглядит – нет проблем с Mono. Некие умники догадались написать сервис на C# (.NET 3.5) Все шло хорошо до тех пор, пока клиенты не захотели этот же сервис, но на Linux, что логично, так как сервера на Windows прошлый век. И тут выяснилось, что пока его изрядно не переписали ничего не работало, так как далеко не все что есть даже в столь дремучем .NET реализовано в последнем Mono. А если реализовано, то работает так же как и в .NET.
А что вы хотите? Это же опенсурс. Программисты пишут для себя, если повезёт, то и другие смогут пользоваться после доработки напильником. Закиньте несколько PR на моно, и у вас всё получится.
Кстати, в линуксе вэйланд допили? Или до сих пор заплатки на экс-окна лепят?
Здравствуйте, red75, Вы писали:
R>А что вы хотите? Это же опенсурс. Программисты пишут для себя, если повезёт, то и другие смогут пользоваться после доработки напильником. Закиньте несколько PR на моно, и у вас всё получится.
Лично я ничего не хочу. Просто объясняю что стереотип "если написали на .NET, то возьмите Mono и будет работать везде" – это не более чем дремучее заблуждение.
R>Кстати, в линуксе вэйланд допили? Или до сих пор заплатки на экс-окна лепят?
Не знаю, если честно. Я в качестве основной системы обычно OS X использую и проблемы Linux за пределами командной строки меня мало волнуют
Здравствуйте, DarkEld3r, Вы писали:
B>>Проблемы той же Java, связанные с исключениями, связаны с тем, что во-первых в языке присутствуют unchecked exceptions, а во-вторых в стандартной библиотеке есть общий базовый класс для checked exceptions, с помощью которого в говнокоде постоянно утекают абстракции через throws Exception. DE>Периодически встречал заявления, что checked exceptions в джаве — это была неудачная идея. Я лично далёк от джава-мира так что интересно насколько эти идеи общепринятые.
Практически общепринятые.
DE>Во многих проектах они используются?
Если речь про библиотеки — используются крайне редко. Я сходу не припомню популярную библиотеку с Checked Exceptions.
DE>Как себя в этом плане стандартная библиотека ведёт?
99% стандартной библиотеки было написано давно, когда эту идею считали хорошей, поэтому там есть Checked Exceptions. Основные, с которыми приходится сталкиваться это IOException, SQLException. В Java 8 ввели класс RuntimeIOException, который наследуется от RuntimeException и "оборачивает" IOException. В Java 8 нет никаких способов использовать Checked Exceptions со стандартными функциями, принимающими лямбды. Хотя могли бы что-нибудь придумать для их поддержки. Но не стали.
В общем мой вердикт — в Java проверяемые исключения неофициально и официально признаны неудачной идеей. Не удивлюсь, если в какой-нибудь следующей Java их просто уберут из языка. Обратную совместимость это не сломает.
Здравствуйте, Васильич, Вы писали:
В>Гарантии безопасной работы с памятью, большей частью на этапе компиляции;
Мдя, я на этих гарантиях сдался походу. Любая попытка сделать более-менее гибкую архитектуру, которая не сваливается в бесконечный рефакторинг при любом изменении, приводит тупо к обмазыванию всего и вся в Rc<RefCell>. А это нифига не этап компиляции так-то.
Здравствуйте, T4r4sB, Вы писали:
В>>Гарантии безопасной работы с памятью, большей частью на этапе компиляции; TB>Мдя, я на этих гарантиях сдался походу. Любая попытка сделать более-менее гибкую архитектуру, которая не сваливается в бесконечный рефакторинг при любом изменении, приводит тупо к обмазыванию всего и вся в Rc<RefCell>. А это нифига не этап компиляции так-то.
Это значит, что выбрана неверная архитектура.
Вот ты на Rust откуда перешёл? Если с C++, то просто представь себе, как бы ты писал на C++ этот же проект, естественно максимально соблюдая правильный современный стиль C++. И далее просто переведи эту архитектуру на Rust. И если в какой-то точке проекта для этого потребуется вставить одну unsafe строчку, то это будет абсолютно нормально. И даже более канонично для Rust, чем плодить ненужные рантайм проверки в стиле управляемых языков.
Самая большая проблема C++, что многие его свойства были обнаружены случайно
и получили дальше какое-то дальнейшее развитие. Язык развивался эволюционным путём
фактически. И в какой-то момент следовало бы откинуть всё и начать с начала.
Перво-наперво C++ это не единый язык, как другие языки. Это по меньшей мере
два языка работающих с разными абстракциями и в разное время. Один из них -- "C с классами",
мало чем отличается от других языков, того же Rust. И даже уступает им. Но вся соль
в другом, в декларативном языке работающем в пространстве типов в момент компиляции.
В том, что ошибочно считают шаблонами. Проблема лишь в том, что этот второй язык возник
случайно, имеет массу ограничений, дефектов и неожиданных свойств.
Здравствуйте, Васильич, Вы писали:
В>Это очень показательный пример, когда человек, привыкший к необдуманному кодингу, сталкивается с растом. Тут важно запомнить одно: сильнейшая сторона Rust'а в его строгости,
Нет, здесь Rust ничем не отличается от голого C и подобных языков.
C++ в отличии от может знать правила преобразования типов и применять их автомагически.
Либо требовать так же вписывать reinterpret_cast с неизвестным результатом.
Здравствуйте, ELazin, Вы писали:
В>>У Rust'а: В>>Продвинутая система модулей; EL>В С++ тоже скоро будет.
Не нужна. Что она даёт? Кроме того, что хедеры теперь будут идти в блобах. Время компиляции?
Это не та проблема. Будет как в C#, когда у них тоже "модули", но рядышком лежать те же
недохедеры (в студии по F11, вроде, вызываются). Хуже того, масса кода требует перекомпиляции
каждый раз и может параметром воспринимать значения макросов, наличие и свойста типов в неймспейсах
и т.п. Модули имеют узкое применение, интерфейс к сторонней библиотеке, например.
В>>C++ имеет похожие возможности в некоторых областях, но при этом не дает никаких гарантий. EL>Что значит "не дает гарантий"? Какие гарантии дает язык? У С++ есть стандарт, поэтому я могу точно сказать как должен вести себя тот или иной фрагмент кода. Стандарт определяет некоторые вещи как UB (undefined behaviour)
А в следующей версии Rust всё будет шиворот-навыворот, вот тебе и "гарантии".
Как начинать какой-то проект с Rust, если он не будет собираться завтрашним компилятором, а сегодняшний
окажется устаревшим и неподдерживаемым.
Здравствуйте, AlexRK, Вы писали:
ARK>>>В требовательном к надежности коде исключения неприемлемы. B>>Очень спорное утверждение, видимо, связанное с непониманием того, как исключения могут работать "в требовательном к надежности коде".
ARK>Это утверждение, которое вполне подтверждается практикой. Все распространенные операционные написаны на С. Софт для марсохода написан на С.
Дада, у них там вместо исключтений -- longjmp. Дальше можно не продолжать...
Здравствуйте, fk0, Вы писали:
fk0> Одно и сомнительное -- borrow checker. Сомнительное, потому, что идея fk0>хоть интересная, но сырая.
А ещё более-менее вменяемый дизайн без косорылых несимметричностей, а ещё более простой способ скачивать модули, а ещё возможность любой тип распечатать без ручного перечисления полей, а ещё комплиятор выдаёт куда более вменяемые ошибки, чем кусок кала под названием Govno Compiler Collection
Все шло хорошо до тех пор, пока клиенты не захотели этот же сервис, но на Linux, что логично, так как сервера на Windows прошлый век. И тут выяснилось, что пока его изрядно не переписали ничего не работало, так как далеко не все что есть даже в столь дремучем .NET реализовано в последнем Mono. А если реализовано, то работает так же как и в .NET.
