Опубликован релиз языка программирования общего назначения Rust 1.80, основанного проектом Mozilla, но ныне развиваемого под покровительством независимой некоммерческой организации Rust Foundation. Язык сфокусирован на безопасной работе с памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime (runtime сводится к базовой инициализации и сопровождению стандартной библиотеки)...Подробнее: https://www.opennet.me/opennews/art.shtml?num=61614
Изучаю его, по моему отличная штука. Сейчас хэловорд проект на нем катаю. Долго возился с обработкой ошибок что бы сделать ее удобной в проекте так как есть море их видов, а на выходе вебсервера вебсерверу надо одну. Так же долго возился с тем что бы в порождающих функциях делать всякое ссылками вместо возврата упаковки, но плюнул, шибко неудобно возвращаю умные указатели и прочее подобное. Сошелся на том, что порождая возвращать упаковку, а используя отдавать ссылку. В целом штука годная, либы нужные уже есть, можно пилить себе всякое. Время ответа вебсервера на простенькое 1мс, памяти ест немного.
Напомни а зачем в твоём хеллоуворлде безопасная работа с памятью? Кто и зачем будем за границы буфера выходить и что он с этим будет делать?
Предлагаешь написать хэловорд на расте без безопасного управления памятью?
Да, предлагаю!
> Да, предлагаю!Поддерживаю! Отличный язык!
А те кто против от обид за собственную бездарность - уже не знают что сказать, уже сколько лет в начале говорили, что clang не взлетит, и обо...сь в своих прогнозах, потом про Rust, и набрасывают уже лишь собственную желчь, без осмысленного содержания...
Проблема лишь в том что ты судишь по себе. И приписываешь другим свои негативные стороны. Это при том что раст не взлетел от слова ваще.
Угу, только его добавили в ядро, разрешив использование в отличии от плюсов.
На нем пишут команды в таких проектах как андроид и хром.
Ну и куча софта который уже работает (амазок, клоудфаря и тд)Совершенно не взлетел! Анон не может ошибаться))
Тут всё просто: корпорасты поняли, что сажать тысячи "входящих в IT" обезьянок без опыта за низкоуровневый язык без боровов нельзя - налажают везде, где смогут. Ну и напилили что-то, чтобы хоть как-то ваяли "войну и мир".
Внезапно люди с годами опыта на C порождают бесконечные CVE, а вроде не обезьянки…
Внезапно хеллоуворлды в плане CVE мало кого интересуют. Равно как и "внутренние проекты" тех самых корпорастов. Вот и не порождаются.
> Внезапно хеллоуворлды в плане CVE мало кого интересуют.Хеллоуворлды - да. А продукты, находящиеся в проде - ещё как. А таких, написанных на морально устаревшем языке программирования, увы, очень много пока что.
>Равно как и "внутренние проекты" тех самых корпорастов.
Линукс там, или Андроид тот же - это "внутренние проекты" самих корпорастов? А есть что-то, что не входит в эту категорию?
> А есть что-то, что не входит в эту категорию?Конечно!
Величайшие поделия какиров из Сообщества! Свободных от корпов и здравого смысла))
Примеров много, но они известны в очень узких кругах.
Причём обычно в этом самом узком кругу никого кроме автора нет и не будет.
И что? Это блин и называется взлетел, если его используют) То что он вам не нравится - это другой вопрос)
Это называется не "взлетел", а "временно заткнул образовавшуюся дыру в заднем проходе". Где-то рядом с рубями и прочими около.
Именно по этой причине - это самый обожаемый язык на том же СтэкОверфлоу. Да? Кстати, не только самый обожаемый, а уже и довольно активно используемый, судя по последнему опросу.
> только его добавили в ядроКак сразу весь кипешь вокруг написания модулей ядра на расте мгновенно затих, давно тут новостей об расте в ядре не было)
> Как сразу весь кипешь вокруг написания модулей ядра на расте мгновенно затихТак кипиш был из-за самого факта добавления, а не из-за того что на нем что-то пишут. Типа луддиты и неосиляторы не смогут понять что же там написано. Но Торвальдс поставил всех на место и язык приняли.
И вроде очевидно, что между тем, как на языке разрешили писать, и тем, как появятся первые большие модули, должно пройти время как раз равное времени написания модуля. Но возможно очевидно не всем :)
Вот Nova, драйвер для GPU NVIDIA уже анонсировали opennet.ru/opennews/art.shtml?num=60821
Но для написание нужно время, не так ли?
> Вот Nova, драйвер для GPU NVIDIAУ Нвидии ж вся работа в клозед сорс firmware делается, то что они пишут - просто прокладка между блобом и GPL кодом ядра, зачем там раст? Чисто номинальный драйвер. Интересно что-то настоящее, ФС например лучше ext4 или btrfs, или шедулер или что-то ещё такое.
Самые интересные ништяки, вроде вулкана, опенгла, куды, как раз в юзерспейсе. В фирмвари низкоуровневое управление железом, вроде управления энергопотреблением. Внезапно, в красных карточках тоже самое, и так же есть блоб с фирмварью.
Что-то я сильно сомневаюсь, что они на расте куду перепишут или компилятор шейдеров.
> А Радеон имеет ту же закрытую firmwareКак тогда на эльбрусах радеон запускают? https://www.altlinux.org/%D0%92%D0%B8�...
Так же, как и на других процессорах - загружают фирмварь в "карточку", где её и исполняет интегрированный в GPU контроллер.
> Да, предлагаю!Так и пиши тогда это сам.
Потому что люди просто устали от сишки. Надоело
Ц тебя богатое воображение.
>Потому что люди просто устали от сишки. НадоелоОднозначно. Хорошо помню такое своё настроение ("надоело!") после очередного многочасового дебага необходимой C++-библиотеки с понасаженными там UB.
Кто то подменяет понятия...
> Долго возился с обработкой ошибок что бы сделать ее удобной в проекте так как есть море их видов, а на выходе вебсервера вебсерверу надо одну.Сведение доменов ошибок — известная проблема еще с Haskell. Впрочем,
https://docs.rs/thiserror/latest/thiserror/ для библиотек, и
https://docs.rs/anyhow/latest/anyhow/ для приложений.
Да, их и заюзал и двойную упаковку, сначала все в anyhow, а потом anyhow в свое с реализацией трейтов, которые надо вебсерверу и на стадии генерации ответа распаковка бутерброда. Таким образом в коде все просто, хоть и не шибко красиво. А своя ошибка на thiserror
>thiserror
>anyhowПочему-то мало известна такая библиотека, как SNAFU. А она лучшая в обработке ошибок. Имел долгий опыт и с anyhow, и с thiserror; они хороши и полезны, но SNAFU — ещё лучше (один только метод context трейта ResultExt экономит массу усилий). Правда, достоинства не сразу очевидны и, пожалуй, в полной мере проявляются на реально больших и сложных проектах.
SNAFU известна – она появилась первая и является основоположником обёрток для ошибок в расте.thiserror и anyhow появились спустя несколько месяцев, как работа над ошибками в дизайне SNAFU.
>работа над ошибками в дизайне SNAFUТы что-то путаешь. Anyhow вообще костыльная штука для быстрого прототипирования, и почти ничего общего у него ни с thiserror, ни с snafu нет.
У thiserror и anyhow один автор и работы над этими библиотеки начаты одновременно.
Автор изначально разделил области применения этих либ. Как видно из статистики скачивания: по 10М у thiserror и anyhow vs 1.5М у SNAFU, людям понравилось разделение на разные области применения и эти крейты стали популярнее.
Возможно, моё сообщение можно прочитать как "сделали SNAFU, поняли что получилось фигня, решили переделать". Нет, я думаю как раз наоборот: "один человек написал SNAFU, другой увидел, что получилось клёво и решил развить идею в другом стиле".
> Anyhow костыльная штука для прототипирования
> ничего общего у него ни с thiserror, ни с snafu нетТо что она для прототипирования, не делает её костыльной.
И непонятно, почему либа для сокрытия внутренней кухни работы с ошибками, должна иметь что-то общее с библиотеками для детальной проработки последних.
>Anyhow вообще костыльная штука для быстрого прототипирования, и почти ничего общего у него ни с thiserror, ни с snafu нет.Anyhow просто для приложений, а не для библиотек, и вполне приближает легкость обработки ошибок к языкам с исключениями.
Есть еще улучшенный вариант anyhow - eyre, и если использовать еще и color-eyre то получаются вполне читабельные отчеты намного лучше чем портянки стектрейсов в языках с исключениями.
Спасибо, погляжу.
Ты кажется на лоре ещё эту пакость рекламировал. Нет, на неё не стоит даже смотреть.
>долго возился с тем что бы в порождающих функциях делать всякое ссылками вместо возврата упаковки, но плюнул, шибко неудобноОчень неудобно что надо указывать время жизни ссылок
> либы нужные уже естьРискну предположить, что раст тебе не нужен.
Да вот тоже хотел запилить проект HelloWorldNG. Ну, значит, начал с создания базового класса... Упс, а нету такого ключевого слова. Обломалсо.
Классы -- бредовая идея, если так подумать. С самого начала существования различных ЯП - данные отделяли от логики. К этому мы возвращаемся вновь в современных языках типа раста. Ну а классы породили такую бессмысленную дисциплину, как "паттерны ООП", причем значительная их часть посвящена решению проблем, возникших при добавлении в ЯП такой бредовой идеи, как классы.
Да-да-да, мметь рядом с данными семантику их использования выраженую через набор методов это очень бредовая идея. А вот передавать и валидировать сырые данные в наборе несвязанных лапшеобразных функций это очень прогрессивно.А паттерны ООП нужны для очень больших проектов, где всю кодовую базу знать тяжело. За каждым велосипедом не уследишь, а вот за унифицированными архитектурными решениями вполне.
>Да-да-да, мметь рядом с данными семантику их использования выраженую через набор методов это очень бредовая идеяЭто как-раз в расте более чем доступно, из ООП там только наследования реализации нет.
В расте нет наследования данных. Реализация как раз наследуется
>В расте нет наследования данных. Реализация как раз наследуетсяКорректнее будет что наследования вообще нет, реализация тоже "наследуется" только из функций трейтов которые данные не могут использовать. Но с данными как раз попроще, агрегация + Deref который тривиально реализуется.
> Корректнее будет что наследования вообще нетНекорректно говорит что "наследования вообще нет", если оно есть.
Если кто-то под "наследованием" понимает только "наследование в стиле ООП", то это его проблемы.
> агрегация + Deref который тривиально реализуется.Не надо изобретать "rust с классами", это тупиковый путь. И антипаттерн.
>Некорректно говорит что "наследования вообще нет", если оно есть.Не хочется терминологический спор начинать, но все-таки наследования нет, трейты же даже не интерфейсы, только в некоторых аспектах похожи на них, они же это цельнотянутые из хаскеля классы типов.
>Не надо изобретать "rust с классами", это тупиковый путь. И антипаттерн.
"rust с классами" наверно только на макросах реально сделать, но "rust с объектами" в смысле близком как например используются классы в стандартной библиотеке C++ (без наследования и обобщенные) вполне норма для rust.
> Не надо изобретать "rust с классами", это тупиковый путь. И антипаттерн.Вполне себе правильный путь и полезный паттерн.
Удачи в работе над хэловордом, желаю довести дело до конца!
99% функционала раста с легкостью достигается на плюсах через:
-mshstk
-fsanitize=safe-stack
Пользуйтесь.
Так дьявол в оставшемся 1%. И без той 99%-ой сковородки та 1%-я чалма не работает. Это не говоря уже об «удовольствии» программирования на C++. Даже за деньги трижды подумал бы связываться.
1% - это недостижимая часть cfg.
Я бы согласился про "довольствие" от с++, если бы не было сравнения с растом
Сравнение с Растом существует только в твоей голове.
Расскажи это Гуглу, а то пацаны не догадались.
> 99% функционала раста с легкостью достигается на плюсах через...Чел, это флажки рантаймовых проверок. Они никакого функционала из Раста не достигают.
Я дико извиняюсь, но как с помошью
> -mshstk
> -fsanitize=safe-stackможно достичь move-семантики, match-выражений, монадов, асинхронного программирования, отсутствия заскарузлого синтаксиса вроде "void*(*name)(void*)", отсутствия 65535 нестандартных расширений, адекватных макросов, единой системы документации, качественной документации стандартной библиотеки, единой системы сборки, единого репозитория пакетов с утановкой в одну команду без dependency hell, отсутсвия UB на каждом шаге (Вы же в курсе что бесконечный цикл может вызвать UB? Как и (int8_t)(INT8_MIN / -1).), стандартизированного поведения оператора >> для беззнаковых, стандартизированного представления целых чисел, осмысленных сообщений об ошибках от компиляторя, отсутсвия парсинга литералов в рантайме и так далее?
> стандартизированного поведения оператора >> для беззнаковыхМне кажется, или ты сначала написал про UB, а потом отредактировал коммент? Там именно UB[1].
Чего-то можно достичь заменой сей на плюсы, что-то из недостатков позволяет поддерживать больше платформ, где-то "безопасности по умолчанию" на самом деле не хватает, где-то UB - продукт эволюции от "продвинутого макроассемблера[2]" до "языка с умными[3] оптимизациями".
[1] https://godbolt.org/z/1xEbe95fa
[2] это как когда сишку хвалят за отсутствие неявного поведения, когда-то это было правдой
[3] ну, по мнению комитета - умными, а на деле ядро с нестандартным -fno-strict-aliasing собрано
(компилятор в одном месте предупреждает, но это легко исправить: https://godbolt.org/z/4cevjaofz)
> Мне кажется, или ты сначала написал про UB, а потом отредактировал коммент? Там именно UB[1].Опечатался, вместо "знаковых" написал "беззнаковых". Я имел ввиду значение вдвигаемого слева бита, которое может быть как 0, так и 1 в зависимости от имплементации.
> то из недостатков позволяет поддерживать больше платформ,
По-моему чья-то необходимость прогрммировать 3.5 DSP и 2.5 вымерших архитектуры процессора не оправдывает введения поведения, специфичного для этих эзотерических платформ, в язык общего назначения.
> ОпечаталсяНо всё равно оказался прав.
"If the value of the right operand [оператора сдвига влево или вправо] is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined" - https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf#p...
То что сдвиг на число бит, превышающее размер операнда это UB и так понятно. Я имею ввиду именно поведение, зависяшее от имплементации, а не UB, даже если E2 находится в допустимых пределах.
5.6.7.5
The result of E1 >> E2 is E1 right-shifted E2 bit positions. [...] If E1 has a signed type and a negative value, the
resulting value is implementation-defined
> То что сдвиг на число бит, превышающее размер операнда это UB и так понятноНет, если его честно выполнять, то результатом будет ноль. Надо понять, что в процессорах это могут оптимизировать так, что `uint64_t(x) >> y` выполняется как `uint64_t(x) >> (y & 0b11'1111)`, тупо по маске. В альтернативной реальности все процессоры могли бы делать ещё `if (y & ~0b11'1111) return 0;` и UB бы не было. Не так уж очевидно.
> Я дико извиняюсь, но как с помошью [...] можно достичьОчень просто! Нужно быть не в зуб ногой ни в плюсах, ни в Расте - и тогда "все достигается с легкостью" и все эти ваши расты нинужны.
move семантика есть, асинхронное программирование есть, с синтаксисом раст ничуть не лучше. А говорить про нестандартные расширения, когда в расте стандарта нет вообще, ты это серьёзно? Да и многие ими не пользуются. В расте нет нормальных шаблонов и вот вообще всё реализуется через костыли в виде макросов. Документация стандартной библиотеки и остального: cppreference. Единая система сборки? Так cmake можно сказать что монополизировал всё. А за счёт того что в языке есть UB, компилятор может лучше оптимизировать код, или это сделано для поддержки платформ. Чтобы не парсить литералы в рантайме, можно просто использовать constexpr. И закинуть строку в шаблон. А вот костыли в виде паттерн матчина из раста, или его енамов с генериками и даром не нужны.
> когда в расте стандарта нет вообщеТак и в плюсах нет стандарта. А то им называют - набор рекомендаций для компиляторописателей. Как они заимплементят тот или иной пункт - терра инкогнита. И ладно бы реализация была один раз и навсегда, так нет, может и с версией поменятся.
Это всё что угодно, но не стандарт.
Ложь. Стандарт C++ это как раз проверка на корректность компилятора. Кстати именно поэтому он допускает UB, смысл которого большинство не понимает. Компилятор ОБЯЗАН делать то, что ему приказывает делать стандарт, но сам стандарт не требует ничего сверхъестественного, а UB позволяет производить оптимизации быстродействия вместо того чтобы обеспечить все варианты "эзотерического" использования функциональности. Если вы не знаете как что-то работает: открываете стандарт и смотрите то, что все компиляторы обязаны поддерживать. Необязательная поддержка указывается отдельно, но "необязательная" здесь НЕ означает то, что можно делать что хочешь, а значит лишь то, что её может не быть в реализации вовсе, а если есть, то будьте добры и следуйте стандарту.
1. Большинство компиляторов С/++ не поддерживает стандарты полностью, что автоматически переводит понятие "стандарт" в "рекомендации".2. UB – это неопределенное поведение, а не неопределенная реализация. Ничего "эзотерического", например, в переполнении целых чисел нет, однако UB там есть. Что, опять же, говорит о "рекомендациях".
3. Открыв стандарт, ты не сможешь на 100 процентов быть уверен, что твой компилятор будет работать ожидаемо. Но и после того как ты убедишься, что верно понял релиз нотсы компилятора по конкретной UB и правильно их заимлемнтил, ты не получаешь никаких гарантий, что поведение сохранился в следующих версиях. Стандарт? Ну-ну.
> А говорить про нестандартные расширения, когда в расте стандарта нет вообще, ты это серьёзно?"Стандарт СИ" это почти как Гост на колбасу вида "колбаса делается из мяса, может содержать добавки в виде сала, туал.бумаги или овна, в зависимости от желания компилятора рецепта - повара"
Не думаю что оно тебя бы сильно порадовало)
Плюсы тоже не далеко ушли.
И там, и там куча мест в стиле "ну мы сами ХЗ как оно должно работать, поэтому любись оно понём 🐴 пусть писаки компиляторов сделают абыкак".
Я уже молчу про то, что из распространенных компиляторов ни один(!!!) не удовлетворяет стандарту полностью en.cppreference.com/w/c/compiler_support> В расте нет нормальных шаблонов и вот вообще всё реализуется через костыли в виде макросов.
Хахаха, а типа эти шаблоны не лютый калище?
> Документация стандартной библиотеки и остального: cppreference.
А какая разница что она есть, если содержимое этой доки овно?
> А за счёт того что в языке есть UB, компилятор может лучше оптимизировать код,
А за счёт того что в языке есть UB можно добавить CVE и бекдоры что дает двойной профит "без работы по исправлению и разргебанию не останешься И можно намутить халтурку ЕВПОЧЯ ;)"
> или это сделано для поддержки платформ.
Которые уже умерли и разложились еще в прошлом тысячелетии, но требования для этих копролитов все еще в "так называемом стандарте".
> А вот костыли в виде паттерн матчина из раста, или его енамов с генериками и даром не нужны.
Конечно лучше пусть все ENUMы будут интами! Это же так удобно по ошибке сравнивать ENUM_1 и ENUM_2.
И главное никто не прикопается что "тут бекдор!", просто покачают головой "опять ненастоящий пограммист обделался в ядре"
> move семантика естьЭто недоразумение, а не move семантика. Когда std::move, внезапно, не делает никакого move, немутабельный объект который можно move'нуть вообще невозможен, return std::move() ломает оптимизации, с moved-from объектом можно делать что угодно..
> асинхронное программирование есть
Какое-какое в плюсах асинхронное программирование? Там корутины даже толком не завезли. Руками сишный libuv дёргать это не асинхронное программирование если что, это онанизм.
> с синтаксисом раст ничуть не лучше
Лучше.
Вы удивитесь, но Rust на самом деле тоже не делает никакого move "за кадром". Вся концепция владения - это фронтенд для разработчика, на системном уровне ничего подобного не существует в принципе. Только в Rust ещё приплели уродливую концепцию времени жизни, что C++ делает пусть хитро иногда (основные хитрости связаны с R-value ссылками), но полностью сам.
А в машинах кодах всё превращается в "уродливую" адресную арифметику, без всяких там типов, классов и прочего мусора, который процессору не нужен, а нужен только разработчику. Как и концепция владения.
Так какой смысл тогда придираться к C++, что move на самом деле "ничего не перемещает" (и это действительно так, это простое преобразование к R-value ссылке), когда в Rust схожая семантическая модель на самом деле тоже "ничего не перемещает".
Это проверки которые нужны разработчику. В расте они работают, в плюсах – нет.
Потому и придираются.
> Это проверки которые нужны разработчику. В расте они работают, в плюсах –
> нет.Какие проверки? move-семантика как раз и создана для того чтобы управление ресурсами вело себя таким же образом как и обычное выделение автоматической памяти. Вы общаетесь лозунгами, а не предметом дискуссии.
Более того, если уж речь зашла о проверках: в C++ можно так настроить компилятор и статические анализаторы чтобы он пресекали попытки писать с UB или проверять на соответствие кода стандарту, а также зачем вообще НУЖЕН UB, притом, что избавиться от UB на самом деле легко, в Pascal UB почти нет и он гораздо проще и логичнее, чем Rust.
Кстати к одному из ваших предыдущих ответов: вы также грубо солгали, когда заявили, мол "компиляторы не реализуют стандарт". Если в компиляторе заявлено какой стандарт он реализует, значит он его РЕАЛИЗУЕТ. Это только так и работает. Вы не понимаете дизайн C++ (да и дизайн Rust на самом деле тоже), а общение с "отделом маркетинга" - это неуважение к себе.
Да, но в Rust безопасная работа с памятью обеспечивается изначально.
И у вас нет выбора кроме как использовать конкретно эту модель памяти. В C++ у вас есть выбор между C-подобной моделью, "классики" в виде new, delete, умные указатели и move-семантика (современный подход), дальше появится транзакционная память (частично уже поддерживается кое где), в результате C++ легко подружить с любым проектом на C, что часто бывает необходимо. В Rust же либо переписывают, либо делают обёртки для сишных либ, а политика "владения" и move-семантика в C++ появилась раньше, чем вообще появился Rust (это всё C++11), хотя смарт-указатели появились и того раньше.
Если бы только ими пользовались...
Поскорее бы уже допилили артификальный интеллект, чтобы люди тратили больше времени на создание полезных программ, а не на придумывание очередного, бог знает какого по счёту языка программирования.
Мне всегда казалось, что компилятор должен помогать программисту делать хорошие программы. То есть программист - главный, а компилятор - его помощник. Однако когда программируешь на Rust е, то складывается ощущение, что всё наоборот: компилятор - хозяин, а программист - его раб. Компилятор диктует что ты должен делать и как ты должен это делать. В Ruste нельзя стукнуть кулаком по столу и приказать "Делай как я тебе говорю и баста!". А в C++ - можно. Rust - это как строптивая и несговорчивая жена. С кем вам лучше жить , со строптивой или покорной - решать вам самим.
Компилятор и помогает погромисту. Компилятор же будет переводить в машинный код все, что там набил своими культяпками погромист.
Набил всё, что ему науказывал компилятор Rust.
В бородатые восьмидесятые доступ к железу был сродни аудиенции у генсека – по талонам и с предварительной записью. Код писался от руки на чем попало, хоть на туалетной бумаге (если повезёт достать). А уж потом, дрожащими от нетерпения руками, эти каракули вводились в ЭВМ. Так что компетенции нынешних гуманитариев, вошедших в айтишечку, сильно недотягивают до того, чтобы они диктовали компилятору свои условия.
>на туалетной бумаге (если повезёт достать)Не всё так плохо, была ж газета Правда.
> компилятор должен помогать программисту делать хорошие программы.Ненадежная программа не может быть хорошей. А чтобы было хорошо, нужно делать хорошо.
Компилятор мешает программисту сделать плохо.> В Ruste нельзя стукнуть кулаком по столу и приказать "Делай как я тебе говорю и баста!".
Можно. Пишешь unsafe и делаешь что хочешь.
С женой такое не проканает))
> Ненадежная программа не может быть хорошей. А чтобы было хорошо, нужно делать хорошо.
> Компилятор мешает программисту сделать плохо.Так ты бери и делай сразу хорошо! А кто не может хорошо - тот плохой программист!
Как показывает многолетний опыт разработки сравнительно сложных программ - никто не может. ¯\_(ツ)_/¯
Давно пора сделать аналог GC, только в compile time. 100% что можно просчитать когда можно уже делать free(), fclose(), glDeleteTextures() и всё такое. К сожалению, современная айтишечка - колосс на глинянных ногах, никто не хочет развивать базу, ЯП развиваются очень медленно. Так что имеем 3 неудобных стула в виде runtime GC, ручного управления и смартпойнтеров / боров чекеров.
> Давно пора
> 100% что можно просчитать когда можно уже делать free(), fclose(), glDeleteTextures() и всё такое.
> Так что имеем 3 неудобных стула в виде [...] смартпойнтеров [...]Его и сделали давно. RAII называется (смартпоинтеры его частный случай). Что конкретно тебе неудобно?
> RAIIУбогое. 90% плюются с плюсов и раста с их raii и боров чекерами, остальные делают вид что им ок (но работают медленнее и зп меньше получают, т.к меньше фич за то же время в прод катят). Инди девелоперам и стартаперам некогда боровов ублажать и юник птр везде тулить и мувить - да и выглядят эти портянки лишних закорючек стремно. Надо чтобы как мейнстрим языках вообще не делать никаких лишних телодвижений, и даже лучше - чтобы не только память автоматически освобождалась, но и все остальные ресурсы. Так как с последним там или ничего или нелепые костыли try-with-resources.
> и даже лучше - чтобы не только память автоматически освобождалась, но и все остальные ресурсы. Так как с последним там или ничего или нелепые костыли try-with-resources.Чел, ты бы вникнул, что такое RAII и не нисал глупости. Оно буквально об освобождении всех ресурсов автоматически без лишних телодвижений и try-with блоков - как раз то, о чем ты писал.
> Чел, ты бы вникнул, что такое RAIIТипикал С++ фан. Про raii я очевидно знаю, раз пишу. Я работал в разных командах, и с С++ в т.ч. - они самые зазнавшиеся и при этом самые медленные. Шире надо мыслить, а не цепляться за устаревшие на коленке слабанные примитивные технологии.
> Про raii я очевидно знаю, раз пишу.Очевидно, не знаешь. Ибо пишешь про него чушь, да и вообще только что удивлялся, почему никто до сих пор не сделал "аналог GC, только в compile time".
> Я работал в разных командах, и с С++ в т.ч
Ты бы лучше не пыль в глаза пускал, а таки описал как, по-твоему, должен выглядеть автоматический fclose(), и чтобы при этом без RAII.
> Очевидно, не знаешьМне деньги за то что знаю и применяю платили.
> таки описал как
Человек умеет решать эту задачу не особо задумываясь, значит и в алгоритм можно перенести. Компилятор должен знать о том, какие функции выделяют ресурсы и какие освобождают, находить функции выделения ресурсов и рассчитывать во время компиляции условия для их освобождения.
> Компилятор должен знать о том, какие функции выделяют ресурсы и какие освобождают, находить функции выделения ресурсов и рассчитывать во время компиляции условия для их освобождения.Ты не поверишь, но это именно то, что делает RAII...
Кроме, конечно, "находить функции выделения". Тут я вообще не понял, что ты имеешь в виду.
Объявить компилятору, какие функции выделяют ресурсы и какие их освобождают, можно например так:
import libc.malloc closable libc.free
import libc.fopen closable libc.fclose
И так далее для любых библиотечных ф-ий, которые что-то выделяют.
> import libc.fopen closable libc.fcloseИ я должен писать такое чудо в каждом файле, где нужна функция? Спасибо, но нет.
И ответь на милость, что должно происходить, когда я буду копировать указатель FILE*? Как, по-твоему, компилятор сам определит, когда пора вызывать fclose()? Вставлять рантаймовый счетчик ссылок?
> Объявить компилятору, какие функции выделяют ресурсы и какие их освобождают, можно например
... например, конструктором и деструктором, как делалось десятилетиями.
> И я должен писать такое чудо в каждом файле, где нужна функция? Спасибо, но нет.Как хочешь, пиши дальше уродливое
struct file_deleter {
void operator()(std::FILE* fp) { std::fclose(fp); }
};using unique_file = std::unique_ptr<std::FILE, file_deleter>;
> Как, по-твоему, компилятор сам определит, когда пора вызывать fclose()?
Строить граф видимости переменных по скоупам, если после текущего места исполнения все переходы ведут туда, где переменная не видна - значит, её пора удалять. Если там есть какие-то ветки условного исполнения, такие что по одной ветке переменная будет видна, а по другой - нет - применить то же условие к вызову fclose().
>> И я должен писать такое чудо в каждом файле, где нужна функция? Спасибо, но нет.
> Как хочешь, пиши дальше уродливоеЯ это "уродливое" напишу только один раз и буду реюзать по всей кодовой базе.
> Строить граф видимости переменных по скоупам, если после текущего места исполнения все переходы ведут туда, где переменная не видна - значит, её пора удалять.
Ты же понимаешь, что это возможно только во время выполнения? А не compile time, как ты хотел.
> в каждом файле, где нужна функция?Почему обязательно в каждом? Если функция из библиотеки, которая уже на этом языке, там может быть
@closeable free
public void* malloc(u64 count)и тогда по месту использования достаточно
import libc.free или import libc.* для ленивых
> Почему обязательно в каждом? Если функция из библиотеки, которая уже на этом языке, там может бытьТы сейчас описал какой-то недодеструктор. Потому что если это "функция из библиотеки, которая уже на этом языке", то там будет объект файла с нормальным интерфейсом и RAII, а не сишные функции кишками наружу.
> Ты сейчас описал какой-то недодеструктор.Нет это не тоже самое.
1. В общем случае ты не можешь пользоваться объектами с raii как будто у тебя GC под капотом.
2. Деструкторы ты пишешь руками, как будто ХХ век на дворе.> Ты же понимаешь, что это возможно только во время выполнения?
Сишник во время написания программы вручную всё освобждает, а не во время выполнения. И компилятор сможет за сишника, если нормальным незашоренным кодерам поручить разработку.
> В общем случае ты не можешь пользоваться объектами с raii как будто у тебя GC под капотом.Что ты имеешь в виду?
> Деструкторы ты пишешь руками, как будто ХХ век на дворе.
А чем писать твой гениальный костыль? Ножками, что ли?
>> Ты же понимаешь, что это возможно только во время выполнения?
> Сишник во время написания программы вручную всё освобждает, а не во время выполнения. И компилятор сможет за сишника, если нормальным незашоренным кодерам поручить разработку.То есть, ты даже сам не можешь объяснить, как с технической стороны будет работать твоя гениальная идея. Извини, но магическое мышление не работает в реальном мире...
> Что ты имеешь в виду?Сравни код на яве и на С++, вроде разница очевидна.
> Ножками, что ли?
Ничем, как до тебя не дойдёт то. Просто не нужно делать то, что машина сама может вычислить.
> То есть, ты даже сам не можешь объяснить
Верхнеуровнево я вроде доходчиво объяснил. Детали реализации в сообщение нет смысла упихивать, тем более для хейтеров.
> Сравни код на яве и на С++, вроде разница очевидна.Чел, это твоя ответственность - объяснить, почему вдруг "не можешь пользоваться объектами с raii как будто у тебя GC под капотом". Вместо этого ты мне предлагаешь сравнивать какой-то (какой?) код нв яве с C++...
> Ничем, как до тебя не дойдёт то.
Ты только что заливал про "@closeable free" и "import libc.malloc closable libc.free". С тобой все хорошо?
> Верхнеуровнево я вроде доходчиво объяснил.
Нет, даже верхнеуровнево твоя идея несовместима с реальностью. А объяснение уровня "сишник смог, значит и компиллятор сможет" я даже не знаю, как комментировать...
> Чел, это твоя ответственностьС чего вдруг? Если вдруг когда-то соберусь свой язык делать, тогда и распишу как что и куда.
>> Чел, это твоя ответственность
> С чего вдруг?С того, что так работает дискуссия между людьми. Но раз ты захотел так бездарно съехать - скатертью дорога.
> Сишник во время написания программы вручную всё освобждает, а не во время выполнения.Ага, или не освобождает. Или освобождает дважды. Тут уж как повезет...
> И компилятор сможет за сишника, если нормальным незашоренным кодерам поручить разработку.
Учитывая, что ни один компилятор в мире сейчас такого не может, то поучается, что их писали и пишут ненормальные зашоренные кодеры.
Но ты не такой, конечно. Жаль только, что в предмете ты не сечешь, и потому твои фантастические идеи рассыпаются еще на этапе рождения...
> Учитывая, что ни один компилятор в мире сейчас такого не можетДа, все языки говно. Компиляторы просто реализовывают это говно.
С++ говно потому что вместо импортов убогие инклуды, раздувающие время компиляции, ручное управление памятью, дурацкие шаблоны, порождающие нечитабельные простыни ошибок, очень многословный, корутины через жопу с каким-то co_return дурацким. Какую-то альтернативу импортам попытались изобразить, но как всегда в с++ через жопу и ни с чем почти не работает.
Java развивается крайне медленно, 21 от 8 мало чем отличается. Records убогие добавили и всё почти. Async/await нет, designated initializers нет, null safety из котлина стащить не догадались за столько лет.
Си просто прошлый век.
Python в 100 раз медленее чем си поэтому тоже говно.
Котлин - та же ява только с другими погремушками, оверхэдом на неудаляемые геттеры/сеттеры, через жопу сделана проверка на null (тоже с оверхэдом).
Js - тут всем всё понятно.
И так далее.
Если не нравится синтаксис умных указателей С++, посмотри на SWIFT. Там есть структуры и они передаются по значению, а есть классы, они всегда передаются по указателю/ссылке и используют подсчет ссылок и автоматическое освобождение ресурсов.
Давно уже сделано, называется D
>Давно уже сделано, называется DТам GC.
Чтобы программе на этапе компиляции просчитать время жизни указателей, ей нужно эту программу, прежде всего, выполнить. Этот факт уже отсекает большую часть областей применения нашего языка, так как нам теперь не рентабельно с точки зрения времени создавать долгоработющие программы. Но мы пойдём дальше: мы создадим аналог нашего идеального языка, но с GC, и во время рантайма запомним, когда нужно освобождать память. Но даже так в этом нет смысла хотя бы потому, что окружающая среда, в которой находится компьютер, постоянно изменяется, и повторить ту же окружающую среду, что была на этапе компиляции нашего идеального языка, невозможно.
> Этот фактЭто выдумка, а не факт.
Зачем вам цепляться к словам, проигнорировав при этом суть сообщения?Возвращаясь к проблеме, я хочу вас спросить: каким ещё в таком случае образом вы можете предложить простому транслятору с человеческого языка узнать результаты ветвления программы, которая будет выполняться когда-то там в будущем, чтобы расставить необходимые закрывающие функции, при этом не нарушая привычные предположения о течении программы, предлагаяя синтаксис, не сложнее чем в Rust'е, и предлагая накладные расходы не больше, чем при использовании GC?
Так ведь сами эти условия ветвления известны на этапе компиляции, в чем проблема-то.
> Так ведь сами эти условия ветвления известны на этапе компиляции, в чем проблема-то.Проблема в том, что в реальном мире и условия ветвления, и количество экземпляров (в т.ч. копий) переменных зависят от внешних даных, известных тольуо во время выполнения.
Какой к лешему граф во время компиляции?
Эта проблема называется "Проблема остановки" и почти 100 лет назад Тьюринг доказал что она есть и не разрешима.
Так это в общем случае. А частных вполне решается, например для HelloWorld. :)
Можно построить граф переходов между всеми областями видимостей переменных, затем, если все пути исполнения после выхода из интересующей области ведут туда, где интересующая переменная недоступна, то можно сразу её освобождать в этой же области. Если во всех путях она видима, то освобождать не нужно. Если часть путей ведет туда, где она видима, а часть - туда где не видима, то то же условие выбора пути, по которому дальше пойдёт исполнение программы, должно решать, освободить переменную или нет. Вроде просто звучит.
Возможно я понимаю: вы предлагаете каждый раз при выходе из скоупа проверять, будет ли использоваться переменная в дальнейшем. В таком случае графы, с помощью которых вы собираетесь реализовывать данную систему, будет недостаточно формировать во время компилирования: их нужно будет хранить во время выполнения программы и регулярно к ним обращаться. Кроме того, что само обращение накладывает дополнительный оверхед, так ещё и требования к памяти для такой программы будут значительно вырастать в зависимости от сложности программы: количества ветвлений, количество скоупов, количества самих переменных. Ещё интересно, что с такой системой, чтобы предоставлять программисту стандартизированный, привычный и последовательный опыт, вам придётся строить графы не только для переменных, хранящих указатели на выделенную динамическую память, но и для обычных автоматических переменных.
А что делать, если моё приложение использует несколько потоков? Граф не поможет понять, какой поток закончил работу раньше, и какой позже, и соответсвенно не сможет понять, когда оптимальнее будет освобождать память.
> их нужно будет хранить во время выполнения программыНет, они только для того чтобы компилятор сам расставил free() где нужно статически. Где статически не получится, там для начала можно будет кидать ошибку на этапе компиляции - правила всё равно менее строгие получатся и менее ограничивающие, чем в с++ и rust, думаю, надо сильно постараться, чтобы статическая подстановка не сработала. Ну а собрав статистику на реальной кодовой базе уже дальше решать, стоит ли делать более сложную систему с динамическими условиями освобождения - которые опять таки будут не оверхэднее ручного управления.
Возьму простой пример из Rust Book'а:
```
char* pick_str1_or_str2(char* str1, char* str2);{
char* result;
char* str1 = "foo";
{
char* str2 = "bar";
result = pick_str1_or_str2(str1, str2);
}
print(result);
}
```Как компилятор в таком случае должен понять, продлевать ему время жизни str2 или не продлевать? Оставлять str2 в живых просто потому, что "может пригодиться", не вариант.
В Rust'e это решается тем, что программист может описать время жизни возвращаемой ссылки, например, обозначив, что возвращаемая ссылка будет жить столько же, сколько и пересечение времени жизни двух её ссылок-аргументов, и мне нравится это решение.
> мне нравитсяТех, кому не нравится, раз в 10 больше.
> возвращаемая ссылка будет жить столько же, сколько и пересечение времени жизни двух её ссылок-аргументов
Какое-то правило с потолка. Какая вообще разница, как соотносятся лайфтаймы уже не нужных аргументов.
Если обсуждать конкретно этот пример, то здесь вопрос хранить или нет вообще не стоит, т.к. str2 инициализруется константой, зашитой в бинарник, т.е. лайфтайм у ней максимальный.
Если допустим имелось ввиду не то что написано, а какое-то абстрактное получение данных откуда-то в str2, то компилятор может заглянуть внутрь pick_str1_or_str2().
> Какое-то правило с потолка.Это единственный вариант, который пропустит Rust в данном случае, если учитывать, что возвращаемая ссылка была выбрана из аргументов.
> Какая вообще разница, как соотносятся лайфтаймы уже не нужных аргументов.
Благодаря описанию лайфтаймов Rust определит область жизни возвращаемого значения и вообще не пропустит аналогичный код.
> Если обсуждать конкретно этот пример, то здесь вопрос хранить или нет вообще не стоит, т.к. str2 инициализруется константой, зашитой в бинарник, т.е. лайфтайм у ней максимальный.
Я бы не стал надеятся на какое-то определённое поведение, выясненное на вашем компьютере, так как в зависимости от реализации C, архитектуры и версии компилятора здесь может происходить что угодно. Правильнее будет опираться на то, что семантически данные вышли из зоны видимости и очистились, что значит больше ими пользоваться нельзя.
> Если допустим имелось ввиду не то что написано, а какое-то абстрактное получение данных откуда-то в str2, то компилятор может заглянуть внутрь pick_str1_or_str2().
Более того, это абстрактный пример, код, данные, ситуация и много чего. Я бы мог расписать, что данные я получаю, например, от пользователя из stdin, но это не меняет сути: функция может быть внешняя, и даже если она внутренняя, то результат её выполнения можно узнать только в рантайме и вы не предскажете во время компиляции какой ветвью пойдёт исполнение.
Для ясности пусть в нашем случае функция возвращает ссылку наименьшей строки:
```
char* pick_str1_or_str2(char* str1, char* str2) {
if (strlen(str1) < strlen(str2) {
return str1;
} else {
return str2;
}
}
```Ваш компилятор не скажет, какой здесь будет результат, и соответственно не скажет, когда нужно очищать str2 в изначальном примере.
> Это единственный вариант, который пропустит RustВ том то и дело, людям некогда подстраиваться под раст. Я бы добавил, что и не зачем, просто нужен более лучший инструмент.
> соответственно не скажет, когда нужно очищать str2 в изначальном примере
Как раз таки довольно простой пример. Просмотрев возможные пути и видимость переменных на этих путях, алгоритму легко понять, что перед return str1 нужно поставить free(str2) и наоборот. С динамическими структурами сложнее, но тоже решаемо.
> перед return str1 нужно поставить free(str2) и наоборотТак у вас исполняемый файл вздуется если под каждое использование функцию мономорфизировать и инлайнить. В функции пропадёт смысл как переиспользуемом участке кода.
Во 1-х функции обычно код организовывают для удобства, ничего страшного, если компилятор по своему перетасует операции, а во 2-х это примерно то же самое, что сишник написал бы вручную, т.е. никакого особого раздутия в реальности не предвидится. В любом случае, о недостатках несуществующего продукта говорить как-то странновато, общая идея - алгоритм должен работать примерно так же, как человек бы вручную расставлял free(), способы реализации - это частности, которые могут быть пересмотрены и/или улучшены.
Смотрите: если мы расмотрим уже другой пример:
```
{
char* result;
char* str1 = "foo";
char* str2 = "bar";
result = pick_str1_or_str2(str1, str2);
print(result);
print(str1); // Либо эта строка
print(str2); // Либо эта может содержать неопределенное поведение
}
```
То здесь ваш вариант с> перед return str1 нужно поставить free(str2) и наоборот
не сработает, так как одна из строк будет очищена, а если это исправить новым экземпляром функции, то мы останемся с двумя идентичными функциями, которые нельзя взаимозаменять. Если речь идёт о большом проекте с множеством функций и мест с их использованием, то бинарник определенно будет слишком большим.
> общая идея - алгоритм должен работать примерно так же, как человек бы вручную расставлял free()
Какой человек? Учитывайте человеческий фактор.
Эффективность ручного управления памятью как раз в том, что человек сам понимает, как работает его код и с какой целью и что там происходит, а если не понимает, то мы получаем неопределенное поведение.
Если вы хотите создать алгоритм умнее человека, то может быть ИИ вам поможет, но и ИИ-фактор тоже никто не отменял.
Универсальных функций, которые подставляются во множество мест, в реальных проектах не так уж много, к тому же ваш пример синтетический. Освобождать память, которая была выделена где-то снаружи, внутри функции - это большая редкость. Так что я думаю что может +10-20% будет, а может и меньше - это несущественно по сравнению с +200 мб на JVM например.
> ваш пример синтетический
> Освобождать память, которая была выделена где-то снаружи, внутри функции - это большая редкость.Не скажите. Ситуации, когда функция может возвратить указатель на аллоцированые внутри данные, отнюдь не редки, и кто знает, зачем, для каких сайд-и-прямых эффектов они нужны вызывающей стороне и когда их освобождать. Лучше пусть программист сам вызовет *free()
> Так что я думаю что может +10-20% будет, а может и меньше - это несущественно по сравнению с +200 мб на JVM например.
Так или иначе проблему вы признали, а гадать числа особо нет без реальных примеров. Хотя я предсказываю увеличение столь большое и зависимое от решений программиста, что инструмент не станет востребованным.
*Предсказываю решение, зависимое от решений программиста неявно, и к тому же ненадёжное
>> перед return str1 нужно поставить free(str2) и наоборот
> Так у вас исполняемый файл вздуется если под каждое использование функцию мономорфизировать
> и инлайнить. В функции пропадёт смысл как переиспользуемом участке кода.Это известная ещё со времён появления в Си++ templates страшилка для детей.
> В том то и дело, людям некогда подстраиваться под раст.Я понимаю что они очень заняты, выдавливают из себя очередную CVE по памяти.
Но ладно, не подстраивайтесь, но хотя бы не вонякайте когда в какой-то проект добавляются раст зависимости. А то в каждой такой новости нытье (кажется последняя была про thunderbird)> Я бы добавил, что и не зачем, просто нужен более лучший инструмент.
От когда появится - тогда и поговорм.
А пока я не вижу никакого плагина для дыряшки, который решал эту задачу.
Возможно она не настолько проста как кажется.
А может сишники и плюсовики ее осилить не могут, а остальным пофиг.
посмотри в собаке
> Компилятор диктует что ты должен делать и как ты должен это делать. В Ruste нельзя стукнуть кулаком по столу и приказать "Делай как я тебе говорю и баста!". А в C++ - можно.Тебе делать нечего что ли? Обязательно нужно на ровном месте покрасоваться "смотрите, как я умею"?
Пиши нормальный код и не выпендривайся.
Абсолютно верное замечание! Вместо того, чтобы ОСВОБОДИТЬ программиста от головняка с указателями, ржавокомпилер наоборот- НАВАЛИВАЕТ на программиста "вот это проверь, вот здесь укажи, вот там передай".... чего6л....?!?!? А можно я уже начну писать БИЗНЕС-ЛОГИКУ, а не делать прыжки в ширину вокруг ваших, мать их, указателей?!?!?!?!?!?!
Неделю попишешь и работа с лайфтаймами становится очевидной, в подавляющем большинстве случаев даже задумываться не приходится. Или можно писать на C, там нету головняка с указателями. По крайней мере на момент компиляции).
Угумс, вот так навалил целую кучу бузинесс логики, остатки размазал по окружающему коду.
Где-то залепил кастами void*.
И вроде все ок, даже не сильно пованивает, особенно если не принюхиваться.Но ведь потом попрут баги.
Будут бессонные ночи "откуда взялся это сигабтр?!"
А потом, не дай боже, найдутся уязвимости, типичные для дыряшки (если на ней писалось).
CVEшки получения рута и тд.В общем если тебе писать прототип - то питон и прочие ЯП.
А если писать надежный код - то лучше получить подсказки от компилятора.
> В Ruste нельзя стукнуть кулаком по столу и приказать "Делай как я тебе говорю и баста!".Да ладно тебе врать-то. В расте есть unsafe, это как раз тот самый кулак по столу.
>В Ruste нельзя стукнуть кулаком по столу и приказать "Делай как я тебе говорю и баста!"Можно:
fn main () {
unsafe{
// ....
}
}
Я сперва думал ты про гошечку
Покорная жена которая изменяет на право и налево или строптивая, но верная?
В мире идеологии неолиберального глобализма ты и должен быть рабом! А раст как раз и есть язык программирования этого нового мира.
> Мне всегда казалось, что компилятор должен помогать программисту делать хорошие программыА мне всегда казалось что программисты должны быть компетентны и не делать ошибок.
> что всё наоборот: компилятор - хозяин, а программист - его раб
Какое ущемление прав, компилятор мешает писать некорретные программы. Потому что корректные писать он не мешает.
> В Ruste нельзя стукнуть кулаком по столу и приказать "Делай как я тебе говорю и баста!"
Можно. Именно и только в нём и можно. unsafe, unchecked_*, куча инструментов именно для этого.
> А в C++ - можно. Rust - это как строптивая и несговорчивая жена. С кем вам лучше жить , со строптивой или покорной - решать вам самим.
В C++ некому стучать, он мямля жрущая любое г-но. Там нет инструментов гарантирующих корректный код, поэтому нет и инструментов для их обхода.
Один гениальный погромист любил делить на ноль. Перепробовал множество языков и компиляторов к ним. Даже на разных аппаратных платформах пробовал. И потом осознал, что это мировой заговор, плюнул на кодинг и ушел в политику.
Еще один плохо читаемый язык с кучей знаков припенания.
А какой по твоему норм? (вопрос серьёзный без подколки)
Lisp.
Ещё бы кобол вспомнил. Впрочем, кобол хотя бы жив в отличии от лиспа.
Лиса с воза - коболу легче
Нет, Кобол я бы не вспомнил, так себе язык на мой вкус. Про живость Лиспа тебе придётся с кем-то другим посмотрить, я на Лиспе в прод писал ещё каких-то два года назад, и точно знаю, что тот проект жив и развивается дальше. Как и сам Лисп в общем-то. Но поскольку стандарту Лиспа лет больше, чем большинству местных комментаторов, то не удивительно, что ситуация с ним «олды не понят, нубьё не знает».
> Как и сам Лисп в общем-то. Но поскольку стандарту Лиспа лет больше, чем большинству местных комментаторовсам себе противоречишь
Где ты тут увидел противоречие? Или в голове не укладывается как можно было в девяностые написать стандарт языка так, чтобы он мог дальше развиваться без изменения стандарта?
Если стандарт зафиксирован, то язык не развивается. Может лишь развиваться разработка на языке.
Я автор книги "GNU Emacs для технических писателей", и мне Lisp не нравится. Конфиги Emacs вообще неплохо бы в YAML перевести.
> А какой по твоему норм? (вопрос серьёзный без подколки)Pascal. Ruby
От Паскаля руки устают.
> От Паскаля руки устают.Можно подумать что ты вручную в блокноте будешь вводить каждую буковку. Более мощный аргумент можно?
Можно. ГЛАЗА. Их ты точно никак не ускоришь. Очевидно, что распознать для глаза "begin" СТОКРАТ сложнее, чем "{". Собственно, потому паскакаль таки погряз в своих "научных недрах", а ЛЮБОЙ си-подобный язык взлетел. Даже Руби или, простихоспади, жабоскрипт.
> ГЛАЗАГлаза, как и мозг (если есть), воспринимают гораздо лучше связанные буквы, которые представляют собой слова, а не крючки и закорючки. Сразу можно понять, какой язык создан для долгосрочных проектов, а какой ради потешить ЧСВ.
комментар> Глаза зпт как и мозг скб если есть скб зпт воспринимают гораздо лучше связанные буквы зпт которые представляют собой слова зпт а не крючки и закорючки тчк
Глазам хочется цепляться за КВЧ ВАЖНОЕ КВЧ зпт а не отвлекаться на мишуру вскл
if ... then ... elseif ... end -- мишура из Lua
if (...) {...} else {...}
if (...) ... else ...ратнеммок
> Глаза, как и мозг (если есть), воспринимают гораздо лучше связанные буквы, которые представляют собой слова, а не крючки и закорючкиКак раз наоборот, лучше воспринимается визуальное отделение блоков, чем слова, сливающиеся с другим кодом. На самом деле и скобки-то избыточны, достаточно отступов как в python.
> Сразу можно понять, какой язык создан для долгосрочных проектов, а какой ради потешить ЧСВ.
Как же ты объяснишь что паскаль не используется ни в одном серьёзном проекте?
Просто Pascal уже не в моде а то что Pascal не используется ни в одном серьёзном проекте ещё доказать надо.
> Очевидно, что распознать для глаза "begin" СТОКРАТ сложнее, чем "{".Не очевидно вовсе. Начнём с того, как ты определяешь "сложнее"? Энергетически затратнее? Больше времени занимает? Или что?
Если же отвлечься от этого, то в текстовом редакторе begin выделен цветом ключевых слов, и с учётом контекста не надо даже буквы читать, чтобы понимать что это begin. Ты можешь сам попробовать отрендерить текст программы, замылить рендер до неразличимости отдельных букв, и посмотреть.
>Если же отвлечься от этого, то в текстовом редакторе begin выделен цветом ключевых слов, и с учётом контекста не надо даже буквы читать, чтобы понимать что это begin.как ты заувалированно подтвердил, что begin абсолютно бесподезен и может быть легко заменен на {, главное что б редактор подсветил правильно.
{ абсолютно бесполезна и может быть легко заменена на begin.
> Можно. ГЛАЗА. Их ты точно никак не ускоришь. Очевидно, что распознать для
> глаза "begin" СТОКРАТ сложнее, чем "{".Неверное понимание. Мозг в известном ему контексте не воспринимает информацию вот так, по буковке, а кусками, т.е. здесь - ключевыми словами формального языка. Если на то пошло, то begin/end как ограничитель ловится именно легче, с меньшей трудозатратой глаз+мозг, чем фигурные скобки, которые близки по очертаниям к квадратным и простым скобкам.
Компактность собственно кода - да, ухудшена.
Ух, какая же боль для анонима - читать буковы!
Переходи на китайские иероглифы в программировании, вообще идеал.
Глупо осуждать язык за синтаксис, ведь это лишь часть парсинга кода в компиляторе.
Идиотский аргумент. А как же тогда названия функцый, переменных и всего остального что длиннее одного символа?
А напомни-ка, у вас там в паскакале лямбды завезли? Как ты напишешь лямбду складывающую число-аргумент с числом из лексически захваченной по ссылке переменной и передашь её в map()?
В универе, в начале 90-х, нам Паскаль преподавали и немножко ассемблер. Потом, уже работая, ковырял Делфи и С++. В начале 2000-х появился С#. Вот это действительно классная вещь. Насчёт серьезности языка - это что?
Всякую шляпу преподавали. Дельфи, прибитый гвоздями к IDE. C# с кучей версий дотнет и теми же трудностями, как у Java.
> А какой по твоему норм?Nim.
Без вариантов.
Это язык с GC.
>Это язык с GC.В последних версиях уже GC опционально, по умолчанию идет автоматическое управления памятью с помощью счетчика ссылок (ARC) плюс разруливитель циклов, аналогично питону или Swift.
Вообще очень интересный язык, жаль что не раскрутился.
Так в nim 1:1 синтаксис раста.
> Так в nim 1:1 синтаксис раста.Угу а в питон 1:1 синтаксис C++.
Любителям бэйсика – пламенный привет!
Бейсик довольно неплох в плане синтаксиса. Современный FreeBASIC годится даже для написания операционных систем. Вот тут подробнее https://wiki.osdev.org/FreeBasic_Bare_Bones
Да.. он хорош
Гуманитариев хлебом не корми - дай за синтаксис потрындеть. Открой любой курс по CS - там вообще такие вещи как синтаксис не разбираются. Разбирают и критикуют семантические свойства. А синтаксис это бирюльки, если очень хочется на нормальном языке ничего не стоит DSL написать.
>А синтаксис это бирюлькиКак быстро все забыли Вирта, он же только в этом году ушёл. Дегенерация во всей свой красе.
А программы писать предлагается с помощью семантических свойств или всё таки с помощью этих амых бирюлек?
Плазменный привет
Вот этим мне он и не нравится, вроде бы подразумевалось, чтобы было лучше, чем Си, но в Си всё же проще кодить
От фрагментов исходного кода Perl-ом запахло. Я не берусь судить, хорошо это или плохо, потому что мне все равно.
Вот бы говнище с anyhow как-то профиксить задолбало городить везде свои обертки ошибок.
Почему в этом языке так активно используются всякого рода скобочки и прочие закорючки? Они лишь ухудшают читабельность. Или это тонкий намёк, что в будущем любой код будет write only?Хороший пример читаемого синтаксиса у COBOL и Ada. Java тоже норм, но уже на грани.
Наверное, по той же причине, что и в математике. Краткость - сестра таланта.
> Наверное, по той же причине, что и в математике. Краткость - сестра
> таланта.В математике нет такого понятия, как простота поддержки (maintainability). Математикам можно побыть страшно далёкими от народа. Они даже языки с динамической типизацией зовут нетипизированными, потому что в голове одни лямбды.
Rust можно покритиковать за закорючечность, потому что в нём на самом деле есть визуально избыточные закорючки для упрощения парсинга (turbofish, например).
>В математике нет такого понятия, как простота поддержки (maintainability).В математике есть такое понятие, как интуитивное понимание.
В чем проблема с чтением кода на Rust, если ты понимаешь концепции, семантику языка? Да, они сложнее, чем в Си. Но при этом проще, чем в Плюсах. Но на Плюсы народ почему-то не жалуется.
>Они даже языки с динамической типизацией зовут нетипизированными
Причём здесь математики? И нет, таким никто не занимается, если мы говорим о грамотных специалистах, потому что динамическую типизацию нельзя приравнять её отсутствию.
>в нём на самом деле есть визуально избыточные закорючки
Но также есть синтаксический сахар.
> динамическую типизацию нельзя приравнять её отсутствиюДля них это одно и то же, что для меня тоже стало открытием на днях. Пройдись по гуглокнигам или scholar'у, там такое часто встречается ("untyped language such as Ruby, JavaScript or Scheme") и можно откопать пояснение, что динамической/латентной/отсутствующей типизацией называется одно и то же (из-за untyped lambda calculus?).
> В математике есть такое понятие, как интуитивное понимание.
Не знаю. Там в любом случае фокус смещается с понятности выкладок на способности читателя этих выкладок. Смог схватить внезапно введённые автором обозначения - молодец. Хочешь растерянного аллигатора[1]? Держи: ⩼ (ещё не вырос, правда).
> В чем проблема с чтением кода на Rust
Если в двух словах, то сишнику не понравится, что у Rust горбы OCaml'овские торчат.
> Но на Плюсы народ почему-то не жалуется.
Ну почему, там хорошо видно, что move semantics пришлось кое-как вкорячивать в уже существующий язык. Как и новые способы инициализации, которые почти решают проблемы предыдущих. Стандартная библиотека известна нечитаемостью[2], потому что читаемый код юзер может случайно переопределить в препроцессоре. Метапрограммы зачастую write-only.
[1] https://xkcd.com/2606/
[2] случайная строчка, например: return __detail::__erase_nodes_if(__cont, __ucont, __pred);
>Если в двух словах, то сишнику не понравится, что у Rust горбы OCaml'овские торчат.OCaml со всеми своими горбами гораздо читабельнее чем си.
| поэтому я и говорю, что 'сишнику, а не ?каждому
Да в смысле? Даже сравнивать сишную императивную лапшу с окамловской строгостью нельзя. А ещё больше мне Clean нравится, такой простоты и четкой сухости никакой имеративщине никогда не добиться.
>Пройдись по гуглокнигам или scholar'у, там такое часто встречаетсяЯ бы обходил стороной такие книги, потому что авторы сами до конца не понимают, о чем пишут.
Кто авторитетнее - профессор или Прохожий?Benjamin C. Pierce в "Types and Programming Languages" противопоставляет "run-time monitoring" и "type systems". То есть мониторинг чего угодно, только не корректности типов:
"monitoring ... when one of its components is not behaving according to specification".Он признаёт, что так говорят, но пишет, что это неформальность, которая в его теорию не укладывается.
"Terms like “dynamically typed” are arguably
misnomers and should probably be replaced by
“dynamically checked,” but the usage is standard".Теория у него про то, что
"A type system is a tractable syntactic method for proving the absence of
certain program behaviors by classifying phrases according to the kinds
of values they compute".Есть, конечно, и другие профессоры с другими теориями...
Не сотвори себе кумира. Знаешь, откуда цитата?Авторитетнее, как всегда, обычный здравый смысл (если не забывать им пользоваться). То, что профессор решил придраться к терминологии, не отменяет того факта, что типы в динамически типизированных языках всё-таки проверяются, а не вообще полностью отсутствуют, что подразумевает под собой язык без типов вообще, или язык со слабой типизацией.
> что типы в динамически типизированных языках всё-таки проверяютсяУ него английским по белому (здесь по зелёному) написано, что это не типы. Потому что он принял определения, согласно которым это не типы. Он про это книжку написал.
> Не сотвори себе кумира. Знаешь, откуда цитата?
"Всегда внимательно читай комментарии" - В. И. Ленин. Я сразу сказал, что "математики"* в своём теоретическом компьютерном сатанизме варятся. Они могут позволить себе заявить, что ~99% практиков ошибаются, веря в динамическую типизацию.
"Математикам можно побыть страшно далёкими от народа. Они даже языки с динамической типизацией зовут нетипизированными, потому что в голове одни лямбды".
> Авторитетнее, как всегда, обычный здравый смысл
Здравый смысл говорит, что тезис "не понимают, о чем пишут" пришлось замять и повозмущаться с позиции практика от невнимательности.
* Ну, это не чистая математика, а стык разных областей. Это очень чистая теоретическая информатика, занимающаяся математическими основами программирования. В том числе лямбда-исчислением, появившимся до программирования.
> У него английским по белому (здесь по зелёному) написано, что это не типы.Но ведь я так и сказал, что человек применяет её по-своему, то есть "придирается к словам". Хорошо, не к словам, к понятиям (на тот случай, если ты тоже захочешь продолжить придирки), вводя свои определения типов.
> Я сразу сказал, что "математики"* в своём теоретическом компьютерном сатанизме варятся.
Но тогда зачем было приводить профессора? Который тоже в своём сатанизме решил свариться?
> Здравый смысл говорит, что тезис "не понимают, о чем пишут" пришлось замять и повозмущаться с позиции практика от невнимательности.
А, вот оно в чём дело. Опять придирки к словам (пардон, использование своей терминологии).
Я понял - есть две точки зрения, твоя и неправильная. Кто за неправильную, тот враг. Кто как бы нейтрально сказывает о неправильной, тот коварный враг! Он то пренебрежительно пишет "в голове одни лямбды", то ссылается на профессорское звание, то говорит несогласии других профессоров. Что за коварные планы он вынашивает?"Какие-то теоретики не согласны с практиками и с обеих сторон нет очевидно ошибающихся" - это вольнодумство.
"Теоретики заблуждаются и выдумывают заведомо ошибочную терминологию" - это по-нашему.---
Почему нельзя просто закончить разговор на "ага, они и правда далеки от народа", "интересно, может пригодиться при чтении книг по CS"?---
Взгляды теоретиков на типизацию ещё объясняют, почему типизацию делят на номинативную и структурную. Первое - это как в Java. Второе - это compile-time утиная типизация. Что-то пропущено, да? Runtime утиную типизацию в этой классификации выкидывают, потому что за типизацию не считают.
> тезис "не понимают, о чем пишут" пришлось замятьПосле некоторого раздумья. Нет, не пришлось. Эти люди таки не понимают, о чём пишут, если говорить о реальности, а не о неких сферических конях в вакууме.
> И нет, таким никто не занимается, если мы говорим о грамотных специалистах, потому что динамическую типизацию нельзя приравнять её отсутствию.В CS есть такая вещь как теория типов, через её использование можно выйти на доказательство утверждений о поведении программы. Но только в том случае, если типы указаны и проверяются статически. Поэтому динамическая типизация, которая с точки зрения инжинегра, вроде как и типизация, с точки зрения CS не более чем неявные автоматически расставляемые рантайм проверки. Они отличаются от if(!is_integer(x)) { throw_an_error() } только своей неявностью, они не меняют ничего практически.
Кроме того, если зайти с "лингвистической" точки зрения, то что такое нетипизированный язык? Если динамическая типизация -- это тоже типизация, то что значит "нетипизированный язык"? Если мы копнём в такой язык, мы увидим, что он рано или поздно будет вынужден принимать решения о типах значений, для того чтобы над ними разные операции проводить. И таким образом, любой язык становится типизированным, они отличаются только тем как смешаны статическая и динамическая типизация, и насколько строго всё это соблюдается. Можно наверное поспорить, что ассемблер нетипизированный, в нём в конце концов нет понятия типа, но даже если мы примем это, то получается что нетипизированными языками являются только ассемблеры. Таким образом пара понятий типизированный/нетипизированный становится практически бессмысленной: если типизированный означает "все языки" то зачем зашумлять сигнал своей речи ненужными словами про типизированность?
Инженегры заходят несколько иначе, и у них языки делятся на динамически типизированные и статически типизированные, и такое деление имеет смысл. А словом "нетипизированные" они просто не пользуются.
> Таким образом пара понятий типизированный/нетипизированный становится практически бессмысленнойНе бессмысленнее, чем "язык высокого уровня == язык выше ассемблера", такое разбиение на низкий*/высокий уровень до сих пор живёт.
* машинные коды + asm
> они не меняют ничего практическиПравда, что ли? Попробуй с переменной числового типа в том же Питоне сотворить какую-то операцию, типичную для строки. В Сях это иной раз вполне возможно. Почувствуйте разницу.
> Если динамическая типизация -- это тоже типизация, то что значит "нетипизированный язык"?
Ну это же проще пареной репы. Нетипизированный язык - это такой язык, где проверка над переменными разных типов при совершении операций над ними не производится ни в каком виде или такая проверка носит не системный, эпизодический характер (языки со слабой типизацией).
> Если мы копнём в такой язык, мы увидим, что он рано или поздно будет вынужден принимать решения о типах значений, для того чтобы над ними разные операции проводить.
Не увидим. Например, в тех же Сях.
> то получается что нетипизированными языками являются только ассемблеры
Получается.
> пара понятий типизированный/нетипизированный становится практически бессмысленной: если типизированный означает "все языки"
Не означает.
>В математике есть такое понятие, как интуитивное понимание.И к Rust это не имеет абсолютно никакого отношения.
Вот для примера: язык Haskell или ML (oCaml, F#) любой профессиональный математик поймёт вообще из коробки 80-90% кода (то есть не открывая доков), потому что там прекрасно спроектированный синтаксис (при этом людям, у которых проблемы с математикой будут тупить даже прочитав доки). Открывая код на Rust вы вообще ничего в нём не поймёте независимо от вашей подготовки, в нём минимум интуитивной логики и много базовых правил прямо со старта. А концепция "ручного" времени жизни в виде ' - это вообще уродство и такого не должно быть в языке.
Потому что язык должен быть новым не столько внутри сколько снаружи. А вдруг он снаружи будет похож на какой нить Си или Java? Парни с кольцом в носу, ну или там с тунелем в ухе, и бутылочкой смузи, скажут фу какая гадость и пойдут программировать на другом языке.
http://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-i...
Называть автора статьи глупым язык не поворачивается. Поэтому скажу, что этот человек просто не озаботился вначале о том, чтобы прояснить для себя одну очевидную вещь: дополнительная безопасность - это всегда дополнительные расходы. И тут уж ты для себя решаешь, стоит ли их нести. Авторы языка Rust об этом знали. Именно по этой причине в языке есть слово unsafe.
Язык создан исходя из неверного утверждения что якобы он добавляет безопасности, но мы много раз убеждались что это не так. Это просто цирк безопасности.
Неправда, чем больше безопасности - тем лучше! Rust - это как замок на двери в вашей квартире!
А ключик (крейты) у чужака.
Сделай их локальными.
1. Можно указывать зависимости из других источников (Git [1], локальная ФС [2])
2. Можно переопределять зависимости [3]
3. Можно добавлять и переопределять registry [4] (в т.ч. это уже поддерживается Artifactory [5])
4. Можно не использовать крейты (вообще), и всё писать в одном проекте руками вендоря зависимости (буханка.png)
5. Можно определить свой слой работы с ОС (или её отсутствием) [6]
6. Можно даже определить свой core (пусть пока это и unstable) [7]Откуда же у всех такая уверенность, что Rust *принуждает* использовать crates.io? С учётом того, что <делать использование удобным> != принуждать использовать.
Любой, кому что-то мешает использовать crates.io, может пойти по любому из путей (преимущественно 1--4)
[1]: https://doc.rust-lang.org/cargo/reference/specifying-depende...
[2]: https://doc.rust-lang.org/cargo/reference/specifying-depende...
[3]: https://doc.rust-lang.org/cargo/reference/overriding-depende...
[4]: https://doc.rust-lang.org/cargo/reference/registries.html
[5]: https://jfrog.com/help/r/jfrog-artifactory-documentation/car...
[6]: https://docs.rust-embedded.org/book/intro/no-std.html
[7]: https://doc.rust-lang.org/nightly/unstable-book/language-fea...
>но мыКто, мы? Гугловцы, которые практики, иначе думают.
Из-за некомпетентного руководства корпорации все так же подвержены хайповым трендам. Гугловцы постоянно принимают глупые решения. Например внедрение нейронок, которые генерируют бредовые ответы на главной при поиске. Или вот гугл стадия...
>Из-за некомпетентного руководства корпорацииТакого некомпетентного, что корпорация мировой лидер на рынке софтостроения? Интересная у тебя логика.
>подвержены хайповым трендам
Если бы смог осилить простой текст на английском в их блоге, то понял бы, что речь не о хайпе, а об уменьшении количества типовых ошибок и об увеличении производительности труда. Но ты, очевидно, не смог.
Ты и русский текст не осилил
Олигополии - весьма устойчивы, и за счёт сверхприбылей, распилов и откатов могут себе позволить заниматься чушью.
Вроде бы взрослый, а таких простых вещей не понимаешь.
Сначала добейся. Стань этой самой олигополией. А то, видишь ли, желающих много, а получается на практике у единиц. Вроде бы взрослый, а таких простых вещей не понимает.
Предыдущее сообщение было про руководство Гугла.Это будет про применение Rust в ОС Android. В их блоге была заметка о том, что после того, как они перешли на использование Rust, количество ошибок с памятью сократилось, а продуктивность программистов выросла. Теперь предлагаю тебе подумать, каким образом относится твоё заявление про чушь, которой якобы занимаются в Гугле (потому что они же могут ею заниматься), к реальности?
Google мировой лидер по части рекламы и слежки в WWW что обеспечивает им кучу денег. Занимая такое положение они там могут заниматься абсолютной хероборой.
Тогда почему у Google поиск по картинкам хуже, чем у Яндекса? (это не шутка). Лидеры такие лидеры. Сервисы Google - это треш. Более того, Google может закрыть доступ к вашим же данным (которые правда юридически уже НЕ ваши) в самый неподходящий для вас момент, если у вас сменился IP и аккаунт не привязан по номеру телефона. Всё, вы утратили доступ. Зато "безопасно". При этом Google уже за руку поймали на слежке и это фактически их реальный доход. При этом Google покупает компании и прихлопывает их деятельность в 90% случаев. Лидер на рынке софтостроения...
Это те что уже изобрели прогрессивный Dart, да на них стоит ровняться.
> Опубликован релиз языка программирования общего назначения Rust 1.80, основанного проектом
> Mozilla, но ныне развиваемого под покровительством независимой некоммерческой организации
> Rust Foundation.Вот в целом если, то ни по замыслу, ни по синтаксису данный ЯП вот такой уж новацией не является.
А смысл его бытия косвенно указывается тем, кто его владельцы и толкачи (как и в любом другом техническом решении/проекте/итд)
>такой уж новацией не являетсяЕсли рассматривать каждую фичу по отдельности, то так и есть. Но ведь в Rust их все объединили под одной крышей. И это само по себе уже очень даже весомое преимущество.
А надо было делать язык, где можно добавлять разных формальных проверок, а можно этого и не делать.frama-c добавить в c но не как комментарии, чтобы компилятор поддерживал.
что-то типа dafny сделать, но более удобный
А не так, взять 2.5 штуки из формальной верификации и прибить это всё гвоздями.
> А надо было делать язык, где можно добавлять разных формальных проверок, а можно этого и не делать.
> frama-c добавить в c но не как комментарии, чтобы компилятор поддерживал.
> что-то типа dafny сделать, но более удобныйМисраС уже есть, но если проверки будут не обязательными, то им никто не будет пользоваться.
Как писан на этом форуме один любитель дыряшки "я не буду ждать 15 минут пока будут проходить тесты CI! я в своем коде уверен"> А не так, взять 2.5 штуки из формальной верификации и прибить это всё гвоздями.
Так сделай лучше!
Покажи этим смузихлебам как нужно.
Твой язык станет супер популярным и раст отправится на свалку истории.
Но пока, ты как тот Мудрый Филин из анекдота про мышей и ежиков.
Задумка языка хороша, но реализация в плане синтаксиса для меня диковата. В коде множество спецсимволов из-за этого мне проще читать код c++.
Дело чисто привычки. Будешь работать с ним, это не будет проблемой.
>В коде множество спецсимволовНе больше, чем в C++ ¯\_(ツ)_/¯
Например, каких спецсимволов там больше, чем в C++?
Вот тут, например, скобочек больше :)
Ok(())
Тебе шашечки или ехать?
Шаблоны в C++ - вообще эзотерика для неподготовленного человека, но тем не менее, их пишут, с расчётом на то, что компилятор всё посчитает на этапе компиляции программы, и итоговая программа будет работать быстрее.
Дело в том, что на фоне решаемых задач синтаксис - лишь флёр для новичков.
100500-я жалоба на синтаксис Rust, и ни одного примера. Свободен.
В rust синтаксис сильно проще плюсов и меньше перегружен спецсимволами. К чему именно претензии?
Зачем в каждой новости писать первые 3 абзаца? Чтобы никто не забыл про безопасность?
Что за убогий синтаксис у раста? У автора что тремор был когда на двоеточие жал? А в println зачем восклицательный знак? Что за хрень?
println! - это макрос. Ты бы хоть немного почитал доку, прежде чем высказывать своё "ценное мнение", а?
> println! - это макрос. Ты бы хоть немного почитал доку, прежде чем
> высказывать своё "ценное мнение", а?Что за хрень? Что, в расте нет функции printf(ln)?
Нет там такой функции. Зато есть макрос. Что конкретно тебя смущает? Или ты макрос в глаза в первый раз в жизни видишь?
> Нет там такой функции. Зато есть макрос. Что конкретно тебя смущает? Или
> ты макрос в глаза в первый раз в жизни видишь?Что за язык такой, если нет printf?
А зачем, если если макрос, который делает то же самое плюс ещё некоторые фичи там есть?
Правильно, зачем printf? Лучше двоеточий побольше захреначить, сразу улучшится управление памятью...
Остапа понесло.
Да и функция эта - она не относится к языку. Или этого ты тоже не знаешь?
А к чему она относится?
К библиотеке же.
> К библиотеке же.А библиотека к чему?
Ни к чему. Она живёт уже своей жизнью.
Стандартная библиотека, в которой есть функция printf, описана в стандарте ISO/IEC 9899, соответственно является частью языка Си. Прохожий этого не знает.
Почему это важно в контексте изначально обсуждаемой темы? Или просто надо было к словам придраться?
> Почему это важно в контексте изначально обсуждаемой темы?Ты сам про это написал в #184, а я должен объяснить, зачем ты это сделал?
> Или просто надо было к словам придраться?
Вот сейчас я придерусь к словам: заявление "функция эта - она не относится к языку" ложно, но вместо признания ошибки (в том числе и с обвинениями оппонента "ты не знаешь?") началась демагогия.
И ещё одно замечание. То, что библиотечная функция является частью стандарта, не означает, что она относится именно к языку, как таковому в общем понимании этого термина. Почему? Потому что без этой библиотечной функции всё ещё можно будет писать программы на этом языке. Собственно, поэтому и разделяют понятия "язык программирования" и "стандартная библиотека".Так что, может быть, и хорошо, что стандартная библиотека является частью стандарта, но при этом она, всё же, живёт своей жизнью, и относится только к тому ПО, которое её задействует.
> И ещё одно замечание. То, что библиотечная функция является частью стандарта, не
> означает, что она относится именно к языку, как таковому в общем
> понимании этого термина. Почему?Потому что ты не знаешь, как называется стандарт. А стандарт называется "Язык программирования Си". Соответственно, стандарт описывает всё, из чего состоит язык.
> Потому что без этой библиотечной функции всё ещё можно будет писать программы на этом языке.
Про это написано в пункте стандарта о conforming implementations. В общем, что бы говорить о языке и стандарте, хорошо бы сначала знать язык и стандарт.
> Так что, может быть, и хорошо, что стандартная библиотека является частью стандарта, но при этом она, всё же, живёт своей жизнью, и относится только к тому ПО, которое её задействует.nooby в этом вопросе жесточайше принципиален и считает, что линукс написан не на Си. А на Си с расширениями, который не является Си, потому что среди расширений есть противоречащие стандарту (большинство таких).
Наверное, тогда почти ничего на Си не написано... И линусовская речь[1] о стандартах как туалетной бумаге выглядит практичнее, чем такие принципы. Но принципы тверды!
> nooby в этом вопросе жесточайше принципиален и считает, что линукс написан не на Си. А на Си с расширениями, который не является Си, потому что среди расширений есть противоречащие стандарту (большинство таких).Хм, а разве он не прав?
Ядро же писалось на ГНУтых расширениях, которые в тот момент поддерживались только одним ГНУтым компилятором. Который к тому же хотел заражать компилированный код гну-раком.
Типичное ЕЕЕ только со вкусом и запахом Щво6одки (и возможно запашком Бороды).> Наверное, тогда почти ничего на Си не написано... И линусовская речь[1] о стандартах как туалетной бумаге выглядит практичнее, чем такие принципы. Но принципы тверды!
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=638477#c129Фин много чего вякал, даже пальчики показывал.
Потом ему умные дяди объяснили, что так делать плохо и если продолжать, то можно сходить на Хурд и остаться без зарплаты с кучей нулей.
ИЧСХ его попустило!
Так что на его эмоциональные высказывания (как у типичного б-ла) полные[1] crap/hell/anal и прочее можно не обращать внимание.
[1] habr.com/ru/articles/345846/
> Хм, а разве он не прав?Это спор о терминах. Большинство скажет, что диалект Си или Си с расширениями - это всё ещё Си. Комитет с этим, в общем-то, не спорит. Иначе бы мог давить таких за нарушение интеллектуальных прав - устроил бы что-то вроде "ECMAScript наоборот"*.
---
Конечно, стандарт - это просто (в меру полезная) бумажка. У майкрософта вон тоже своё ядро на своём Си со своими расширениями. То что у тебя по поводу Линуса болит - проигнорирую.* То есть обязывал бы каждую non-conforming implementation называть так, чтобы не было связи с названием "Си". Стандарт бы назывался просто "Си", а почти все реализации - с подвывертом, чтобы не засудили (не "Си с расширениями IAR", например, а ThirdLetterLang).
В чём n00by жесточайше принципиален, так это в классификации персонажей, кто любит фантазировать и приписывать n00by своё мнение.Тёмные Силы Электричества согласны с n00by, выдав капчу 77777 ;)
> В чём n00by жесточайше принципиален, так это в классификации персонажей, кто любит
> фантазировать и приписывать n00by своё мнение.Это не та ситуация, в которой надо на всякий случай всё отрицать.
Вот библиотека Cosmopolitan Libc обсуждалась[1], в которой `extern const errno_t EINVAL`, `#define EINVAL EINVAL`.
Ты медленно достал свой ISO/IEC 9899:2017, назвал нарушенный пункт и пришёл к выводу:> То есть формулировка "Си-библиотека Cosmopolitan" не является корректной.
> Правильнее говорить "похожая на Си"Чтобы сделать вывод про Linux или любое другое применение нестандартного Си, достаточно индукции.
[1] https://www.opennet.me/openforum/vsluhforumID3/130995.html#32
>[оверквотинг удален]
> Это не та ситуация, в которой надо на всякий случай всё отрицать.
> Вот библиотека Cosmopolitan Libc обсуждалась[1], в которой `extern const errno_t EINVAL`,
> `#define EINVAL EINVAL`.
> Ты медленно достал свой ISO/IEC 9899:2017, назвал нарушенный пункт и пришёл к
> выводу:
>> То есть формулировка "Си-библиотека Cosmopolitan" не является корректной.
>> Правильнее говорить "похожая на Си"
> Чтобы сделать вывод про Linux или любое другое применение нестандартного Си, достаточно
> индукции.
> [1] https://www.opennet.me/openforum/vsluhforumID3/130995.html#32Что бы ты мог воспользоваться индукцией, тебе следует начать понимать, что это вообще такое, а так же изучить разницу между необходимыми и достаточными условиями.
Пока ты взял мою оценку реализации стандартной библиотеки Си (требования к ней описывает стандарт) и попробовал натянуть её на клиентский код (к чему стандарт определяет понятие ill-formed, и то лишь в Си++).
> Пока ты взял мою оценку реализации стандартной библиотеки Си (требования к ней
> описывает стандарт) и попробовал натянуть её на клиентский код (к чему
> стандарт определяет понятие ill-formed, и то лишь в Си++).Ну ты шутник, какая разница, где стандарт нарушать? Вот клиентский код на Rust нарушает стандарт Си, совсем не компилируется. А по твоей логике его можно назвать Си-программой?
Или серьёзный пример:
- берём компилятор с расширением, делающим реализацию Си nonconforming[1] (например, asm())
- называем его компилятором "языка, похожего на Си" из-за нарушения стандарта
- пишем программу с использованием этого расширения, получаем nonconforming program[2]
- на каком языке эта программа?> стандарт определяет понятие ill-formed, и то лишь в Си++
В стандарте Си вместо плюсового well-formed program используют conforming program и strictly conforming program. Есть совпадающая фраза, где strictly conforming в Си++ лишь заменили на well-formed[3] (смысл поменялся, но не уверен, что намеренно).
---
[1] "The inclusion of any extension that may cause a strictly conforming program to become invalid renders an implementation nonconforming. Examples of such extensions are new keywords, extra library functions declared in standard headers, or predefined macros with names that do not begin with an underscore."[2] "A conforming program is one that is acceptable to a conforming implementation"
[3] "A conforming implementation may have extensions (including additional library functions), provided they do not alter the behavior of any well-formed program."
>> Пока ты взял мою оценку реализации стандартной библиотеки Си (требования к ней
>> описывает стандарт) и попробовал натянуть её на клиентский код (к чему
>> стандарт определяет понятие ill-formed, и то лишь в Си++).
> Ну ты шутник, какая разница, где стандарт нарушать?Если бы ты потрудился и привёл цитату стандарта на эту тему, я бы продолжил диалог. А так - не вижу смысла за тебя читать стандарт. Спасибо, что ты показал выше, что я читал стандарт и могу его процитировать.
>> *Три цитаты из стандарта*
> Если бы ты потрудился и привёл цитату стандарта...У тебя иногда срабатывает психологический блок и ты как бы физически теряешь возможность участвовать в неудобных спорах.
Если ты до сих пор не понял, я с тобой принципиально не спорю. В данном случае я тебе объясняю, что тебе необходимо найти цитату стандарта и на её основании дальше фантазировать своё "нуби считает, что ядро linux не является стандартной библиотекой языка Си".
- Там три цитаты из стандарта
- В глазах темнеет!
- Включите свет
- Мы его теряем!..
Если бы ты не обнулил себя заявлением "какая разница, где стандарт нарушать?" может быть я бы до них и дочитал. А так - не увидел смысла учить Анонима.
А если всё-таки превозмочь и не надувать щёки?
Если нарушить в программе, то будет nonconforming program.
Если нарушить в реализации Си, то будет nonconforming implementation.
Где сверх-разница, кроме очевидной?В случае с линуксом имеем и то, и то, это видно по asm(), как уже писал. С дефолтными и линуксовыми флагами GCC нарушает стандарт.
---
Если уж искать у меня ошибки, то здесь:
> среди расширений есть противоречащие стандарту (большинство таких).
> большинствоВ стандарте Си фраза в предложении [3] ("A conforming implementation may have...") разрешает расширения, меняющие поведение программ с unspecified/undefined/implementation-defined behavior, это в Си++ такого намерения в этой фразе нет (там фраза разрешает менять поведение только ill-formed программ), да и всё равно, наверное, не большинство.
> А если всё-таки превозмочь и не надувать щёки?
> Если нарушить в программе, то будет nonconforming program.
> Если нарушить в реализации Си, то будет nonconforming implementation.
> Где сверх-разница, кроме очевидной?Очевидно то, что ты приписал мне некую свою бредятину, стало быть на тебе и лежит бремя доказательства. Как только ты задаёшь мне вопрос, я автоматически множу твою писанину на 0.
Потому что printf и прочие при каждом вызове заново интерпретируют строку форматирования, что медленно и зачем
Макрос println! в Rust парсит шаблон один раз на этапе компиляции, сразу выдаёт ошибки в синтаксисе если они есть, и генерирует оптимальный кодЗачем делать хуже, если можно сделать лучше?
> Потому что printf и прочие при каждом вызове заново интерпретируют строку форматирования,
> что медленноНа самом деле GCC разбирает большинство вариантов использования на этапе трансляции, заменяя на puts (или даже write, но не суть) и т.п.
>> Потому что printf и прочие при каждом вызове заново интерпретируют строку форматирования,
>> что медленно
> На самом деле GCC разбирает большинство вариантов использования на этапе трансляции, заменяя
> на puts (или даже write, но не суть) и т.п.Как минимум не по дефолту.
https://godbolt.org/z/YxG46dKWK
>>> Потому что printf и прочие при каждом вызове заново интерпретируют строку форматирования,
>>> что медленно
>> На самом деле GCC разбирает большинство вариантов использования на этапе трансляции, заменяя
>> на puts (или даже write, но не суть) и т.п.
> Как минимум не по дефолту.
> https://godbolt.org/z/YxG46dKWK"%d + %d = %d" - один из спецификаторов, а не большинство.
> "%d + %d = %d" - один из спецификаторов, а не большинство.
> https://www.ciselant.de/projects/gcc_printf/gcc_printf.htmlСогласно документу, упомянутые тобой "большинство спецификаторов" = строки, РАВНЫЕ
"%s\n"
"%c"
""
<Строка из одного символа>
<Константная строка кончающаяся на \n>И где ж это "большинство вариантов использования", если оно не поддерживает ни один спецификаторов в составе строки, зачем в таком случае нужен printf?)
Прямо говоря - оно может заменить один вызов printf на один вызов puts/putchar в тривиальных случаях.
>> "%d + %d = %d" - один из спецификаторов, а не большинство.
>> https://www.ciselant.de/projects/gcc_printf/gcc_printf.html
> Согласно документу, упомянутые тобой "большинство спецификаторов"Не стоит приписывать мне ложные заявления. Цитирую себя, #423: "GCC разбирает большинство вариантов использования на этапе трансляции".
> = строки, РАВНЫЕ
> "%s\n"
> "%c"
> ""
> <Строка из одного символа>
> <Константная строка кончающаяся на \n>
> И где ж это "большинство вариантов использования", если оно не поддерживает ни
> один спецификаторов в составе строки, зачем в таком случае нужен printf?)Большинство вариантов использования функции printf() находится в бесконечном количестве программ "Hello, World!" (только я их написал штук 30 или 40), а не в том единичном надуманном примере.
А что такое спецификатор формата, написано в стандарте, советую его почитать, если подмена тезиса произошла не намеренно, а по недоразумению.
> Прямо говоря - оно может заменить один вызов printf на один вызов
> puts/putchar в тривиальных случаях.Если же ещё прямее - я намеренно использую такие формулировки, что бы отличить людей вдумчивых от желающих тупо поспорить. Правильно было бы попросить у меня статистику об использовании printf, но сейчас уже слишком поздно.
в Си макросы как-то без восклицательных знаков справляются. Может для каждой синтаксической конструкции по спец символу дописивать?
> в Си макросы как-то без восклицательных знаков справляются.Вот смотришь ты на код на сишки, и можешь сразу ответить "это макрос или нет?"
А "спец символ" сразу позволяет это понять в расте.
Да, традиционно они пишутся капсом. В противном случае есть LSP.
>традиционно они пишутся капсомТо есть оставлена возможность совершения ошибки на ровном месте (вспомнить знаменитые C-макросы min и max). А в Rust нет такой возможности, что прекрасно. Не вижу проблемы в восклицательном знаке; можно произносить "про себя" println! как "принтлн-макро".
> А в Rust нет такой возможности, что прекрасноВам лишь бы запретить
>> А в Rust нет такой возможности, что прекрасно
> Вам лишь бы запретитьПрикинь, жизнь человека наверное наполовину (хотя мне кажется больше) состоит из запретов.
Нельзя ссать в лифте, нельзя приставать и делать определенные действия сексуального характера, если человек против.
Нельзя продавать г̶о̶л̶у̶б̶ц̶ы̶ ̶с̶ ̶г̶о̶в̶н̶о̶м̶ испорченную еду, бегать на красный свет или ехать по встречке со скорость в 200км/ч (вообще ПДД это сплошные запреты! ДОКОЛЕ!).И знаешь, я в общем-то не против)
> Да, традиционно они пишутся капсом."Просто офигенное решение, если я правильно понял. Надёжное, как швейцарские часы!"
А как отличить константу от макроса без параметров?
А если в конкретном проекте нетрадиционные традиции?
> в Си макросы… такое убожество, что непонятно, почему они вообще макросами называются.
Да нормальный синтаксис, что тебе не нравится?
```
unsafe {
fn main() {
std::::::input::::::output::::::stdout::::::<&'static mut dyn impl Box<StdOut>>!!!!!("helo world")??.unwrap()?.unwrap()???.unwrap()?;
}
}
```
> Да нормальный синтаксис, что тебе не нравится?
> ```
> unsafe {
> fn main() {
> std::::::input::::::output::::::stdout::::::<&'static mut dyn impl Box<StdOut>>!!!!!("helo
> world")??.unwrap()?.unwrap()???.unwrap()?;
> }
> }
> ```Ахаха... Спасибо большое, поднял настроение!!!
Ну, умственно отсталые шуточки это всегда популярно.
Ты не думал заняться стендапом?Но синтаксис раста осиливают даже гошники, а вот сишники нет.
Это печально, но закономерно.
Ты сначала ник свой подправь, "гений" долбаный, потом уже про юмор будешь разглагольствовать...
Помнится пытался носую mesa сеобрать для дебиан, Одна из реализаций написана на rust в и требует либу поновей а та стебует компилятор раста новый, он в свою очередь требует пересобрать пол системы... С плюсамы такой хрени почему-то не случается LLvm 10 летней свежести прекрасно справляется, но растоманам надо все новое... и пофиг тчо его еще нет в дистрибутивах нормальных.
> С плюсамы такой хрени почему-то не случаетсяМожет потому, что, во-первых, новые версии для Плюсов выходят раз в несколько лет. А во-вторых, потому, что далеко не все компиляторы Плюсов сразу могут поддерживать новые стандарты?
В Rust же версии выходят раз в полтора месяца (примерно, точный период не помню). И там с компилятором проблем, подобных Плюсам, нет.
Может потому на расте так и не написали ничего путного, ибо нельзя что-то серьезное поддерживать с таким подходом...
Дай определение слову "путное" для начала, чтобы продолжать с тобой дискуссию.А так, примером продуктов на Rust - предостаточно уже. Это тебе и Дискорд, и Дропбокс, и часть ОС Android, и прокси Клаудфлэр, и утилитки, подобные ripgrep.
о да... наверное самая самая важная часть андройда? или как обычно - давайте впендюрим запасное колесо на расте - вроде ехать не мешает и растоманы довольны...
> о да... наверное самая самая важная часть андройда?Сложно сказать какая часть ОСи самая важная.
Но те, про которые речь, имеют повышенные требования к надежности.
Это напр. Android Keystore 2
android.googlesource.com/platform/system/security/+/refs/heads/main/keystore2/src/Bluetooth стек, еще не весь переписан, но там работа еще в процессе
android.googlesource.com/platform/packages/modules/Bluetooth/+/refs/heads/main/system/rust/
android.googlesource.com/platform/packages/modules/Bluetooth/+/refs/heads/main/system/gd/rust/Это для тебя запасное колесо? Или как?
Одно никто толком не успел использовать, второе вообще не доделаночто-то мне это напоминает... ах да... другой проект на р :)
https://www.linux.org.ru/news/opensource/12361609?cid=12362052
То есть, по поводу остальных перечисленных продуктов (кроме Андроида) у тебя вопросов нет? Вот и отлично.
Есть :)Но ведь также как с ведройдом сольетесь... не интересно...
clang, gcc и msvc поддерживают, для специфических компиляторов под микрухи, вы и так не будете использовать 80% функциональности и там вам компилятор урежут до с++11 или до с++98 (ну а под Rust в особых случаях может вообще не быть компилятора, окэй?).
Каждый месяц выпускают новые вырсии, хочется спросить, а слабо сразу нормально выпустить? Ну не шлепать каждый месяц, а лет 5, а лучше все 10, работать над архитектурой и чтоб все к релизу стабильно было
Раз в 5 лет, раз в 10 лет - это для старых пердунов. Да и не модно так нынче. Если хочется прогресса, то надо выпускать новую версию каждый месяц!
А теперь давайте подумаем: если каждый месяц (а лучше каждый день) выпускать новую версию с кучей новых фич, что станет с этим языком через 5 лет? А каким он будет через 10 лет? А сколько книжных страниц будет занимать полное описание такого языка?Учитывая, что объём памяти человека не меняется уже 20 тысяч лет, сколько времени понадобится программисту через 10 лет чтобы прочитать и освоить полное описание Rusta?
Люди хотят повторить ошибку плюсов.
Ошибка плюсов что в них слишком мало фич и некоторые недостаточно продуманы
>А теперь давайте подумаем: если каждый месяц (а лучше каждый день) выпускать новую версию с кучей новых фич, что станет с этим языком через 5 лет? А каким он будет через 10 лет? А сколько книжных страниц будет занимать полное описание такого языка?Мне кажется, ты не совсем понимаешь, как развивается Rust. Концептуально новых фич (вроде async или появившихся не так давно GAT) добавляется совсем немного. Даже соседние редакции (2018 -> 2021) не означают революции, так что программист переходит с одной на другую почти без усилий. Тот список изменений, который публикуется с каждой новой версией, как правило, представляет расширение действия уже имеющихся фич, багфиксы и т.п. Это, на мой взгляд, означает, что язык получился весьма удачным.
> А теперь давайте подумаем: если каждый месяц (а лучше каждый день) выпускать новую версию с кучей новых фич, что станет с этим языком через 5 лет? А каким он будет через 10 лет? А сколько книжных страниц будет занимать полное описание такого языка?
>
> Учитывая, что объём памяти человека не меняется уже 20 тысяч лет, сколько времени понадобится программисту через 10 лет чтобы прочитать и освоить полное описание Rusta?Ты наверное никогда не программировал и не знаешь что во-первых, не обязательно всё это осваивать чтобы писать программы, при этом даже качественные, во-вторых, полное описание избыточно относительно основных концепций, которые даже с ростом спеки остаются константного размера? Например, я никогда не пользовался HastSet, но знаю что у контейнера есть iter(), а у итератора есть collect(). Значит пусть в следующей версии появится хоть 100500 новых контейнеров, я знаю как их друг в друга конвертировать и как по ним итерироваться, и вообще всё что можно делать с коллекциями. На самом деле, язык наоборот идёт к консистентности - например я знаю что у итератора должен быть collect_into(). Но в языке его ещё нет, но будет.
>слабо сразу нормально выпустить?Что за идиотская претензия? Любой программист знает, что лучше всего разрабатывать систему эволюционно, небольшими контролируемыми изменениями.
Раст критикуют в основном не программисты, люди не из отрасли. Поэтому и претензии идиотские - нумерация версий, синтаксис и тп
внезапно... в следующий раз когда ты придешь в кафешку и тебя принесут какую-нибудь хрень - не смей критиковать блюдо - ты же не повар и не из представителей общепита!
> внезапно... в следующий раз когда ты придешь в кафешку и тебя принесут
> какую-нибудь хрень - не смей критиковать блюдо - ты же не
> повар и не из представителей общепита!Вообще мимо. Ты собираешься придти в кафешку, завалиться на кухную и начать критиковать повара что у него ̶п̶р̶о̶б̶е̶л̶ы̶,̶ ̶а̶ ̶н̶е̶ ̶т̶а̶б̶ы̶ сковордки не от большей к меньшей висят. Хотя ему так удобнее.
И если оно никак не влияет на результат, то критиковать это у тебя ну... маловато прав - ты вообще мимокрокодил какой-то.А вот когда оно влияет на готовое блюдо - ты критиковать имеешь полное право.
И если у повара грязная кухня, в полу куча дыр из которых лезут крысы и тараканы, со сковородок давно облезло покрытие и к ним все пригорает, а суп он мешает ершиком от унитаза, просто потому что... то ты в полном праве говорить - "ваша еда ##### в том числе потому что ваша кухня #####"Точно также как несишники имеют право критиковать сишников за бесконечные однотипные CVE, которые повторяются десятки лет и в которых сишники не видят никакой проблемы. Потому что эта "кухня" очень сильно влияет на финальный продукт.
ой...это вроде не специализированный растовский ресурс для фанбоев, почему же здесь я не имеею полного права обсуждать раст по твоему мнению?
Если ты не программист - не имеешь. Я же не прихожу на форум сантехников с претензией вы всё неправильно делаете. Это как минимум глупо и невежливо. Почему в айти должно быть по-другому? Почему каждый подкроватник должен иметь возможность высказать свое мнение не по своей сфере? Иди на форум убунты или чего у тебя там и обсуждай настройку нжинкса для себя и своей кошки.
Ну почему. Ты приходишь на форум сантехников жаловаться на плохие результаты и обзываешь их нехорошими словами, умников хитрых таких. Это вполне уместно, если этого не делать, они будут и дальше творить что заходят, и никто из них не задумается, о том, какие поганые результаты являются итогом их труда. Это очень правильно и полезно для общества. Но ты конечно проглотишь, и это твоя персональная вина, что пострадает кто-то ещё.
Сантехников можно, а пограммистов нельзя!Это другое, понимать надо!
Есть два подхода к проектированию и разработке софта. Первая модель - waterfall - хороша, когда всё (или почти всё) известно на старте. И тогда почти всегда можно "сразу" сделать нормально. При этом, если требования вдруг как-то изменились, так, что спланированная архитектура уже не может им соответствовать, переделка влетает в немалую копеечку.Вторая модель - agile. Подразумевает под собой постоянные относительно короткие итерации при продвижении вперёд. Там сразу сделать хорошо невозможно в силу постоянно (часто) меняющихся требований, или неизвестных на старте требований.
Очевидно, что разработка Rust следует второй модели. Почему? Потому что разработчики находятся на терра инкогнита. То есть, в их случае невозможно предусмотреть заранее все возможные проблемы. Вот и движутся частыми итерациями, потихоньку осваивая предметную область.
Собственно, почти тот же подход мы можем наблюдать практически во всех сколь-либо современных языках программирования.
> Потому что разработчики находятся на терра инкогнитану да... это же первый язык пограммирования в мире... до этого не было вообще ничего, они пионеры первопроходцы...
> ну да... это же первый язык...... с попыткой расчета времен жизни на этапе компиляции.
По крайней мере, среди тех, кто вышел за пределы чьей-то дипломной работы.
И таки да, они сталкиваются с проблемами, которые никто раньше не решал.
Ахах, там ращёты лайфтаймов на уровне С++11.
Это только прикладные программы можно так разрабатывать. Дизайн языка должен быть с самого начала хорош. С языком не получится так: сделаем сначала дрянь, а потом потихонечку трансформируем её в конфету.
А какие у тебя примеры, как-либо подтверждающие твои слова? С питоном и додиезом же получилось, и это говорит об обратном.
> С питоном и додиезом же получилось, и это говорит об обратном.Потому 10 лет с Питон 2 переписывали на Питон 3, а джависты при необходимости берутся перевести с шарпа на свой за разумное время?
Примеры? Все хорошие языки с самого начала были хорошие, а с плохим дизайном как были плохие так и остались плохие.
Python и C# - как раз пример деградации. Изначально были хороши, а потом стали слишком сложные.
Плохой дизайн у стандартного Пролога и стандартного Паскаля (ISO Pascal и ISO Extended Pascal). Их никто не использует.
> Python и C# - как раз пример деградации. Изначально были хороши, а потом стали слишком сложные.В python новые конструкции в язык вводят раз в год от силы. Что там за последние лет 10 вообще было? async, match, f-строки, :=, positional-only args. Это всё. Даже изменения в 2->3 можно по пальцам двух рук пересчитать. Если ты не успеваешь за этим темпом, то это пример твоей дегрдации.
А с сишкой не получилось, как было 101 UB, так и осталось.
> Дизайн языка должен быть с самого начала хорошНе должен. Желательно, конечно, но всякое случается. Вот в Rust есть редакции на такие случаи. И они работают.
> Дизайн языка должен быть с самого начала хорош.Такого не бывает.
> С языком не получится так: сделаем сначала дрянь, а потом потихонечку трансформируем её в конфету.
Только так и получится, потому что какую бы конфету ты там не напроектировал, через 10 лет требования поменяются кардинально и она уже будет говном по определению. Поэтому всё что должно быть спроектировано в языке - грамотная политика поддержки и депрекаций, чтобы не тащить за собой полвека все изначально неудачные или ставшие неудачными решения, как плюсы, и не кидать всё сообщество полной потерей совместимости как питон.
Вторая "модель", совершенно внезапно - прямая противоположность waterfall - reverse engineering. Agile придумали неспособные комбинировать два основных подхода, кому важен не результат, а процесс.
Причём здесь reverse engineering? Какое он имеет отношение к созданию нового ПО?> Agile придумали неспособные комбинировать два основных подхода, кому важен не результат, а процесс.
Прям неспособные? Ты вот реально предвидеть на много лет вперёд? А ведь проектирование и реализация языка программирования - это многолетний проект. Я уж молчу про ПО для реального бизнеса, где обстоятельства меняются иной раз кардинально чуть ли не каждый месяц.
> Причём здесь reverse engineering? Какое он имеет отношение к созданию нового ПО?Такое же, как и инженерия в общем. Проектирование бывает "прямое" (в твоей терминологии - Waterfall) и "обратное". Новое требуется, когда старое не устраивает. Автор Rust взял части из OCaml, C++, чего-то то там ещё и слепил из них, что получилось - это обычная реверсинженерия, если ты не знал и путаешь с reverse code engineering. Потом подрихтовал дизайн сверху вниз, что бы стало красиво.
>> Agile придумали неспособные комбинировать два основных подхода, кому важен не результат, а процесс.
> Прям неспособные?Прямо. Инженеров же нет, есть какие-то бакалавры и магистры, не так ли?
> Ты вот реально предвидеть на много лет вперёд? А ведь
> проектирование и реализация языка программирования - это многолетний проект. Я уж
> молчу про ПО для реального бизнеса, где обстоятельства меняются иной раз
> кардинально чуть ли не каждый месяц.Обстоятельства могут и каждый день меняться, а допустимое время на адаптацию может составлять час. Циклы Agile пролетают как фанера над парижем.
> Автор Rust взял части из OCaml, C++, чего-то то там ещё и слепил из них, что получилось - это обычная реверсинженерия, если ты не знал и путаешь с reverse code engineering. Потом подрихтовал дизайн сверху вниз, что бы стало красиво.Т.е он не добавил новых идей?
Мне казалось что все началось таки с идеи, а потом обросло синтакисом который ему понравился.> Прямо. Инженеров же нет, есть какие-то бакалавры и магистры, не так ли?
Анал-итика уровня ПТУ животноводства.
Итеративная разработка применялась уже в 60х. А ты ее пропускаешь вспоминая только водопад.
То что старые идеи немного развили и завернули в более мягкую упаковку не делает их плохими.
В 90х уже был RAD, которые разработали где-то в 80х в ИБМ.
Всякие скрамы и агили появились попозже.
> Обстоятельства могут и каждый день меняться, а допустимое время на адаптацию может составлять час. Циклы Agile пролетают как фанера над парижем.А может не составлять) Может у тебя время на адаптацию 2 недели или месяц.
Я уже молчу что водопад точно так же пролетит, ибо за 2 часа можно только залепить баг.
>> Автор Rust взял части из OCaml, C++, чего-то то там ещё и слепил из них, что получилось - это обычная реверсинженерия, если ты не знал и путаешь с reverse code engineering. Потом подрихтовал дизайн сверху вниз, что бы стало красиво.
> Т.е он не добавил новых идей?
> Мне казалось что все началось таки с идеи, а потом обросло синтакисом
> который ему понравился.Попробуй заняться инженерным делом, если повезёт, поймёшь ошибки в своих рассуждениях.
>> Прямо. Инженеров же нет, есть какие-то бакалавры и магистры, не так ли?
> Анал-итика уровня ПТУ животноводства.
> Итеративная разработка применялась уже в 60х. А ты ее пропускаешь вспоминая только
> водопад.Цитирую себя, #284: "... комбинировать два основных подхода"
Как видно, пропустил ты, так что записываем и остальное в проекции.
> Попробуй заняться инженерным делом, если повезёт, поймёшь ошибки в своих рассуждениях.Это как раз тебе нужно сделать. Потому что кроме трепа тут ты ничего не демонстрируешь.
> Цитирую себя, #284: "... комбинировать два основных подхода"
> Как видно, пропустил ты, так что записываем и остальное в проекции.Не пропустил. Ты голословно утвержаешь, что "есть два основных", как обычно ничем не подтверждая свои слова. При этом на возражение ты пишешь "я же говорил" так, как будто твое утверждение верно.
И завязывай со своими навязчивыми идеями про проекции.
>> Попробуй заняться инженерным делом, если повезёт, поймёшь ошибки в своих рассуждениях.
> Это как раз тебе нужно сделать. Потому что кроме трепа тут ты
> ничего не демонстрируешь.Твой мозг уже на уровне рефлексов должен был сгенерировать мой ответ на подобный выпад: кому демонстрировать? Анониму?
>> Цитирую себя, #284: "... комбинировать два основных подхода"
>> Как видно, пропустил ты, так что записываем и остальное в проекции.
> Не пропустил. Ты голословно утвержаешь, что "есть два основных", как обычно ничем
> не подтверждая свои слова.Ты подтвердил это за меня, написав "итеративная разработка".
> Может у тебя время на адаптацию 2 недели или месяц.Видишь ли в чём дело. Для тебя это такой привычный манипулятивный убедительный приём, а для меня показатель - у тебя нет собственных случаев, о каких ты можешь сообщить. То есть ты не авторитет в вопросе и потому с тобой не интересно обсуждать, что там может быть у меня.
> Каждый месяц выпускают новые вырсии, хочется спросить, а слабо сразу нормально выпустить? Ну не шлепать каждый месяц, а лет 5, а лучше все 10, работать над архитектурой и чтоб все к релизу стабильно былоЭто невозможно. Тогда этот rust никогда не выпустят, а к тому моменту когда должны были выпустить, все будут уже 9 лет писать на hrust который эти 10 лет каждый месяц выпускал новые версии, гармонично развивался, обрастал сообществом, тулингом и библиотеками.
Вам лично чем-то мешает что язык развивается?
А вот интересный момент. Почему разработчики RUST решили сделать такой "новый" синтаксис, вместо того, чтобы взять тот же С++ (или С, если так нравиться) и, оставив годные части, исключить то, что было "унаследованно" из старых стандартов и реализаций языка?Т.е. сделать формально несовместимый язык, но - легко осваиваемый программистами?
А почему разработчики RUST должны тырить чужие синтаксисы? Ей богу, ты рассуждаешь как ворюга! Их язык как хотят так и делают.
Для того, чтобы Rust не был похож ни на какой язык.
Это была ошибка, что Java сделали похожим на C++, из-за этого эти языки путаются в голове (у меня, по крайней мере). Пишешь на Java, а руки непроизвольно пишут на C++.
Поэтому Python такой популярный, что не похож ни на какой язык. Ничего не путается.
Почему ни на какой? На Icon похож.
Но Icon же практически никто не знает. Поэтому не похож.
В синтаксисе раста нет НИЧЕГО что принципиально отличалось бы от плюсового синтаксиса в их общем подмножестве языковых конструкций. А все непринципиальные различия - в сторону упрощения. Как-то оператор . вместо . и ->, || вместо [](){}.
В Rust очень раздражающая тема - это время жизни. То, что C++ делает сам, пусть иногда по хитрым правилам, в Rust запросто может появиться ситуация, когда ваша программа не скомпилируется из-за того, что где-то вы забыли ' указать. Это абсолютно уродливая методология как при написании, так и чтении кода. Притом, что Rust не предлагает вообще ничего нового, а 80% функционала уже было в C++11 (умные указатели, парадигма владения ресурсами, семантика перемещения) подкрепив всё это санитайзерами и строгой компиляцией в C++11 вообще не останется пространства для ошибок (разве что допустить их специально), а от семантических ошибок не застрахован никто. При этом компилятор C++ не делает вас своим рабом.
Интересно, а Rust уже достиг проблемы Ada? Это когда в язык и стандартные библиотеки нахреначили столько разных фич, что никто из программистов не использует их все. И даже половину.А значит, возникают проблемы: код одного программиста с трудом воспринимается другим программистом, т.к. они используют разный набор возможностей языка?
С моей точки зрения, современный С++ к этому пришёл где-то начиная с 14 стандарта.
А Rust похоже изначально именно так и проектировался.
Rust ещё не дошёл, но это вопрос времени.
Нельзя объять необъятное - учила история с PL/1. PL/1 тоже настолько разросся, что никто не знал его полностью, а в каждой программисткой компании была целая группа экспертов по PL/1: один знал эту фичу в языке, другой - другую, третий - ещё другую фичу и т.д.
Кончилось тем , что все плюнули на этот PL/1 и перешли на простой C, который один человек может выучить и помнить.
А затем Си и C++ разбухли до такой степени, что количество страниц в спецификации ISO либо сравнялось с PL/1, либо превзошло. И ведь ими всё ещё пользуются! И будут пользоваться ещё несколько десятилетий! Никто не перепишет Linux, GCC, Clang и кучу других продуктов с си и плюсов.
Смотрю на пугающе толстую книгу Страуструпа "Язык C++", как-то сразу грустно становится
Книжка и книжка, привычка читать снимает страх перед объемом. Вот по работе в одной из систем описание аналитической подсистемы порядка 1500 листов и это подсистема, которая за аналитические функции отвечает, а есть еще системные, интеграции, интерфейсные и т.д. Причем в описании кода считай нет, там диаграммы, алгоритмы, пояснения. Так, что С++ весьма лаконичен.
Вообще не страшно. Особенно ещё и потому, что её не обязательно читать полностью, а также то, что там довольно просто объясняются принципы языка с примерами типичного использования (т.е. вы сразу поймёте как это работает и сможете безопасно применить на практике). На самом деле в C++ страшнее лезть в неизведанные земли отходя от концепций "типичного" использования некоторых инструментов (например, это касается R-value ссылок). В Rust типичная история, это когда вы берёте пример, который в одних ситуациях работает, а в других - нет. А дело вскроется, что где-то вы не учли время жизни объекта и всё пошло наперекосяк. Часто проблему можно исправить, но это начинает походить на шаманизм, когда вы выполняете действия, которые язык должен делать сам.
Ложь про C. Язык C по прежнему очень прост. В С11 добавили НЕОБЯЗАТЕЛЬНУЮ поддержку атомарных типов (для упрощения многопоточности), простенькую либу (тоже необязательную), которая фактически копирует pthread и отменили кое-какие правила стандарта с99. Т.е. в переводе означает, что вы можете читать книгу по c89 и всё освоите, останется лишь изучить теорию параллелизма и многопоточности, но эту теорию для любого языка придётся учить и она везде похожа.
На C++ всё хорошо тем, что он развивается модульно, и никто не заставляет вас переходить на новые парадигмы или наоборот использовать старые, это тот язык, на котором можно начать писать в ВУЗе со 2-го курса, что-то доучить на 1-й работе, и это всё происходит почти автоматически, т.к. концепции хорошо документированы и по ним много реальных примеров и промышленного кода, который прост как палка и зарефакторен до блеска.
Миф "Си и C++ разбухли" я здесь старательно поддерживаю фразами вида "кто читал 2000 страниц стандарта?" Они, естественно, их не читали, а потому понимают по-своему. :)
> Rust ещё не дошёл, но это вопрос времени.Так про любой язык программирования можно сказать, который более-менее активно развивается. Почему? Потому что со временем появляются какие-то ситуации, которые предусмотреть ранее было невозможно. Или какие-то программисты захотели новых функциональных возможностей. И всё это закрывается новым синтаксисом и/или семантикой.
А потом появляется новый язык, который исправляет недостатки предыдущего. И так, похоже, будет продолжаться до тех пор, пока компьютеры не научатся сначала полноценно читать мысли людей, а потом и выполнять все их хотелки. Собственно, подвижки в эту сторону уже начались, хотя до желаемого результата пока далеко.
>С моей точки зрения, современный С++ к этому пришёл где-то начиная с 14 стандарта.C++ 98 уже вполне успешно этого достиг, были его подварианты "Си с классами", "не используем stl", "варианты завязанные на GUI фреймворки MFC, Qt, VCL (c++ builder)", "укушен Александреску" и т.п. .
> С моей точки зрения, современный С++ к этому пришёл где-то начиная с 14 стандарта.
>
> А Rust похоже изначально именно так и проектировался.Такое же ощущение. Но только грустить тут не о чем, потому что это неизбежно. И у rust тут ситуация несравнимо лучше плюсов, отягощённых легаси с одной стороны, неадекватным лебедь-рак-щука комитетом с другой, и двумя декадами стаграции с третьей.
У Rust есть классный встроенный линтер, который тебе все новые удобные фичи наглядно покажет, после него код становится совсем приятным
Не все ещё знакомы с языком Rust (наверное), поэтому перечислю его достоинства и недостатки. Достоинств два. Первое - высокая скорость работы программ на нём. Rust - самый высокоскоростной язык высокого уровня, то есть быстрее C++, Ada, Delphi, Free pascal и т.д.
Скорость практически как у C.
Второе достоинство - надёжность. Даже у полных раздолбаев программы на Ruste, на удивление, не падают.
Недостатков тоже два. За высокую скорость и надёжность надо платить. Платить приходится неудобством разработки и ограничением области применения.
> Недостатков тоже два. За высокую скорость и надёжность надо платить. Платить приходится
> неудобством разработки и ограничением области применения.Хм.. удобство-неудобство это немного вусовщина.
У меня был коллега из соседней команды, которому было ок писать JS код прямо в блокноте.
Синтаксис это тоже дело привычки, писали же люди на лиспе и фортране))
Ну и для программиста должно быть нормой относительно быстро обучаться чему-то новому.Ограничение области применения..
Тут соглашусь, но с оговоркой - у перечисленных языков тоже область ограниченная.
Никто не будет писать сайт на C++ или Ada.
Мало кто будет писать прикладные программы на чистой СИшке, скорее возьмут плюсы.
Мало кто будет вообще что-то пистаь на делфи и тем более на паскале)Так что каждому языку - своя ниша.
> Даже у полных раздолбаев программы на Ruste, на удивление, не падаютNone.unwrap() - "не падает"? Открой любой исходный код на расте, там всё на unwrap-ах. Всё это может не падать только если где-то в main паники перехватываются, иначе время от времени будет неизбежно падать. В чём тогда эта ваша "надёжность" заключается?
В хорошем Rust-коде не должно быть голых unwrap, вместо них expect. И только в тех случаях, когда паника — лучшая реакция на конкретное состояние (как правило — "ошибки, которые не должны происходить"). В таких случаях обычно лучше пораньше упасть, чем продолжать работу в некорректном состоянии. Надёжность — больше, чем способность программы дольше "продержаться" :-).
expect от unwrap ничем не отличается кроме наличия сообщения - разница чисто косметическая, а так это паника в любом случае. Только какие претензии могут быть к панике, когда данные невалидны? Звиняй, если 1/0 в целых числах, то это не 1, не 0, не 42, не <type>::max(), не random, не ввести значение вместо 0. Это некорректная операция, поэтому либо паника, либо возврат ошибки, поэтому либо unwrap/expect, либо ?, другого не дано. И конечно rust код будеи пестрить этими unwrap/expect и ?, потому что там каждая некорректная операция проверяется. Не может там nullptr неожиданно вернуться, или число переполниться.
> None.unwrap() - "не падает"? Открой любой исходный код на расте, там всё на unwrap-ах.В том что оно падает, представь себе. Потому что если оно не будет падать, оно будет генерировать некорректные данные, корраптить существующие, или падать в другом месте уже с SEGV, предварительно нагеренив некорректных и покорраптив существующих данных, и это ещё придётся с другом отлавливать. В плюсах вместо None.unwrap() будет *(sometype*)(nullptr_t).
Ты что думаешь, там эти unwrap'ы на пустом месте берутся? Они берутся там где операция может завершиться неуспешно. Их могло бы быть только если неуспешный результат тихо заметается под ковёр, как в C++ переполнение (в том числе и беззнаковое, которое хоть и не UB, но ожидаемо и допустимо только в редких случаях которые должны быть обозначены явно).
> Всё это может не падать только если где-то в main паники перехватываются, иначе время от времени будет неизбежно падать. В чём тогда эта ваша "надёжность" заключается?
А это ничем не отличается от любого другого языка. Так и в плосах, и в питоне большинство приложений не ловят исключений. Для cli утилиты, например, это совершенно нормально - потому что она либо выполняется успешно без ошибок, либо падает при любой возможности. Ловля исключений появляется там где можно что-то поретраить, там же она появляется и в rust.
Если выкинуть исключение и не перехватить его - программа упадёт.
Открытие века!Уровень экспертов достиг подвала, но экспертов не остановить...
Так C++ и не преподносится как "safe" язык, в этом и разница. Зачем обманывать?
Если для тебя "безопасность" - означает что программа никогда не упадёт, то у меня плохие новости: безопасность в расте совсем про другое. Паника - это безопасная операция.
> Если для тебя "безопасность" - означает что программа никогда не упадёт, то
> у меня плохие новости: безопасность в расте совсем про другое. Паника
> - это безопасная операция.Безопасная атака вида "отказ в обслуживании"?
> Безопасная атака вида "отказ в обслуживании"?Потрясающее умение складывать слова в бессмысленные предложения.
Как, на уровне языка, ты собираешься защищаться от dos'а?
>> Безопасная атака вида "отказ в обслуживании"?
> Потрясающее умение складывать слова в бессмысленные предложения.Да, не могу уловить смысл.
> Как, на уровне языка, ты собираешься защищаться от dos'а?
Просто не выпускать компилятор для DOS. WSL2 хватит всем.
> Так C++ и не преподносится как "safe" язык, в этом и разница.
> Зачем обманывать?Обманывать кого? Тех кто решил, что безопасность в расте относится ко всему что можно придумать? Это личные проблемы этих фантазёров.
> Rust - самый высокоскоростной язык высокого уровняОсобенно когда половина кода это обёртки по типу `Rc<RefCell<_>>` или `Arc<_>` и куча `.clone()` чтобы хоть как-то обойти чеккер и уже начать писать что-то полезное. Писать действительно оптимальный код уровня Си на расте практически невозможно, так как кучу лайфтаймов пронести через всю программу нереально.
Когда хочется вечных переменных, то это процедурное мышление. А функциональное - получил данные, вычислил, отдал, очистил всё.
> чтобы хоть как-то обойти чеккер и уже начать писать что-то полезноеЕсли не привык задумываться на безопасностью своего кода, поначалу будет больно, конечно. Но потом адаптируешься, и уже перестаёшь это замечать.
> Писать действительно оптимальный код уровня Си на расте практически невозможно, так как кучу лайфтаймов пронести через всю программу нереально.
Но опыт других людей показывает, что ты не прав. Взять тех же Гугловцев или программистов из Клаудфлэр. Их опыт показывает, что код получается и более быстрый, и более безопасный в итоге. Впрочем, может у тебя другое понимание "оптимальности".
> Особенно когда половина кода это обёртки по типу `Rc<RefCell<_>>` или `Arc<_>` и куча `.clone()` чтобы хоть как-то обойти чеккер и уже начать писать что-то полезное.Полезное? А ты уверен что тот дырявый код, который не пропускает черкер это что-то полезное?
> Писать действительно оптимальный код уровня Си на расте практически
> невозможно, так как кучу лайфтаймов пронести через всю программу нереально.Конечно, лучше побыстрячку наовнокодить кучу дырок и CVE, главное быстро!
> Особенно когда половина кода это обёртки по типу `Rc<RefCell<_>>` или `Arc<_>` и куча `.clone()` чтобы хоть как-то обойти чеккер и уже начать писать что-то полезное. Писать действительно оптимальный код уровня Си на расте практически невозможноПрактика показывает что это отчасти правда, но имеет место только в небольших функция реализующих нетривиальные алгоритмы, например встречались построить дерево из потока записей с заданным уровнем вложенности (там нужен mutable стек текущей ветки из-за чего получаем двойной mutable borrow), и мутирующий обход списка элементов ссылающихся друг на друга, в процессе которого нужен был ещё один мутирующий обход по связям). В обоих случаях получилось переписать даже не прибегая к RefCell, при этом всегда был вариант с RefCell и на совсем крайний случай, unsafe и сырые указатели. Последнее позволяет писать код полностью эквивалентный "оптимальному оду уровня C".
Это вообще типичная проблема неопытных в rust люлей: первые ожидают от последнего решения всех проблем программирования. Я понимаю что хотелось бы, но увы, мы живём в неидеальном мире, rust далеко не завершён (см. например продление ссылок в, емнип, 1.79), а некоторые вещи неразрешимы вовсе (см. проблемма останова). Важно то что rust никаких возможностей не забирает - ты можешь писать в точности как на C где это нужно, а предоставляет беспрецедентный их набор, потому что в 98% остального где не нужны такие сложности тебе гарантируется отсутствие UB, да и те 2% ты можешь писать безопасно с рантайм костом на RefCell'ах, а в каких-то случаях и на чистом расте.
> так как кучу лайфтаймов пронести через всю программу нереально.
Что это вообще значит? Лайфтаймы проносятся вместе с ссылками через функции которые их возвращают и структуры где они хранятся, нет никаких "через всю программу". Нет и не может быть с ними никаких проблем. Если ты этого ещё не понял, задумайся что точно такие же лайфтаймы есть и C, только там от тебя их скрывают и никто тебе не скажет что ты возвращаещь ссылку на локальную переменную или освобождённую память.
Бред. В типовых задачах в 2 раза медленнее Си.
У тебя, конечно, и доказательства есть?
После обкладывания кода на С кучей обёрток и проверок для устранения возможностей выстрелить в лицо, прыткость С убавляется, а сложность поддержки увеличивается.
> Rust - самый высокоскоростной язык высокого уровня, то есть быстрее C++, Ada, Delphi, Free pascal и т.д. Скорость практически как у C.Это бред, конечно, языки по скорости не сравнивают. Можно сравнивать компиляторы, и в рамках llvm, а это c, c++ и rust, скорость логически идентичных программ будет равна. Нет в C ничего, что магически ускоряло бы код.
>Нет в C ничего, что магически ускоряло бы кодЧитал в разных популярных статьях, что некоторые компиляторы C и C++ действительно достигают лучшей производительности благодаря тому, что производят оптимизации на основе неопределённого поведения.
> Читал в разных популярных статьях, что некоторые компиляторы C и C++ действительно достигают лучшей производительности благодаря тому, что производят оптимизации на основе неопределённого поведения.Такого же UB можно добиться и в rust, только это нужно делать явно, для этого есть всякие unchecked_*, unsafe{} и прочая. И это правильно, потому что должно быть безопасно по умолчанию, и максимально явно, когда небезопасно.
Вот такой пример мы буквально на прошлой неделе разбирали со студентами (код берёт цифру полученную с numpad и транстирует её в альтернтивную функцию клавиши которая включается по numlock):
```rust
let num_key: u32 = read_numpad(); // возвращает число от 0 до 9
let numlock_key = match num_key {
0 => Some(Ins),
1 => Some(End),
2 => Some(Down),
3 => Some(PgDn),
4 => Some(Left),
5 => None,
6 => Some(Right),
7 => Some(Home),
8 => Some(Up),
9 => Some(PgUp),
10.. => //???
};
```пользуясь случаем отмечу крутость match, которая позволяет гарантировать что все варианты обработаны, при том что в C++ можно только warning (да, можно `-Werror`, но это надо не забыть) и то только для `enum class`. При этом fallback можно сделать не просто `_`, а `10..`, что не позволит пропустить один из 10 вариантов.
Возвращаясь к оптимизациям, что написать в fallback ветке, если мы считаем что не можем получить ничего кроме 0..9 (ну и нам очень важна тут производительность)?
Можно написать `unreachable!()`. И это safe default. При этом сгенерируется примерно такой код:
```
ЕСЛИ num_key > 9
ПАНИКА
ИНАЧЕ
ПОЛОЖИТЬ В numlock_key ЗНАЧЕНИЕ ИЗ ТАБЛИЦЫ ИЗ 10 ЭЛЕМЕНТОВ ПО КЛЮЧУ num_key.
```Что позволяет сделать rust? Написать вместо `unreachable!()` `std::hint::unreachable_unchecked()`. Это вот то самое UB. Компилятор считает что оно никогда не происходит, и генерирует более оптимальный код:
```
ПОЛОЖИТЬ В numlock_key ЗНАЧЕНИЕ ИЗ ТАБЛИЦЫ ИЗ 10 ЭЛЕМЕНТОВ ПО КЛЮЧУ num_key.
```Это отлично демонстрирует и оптимизации связанные с UB, и его опасность (подумайте что будет когда в num_key таки окажется 11), а также гибкость и мощность rust в работе с ним.
И таких инструментов в rust широчайший набор, и он позволяет в том числе код оптимальнее C, потому что в последнем очень много случаев где считается что полагаться на UB небезопасно, и возможность оптимизации упускается. Rust же позволяет
- выразить невозможные ситуации явно, что открывает больше возможностей для оптимизации.
- имеет безопасное поведение по умолчанию, причём это касается не только UB, но и определённого, но обычно нежелательного поведения - например, беззнакового переполнения.
- имеет возможность явно задать поведение (overflowing_{add,...}, saturating_{add,...}), причем симметрично для знаковых и беззнаковых типов.PS. Кстати, правильный ответ на вопрос про fallback ветку = `debug_assert!()` + `unreachable_unchecked()`, что позволит ловить проблему в debug и даст оптимизацию в release.
Мне кажется, если вы напишете книжку про тонкости программирования на Rust, то будет хороший спрос на неё. Если надо проспонсировать написание, то этот вопрос, в принципе, решаемый.
Но книга уже написана https://www.rust-lang.org/learn[сообщение отредактировано модератором]
Было очень познавательно, спасибо!> на прошлой неделе разбирали со студентами
А у вас нет видео лекций или статей на каких-то ресурсах?
>Это бред, конечно, языки по скорости не сравниваютСравнивают
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
>> Это бред, конечно, языки по скорости не сравнивают
> СравниваютНет уж, вы меня полностью процитируйте:
>> Можно сравнивать компиляторы, и в рамках llvm, а это c, c++ и rust, скорость логически идентичных программ будет равна. Нет в C ничего, что магически ускоряло бы код.
И да, там сходу видно что сравнивают компиляторы, например llvm для rust и gcc для C. Будете спорить что если для паскаля вместо поделки FPC написать фронтэнд для llvm то он будет отличаться по скорости от C?
И ни слова о том, сколько проблем и багов у пакетов с этой 1.80. Ох уж эта хвалёная растовая совместимость.
И сколько же?С совместимостью всё прекрасно, Rust 1.80 успешно собирает хоть Rust 1.0 программы, за SemVer-совместимостью следят.
Более того, есть специальный тул [1], который при потенциально масштабных изменениях в компиляторе/std пересобирает огромную кучу либ и программ с crates.io и GitHub'а, просто чтобы убедиться, что нет регрессий.
Разумеется, можно откопать конкретные проблемные API, которые со временем задепрекейтили, как например mem::uninitialized [2], но даже для них сохраняется совместимость (несмотря на то, что уже есть правильное API [3] для этого).
Отвечая на вопрос сколько, отвечу честно, что больше нуля, и вполне себе возникла регрессия [4], проявляющаяся в том, что специфическая версия конкретной библиотеки перестала собираться. К сожалению, и такое бывает: причина в том, что type inference не всегда может отработать однозначно, и порой добавление реализации чего-то убирает эту однозначность, что приводит к ошибке (что явно приятнее, чем непредсказуемое поведение). Но даже тут инструменты языка позволяют решить супер-специфическую проблему:
1. Проблема в библиотеке исправлена в следующей патч-версии;
2. Даже если бы не была исправлена, из коробки есть инструмент, чтобы пропатчить код чужой библиотеки [5] при локальной сборке.(Человеческие )ошибки есть везде, и тут за этим хотя бы следят и оперативно исправляют подобное или дают простой инструмент для их исправления.
[1]: https://github.com/rust-lang/crater
[2]: https://doc.rust-lang.org/stable/core/mem/fn.uninitialized.html
[3]: https://doc.rust-lang.org/stable/core/mem/union.MaybeUninit....
[4]: https://github.com/rust-lang/rust/issues/127343
[5]: https://doc.rust-lang.org/cargo/reference/overriding-depende...
Похоже, не так прекрасно https://github.com/gentoo/gentoo/pull/37727
Про проблему с крейтом time я как раз выше написал (это то, что про type inference).То же, что ниже:
> One of the new features of Rust 1.80 is that it validates feature flags. I see another build failure in bottom that may be due to this
Это то, что компилятор научился ловить багу с `cfg` (суть баги, которую научился обнаруживать компилятор: кто-то описывал условную компиляцию по невозможной фиче).
На самом деле, для меня тоже странно, что эту проверку [1] включили в рамках релиза (1.80) а не edition'а (2024 скоро будет), и я тут также на стороне мейнтейнеров пакетов, но полагаю, что найдут способ разрешить проблему (тут снова работает подход с тем, что если возможно -- лучше обновить пакет, а если нет, то просто оверрайднуть его на свою фикснутую версию).
> И ни слова о том, сколько проблем и багов у пакетов с этой 1.80.Ни одного?
> Ох уж эта хвалёная растовая совместимость.
Ну хвалёная - не хвалёная, а среди всех популярных языков она лучшая. Языки без пакетного менеджера типа C и C++ он уделывает его наличием, из чего вытекает явная возможность использовать любые явно заданные версии зависимостей. А среди языков с ПМ он единственный кто явно постулирует semver для модулей. Сам язык совместимость не ломает с первой версии. В сумме я даже не представляю как на современном уровне развития технологий обеспечить лучшую поддержку обратной совместимости. Разве что на уровне пакетного репозитория автоматически проверять совместимость API, но это пока отдалённое будущее, и всех проблем всё равно не решит, потому что проблема совместимости значительно шире чем только лишь API.
Если почитать некоторых товарищей, то C++ и C чуть ли не вселенское зло и что–то настолько замороченное что доступно для понимания разве что сверхразумам а все остальные непременно не осилят и сделают не так, а между тем куча программ написано именно на этих двух языках и раньше народ как–то же справлялся.По поводу полных раздолбаев у которых программы на Ruste, на удивление, не падают, то таких раздолбаев быть не должно и если потакать раздолбаям, то в итоге станет только хуже. Причём всем.
>C++ и C — вселенское злоНе зло, а устаревшая технология, начавшая мешать прогрессу. Остальное в цитируемом посте — беспочвенные теоретизирования.
Какому именно прогрессу и в чём именно? И почему устаревшая?
>Какому именно прогрессу и в чём именно?Требования к надёжности и защищённости программных систем повысились с 70-х годов прошлого века. Традиционные языки разработки, такие как C и C++, недостаточно хорошо помогают программисту защититься от типовых ошибок.
>И почему устаревшая?
Язык C был создан на базе случайных, ограниченных и устаревших знаний о системах. Теория выработала с тех пор много идей, которые могут быть реализованы в более совершенных языках. C++ попытался применить некоторые оказавшиеся неудачными идеи: тотальный ООП и исключения и заодно показал на практике, что сохранение обратной совместимости с C обходится слишком дорого.
> тотальный ООПВ плюсах нет тотольного ООП. Тотальный ООП в жаве, а в плюсах он как раз вообще ненавязчив.
> и исключения
Исключения безальтернативны и будут в том или ином виде в любом мейнстримовом языке. Потому что программа должна быть сосредоточена вокруг успешного пути выполнения, а обработка ошибок не должка его замусоривать. Явная обработка каждой ошибки как в Go и C - это вообще немыслимо, и даже ? в rust - это слишком многословно для этой цели. Тем более что ? нельзя делать в лямбдах.
Поэтому в rust есть паники, и никто никогда не будет в прикладном коде (например, cli утилите) городить Result'ы, а будет всегда звать expect(). Библиотечный код, увы, приходится обкладывать вопросами, и только для того чтобы caller сделал с такими силами проброшенному Result unwrap().
> заодно показал на практике, что сохранение обратной совместимости с C обходится слишком дорого.
Нет, в совместимости с C проблем никаких нет. Проблемы в совместимости с собственным архаичным и жопой спроектированным стандартом. Одни итераторы только чего стоят.
? работает в замыканиях, как и return.
Про Result в прикладном коде вы чушь написали. Сразу видно, что на Rust не программировали: "никто никогда не будет в прикладном коде (например, cli утилите) городить Result'ы" - сплошь и рядом, практически всегда в прикладном коде используется Result.
> ? работает в замыканиях, как и return.Нет, не работает, потому что введение резалта в лямбду меняет её сигнатуру, а сигнатура фиксирована, потому что это вызов map или какого-нибудь fold.
> а между тем куча программ написано именно на этих двух языках и раньше народ как–то же справлялся.Ну кучу лет дровами грелись и на лошадях грузы перевозили, скажите умно ли было при появлении автомобилей и центрального отопления спорить с тем что пора от дров и лошадей отказываться?
Нет, C и C++ не заморочены и на них вполне можно писать. Но зачем, если есть инструмент на голову выше? А вселенское зло это те кто в этих условиях продолжает увеличивать легаси кодбазу на C/C++.
> Нет, C и C++ не заморочены и на них вполне можно писать.Совершенно не согласен.
Начиная от толстенного талмуда бесполезного "типа стандарта" в котором куча UB и IB.
Заканчивая компиляторами в которых сделано как захотелось левой пятке, и которые тот самый "стандарт" полностью не реализуют.
Да просто не нужно мудрствовать и писать наворочено..Пиши просто, понятный другим код, инициализируй переменные и объекты, не используй самый последний стандарт, используй анализаторы кода и все будет тип-топ, уже много раз проверено!
И не будет нужен RUST, для которого даже UI внятного еще не написали..
> Да просто не нужно мудрствовать и писать наворочено..Просто делайте хорошо и не делайте плохо!
Зачем вы пишете код с багами, надо писать без багов!
...
и другие премудрости с п̶а̶ц̶а̶н̶с̶к̶и̶х̶ пограмистких форумов> Пиши просто, понятный другим код, инициализируй переменные и объекты, не используй самый последний стандарт, используй анализаторы кода и все будет тип-топ, уже много раз проверено!
Ага, вот заглянул я в ядро... а там /_-
СИшка копролитной версии которой уже больше десятка лет (а джва года назад был вообще С99!).Патчи отправляются почтой (слава богу-машине не голубиной), в ядро заливается просто не компилирующееся офно, так что какому-то Торвальдсу приходится идти в комменты и ругаться (lore.kernel.org/dri-devel/CAHk-=wgPJttFz8yrdpPTN-ypMmDXHOKw9yi1nZSEq+7+tGftZA@mail.gmail.com/).
Тесты, анализаторы кода, CI который не пропустит плохой пуллреквест...
Это вообще фантастика)
Ты в курсе что параметр компиляции ядра -Werror добавили в 2021 (две тысячи двадцать первом, Карл!) году?
И все годы до этого было "компилятор сыплет warning'ами? А нам просто пøх!"
А ведь речь идет о ядре, наверное один из главнейших столпов существования линукса.> И не будет нужен RUST, для которого даже UI внятного еще не написали..
Думаю Торвальдс понял (или ему помогли) что офнокодеры в ядре навсегда. Пока там есть дыряшка.
Поэтому он добавил Раст в ядро, чтобы хоть немного улучшить ситуацию.
Да я C++ имел ввиду, современный. И без ковыряния говна мамонта.
Так-то да, конечно.
> Да я C++ имел ввиду, современный. И без ковыряния говна мамонта.
> Так-то да, конечно.Из всех проектах на с++ меня больше всего впечатлил LLVM.
Здоровая кодовая база, но при этом современный С++17, тонны тестов включая фаззинг.
Поэтому их аудит просто зависть)
opennet.ru/opennews/art.shtml?num=60707
То, что LLVM и GCC написаны на C++, фактически уже обеспечили языку бессмертие. Разве что часть функциональности постепенно будут условно "запрещать" (компилятор выдаст warning или ошибку в зависимости от настроек). Мягко это даже УЖЕ произошло, т.к. в старом стиле если и пишут, то для личных проектов и своего рода развлечения. Серьёзный проект, который не должен упасть уже невозможен без умных указателей, move-семантики, подкреплённых санитайзерами, при этом компилятор не стремится сделать из вас осла и даёт вам ВЫБОР как стиля, так и степени беспокойства о качестве вашего кода.
> Начиная от толстенного талмуда бесполезного "типа стандарта" в котором куча UB и IB.А к чему конкретно претензия?
- К наличию стандарта? Было бы лучше без него?
- К его размеру? К тому что язык подробно написан? Или ты думаешь что стандарт другого языка был тоньше?
- К наличию UB? UB позволяет делать оптимизации.
- К наличию IB? IB позволяет языку быть переносимым и при этом эффективным.> Заканчивая компиляторами в которых сделано как захотелось левой пятке, и которые тот самый "стандарт" полностью не реализуют.
Про левую пятку это ты врёшь. А то что реализации отстают от стандарта вообще неминуемо, пока стандарт есть и над ним работает отдельная команда.
> К наличию стандарта? Было бы лучше без него?Да, было бы не хуже. Потому что "стандарт" не написали, его просто зафиксировали текущее состояние в 1988-89 через десятилетия после создания языка. А предыдущее описание вроде K&R C стандартом не было, но почему-то как-то работало.
> К его размеру? К тому что язык подробно написан? Или ты думаешь что стандарт другого языка был тоньше?
К соотношению размер-качество. Можно написать толстый, но при этом продуманный и однозначный стандарт. А можно написать толстый "стандарт" Си. Почувствуй разницу.
> К наличию UB? UB позволяет делать оптимизации...
А также отстреливать себе ноги по самую ж. Что мы наблюдаем доброй части CVE.
> К наличию IB? IB позволяет языку быть переносимым и при этом эффективным.
Позволяет языку быть НЕпереносимым. Потому что как только тебе нужно перенести уже имеющийся код на другую платформу, тебе нужно вычитать его практически весь заново и найти все места, где на новой платформе будет другое поведение. И обмазаться еще ifdef'ами.
> Про левую пятку это ты врёшь.
Думаешь это всё решала правая пятка? Ну, может быть, может быть...
PS. А ты знаешь почему стандарт получился таким какой он есть? С таким количеством UB и IB.
Совсем не ради каких-то оптимизаций и переносимостей. А потому что к моменту стандартизации уже была уже кодовая с различными реализациями под разные платформы. И если посмотреть, кто сидел в комитете, то неудивительно что каждый тянул одеяло на себя и они просто не могли договориться - никто не хотел переписывать свою кодовую базу.
Т.е. ни одну претензию ты так и не озвучил, типичный некомпетентный балабол.
> Т.е. ни одну претензию ты так и не озвучил, типичный некомпетентный балабол.Дурилка, ты что читать не умеешь?
Претензии уже перечислены - "стандарт" из офна и палок.
Язык с кучей архитектурных проблем (например отвратительные enumʼы или макросы).
Куча UB которые стреляют CVEшками постоянно уже 30+ лет.
Ни и умственно отсталые пограммисты которые этим пользуются и воняют на новые инструменты.
Этого что мало)?
На какую голову Rust выше? В C++ ДО появления Rust появилась концепция владения, умные указатели, move семантика, при этом вам решать какую концепцию владения ресурсами использовать в вашем проекте. Из "новомодного" уже добавили корутины, фактически добавили транзакционную память (ещё нет в стандарте, но уже есть реализации). Ваш пост (этот и другой) говорит лишь о том, что вы абсолютно не разбираетесь в C++ и знаете его где-то на уровне "Си с классами". Даже не C++11, который УЖЕ делает Rust бесполезным. Сегодня на дворе 2024 и в C++ добавлено немало инструментов на все случаи жизни. На сырых указателях давно никто не пишет (разве что энтузиасты "для души" в личных проектах или высокопроизводительных системах).
Rust 1.80? Ну это прям прорыв в мир безопасных указателей и грамотно утилизированной оперативной памяти! Значит, теперь, наконец-то, можно писать код, который не свалится в ядро на 14-й минуте работы из-за попытки разыменовать нулевой указатель. Ну и кстати, вот ты говоришь про отсутствие сборщика мусора — это вообще-то просто находка для тех, кто хочет экономить на электричестве! Не нужно гонять этот сборщик, который работает в режиме ядра через DirectX-предикаты, сжирая мегагерцы прямо с видеокарты.Cargo — это вообще песня! Я всегда говорил, что сборка проекта через пакетный менеджер — это как залить данные в БД через аудиопорт, только тут ещё и с гарантией, что библиотеки не перекрестятся. Особенно порадовала тема с crates.io — как будто ты скачиваешь пакеты прямо через FTP-протокол в облаке, только без облака и без FTP, но с поддержкой Rust. Всё это накладывает строгие ограничения на целочисленные переполнения, которые, кстати, можно обойти.
Ну и концепция неизменяемости переменных — это вообще что-то с чем-то! Представь себе, у тебя есть ссылка, а её изменить нельзя! Это как попробовать скомпилировать JavaScript через BIOS. Но если вдруг начнутся проблемы, всегда можно пересобрать ядро компилятора в режиме совместимости с Fortran и, конечно, не забыть включить телеметрию, чтобы следить за частотой нажатий на клавишу "Enter".