https://www.opennet.dev/openforum/vsluhforumID3/137151.html Дрю ДеВолт (Drew DeVault), автор пользовательского окружения Sway, почтового клиента Aerc и платформы совместной разработки SourceHut, опубликовал выпуск языка программирования Hare 0.25.2. Номер версии образован как 0.YY.Q, где YY - две последние цифры года, а Q - номер квартала, прошлый выпуск Hare 0.24.2 был опубликован год назад. Hare преподносится как язык системного программирования, близкий к языку Си, но проще, чем Си. Исходный код компилятора и инструментария распространяются под лицензией GPLv3, а код стандартной библиотеки под лицензией MPL (Mozilla Public License)...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=63441<br> https://www.opennet.dev/openforum/vsluhforumID3/137151.html#94 Wed, 25 Jun 2025 15:20:38 GMT Растолюбы проверяют результат, но делают это без уважения!<br><br>Мне не нравится, что проверка закопана в какую-то невнятную функцию-прицеп. Выглядит уродливо. Классические проверки на null или исключения выглядят красивее и заметнее.<br><br>Второй недостаток в обязательности таких проверок везде и всегда из того, что ошибка это часть типа. Язык требует ритуала разворачивания в нормальный тип из типа с ошибкой, даже там где программист на 100% уверен, что всё пройдет без эксцессов. Например в каждом серьезном приложении есть внутрений слой моделей, которые по умолчанию считают все свои данные и окружение доверенным, из-за чего можно пропустить шаги валидации. Раст такую такую вольность не позволит.<br><br>В нормальных языках почти не используется типовой мусор вроде Result&lt;t, e&gt;, Optional, Maybe и проч. Привязывать ошибку у типу непрактично, такой прием используется только в функциональщине, где нельзя сохранить ошибку через состояние объекта(т.е. вообще безотносительно его типа). Зачем эту функциональную юзлес фигню та https://www.opennet.dev/openforum/vsluhforumID3/137151.html#93 Wed, 25 Jun 2025 14:45:34 GMT Пара человек когда не было ни индустрии, ни экосистемы, ни нормальных ЯП, ни требований к ним это как-бы немножко другое. Тогда язык действительно можно было наговнякать (что, ЧСХ, и произошло с C++) водиночку, и что бы ты не наговнякал, оно уже решало какие-то проблемы существующих языков, даже о совместимости думать почти не надо было. Сейчас, for starters, вокруг языка нужно понаписать кучу тулинга (пакетный менеджер, пакетная экосистема, линтеры, форматтеры, плагины под ide, поддержка в gdb, генерация документации, биндгены и т.д. и т.п.), достаточно жирную стандартную библиотеку и биндинги к, как минимум, примерно сотне существующих фундаментальных библиотек. Дальше, низковисящие проблемы все уже порешаны, никому не нужен язык отличающийся от существующих только вариациями function vs. fn и var vs. let. И планка повышена - никому уже не нужен язык без memory safety.<br> https://www.opennet.dev/openforum/vsluhforumID3/137151.html#91 Wed, 25 Jun 2025 12:43:57 GMT C/C++ написан парой человек<br> https://www.opennet.dev/openforum/vsluhforumID3/137151.html#89 Wed, 25 Jun 2025 10:15:44 GMT &gt; Организационные решения внутри проекта &#8212; моя прямая должностная обязанность.<br><br>Как и любого анонимного комментатора на Опеннете!<br>Мы стоим на страже ваших проектов с 1996 года!<br> https://www.opennet.dev/openforum/vsluhforumID3/137151.html#87 Wed, 25 Jun 2025 04:49:18 GMT А кто мешает сделать 0.101.2 например?<br> https://www.opennet.dev/openforum/vsluhforumID3/137151.html#86 Wed, 25 Jun 2025 04:37:19 GMT Господи, сколько апломба-то!<br><br>По-хорошему, это прокол вендора что они не включили последние подверженные версии и/или первые неподверженные в свой аннаунсмент. Если такой информации нет - идти, искать/шерстить ченджлоги, смотреть CVE напрямую и так далее. Вендор тебя подвёл и теперь это твоя работа, да.<br> https://www.opennet.dev/openforum/vsluhforumID3/137151.html#85 Tue, 24 Jun 2025 17:38:27 GMT все Hare отработали лавэ ))<br> https://www.opennet.dev/openforum/vsluhforumID3/137151.html#84 Tue, 24 Jun 2025 17:09:08 GMT &gt; 2. Исходный код преобразуется в ассемблерние листинги в синтаксисе AT&T.<br>&gt; Clang является частью LLVM, вот там-то да, происходят эти непонятные наркоманские "GIMPLE, <br>&gt; SSA, RTL и прочие IR".<br><br>[CODE]<br>% echo "int foo(int bar) {return bar*2;}"&#124;gcc -O1 -fdump-tree-ssa=stdout -xc - <br><br>;; Function foo (foo, funcdef_no=0, decl_uid=2694, cgraph_uid=1, symbol_order=0)<br><br>int foo (int bar)<br>{<br> int _2;<br><br> &lt;bb 2&gt; :<br> _2 = bar_1(D) * 2;<br> return _2;<br><br>}<br>% echo "int foo(int bar) {return bar*2;}"&#124;gcc -O1 -fdump-tree-gimple=stdout -xc - <br>int foo (int bar)<br>{<br> int D.2697;<br><br> D.2697 = bar * 2;<br> return D.2697;<br>}<br><br>% echo "int foo(int bar) {return bar*2;}"&#124;gcc -O1 -fdump-rtl-ce1=stdout -xc - <br> <br>;; Function foo (foo, funcdef_no=0, decl_uid=2694, cgraph_uid=1, symbol_order=0)<br><br>0 registers.<br><br>3 basic blocks, 2 edges.<br><br>(note 4 0 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)<br>(insn 2 4 3 2 (set (reg/v:SI 83 [ bar ])<br> (reg:SI 5 di [ bar ] https://www.opennet.dev/openforum/vsluhforumID3/137151.html#83 Tue, 24 Jun 2025 15:58:11 GMT &gt;парсинг, препроцессор, проверка синтаксиса<br><br>Всё это уже входит в первый пункт, как нечто разумеешееся. Парсинг и проверка синтаксиса происходит одновременно и не является подпунктом.<br><br>&gt;выстраивание AST<br><br>Чистосишному компилятору это не нужно. Ты видимо попутал с C++. Исодный текст сразу преобразуется в ассемблерные листинги. Сишка не производит, как у Rust, накркоманских преобразований кода во всякие промежуточные представления.<br>