Поискать можно по словам типа “Rust type system unsoundness”
Ещё я не нашёл ссылки, но суть в том, что некоторые стандартные классы в языке можно было бы сделать монадами, но так сложилось, что их написали как набор отдельных самостоятельных классов со своими уникальными названиями методов.
Исходная точка: физические ограничения против теории типов Мой подход исходит из физических ограничений целевого железа (8-битный МК и 2 КБ ОЗУ). Это не абстракция, а жесткая реальность. Каждая фича языка в vm5277 должна платить за свое существование байтами Flash/RAM и тактами процессора. Ваш подход, как я понял, идет от выразительности и корректности на уровне типов. Это прекрасно там, где есть гигабайты ОЗУ и JIT-компилятор, но избыточно для микроконтроллеров.
У вас ложная дихотомия. Корректность и сложность системы типов ортогональны размеру скомпилированного бинарника. Они могут усложнить компилятор, но не требуют сложности от рантайма. Например, явная nullability в котлине позволяет на этапе компиляции явно доказать, что какие-то ссылки нулевыми не будут и спасает от ошибок. Или, например, лайфтаймы в расте существуют только во время компиляции как доказательство корректности, в скомпилированном коде их нет. (Конкретно в Расте кстати не всё хорошо, авторы игнорировали теорию типов, в итоге в языке оказались проблемы, которые просто так не выкорчевать). И всякие constexpr и consteval фичи в с++ это как раз про то, чтобы помочь компилятору вынести какие-то вычисления на этап компиляции, а не в рантайм.
Вопрос про подсчёт ссылок: кольцо из ссылающихся объектов приведёт к утечке? Сборщик мусора двигает объекты в памяти при сборке или нет? Если нет - как решается проблема фрагментации? Есть ли escape analysis, когда объект создаётся внутри функции, гарантированно не утекает и тут же выкидывается? (Тогда можно вообще счётчик ссылок не заводить)
И ещё одно замечание про оверхед со ссылками и прочее - в С# в системе типов изначально были ещё и структуры (а в java их всё никак не приделают), и кажется что для МК они нужны. Идея структуры в том, что она передаётся по значению (прям как си), и позволяет создавать меньше объектов и плотнее хранить данные в памяти.
P.s. я сам пробовал задизайнить язык, но я правда пришёл к ещё более радикальной идее - у меня один и тот же класс может передаваться и по ссылке и по значению. У меня у ссылок на объект в куче тип Gc[Smth], а у объекта по-значению - Smth, и можно один и тот же класс точечно и на куче создавать и на стеке (например, если я как программист знаю, что он временный).
не перепутали ли мы эстетическую проблему с гораздо более серьёзной — исчезновением редакционной ответственности?
Так её никогда на Хабре и не было. Нейронки просто наглядно показывают, насколько авторам корпоблогов наплевать на качество. Раньше так плохо не получалось, потому что всё-таки текст руками человек писал. Хотя некоторые авторы типа Ализара умудрялись и без нейронок отличаться.
Кажется, в этом празднике жизни с платными корпоративными аккаунтами надо задавать более экзистенциальный вопрос - а есть ли смысл вообще читать статьи и тратить время, если даже самим авторам на них плевать?
Кстати насчёт паттерна Command и Factory и замены их на лямбды: при усложнении сценариев использования всё равно удобнее переходить на реализацию с интерфейсами и прочим. Во-первых упрощается поиск в коде, можно быстро найти все места, где создаётся и где используется. И удобнее в отладке или логах видеть объект типа “CreateUnitCommand”, вместо непонятной лямбды. Особенно актуально, если там какие-нибудь коллбеки без аргументов и возвращаемых значений - их вообще легко перепутать друг с другом.
А экран так и будет с низким разрешением и монохромным? На флиппере зеро оно логично для микроконтроллера, а с начинкой как в первом кажется что экран на энергопотребление и цену не сильно повлияет.
P.S. за количество и выбор портов для подключения респект, действительно для всего :)
Кстати, а что вы думаете про архитектуры типа apple m5 и ryzen ai, где память общая для всего? И в стимдеке тоже так.
Там, с одной стороны, процессор, gpu и npu могут конкурировать за память, а с другой - шина памяти более широкая и в итоге и процессору веселее, и необходимость перекладывать данные между gpu и cpu пропадает, только синхронизацию сделал и читай?
Так для справки - у райзена память 8 Ггц и 4 канала (в сумме вроде 256 ГБ/сек), у маков зависит от объёма оперативки (у модели на 128 ГБ вроде 600 ГБ/сек).
Мне кажется, из английского. Русского языка в обучающей выборке мало, и вдобавок токенизатор заточен под английский, многие слова идут одним токеном, а на русском буквально по слогам. И как будто построение предложений протекает из английского в русский.
Из моделей ещё интересная GLM-flash - она чуть побольше, но с экспертами, и из-за этого работает сильно шустрее. На видеокарте 4080 я видел скорость генерации больше ста токенов в секунду.
Не совсем, надо не только выбрать по возможности лучшего, но и не потратить время на 100 кандидатов. Если каждому устраивать по 4 часа собеседований, то в сумме 400 рабочих часов - 10 рабочих недель, потраченных собеседующими.
Раньше до ИИ было, что изменения в код добавлялись медленнее, и в найтли сборке было легче заметить изменения и найти причину.
Вдобавок людям лень писать повторяющийся код, и они начинают его как-то реорганизовывать и более лаконично писать, а ИИ это чуждо и он может однотипных изменений хоть на тысячу строк сделать. И, к сожалению, как будто теперь вместо простого и организованного кода, его теперь просто больше и он хуже качеством.
Получается что-то вроде трагедии общин - каждому разработчику проще нагенерить код ценой потери качества, но в итоге получается раздутый проект с техдолгом, в котором всё перманентно разломано и все страдают.
P.S. А про слои ревью - полностью согласен. В предыдущей команде можно было влить изменения в мастер и потом создать ревью - было очень удобно. Сейчас требуется обязательный аппрув ревью человеком + долгое и очень нестабильное CI, в сумме это ад. Сначала ждёшь ревью от человека, потом он просит что-нибудь поправить (один слой), потом CI перезапускает тесты и зачастую падает. И эти тесты - ещё один слой, причём там бывают и тесты нестабильные, и просто поломанные кем-то другим, когда только ребейз поможет. Всякие мелочи даже исправлять не хочется, код пишется за минуты и потом тратятся дни, чтобы его влить.
В сумме вроде 550 строчек, я про их количество вообще не думал. Что меня впечатлило - в отличие от самбы и прочих штук, за несколько лет использования на домашнем сервере проблем вообще не было и скорость приличная (упирается в скорость локальной сети). И ещё приятный момент, что написал сам и сам же использую.
Нет, скалу я и так использую, её к счастью ждать не надо. А вот именно value классы на уровне JVM мне бы очень хотелось увидеть из соображений производительности. GC и JIT компиляция с инлайнингом в каких-то случаях хорошо работают, но к сожалению не всегда.
Есть такое видео, но его сложновато слушать: https://www.youtube.com/watch?v=1iPWt1gvT_w
И ссылки на почитать. https://habr.com/ru/articles/1033328/ https://github.com/rust-lang/rust/issues/25860 https://github.com/rust-lang/rust/issues/135011
Поискать можно по словам типа “Rust type system unsoundness”
Ещё я не нашёл ссылки, но суть в том, что некоторые стандартные классы в языке можно было бы сделать монадами, но так сложилось, что их написали как набор отдельных самостоятельных классов со своими уникальными названиями методов.
У вас ложная дихотомия. Корректность и сложность системы типов ортогональны размеру скомпилированного бинарника. Они могут усложнить компилятор, но не требуют сложности от рантайма. Например, явная nullability в котлине позволяет на этапе компиляции явно доказать, что какие-то ссылки нулевыми не будут и спасает от ошибок. Или, например, лайфтаймы в расте существуют только во время компиляции как доказательство корректности, в скомпилированном коде их нет. (Конкретно в Расте кстати не всё хорошо, авторы игнорировали теорию типов, в итоге в языке оказались проблемы, которые просто так не выкорчевать). И всякие constexpr и consteval фичи в с++ это как раз про то, чтобы помочь компилятору вынести какие-то вычисления на этап компиляции, а не в рантайм.
Вопрос про подсчёт ссылок: кольцо из ссылающихся объектов приведёт к утечке? Сборщик мусора двигает объекты в памяти при сборке или нет? Если нет - как решается проблема фрагментации? Есть ли escape analysis, когда объект создаётся внутри функции, гарантированно не утекает и тут же выкидывается? (Тогда можно вообще счётчик ссылок не заводить)
И ещё одно замечание про оверхед со ссылками и прочее - в С# в системе типов изначально были ещё и структуры (а в java их всё никак не приделают), и кажется что для МК они нужны. Идея структуры в том, что она передаётся по значению (прям как си), и позволяет создавать меньше объектов и плотнее хранить данные в памяти.
P.s. я сам пробовал задизайнить язык, но я правда пришёл к ещё более радикальной идее - у меня один и тот же класс может передаваться и по ссылке и по значению. У меня у ссылок на объект в куче тип Gc[Smth], а у объекта по-значению - Smth, и можно один и тот же класс точечно и на куче создавать и на стеке (например, если я как программист знаю, что он временный).
P.p.s. какие-то мысли про язык и процесс разработки (сам язык сильно отличается, но надеюсь какие-то вещи могут пригодиться) : https://kright.me/2026/07/06/delaiu-svoi-iazyk-programmirovaniia/
Лол, а остальные статьи на Хабре вас не смущают, включая статьи самих редакторов?
Так её никогда на Хабре и не было. Нейронки просто наглядно показывают, насколько авторам корпоблогов наплевать на качество. Раньше так плохо не получалось, потому что всё-таки текст руками человек писал. Хотя некоторые авторы типа Ализара умудрялись и без нейронок отличаться.
Кажется, в этом празднике жизни с платными корпоративными аккаунтами надо задавать более экзистенциальный вопрос - а есть ли смысл вообще читать статьи и тратить время, если даже самим авторам на них плевать?
Ага, и на мой взгляд будет круто, если у них всё получится. Выглядит очень смело и амбициозно.
Они и хотят и пытаются. К текстовому редактору намного проще делать плагины и изменения, чем к IDE с кучей внутренних взаимосвязей и ограничений.
Кстати насчёт паттерна Command и Factory и замены их на лямбды: при усложнении сценариев использования всё равно удобнее переходить на реализацию с интерфейсами и прочим. Во-первых упрощается поиск в коде, можно быстро найти все места, где создаётся и где используется. И удобнее в отладке или логах видеть объект типа “CreateUnitCommand”, вместо непонятной лямбды. Особенно актуально, если там какие-нибудь коллбеки без аргументов и возвращаемых значений - их вообще легко перепутать друг с другом.
То же самое хотелось сказать. Отвратительно написанная новость, только в заблуждение вводит, хотя по-факту ничего не изменилось.
А экран так и будет с низким разрешением и монохромным? На флиппере зеро оно логично для микроконтроллера, а с начинкой как в первом кажется что экран на энергопотребление и цену не сильно повлияет.
P.S. за количество и выбор портов для подключения респект, действительно для всего :)
Кстати, а что вы думаете про архитектуры типа apple m5 и ryzen ai, где память общая для всего? И в стимдеке тоже так.
Там, с одной стороны, процессор, gpu и npu могут конкурировать за память, а с другой - шина памяти более широкая и в итоге и процессору веселее, и необходимость перекладывать данные между gpu и cpu пропадает, только синхронизацию сделал и читай?
Так для справки - у райзена память 8 Ггц и 4 канала (в сумме вроде 256 ГБ/сек), у маков зависит от объёма оперативки (у модели на 128 ГБ вроде 600 ГБ/сек).
Мне кажется, из английского. Русского языка в обучающей выборке мало, и вдобавок токенизатор заточен под английский, многие слова идут одним токеном, а на русском буквально по слогам. И как будто построение предложений протекает из английского в русский.
Из моделей ещё интересная GLM-flash - она чуть побольше, но с экспертами, и из-за этого работает сильно шустрее. На видеокарте 4080 я видел скорость генерации больше ста токенов в секунду.
Не совсем, надо не только выбрать по возможности лучшего, но и не потратить время на 100 кандидатов. Если каждому устраивать по 4 часа собеседований, то в сумме 400 рабочих часов - 10 рабочих недель, потраченных собеседующими.
Раньше до ИИ было, что изменения в код добавлялись медленнее, и в найтли сборке было легче заметить изменения и найти причину.
Вдобавок людям лень писать повторяющийся код, и они начинают его как-то реорганизовывать и более лаконично писать, а ИИ это чуждо и он может однотипных изменений хоть на тысячу строк сделать. И, к сожалению, как будто теперь вместо простого и организованного кода, его теперь просто больше и он хуже качеством.
Получается что-то вроде трагедии общин - каждому разработчику проще нагенерить код ценой потери качества, но в итоге получается раздутый проект с техдолгом, в котором всё перманентно разломано и все страдают.
P.S. А про слои ревью - полностью согласен. В предыдущей команде можно было влить изменения в мастер и потом создать ревью - было очень удобно. Сейчас требуется обязательный аппрув ревью человеком + долгое и очень нестабильное CI, в сумме это ад. Сначала ждёшь ревью от человека, потом он просит что-нибудь поправить (один слой), потом CI перезапускает тесты и зачастую падает. И эти тесты - ещё один слой, причём там бывают и тесты нестабильные, и просто поломанные кем-то другим, когда только ребейз поможет. Всякие мелочи даже исправлять не хочется, код пишется за минуты и потом тратятся дни, чтобы его влить.
Слава тебе, человече! Окромя того хочу добавить, что в Котлине можно классы, переменные и типы называть на кириллице.
Ежели сильно охота, можно и сейчас так писать, только ключевые слова на басурманском останутся.
На кодохранилище заморском можно найти код, где имена переменных и комментарии иероглифами китайскими написаны, а мы чем хуже?
По-моему, то же самое можно рассказать куда проще и короче: https://kright.github.io/2025/08/09/Scala-3,-Monocle,-иерархия-неизменяемых-объектов.html
Четыре года назад ради интереса написал маленький сервер, который даёт скачивать файлики через браузер.
https://github.com/Kright/files-web-server
В сумме вроде 550 строчек, я про их количество вообще не думал. Что меня впечатлило - в отличие от самбы и прочих штук, за несколько лет использования на домашнем сервере проблем вообще не было и скорость приличная (упирается в скорость локальной сети).
И ещё приятный момент, что написал сам и сам же использую.
Нет, скалу я и так использую, её к счастью ждать не надо.
А вот именно value классы на уровне JVM мне бы очень хотелось увидеть из соображений производительности. GC и JIT компиляция с инлайнингом в каких-то случаях хорошо работают, но к сожалению не всегда.
На самом деле норм подход - всё зараз сделать сложно, а так можно поотмечать незавершённые места и потом доделать.