Дрю ДеВолт (Drew DeVault), автор пользовательского окружения Sway, почтового клиента Aerc и платформы совместной разработки SourceHut, опубликовал выпуск языка программирования Hare 0.25.2. Номер версии образован как 0.YY.Q, где YY - две последние цифры года, а Q - номер квартала, прошлый выпуск Hare 0.24.2 был опубликован год назад. Hare преподносится как язык системного программирования, близкий к языку Си, но проще, чем Си. Исходный код компилятора и инструментария распространяются под лицензией GPLv3, а код стандартной библиотеки под лицензией MPL (Mozilla Public License)...Подробнее: https://www.opennet.me/opennews/art.shtml?num=63441
> "Номер версии образован как 0.YY.Q, где YY - две последние цифры года, а Q - номер квартала"Вы что с нумерации версии сделали? Извращенцы!
LibreOffice подсказал.
А если проект доживет до 2101 года, то это будет 0.01.1? Фигня какая-то.
Ну, наверное, тогда можно и поменять уже будет первую цифру.
Так что 1.01.1, не о чем беспокоиться.
А если версия 0 выйдет за месяца до?
Получается сначала 0.99.4, а потом 0.00.1 😂
Это ты с начала доживи
Если до 2101 доживёт, то поменяют на формат версий Хрома
> opennet, 2101
> ...так же, в новом хромбраузере поправлена проблема переполнение значения счетчика версии
А кто мешает сделать 0.101.2 например?
Ноль целых 25 столетних 2 квартальных
Спасибо тебе КО, ты нас всех снова спас!
Но и правда, харе уже по N+1 кругу C/зайцев гонять :)
Извращенцы — это semver.org. На грани злонамеренного вредительства. Впрочем, от кодеров я иного и не ожидал.
X.X.X - это традиционная для Линукса порядок версионирования. Наоборот, извращенец это ты.
Ну, во-первых, решать как версионировать свой код будут именно кодеры, точно не ты. Во-вторых, semver - лучшая и повсеместно признанная схема версионирования. Вообще, жизнеспособны любые монотонно растущие версии состоящие из числовых компонент, но среди них semver несёт больше всего полезной информации.
> как версионировать свой код будут именно кодеры, точно не тыНет. Организационные решения внутри проекта — моя прямая должностная обязанность.
> жизнеспособны любые монотонно растущие версии состоящие из числовых компонент
Да.
> но среди них semver несёт больше всего полезной информации
Нет. Как не глядя в ченджлог понять какая версия вышла раньше: 1.3.79 или 2.0.12?
> Нет. Организационные решения внутри проекта — моя прямая должностная обязанность.Принимать организационные решения никогда не возьмут человека, не понимающего банальных и фундаментальных концепций.
> Нет. Как не глядя в ченджлог понять какая версия вышла раньше: 1.3.79 или 2.0.12?
Это и глядя в changelog не понять, потому что changelog разные для 1 и 2 веток. А так, очевидно что сравнивать по времени выхода релизы из разных веток не имеет никакого смысла, и такая задача может возникнуть только ввиду некомпетентности.
> Принимать организационные решения никогда не возьмут человека, не понимающего банальных и фундаментальных концепций.Стало быть мне неимоверно повезло надурить и HR, и четыре уровня технических интервью! Знал бы — поставил бы в тот день весь свой пенсионный фонд на зеро.
> Это и глядя в changelog не понять, потому что changelog разные для 1 и 2 веток. А так, очевидно что сравнивать по времени выхода релизы из разных веток не имеет никакого смысла, и такая задача может возникнуть только ввиду некомпетентности.
Читаю в недельном бюллетене вендора (перевод мой): «все версии библиотеки вышедшие до 1 мая 2025 года подвержены уязвимости». О компетентности вендора судить не берусь, однако знаю точно, что его оборудование и ПО используется практически во всём мире, где есть IP сети. Не возьмусь так же судить о компетентности моих предшественников, решивших не ломать рабочую систему и процессы наших кастомеров, и решивших вместо этого постепенно переводить всех на новую, допиливая недостающие фичи по необходимости. В старой системе библиотека версии 1.3.79, в новой — 2.0.12. Так как понять которую из систем надо срочно обновлять? Блесни компетентностью.
> Стало быть мне неимоверно повезло надурить и HR, и четыре уровня технических интервью! Знал бы — поставил бы в тот день весь свой пенсионный фонд на зеро.
Господи, сколько апломба-то!По-хорошему, это прокол вендора что они не включили последние подверженные версии и/или первые неподверженные в свой аннаунсмент. Если такой информации нет - идти, искать/шерстить ченджлоги, смотреть CVE напрямую и так далее. Вендор тебя подвёл и теперь это твоя работа, да.
> Организационные решения внутри проекта — моя прямая должностная обязанность.Как и любого анонимного комментатора на Опеннете!
Мы стоим на страже ваших проектов с 1996 года!
С-Самонадеянность и Н-Некомпетентность. Сходу ограничить частоту релизов и исключить возможность багфикс релизов.
Ваще топ язык! Автор красава!
Полностью согласен с вами, коллега!
Автор, перелогинься!
Что вы, я никогда под такими учётками никуда не хожу. Это воссторженные фанаты мимикрируют
Ето не я!
Выглядит не вырвиглазно, на первый взгляд.
Работу с Си наследием притянул уже. Любопытно что там с шаблоно-объектно-функциональщиной и как это в деле выглядит.А затем тесты, сравнения и через лет 5...
Увы, очередной недоди-перепитон. Каких-то сильных сторон у языка нет.
Проект существует скорее благодаря nih, нежели из реальной нужды.
Если будет drop() из Rust и включены в стандартную библиотеку списки, словари и деревья, то вполне замена С.
А потом всё равно каждый пишет свои коллекции и делает свои аллокаторы, потому что всё не то и всё не так.
Кто "каждый"? Проекты на ЯВУ со своими реализациями коллекций можно по пальцам пересчитать, и причиной наличия этих реализаций примерно в 90% будет некомпетентность разработчика, а остальные 10% примерно одинаково делятся между легаси кодом (из C++03 эпохи где не было `unordered_map`) и реальной необходимостью.Для недоязыков типа С написать свою коллекцию с своим UB, вместо того чтобы писать проект - это традиция и дело чести.
А аллокаторы - смотря что вы имеете в виду. Глобальные никто не пишет, потому что для юношей с горящими глазами это слишком сложно, а те у кого хватит скиллов понимают что это не нужно. А подключить jemalloc/mimalloc, сравнить перф и потребление и выбрать лучшее - это операция доступна и имеет смысл независимо от языка. А что касается арен, то в них часто есть смысл, опять же это не зависит от языка. Но в нормальных языках есть готовые реализации bump и slab арен.
а тут хоть строки нормальные есть?
какие считаются нормальынми?
С ИИ внутри
Конечно есть. В ассемблере строки это просто байты, поэтому и тут, и в Си есть нормальные строки.
Там много вариантов строк бывает. Черт его знает что он там нормальным считает. Может вариант с длинной и нулевым символом, а может UTF-16 у всех разное ...
> строки это просто байтыА текст — это просто буквы.
А в чем прикол? Синтаксис на любителя, из того что в новости - совсем не проще Си.
Даже безопасной работы с памятью нет - так зачем мне переходить с Си на это поделие?
Синтаксис определённо растом навеян. Типы полей структур, атрибуты... и много что ещё, если пойти и посмотреть доки.Но это
use fmt;
use os;export fn main() void = {
const user = os::getenv("USER") as str;
fmt::printfln("Welcome to the Hare documentation, {}!", user)!;
};
По-моему читается хуже, чем это:
use std::env;fn main() {
let user = env::var("USER").unwrap_or_default();
println!("Welcome to Rust, {user}!");
}
Согласен. У раста здесь синтаксис понятнее, даже для того кто на нем не пишет. А по верхнему коду есть вопросы, например нафига тут export? Из кода совсем не ясна логика программы на этом самом Харе.
>unwrap_or_defaultДаже в таком коротком коде не обошлось без приседаний перед идолом безопасности, завернутых во вспомогательную функцию.
Походу Руст это язык тревожных невротиков с гиперкомпенсацией контроля, лол.
>>unwrap_or_default
> Даже в таком коротком коде не обошлось без приседаний перед идолом безопасности, завернутых во вспомогательную функцию.ЧСХ, эта "вспомогательная функция" автоматом есть у всего, возвращающего результат-или-ошибку Result<T, E>
как впрочем и unwrap_or(some_custom_default_value). Не давая, с одной стороны, "забивать" на ошибки -- и не разводя простыни "if err!=nil" на любой чих, с другой.> Походу Руст это язык тревожных невротиков с гиперкомпенсацией контроля, лол.
Эт да, нет бы просто и привычно сегфолтнуть, если такой переменной окружения нет ...
Не понял, тебе не нравится что результат, который объективно опциональный, нельзя использовать не проверив на наличие?
Растолюбы проверяют результат, но делают это без уважения!Мне не нравится, что проверка закопана в какую-то невнятную функцию-прицеп. Выглядит уродливо. Классические проверки на null или исключения выглядят красивее и заметнее.
Второй недостаток в обязательности таких проверок везде и всегда из того, что ошибка это часть типа. Язык требует ритуала разворачивания в нормальный тип из типа с ошибкой, даже там где программист на 100% уверен, что всё пройдет без эксцессов. Например в каждом серьезном приложении есть внутрений слой моделей, которые по умолчанию считают все свои данные и окружение доверенным, из-за чего можно пропустить шаги валидации. Раст такую такую вольность не позволит.
В нормальных языках почти не используется типовой мусор вроде Result<t, e>, Optional, Maybe и проч. Привязывать ошибку у типу непрактично, такой прием используется только в функциональщине, где нельзя сохранить ошибку через состояние объекта(т.е. вообще безотносительно его типа). Зачем эту функциональную юзлес фигню тащат в мейнстрим для мня загадка.
все Hare отработали лавэ ))
>Для разработки графических приложений развивается инструментарий hare-waylandПравда, вот в wayland ни текст не закодить, ни ресурсы переиспользовать на сервере, в отличие от годной к продакшену подсистемы графики - сверху обязательно будет тулкит.
Память нужно самому освобождать, не кроссплатформенный, не ...
Не нужон
По сути, сейчас есть два языка, два брата, вечно дерущихся: Си и Раст - кому нужна максимальная производительность и кто готов сам! управлять памятью, выбирают Си. Тем, кто готов пожертвовать парой процентов производительности взамен того, чтоб не парится о памяти вообще - выбирают Раст.
О плюсах вообще забудьте - ООП это ошибка, а сам язык настолько перегружен ненужностями, что там те же минус пара процентов производительности, и те же приколы с памятью - так что лучше выбрать Раст.
Си быстро копилируется в двоичный код. Раст - является фронтендом компилятора LLVM. Сам LLVM громоздкий и под его капотом идут поэтапные преобразования кода. Си не брат Расту.
> Си быстро копилируется в двоичный код. Раст - является фронтендом компилятора LLVM. Сам LLVM громоздкий и под его капотом идут поэтапные преобразования кода. Си не брат Расту.Какая чушь. C через clang компилируется тем же LLVM'ом. Можно gcc, но это не сильно быстрее. При этом gcc с недавних пор может и rust.
> Можно gcc, но это не сильно быстрее.Причем там, унутрях gcc, все те же поэтапные преобразования кода (всякие GIMPLE, SSA, RTL и прочие IR).
А вот результаты "быстро компилирующих" компиляторов (я так понимаю, pcc, tcc и возможно scc) почему-то нигде особо не светятся.
Когда ты компилируешь сишный код в GCC, происходит 3 гениальных и простых вещи.1. Содержимое заголовочного файла помещается в исходный код.
2. Исходный код преобразуется в ассемблерние листинги в синтаксисе AT&T.
3. Ассемблерные листинги компилируются в двоичный код.
Если будет статические связывание, то исходники библиотек помещаются в стадии №1.Clang является частью LLVM, вот там-то да, происходят эти непонятные наркоманские "GIMPLE, SSA, RTL и прочие IR".
Гениальность Си в его простоте, а Rust как мы знаем очень сложен. Так что не равняйте эти обе языка.
Где-то между 1 и 2 забыл примерно 5 подпунктов: парсинг, препроцессор, проверка синтаксиса, выстраивание AST, и много чего еще.
>парсинг, препроцессор, проверка синтаксисаВсё это уже входит в первый пункт, как нечто разумеешееся. Парсинг и проверка синтаксиса происходит одновременно и не является подпунктом.
>выстраивание AST
Чистосишному компилятору это не нужно. Ты видимо попутал с C++. Исодный текст сразу преобразуется в ассемблерные листинги. Сишка не производит, как у Rust, накркоманских преобразований кода во всякие промежуточные представления.
> 2. Исходный код преобразуется в ассемблерние листинги в синтаксисе AT&T.
> Clang является частью LLVM, вот там-то да, происходят эти непонятные наркоманские "GIMPLE,
> SSA, RTL и прочие IR".
% echo "int foo(int bar) {return bar*2;}"|gcc -O1 -fdump-tree-ssa=stdout -xc -;; Function foo (foo, funcdef_no=0, decl_uid=2694, cgraph_uid=1, symbol_order=0)
int foo (int bar)
{
int _2;<bb 2> :
_2 = bar_1(D) * 2;
return _2;}
% echo "int foo(int bar) {return bar*2;}"|gcc -O1 -fdump-tree-gimple=stdout -xc -
int foo (int bar)
{
int D.2697;D.2697 = bar * 2;
return D.2697;
}% echo "int foo(int bar) {return bar*2;}"|gcc -O1 -fdump-rtl-ce1=stdout -xc -
;; Function foo (foo, funcdef_no=0, decl_uid=2694, cgraph_uid=1, symbol_order=0)0 registers.
3 basic blocks, 2 edges.
(note 4 0 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 2 4 3 2 (set (reg/v:SI 83 [ bar ])
(reg:SI 5 di [ bar ])) "<stdin>":1:18 83 {*movsi_internal}
(expr_list:REG_DEAD (reg:SI 5 di [ bar ])
(nil)))
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
(insn 6 3 11 2 (parallel [
(set (reg:SI 84)
(ashift:SI (reg/v:SI 83 [ bar ])Как скажешь.
Си ни с кем не дерётся, его уделом осталось лютое легаси. Ну и rust не медленнее C - с чему ему быть медленнее? Есть некоторые рантайм проверки, которые в горячем коде можно отключить с unsafe. Как показывают недавнее переписывание алгоритпов компрессии на rust, например zlib-rs, писать на rust более быстрый код чем на C фактически тривиально.Поэтому, с чем соглашусь - нет смысла не использовать что-то помимо rust для производительного кода.
Но ООП там есть. Без наследования полей, от чего, кстати, много кто плачеи, но и без наследования реализаций, что хорошо, но на C++ последние 20 лет пишут точно так же - иерархии классов, а тем более с ромбиками, никто в здравом уме не строит, делают полностью виртуальный интерфейс и сколько надо его final реализаций. Но да, на трейтах это конечно на порядок удобнее, плюс rust позволяет явно выбирать между статической и данамической диспетчеризацией.
Сам ты ошибка. Выбираем ООП.
V lang лучше
Местечковый язык, который нарочито избегает проприетарные ОС. Идеологически это можно хвалить и поддерживать. Но на практике такой язык не взлетит и останется любительской поделкой. Даже dlang и nim и то больше пользы приносят. Первый так вообще в проде используется кое-где в Европе.
Пусть вернут примеры на русском языке, тогда, может, посмотрим. Нет.
Зачем, если все без исключения русскоговорящие кодеры знают английский хотя бы со словарём?
Язык одного человека, на него нет смысла даже смотреть уже только поэтому.
C/C++ написан парой человек
Пара человек когда не было ни индустрии, ни экосистемы, ни нормальных ЯП, ни требований к ним это как-бы немножко другое. Тогда язык действительно можно было наговнякать (что, ЧСХ, и произошло с C++) водиночку, и что бы ты не наговнякал, оно уже решало какие-то проблемы существующих языков, даже о совместимости думать почти не надо было. Сейчас, for starters, вокруг языка нужно понаписать кучу тулинга (пакетный менеджер, пакетная экосистема, линтеры, форматтеры, плагины под ide, поддержка в gdb, генерация документации, биндгены и т.д. и т.п.), достаточно жирную стандартную библиотеку и биндинги к, как минимум, примерно сотне существующих фундаментальных библиотек. Дальше, низковисящие проблемы все уже порешаны, никому не нужен язык отличающийся от существующих только вариациями function vs. fn и var vs. let. И планка повышена - никому уже не нужен язык без memory safety.
> Буржуазия технологической отрасли уже на протяжении длительного времени ведет войну с трудом, по крайней мере десятилетие. Далеко не собирая никакого сопротивления, большинство технологической рабочей силы даже не понимает, что это происходит с ними. Ваш босс одержим делая вас бессильными и заменяемыми. Вы можете не осознавать, насколько сильное влияние у вас есть над вашим боссом, но ваш босс, безусловно, есть – и делал это все, что в их силах, чтобы подорвать вас, прежде чем вы поумнеете. Не позволяйте вы сами считаете, что являетесь частью их клуба – если ваш доход зависит от вашего зарплату, вы часть рабочего класса.Из его блога. Какой-то хронический коммунист-идиот.
Эксплуататор детектед