Очень мелко, а оператору может быть и 60 лет и некогда приглядываться. Кроме того что панелька отображения может быть промышленной и размером 7-10"
Панель аварий нужна только при авариях, потому лучше отдельным экраном. На основной схеме достаточно подсветки аварийного агрегата и 1-2 строки сообщений
Безопасность в написании программ от непреднамеренных ошибок программирования. Прежде всего при работе с указателями, а также неинициализированные данные, выход за границы массивов итп .
Я такого не помню, да и как то противоречит моей памяти (а был еще и D 1.0). Вроде как позиционировался всегда как более удобный, чем С++, системный язык общего назначения. В принципе, авторы где то книгу истории языка писали, можно поискать. Вот
Как замена С (тут параллели с Zig), режим BetterC появился относительно недавно, в 2017. Когда уже никто его в таком виде не рассматривал.
В любом случае, Zig проще и легче для изучения новичками без C++ бекграунда, как автор этой статьи например.
Проблему со сборщиком мусора, т.е возможность писать без GC в D решили. Но очень уж поздно и до сих пор режим BetterC на роли падчерицы с минимумом внимания.
Также как и с IDE и еще с многими вещами, которые хотело сообщество.
В итоге сообщество прошло мимо, да и корпорации тоже (но те просто тянут на себя - NIH).
Нет, вместо этого они предпочли писать и отлаживать весь системный код на C/C++ примитивными дедовскими методами, а теперь убедили себя, что нет ничего лучше, как переписать его на Rust.
Откуда вообще следует, что они весь системный код решили переписать на расте? Не надо тут схоластики =)
Пока что тут не особо масштабные и официально афишируемые эксперименты (в линухе кстати, та же стадия)
Вообще то есть среда даже бесплатная от RemObjects для Свифта. Но производительность результата так себе и с фреймворками проблема.
Зато ставится без проблем.
Нагнетают, чтобы бабок срубить.
Там везде изолированные сети.
А поддержка полный атас. Отвечают через день "что? пришлите лог*. Могу сделать сккрин
Очень мелко, а оператору может быть и 60 лет и некогда приглядываться. Кроме того что панелька отображения может быть промышленной и размером 7-10"
Панель аварий нужна только при авариях, потому лучше отдельным экраном. На основной схеме достаточно подсветки аварийного агрегата и 1-2 строки сообщений
Вот не надо. Не так там было все плохо.
RE4 до сих пор вспоминаю с удовольствием, целиться было надо прилично
Посмотрел, вижу в последних версиях Эмба занялась этим направлением, и RAII и итераторами и инициализаторами структур. Лучше поздно, чем никогда.
Безопасность в написании программ от непреднамеренных ошибок программирования. Прежде всего при работе с указателями, а также неинициализированные данные, выход за границы массивов итп .
Подробнее писал в статьях
Если поискать на Хабре, тут даже разработчик компилятора пишет статьи.
Gnu Pascal соответствует и существует.
Возможно, и FreePascal в ISO режиме.
кросскомпиляция и кросс-ИДЕ разные вещи
Вообще то нет.
На сегодняшний день безопасность языка Дельфи осталась на уровне С++93.
Весьма дисгармонирует с понижением средней квалификации корпоратив-кодера.
Проблема в дефолтном ВПФ гриде очевидно.
Переписывайте, штош
У меня, кстати, он из 32-бит процесса вылетал по памяти. Пляски с бубном вокруг виртуализации с этим помогли, но с торможением - нет. Надо его менять.
Я такого не помню, да и как то противоречит моей памяти (а был еще и D 1.0). Вроде как позиционировался всегда как более удобный, чем С++, системный язык общего назначения. В принципе, авторы где то книгу истории языка писали, можно поискать. Вот
Как замена С (тут параллели с Zig), режим BetterC появился относительно недавно, в 2017. Когда уже никто его в таком виде не рассматривал.
В любом случае, Zig проще и легче для изучения новичками без C++ бекграунда, как автор этой статьи например.
Проблему со сборщиком мусора, т.е возможность писать без GC в D решили. Но очень уж поздно и до сих пор режим BetterC на роли падчерицы с минимумом внимания.
Также как и с IDE и еще с многими вещами, которые хотело сообщество.
В итоге сообщество прошло мимо, да и корпорации тоже (но те просто тянут на себя - NIH).
Лаги из-за GC прекрасно заметны во всяких играх, особенно на мобилках на Юнити
Да тормозит в сравнении, как ни печально. И WPF и драйверы к СУБД тоже (ODAC например).
Цена прогресса, чтобы археотех вытеснять.
Чтобы не жаловаться на криворуких, можно банально сравнить работу VS6.0 или Delphi c современной VS >2015
А это никуда не денется.
Чтобы не городить вавилонское столпотворение языков в одной программе/системе. в критичных участках можно и подужаться.
Зачем, например, в ядре лямбды?
malloc и сырые указатели никто не отменял, где не хватает статики и стека.
Сложнее, чем реализовывать нетривиальные структуры данных на расте? Не думаю.
Я про то, что это утверждение в общем случае ложно (D как контрпример), и в С#15 вполне может быть stackalloc для объектов.
Тише, тише, про D не забывай. Он и в @ nogc даст фору почти всем.
Так что все возможно и для языков с GC в базе
Откуда вообще следует, что они весь системный код решили переписать на расте? Не надо тут схоластики =)
Пока что тут не особо масштабные и официально афишируемые эксперименты (в линухе кстати, та же стадия)