ASMLings - это набор из ~32 коротких упражнений на ассемблере Intel 8086, выстроенных по возрастанию сложности: от mov ax, 0x1337 до 32-битного сложения через carry flag, циклов, подпрограмм, работы с памятью и стеком.
Полный русскоязычный гайд по asmlings - интерактивной песочнице для изучения ассемблера Intel 8086, в которой 16-битный x86-эмулятор написан на Rust.
Внутри: что это, как устроено под капотом, как установить, как читать и решать упражнения, разборы реальных задач из репозитория, готовые примеры в examples/ и шпаргалки.
Разбор 100+ вопросов с собеседований Rust Полезный реподля подготовки к собеседованиям
Rust Interview Questions - это подборка вопросов, ответов и практических задач по Rust для тех, кто готовится к техническому интервью или хочет проверить, насколько хорошо понимает язык.
Внутри есть материалы по ключевым темам Rust:
ownership и move-семантика
borrowing и ссылки
lifetimes
traits и generics
Option и Result
обработка ошибок
память и безопасность
практические задачи с кодом
ответы и разборы
Rust нельзя нормально выучить только по синтаксису. Нужно понимать, почему borrow checker ругается, как работает владение, где появляются lifetime-ограничения и чем Rust отличается от языков с GC.
Этот репозиторий как раз про это: короткие вопросы, практические проверки и постепенное прокачивание Rust-мышления.
Подойдёт начинающим, которые уже знают базу, и разработчикам, которые хотят освежить Rust перед интервью.
✔️ Отец русской математики, без которого не было бы современного ML: 205 лет Пафнутию Чебышеву
16 мая 1821 года в селе Окатово Калужской губернии родился Пафнутий Львович Чебышев. Человек, без работ которого современный data science выглядел бы совсем иначе: ни тебе закона больших чисел в привычной форме, ни оценок отклонений, ни нормальной теории приближений. Чебышев основал петербургскую математическую школу и почти 35 лет вёл кафедру математики в Санкт-Петербургском университете. Через его руки прошли Ляпунов, Марков и Стеклов, то есть люди, чьи имена сегодня встречаются в любой книге по статистике и теории вероятностей.
Главное, чем он остался в математике: многочлены Чебышева, неравенство Чебышева, результаты по распределению простых чисел и фундамент теории приближений. Если кто-то когда-то открывал учебник по ML, он сталкивался с этим неравенством в первой же главе про концентрацию меры. Многочлены Чебышева до сих пор используют в численных методах, фильтрах и аппроксимациях, на которых построены реальные инженерные системы.
Теперь обещанная история. Чебышев с детства хромал на одну ногу из-за врождённого дефекта, обычные детские игры были для него почти недоступны, и мать делала ставку на учёбу. Именно эта хромота, по воспоминаниям современников, и подтолкнула его всю жизнь возиться с механизмами: он хотел понять, как можно превратить вращательное движение в прямолинейное, чтобы шаги людей и работа машин были ровными. В итоге он построил больше 40 механических устройств, включая знаменитую стопоходящую машину, которая на Всемирной выставке в Париже в 1878 году ходила как настоящее живое существо. Это был один из первых в истории шагающих механизмов, фактически прадед современных шагающих роботов.
Ещё один штрих: Чебышев почти всю свою преподавательскую зарплату тратил на инструменты и модели для собственной мастерской, а женат так и не был, говорил, что наука для него важнее. При этом в Европе его называли просто «русский Эйлер», а Французская академия наук избрала его иностранным членом ещё при жизни.
t.me/rust_code - пишу про вайбкодинг, Rust, тестирую модели и делюсь с вами подписывайтесь!
С версии 1.0 многое изменилось, но история языка всё ещё пишется.
От первого стабильного релиза до сегодняшнего дня Rust вырос в топовые язык, сформированный, аккуратным дизайном и крутым сообществом, которое постоянно поднимает планку качества в разработке ПО.
AI-агенты уже переписывают не пет-проекты, а инфраструктуру уровня Bun
История с Bun выглядит как новый уровень вайбкодинга: не лендинг, не CRUD и не маленький сервис, а почти миллион строк системного кода.
Bun изначально был написан на Zig. После покупки Anthropic проект стал ещё важнее: на нём завязана инфраструктура Claude Code, поэтому любые проблемы runtime напрямую бьют по продукту.
И вот Джарред Самнер начал эксперимент с переносом Bun на Rust при помощи Claude. Сначала это звучало как черновой ресёрч, который легко могут выбросить.
Но через несколько дней Rust-ветка уже проходила около 99.8% тестов на Linux x64 glibc, а в обсуждениях всплыл масштаб порядка 960 тысяч строк портированного кода.
AI-агенты выглядят как инструмент для радикальных миграций: язык, runtime, архитектура, огромная кодовая база.
Да, качество такого порта ещё будут долго разбирать. Да, миллион строк от агента - это не автоматически production-ready. Но сам факт уже меняет планку.
Раньше переписывание большого проекта на другой язык было историей на месяцы или годы.
Теперь это может начинаться как эксперимент на неделю.
Rust Roadmap 2026 на русском: от нуля до production-кода
Недавно я стал фанатом Rust, к чему и вас призываю)
Если давно хотели нормально зайти в Rust, а не прыгать между случайными статьями, вот хороший маршрут: полный roadmap на русском, бесплатный курс для начинающих и большая подборка полезных ресурсов.
Что внутри:
базовый синтаксис и первые программы
ownership, borrowing и lifetimes
Option, Result, traits и generics
обработка ошибок и тестирование
std, smart pointers и многопоточность
async/await и Tokio
macros, unsafe и FFI
web, CLI, embedded, WASM, gamedev и ML
мини-проекты на каждом этапе
Главная ценность roadmap в том, что он ведёт по Rust постепенно: сначала база, потом ключевая модель памяти, затем практические направления и реальные проекты.
Rust сложный не потому, что «невозможный», а потому что его нельзя учить хаотично. Здесь как раз есть нормальная траектория: от первых строк кода до уверенной разработки.
Сохраняйте себе и отправляйте тем, кто всё ещё боится borrow checker.
Rust + LLM: новая и сильная “ОПГ” против C++ и его друзей…
Есть такая штука с Borrow Checker - он ненавидит людей. Не потому, что он плохой, а потому, что требует держать в голове графы данных всего приложения всё время, пока пишешь. Люди устают, раздражаются, и в итоге - unsafe, чувство стыда перед собой и коллегами, и понеслась. А LLM на это просто… скажем, кхм, “не важно”. Ну, надо так надо. LLM итерирует. И самое забавное - ей можно запретить unsafe прямо в промпте, и она не будет искать обходные пути(ну, может, разок другой - Opus попробует, но это ловится простым поиском по файлам, даже PVS-Studio не нужен, хотя с ним было бы фееричнее). Скорее всего, LLM просто найдёт решение в рамках safe Rust. И это круто.
Про Python и JS - там ведь основная проблема не скорость даже(и синтаксически значимые пробелы у некоторых), а то, что деплоится не программа, а среда. Интерпретатор, зависимости, версии, “а на проде другой питон”… Сейчас с линковщиком от Zig можно прямо из Windows собрать бинарник под Linux - статически, без танцев(привет musl!), одним пинком. И это не какой-то хак, это просто работает. Получаешь один файл, который либо запустится, либо нет - без сюрпризов в середине.
C++ тут проигрывает не потому, что он сложный или плохой - он интересный, мощный, с огромной историей и экосистемой. Но именно эта мощность становится проблемой когда код - генерирует LLM(можно выстрелить себе в ногу из гранатомёта, и, самое страшное - не заметить этого). Модель получает слишком много способов сделать что-то, и часть из них - UB. Rust убивает целый класс таких подходов к реализации на уровне компилятора. Это не договорённость и не линтер - это просто не скомпилируется.
Мне кажется, уникальность этой связки тут в том, что задачи разделились очень чисто: LLM думает про логику, компилятор думает про корректность. И они не мешают друг другу. В C++ - см. выше. Именно то, что делает Rust тяжёлым для людей(кроме евангелистов и стримеров), делает его почти идеальным для этой связки.
Ну и если кто был травмирован неудачным опытом с “вайб-кодингом”, и сложилось впечатление, что вся эта пляска с LLM, это не серьёзно - попробуйте отложить китайщину(MiniMax, GLM, DeepSeek...), взять фронтир-модель типа “OpenAI Codex GPT-5.5 на XtraHigh” - и дать ей хотелку в виде описания какого-нибудь серверного приложения на Rust, и просто посмотреть что будет через 15-20 минут. Забейте на клоунов со “змейкой” и прочей мелочёвкой из бенчмарков на ютубе, попробуйте реальную задачку(многохопывый релей между серверами со своим протоколом КВН например и клиентами для Win/Linux). Оно сделает. Быстро. Качественно. Это довольно странное ощущение, честно говоря, видеть такое…
Просто мысли вслух, хотелось поделиться)
-s. TekMetrics certified “Master C programmer”, July 1999
Я давний пользователь Geeknote - это cli для Evernote. Несколько лет назад проект застрял на втором Питоне - и никто не хотел его портировать на третий. Я ждал что кто-то займётся этим - но пришлось самому - так что я форкнул, починил, и даже связался с Виталием Роденко - одним из создателей Geeknote и администратора на PyPI, чтобы получить право туда пушить. За десяток лет я видел как Geeknote переходил из одни руки в другие - и как он забрасывался, и через несколько лет находился новый мантейнер. Было забавно осознать, что теперь и я стал мантейнером программного продукта, который всегда установлен на все мои машины.
Как и большинство из нас, я стал пробовать LLM - как замену поиску, для анализа кодов, советов, и вот наконец - несколько проектов - даже не читая кода - только давая команды и тестируя результат. Известная шутка - переписать на Rust. Почему бы у нет - Geeknote не велик - около пяти тысяч строк на Питоне, что я и попробовал - через Codex gpt-5.5. Несколько десятков итераций, "добавь это", "добавь то", "пропали теги", "пропала анимация" - и за несколько часов я получил рабочий Geeknote на Rust, назвал его reeknote.
Результат: быстрее работает, раза в два. Теперь буду им пользоваться.
P.S.: CLI хороши для перфоманса, SSH, быстрее разработка без GUI, а ещё похоже и для LLM - можно попросить сохранить ответ в Evernote. Как и прочие интеграции, в том числе в скриптах.
Это не туториал, а карта‑шпаргалка, чтобы не потеряться среди десятка библиотек и быстро понять, куда копать под свою задачу.
Перед выбором любого фреймворка — откройте areweguiyet.com. Там видно зрелость, лицензию, платформы и число скачиваний. Лучшая страховка от «библиотека умерла через месяц».
Чтобы не путаться в терминах, стоит уточинить, в чем разница архитектурных подходов.
Immediate Mode (пересобирается каждый кадр). Суть: «Опиши, что должно быть на экране прямо сейчас». Не «создай кнопку и запомни её», а линейная пересборка каждый кадр: «если сейчас здесь нажали — сделай действие, и в любом случае нарисуй кнопку вот здесь».
— egui, Ply, Rust bindings dear imgui
Retained Mode (дерево виджетов в памяти). Суть: «Измени то, что уже есть». Один раз описывается структуру UI (создал кнопку, положил в layout), а потом меняются её свойства: текст, цвет, видимость. Кнопка «живёт» в памяти как объект.
— GTK и FLTK.
Reactive (реактивный режим). Суть: «UI — это функция от состояния». UI описывается как отображение некоторого состояния. Когда состояние меняется, фреймворк сам пересчитывает, что именно в UI нужно обновить.
Hybrid Mode (декларативный API + оптимизированный retained‑рендеринг)
— GPUI(Zed)
Теперь — к конкретным фреймворкам, которые сейчас на слуху.
Tauri. Аналог Electron. Бэкенд пишется на Rust, фронтенд — с помощью JS фреймворков (React, Vue, Svelte). Но архитектура платформы не ограничивается этим стеком. Благодаря поддержке WebAssembly можно использовать и полностью Rust-решения. Например, фреймворк Leptos компилируется в WASM-модуль и запускается во встроенном WebView Tauri.
Egui. Не требует отдельного связывания UI с моделью данных. Отрисовка интерфейса описывается в коде линейно, без колбэков и событий, что ускоряет прототипирование. При этом Egui поддерживает адаптивный рендеринг.
Iced. Кроссплатформенная библиотека, вдохновленная Elm Architecture (TEA). Типобезопасность и простота использования заявляются как ключевые принципы.Проект находится в активной разработке.
Dioxus. Фреймворк, похожий на React. Использует собственный Virtual DOM и макрос rsx!, позволяя писать HTML‑подобный код прямо внутри Rust. Dioxus Native: экспериментальный рендерер на базе WGPU, отрисовывает дерево компонентов напрямую, без использования WebView или CSS‑движка. UI‑логика и бэкенд выполняются в одном процессе, в отличие от Tauri, где фронтенд и бэкенд разделены.
Slint. Фреймворк, нацеленный на легковесность, вплоть до использования на встраиваемых устройствах. Для описания интерфейса используется собственный язык разметки (.slint), для кода доступны биндинги к Rust, C++ и JavaScript. Предлагает инструмент Live‑Preview для визуальной разработки.
Xilem. Экспериментальный фреймворк от команды Linebender на основе оригинальной архитектуры (Xilem architecture), вдохновленной Elm, SwiftUI и Flutter. Разрабатывается как преемник библиотеки Druid, работа над которой была прекращена.
Следующий шаг.
Выбор фреймворка по документации и отзывам — это половина дела. Вторая половина — попробовать его руками на минимальном примере.
Многие Rust‑фреймворки требуют системных библиотек для графики и оконных систем. Настройка «на голой» машине может занять ощутимое время и зависеть от ОС. Чтобы не разворачивать отдельное окружение под каждый вариант, удобно использовать dev‑контейнеры в VS Code. Контейнер фиксирует эту настройку один раз, и она работает одинаково на Windows, macOS и Linux (с учётом специфики Docker).
Преимущества контейнеров:
Изолированное, воспроизводимое окружение для каждого фреймворка.
Отсутствие конфликтов версий и зависимостей на основной машине.
Возможность переключаться между фреймворками параллельно, не теряя контекст.
проверка интерфейса
Этот подход позволяет за пару часов собрать минимальные приложения в 3–4 фреймворках и сравнить ощущения от кода, скорость сборки, поведение окна, качество документации к старту.
Наконец-то поднял публичную демку Aximo на Hugging Face Spaces 🎙️
Это локальный speech-to-text API, который работает на CPU, использует Parakeet v3 и позволяет тестировать транскрибацию прямо из браузера через Swagger UI с записью с микрофона, о котором писал в одном из своих предыдущих постов.
Aximo — локальный STT API на Rust для CPU-only inference
Недавно сделал Aximo — self-hosted микросервис для speech-to-text, который можно запускать локально без облака и без зависимости от внешних SaaS.
Идея была довольно простая: хотелось собрать вменяемый STT API, который работает на CPU, поднимается как обычный сервис и при этом остается достаточно прозрачным с инженерной точки зрения.
В основе — Rust, локальный inference через Parakeet v3, HTTP API для обычной транскрибации и WebSocket-слой для realtime-сценариев. Из коробки также добавил Docker, OpenAPI и разбиение на несколько crates, чтобы проект не выглядел одноразовой демкой и оставался удобным для дальнейшего развития.
На текущем этапе это скорее крепкий MVP, чем законченный production-ready продукт, но уже сейчас сервис можно запускать локально, тестировать на своих аудиоданных и использовать как основу для дальнейших экспериментов.
Из интересного: доработал Swagger, добавив возможность отправки записи с микрофона:
Может многие и не задавались вопросом, но я думаю это интересная тема, которую можно прояснить.
Допустим, мы пилим какой-нибудь интересный сервис. Ну вот написали мы бэкенд, а как пользователь будет с ним взаимодействовать? По моему мнению сейчас есть несколько основных вариантов: веб-приложение, мобильное прилижение и телеграм-бот. Конечно, если есть много лишних рук, можно написать всё и сразу, но это не мой варик.
В моём случае каждая строчка кода дорога. Работаю я в одиночку.
Сейчас я разрабатываю сервис по изучению иностранных слов и на основе моего опыта хочу сделать некое сравнение этих подходов.
Телеграм-бот
Вообще начал я user-side телеграм-ботом. Поначалу это, конечно, может, и казалось достаточным, но всё-таки для какого-либо функционала простого телеграм-бота не хватает.
Да и ещё в добавок в Russian Federation начали блокировать тг, поэтому пользоваться им приходится с костылями, а бот перестал стабильно работать.
Вывод: тг-бот - для простого функционала, но довольно нестабилен и ограничен функционал
Хотя, есть mini-app, но в их подробности я не вдавался.
Веб-приложение
Следующий очень популярный вариант - веб-приложение. Этот вариант намного более гибок. Но по моему мнению всё же не максимально стабилен, так как его работа зависит от состояния браузера. Но у этого варианта есть огромное преимущество: он работает на всех устройствах, на которых можно открыть веб-сайт. Это, так сказать, униварсальный вариант.
Но есть проблема. Допустим, человек пользуется чем-то на постоянной основе и хочет максимально быструю и адаптированную работу. Он будет постоянно заходить в браузер и копаться во вкладках? Или лучше тогда выбрать мобильное приложение?
Мобильное приложение
Наверное самый сложный и трудозатратный, но по моему мнению в нынешнее время самый перспективный вариант. Да, по сравнению с веб-собратом работать оно будет не везде, а только на мобилке, при том на определённой (IOS или Android).
Но при этом мобильное приложение даёт реализовать максимально удобное и оптимизированное управление, потому что почти всё можно настроить под свой продукт.
Небольшая сводка
Для чего бот: для простого функционала. Можно использовать как небольшое дополнение к какой-либо инфраструктуре. Этот подход наименее трудозатратен.
Для чего веб-приложения: для продуктов, где нужна кроссплатформенность и довольно широкая кастомизация. Подход не сильно трудозатратный.
Для чего мобильные приложения: для продуктов где важна максимальная быстрота и удобство и наилучшии возможности кастомизации. По моему мнению наиболее подходит для каких-то интересных и уникальных сервисов. Это самый трудозатратный подход из перечисленный, но в некоторых случаях он более чем себя оправдывает.
Что кому разрабатывать в первую очередь зависит от самого проекта, универсального варианта здесь нет по моему мнению.
PS: интересно узнать чужое мнение, так как возможно здесь много субъективщины.
Открытый проект Cheat-Sheets предоставляет учебны материалы для Python, Rust, Swift, JavaScript, Kotlin, Go, Git, и других проектов. Там есть все важнейшие концепции, правила, стили программирования, фреймворки, библиотеки и прочее. Внутри также курсы по Git, Docker, базам данных, а также алгоритмам. Все материалы разделили по уровням сложности, к каждой главе есть контрольные вопросы и десятки задач. Все концепции авторы объясняют на конкретных примерах и разжевывают до последней строчки кода.
Работаем из Java с устройствами с serial-интерфейсом (COM и USB) без JNI — по TCP.
Раньше пользовались rxtx, затем jssc. После очередных крэшей JVM в коде нативных библиотек решил не выбирать замену, а отказаться от них полностью.
В качестве прокси serial-TCP можно взять ser2net или поэкспериментировать с socat, но я запилил свое простое (Rust, mio), под конкретную задачу:
Запускается из основного приложения, свой процесс для каждого устройства
Конфигурация через аргументы запуска и переменные окружения
Завершает работу при отсутствии или отключении устройства (для USB), отключении или отсутствия подключения TCP-клиента
В качестве TCP-клиента Netty. Для интеграции с легаси данные читаются в кольцевой буфер ( OneToOneRingBuffer из agrona), а оттуда уже используются по месту в удобное время.
За счет неблокирующего чтения и использования epoll в mio и Netty минимальные задержки, моментальное оповещение о наличии данных (без Thread.sleep) и об отключении USB-устройства.
Задержки настолько меньше, что пришлось адаптировать кривой код, который не был готов к тому, что драйвер железного serial-порта в Linux отдает данные порциями по 8 байт. Решилось реализацией ByteToMessageDecoder, где возможно, а где нет — буферизацией на стороне прокси и отправкой по таймеру.
Для надежной работы уменьшаем и выравниваем буферы записи, пишем через writeAndFlush с ожиданием завершения, чтобы устройство успевало читать.
Бонус: можно работать с устройством, подключенным к другому системному блоку (например, для разработки) и использовать TCP-эмуляторы вместо реальных устройств без изменения кода интеграции.
Слышу уже от второго человека, что язык Rust не дает нормально работать с указателями в связанных списках, деревьях и графах (в моей вселенной ЯП без этого - это как свадьба без невесты). Взял ChatGPT, задал промпт: "write a code to insert a node into a doubly linked list in rust". Оно сгенерило нечто с кучей дополнительных слов, которых не было ни в Си, ни в Паскале 40 лет назад: borrow, as_ref, and_then, upgrade, map, downgrade, Some, clone, borrow_mut. Это все реально нужно или они там совсем озверели?
Российская компания Selectel, развивающая Linux-дистрибутив Selectel OS на пакетной базе Debian, представила инициативу OpenFix, в рамках которой начнёт выплачивать энтузиастам денежные вознаграждения за участие в работе над задачами, связанными с развитием и исправлением ошибок в открытом ПО. Код выполненных проектов будет публиковаться под пермиссивной лицензией с сохранением авторства участников.
Вознаграждения назначается индивидуально и выплачивание после принятия изменения в Debian или Ubuntu и закрытия сообщения об ошибке.
Предложено три направления деятельности, выполнение задач в которых Selectel готов оплачивать:
переписывание известных открытых проектов на язык Rust. В настоящее время доступны три задачи, связанные с переписыванием с языка С на Rust кода проектов xz, c‑ares и libxml2 c сохранением поведения оригинала.
вознаграждение за переписывание библиотек libxml2 и c‑ares и определено в 350 тысяч рублей, а библиотеки xz в 200 тысяч рублей, но в случае xz указано, что достаточно переписать критические части библиотечных обвязок и связать с существующей Си‑реализацией алгоритма LZMA.
формирование и последующее сопровождение (подготовка обновлений) пакетов для Debian GNU/Linux. Приложения для которых предлагается создать deb‑пакеты (c опциональным продвижением созданного пакета в Debian Unstable): apache‑pulsar, bash‑it, bazel, bitwarden‑cli, composefs, cve‑bin‑tools, doh‑cli, dupd, dyff, firecracker, griddb, jailhouse, keycloak, oauth2-proxy, phoronix‑testsuite, photodedupe, purritobin, shh, skim, sssh‑tpm‑agent, uv, vaultwarden. Размер вознаграждения от 30 до 160 тысяч рублей. Премии меньше 50 тысяч рублей определены для uv, dyff, doh‑cli, purritobin и bash‑it, а больше 100 тысяч для jailhouse, bazel, sssh‑tpm‑agent, keycloak, griddb, firecracker и apache‑pulsar.
Исправление ошибок в существующих открытых проектах. Участники на своё усмотрение могут выбирать проблемы, подтверждённые в системах отслеживания ошибок Debian и Ubuntu (Launchpad), после чего согласовать возможность получения вознаграждения за их исправление с Selectel. Вознаграждения назначается индивидуально и выплачивание после принятия изменения в Debian или Ubuntu и закрытия сообщения об ошибке.
Лутаем Open Source #24. Они наконец-то починили MongoDB! Перенеся его на PostgreSQL...
DocumentDB – БД от Microsoft, которая состоит из 3-х частей:
PG расширение, добавляющее BSON формат (написанный, на С)
CRUD API поверх него (С)
Сервис трансляции Mongo Query в SQL (Rust)
GitHub - documentdb/documentdb: MongoDB-compatible database engine for cloud-native and open-source workloads. Built for scalability, performance, and developer productivity.
И вроде как: "PG – классная база, а MongoDB Query + BSON популярные технологии" – и можно было бы поразмышлять чем это круто, но сначала важно ответить на один туманный вопрос: "кому такая БД может быть нужна?"
Классический PG
Сначала рассмотрим кейс, когда мы накладываем DocumentDB на обычный PostgreSQL.
Те, кто используют MongoDB если попробуют переехать на такой сэтап столкутся с тем, что:
Там нет шардинга (и насколько бы он не был сложно реализован в MongoDB, он есть и им активно пользуются)
Придется использовать двойной тулинг: Compas, чтобы наблюдать за корректностью данных с MongoDB Query, и SQL если надо посмотреть что там внутри
MongoDB поддерживает Uncommitted Read и Write Majority, что странно накладывается на PG: если разраб достаточно продвинутый и намеренно использовал Uncommitted, то с PG он потеряет скорость и Availability из-за PG Committed, а если он использовал Write Majority, то PG не совсем дает такую гарантию (обвал диска при WAL репликации – менее надежен, чем Write Majority)
А самое главное: когда ты работаешь с MongoDB ты можешь открывать 1000 коннекшенов и он вполне себе все это сожрет, потому что (1) коннекшен это тред, (2) при запросах нет никакой проверки реляционной целостности, да и в целом проверка сильно проще, чем в PG, а значит придется потанцевать с пуллерами и даже менять где-то запросы, чтобы не упасть по скорости
То есть, у mongo-юзеров это заберет все особенные фичи MongoDB и при этом не даст фишки PostgreSQL.
Distributed PG-like
А что, если мы положим DocumentDB на что-нибудь из серии CockroachDB, YugabyteDB, AWS Aurora, Citus или Neon?
Все 3 проблемы решаются:
Шардинг из коробки
Достаточно высокая скорость записи и чтения
Отсутствие проблем с коннектами
В такой ситуации DocumentDB начинает играть новыми красками.
Но если в Neon и Citus (и может YugabyteDB) еще есть шанс добавить текущий DocumentDB BSON плагин, то в для других представителей придется писать его с нуля (причем под каждый свой, потому что они построены каждый на своем KV хранилище).
Переезд в Linux Foundation
А еще они сейчас в процессе переезда из Microsoft в Linux Foundation, из плюсов они будут полностью под MIT лицензией и пейвола, за который будут прятать полезные фичи, из минусов, Microsoft могут и забросить, а никто другой не подхватить.
Итоги
Неоднозначная технология, пока имеет смысл в каких-то тонких кейсах, но в общем и целом, не вижу пока где тут middle-ground, может, вы что-то подскажете?
Привет Хабр! Это мой первый пост, и я просто хотелось спросить, стоит ли уходить в Go? У меня есть небольшая база в программировании, делал сайты на реакт и ларавел, реализовывал бэкенд с Солид и паттернами, писал на нативном пхп файловые обменники и апи. Не много знаю базы данных соответственно, гит, докер. Сейчас засматриваюсь на Go, где то вычитал что мол крутая штука для бигтехов в России, а сам я студент и пока сижу на шее у родителей, но в следующем году я окончу к курс, и хочу где то месяца за 4-5 изучить все нужное в го и во всех других сопутствующих технологиях для разработки высоконагруженных приложений и микросервисов и всякого подобного. Стоит ли сворачивать на этот путь, или добить стек ларавел плюс вью? Немного боюсь, так как слышал что в го нужны уже 25 летние синьоры со стажем работы минимум в 20 лет, но и не хочется проторчать всю жизнь в челябинской галере на фуллстеке за 70 деревянных на руки.
Спойлер: принципиальное решение проблемы - найдено. Купил маленькую коробочку на "мейнстримной" архитектуре, на которой все цветет и пахнет.. кроме моего внутреннего(ну и внешнего, че уж там) инженера) Так что решение выкинуть железку - можно не предлагать
Так вот, пока я писал код, и готовил сборочные скрипты ничто не предвещало беды - я спокойно потестил код локально, написал Dockerfile для сборки на poetry. Настало время развернуть это все на NAS - казалось бы ARM уже давно мейнстрим, но тут понеслось
python как всегда лишь удобный биндинг к куче платформозависимого кода) подавляющее большинство python-зависимостей под arm/v7 приходится компилировать
готовых бинарников polars под arm/v7 - тоже нет
Никаких блокеров к тому, чтобы собрать polars под arm/v7 я не нашел. Но скомпилить его нативно на 4Гб ОЗУ - не получится, даже с минимальными оптимизациями. Нужна кросс-компиляция. Благо с rust и maturin(которым собирается polars) - это несложно, target armv7-unknown-linux-gnueabihf в хорошем tier-е поддержки
забегая чуть вперед указываем окружение для сборки аллокатора jemalloc(по умолчанию в polars) под 32k страницу
Итак, усложняем сборку Docker(см. repro) - используем кросс-компиляцию, энв-переменные, QEMU, охапку дров и теперь у нас есть приложка, которая успешно стартует в докере на целевой железке. Вот только за рамками самых примитивных тестов - OOM-ится, причем память точно есть, никакой OOM-киллер процесс не убивает(на всякий случай смотрим лимиты cgoup) - оно "шамо":
memory allocation of 1345920 bytes failed
(подробные логи можно посмотреть по ссылкам в конце поста)
Что же делать?
пробуем mimalloc - он использует для конфигурации рантайм(getconf), эффект - тот же
пробуем env-крутилки, в частности arena_reserve может стоит просто меньше резервировать - но нет, просто больше попыток, но по факту все равно OOM
И вот на этом месте я застрял. Я не большой спец по системному программированию - не понимаю куда копать
Общение с поддержкой QNAP свелось к
Справедливости ради они еще дали советов что попробовать, но это я уже попробовал до них
Пытался отлаживать приложение в gdb - никаких аномальных трейсбэков во время OOM не увидел: rust честно пытается аллоцировать большой raw_vec(трейс есть в вопросе на stackoverflow)
Как-то глубоко копать переменные не получается, т.к. дебаг-символы для бинарника polars получаются слишком большими
BFD: error: /app/.venv/lib/python3.12/site-packages/polars/polars.abi3.so(.debug_str) is too large (0x498a9fd1 bytes)
Я сделал небольшое repro на голом расте - там эта проблема не воспроизводится, значит базово бинарная совместимость - в порядке
Есть несколько гипотез, но я не знаю как их проверить
возможно, кривая вся адресация, но ее проверить я тоже не могу
возможно, стоит чего-нибудь половить в ядре bpf-ом, но что..
кастомное ядро 4.2.8 кастомный дистриб(QTS) не богат средствами отладки - как я понял там запускается busybox набор утилит
А мне бы хотелось все-таки дожать диагностику и однозначно ответить на вопрос: это лыжи не едутя не умею собирать приложения под нужное окружение или все-таки целевая платформа не умеет выполнять корректно собранное? Не потому что эту проблему нельзя решить по-другому, а потому что в том, чем пользуешься - хочется разбираться.
Пишите в комментах ваши соображения. Если что-то удастся прояснить - буду держать читателей поста в курсе
