Rust *

Российская компания 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-х частей:

1. PG расширение, добавляющее BSON формат (написанный, на С)

2. CRUD API поверх него (С)

3. Сервис трансляции Mongo Query в SQL (Rust)

Для кого это?

И вроде как: "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, может, вы что-то подскажете?

P.S.

А еще приглашаю вас к обсуждению в свой паблик в телеграмме 🦾 IT-Качалка Давида Шекунца 💪

Привет Хабр! Это мой первый пост, и я просто хотелось спросить, стоит ли уходить в Go? У меня есть небольшая база в программировании, делал сайты на реакт и ларавел, реализовывал бэкенд с Солид и паттернами, писал на нативном пхп файловые обменники и апи. Не много знаю базы данных соответственно, гит, докер. Сейчас засматриваюсь на Go, где то вычитал что мол крутая штука для бигтехов в России, а сам я студент и пока сижу на шее у родителей, но в следующем году я окончу к курс, и хочу где то месяца за 4-5 изучить все нужное в го и во всех других сопутствующих технологиях для разработки высоконагруженных приложений и микросервисов и всякого подобного. Стоит ли сворачивать на этот путь, или добить стек ларавел плюс вью? Немного боюсь, так как слышал что в го нужны уже 25 летние синьоры со стажем работы минимум в 20 лет, но и не хочется проторчать всю жизнь в челябинской галере на фуллстеке за 70 деревянных на руки.

Быстрая замена mypy на Rust'е: pyrefly

Еще одно видео про еще один новый тайпчекер для питона на расте! Много их нынче стало.

В видео:

• Обсуждаем первую версию: pyre-check, обсудили taint analysis

• Сравниваем pyrefly с ty и mypy

• Смотрим на внутреннее устройство

• Применяем на реальном проекте

Ключевые ссылки из выпуска:

• Доклад о pyrefly на PyCon: https://youtu.be/ZTSZ1OCUaeQ?si=s_DPOOzsdeTk5Uqo

• pyrefly vs ty: https://blog.edward-li.com/tech/comparing-pyrefly-vs-ty (сильно советую!)

Вывод: пока очень сырой, много багов, но быстрый. Ключевой вывод: отлично, что есть конкуренция.

Инженерной боли пост. С надеждой на дельные советы

Все началось с pet-проекта, который использовал polars(сорцы) и должен был крутиться в Docker на моем домашнем NAS, в следующей конфигурации:

• CPU arm/v7 32-bit, Annapurna Labs Alpine AL314 Quad-core ARM Cortex-A15

• 4Гб RAM

• ОС QNAP QTS на linux ядре 4.2.8 с увеличенным до 32k размером страницы памяти, и с официальной поддержкой Docker

Спойлер: принципиальное решение проблемы - найдено. Купил маленькую коробочку на "мейнстримной" архитектуре, на которой все цветет и пахнет.. кроме моего внутреннего(ну и внешнего, че уж там) инженера) Так что решение выкинуть железку - можно не предлагать

Так вот, пока я писал код, и готовил сборочные скрипты ничто не предвещало беды - я спокойно потестил код локально, написал Dockerfile для сборки на poetry. Настало время развернуть это все на NAS - казалось бы ARM уже давно мейнстрим, но тут понеслось

1. python как всегда лишь удобный биндинг к куче платформозависимого кода) подавляющее большинство python-зависимостей под arm/v7 приходится компилировать

2. готовых бинарников polars под arm/v7 - тоже нет

3. Никаких блокеров к тому, чтобы собрать polars под arm/v7 я не нашел. Но скомпилить его нативно на 4Гб ОЗУ - не получится, даже с минимальными оптимизациями. Нужна кросс-компиляция. Благо с rust и maturin(которым собирается polars) - это несложно, target armv7-unknown-linux-gnueabihf в хорошем tier-е поддержки

4. забегая чуть вперед указываем окружение для сборки аллокатора jemalloc(по умолчанию в polars) под 32k страницу

Итак, усложняем сборку Docker(см. repro) - используем кросс-компиляцию, энв-переменные, QEMU, охапку дров и теперь у нас есть приложка, которая успешно стартует в докере на целевой железке. Вот только за рамками самых примитивных тестов - OOM-ится, причем память точно есть, никакой OOM-киллер процесс не убивает(на всякий случай смотрим лимиты cgoup) - оно "шамо":

memory allocation of 1345920 bytes failed

(подробные логи можно посмотреть по ссылкам в конце поста)

Что же делать?

1. пробуем mimalloc - он использует для конфигурации рантайм(getconf), эффект - тот же

2. пробуем env-крутилки, в частности arena_reserve может стоит просто меньше резервировать - но нет, просто больше попыток, но по факту все равно OOM

3. помимо jemalloc и mimalloc не работают также: стандартный аллокатор rust(чем бы он ни был), libc-аллокатор и версия mimalloc, установленного как системная библиотека

И вот на этом месте я застрял. Я не большой спец по системному программированию - не понимаю куда копать

• Общение с поддержкой 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 набор утилит

В итоге я завел

• вопрос на stackoverflow - там есть логи аллокатора и трейсбэк

• ишью в репозитории mimalloc

• repro-проект с минимальным примером на котором проблема воспроизводится

Но активности там не очень много(

А мне бы хотелось все-таки дожать диагностику и однозначно ответить на вопрос: это лыжи не едутя не умею собирать приложения под нужное окружение или все-таки целевая платформа не умеет выполнять корректно собранное? Не потому что эту проблему нельзя решить по-другому, а потому что в том, чем пользуешься - хочется разбираться.

Пишите в комментах ваши соображения. Если что-то удастся прояснить - буду держать читателей поста в курсе

TUI Rust, это Хабр. Хабр, я нашёл тебе годноту.

По этой ссылке https://www.youtube.com/watch?v=rWMQ-g2QDsI обнаружилось видео (11:16) с тучей прелюбопытнейших отсылок объединённых идеей использования Rust для написания консольных приложений.

А за ним занятный канал, Автор которого, помимо носительности качественного английского языка, вроде как является приверженцем следующих идей

• не плоди сущности без необходимости

• используй меньше чтобы сделать больше

• велик C и Rust наследует ему

• всё преходяще, кроме вечного

Рекомендуется к ознакомлению вкатунам и начинающим пользы ради, а остальными удовольствия для.

Конкретика: Uutils, Fish, Nushell, Ripgrep, Fd, Bat, Eza, Zoxide, Xh, Zellij, Gitui, du-dust, dua, starship, yazi, hyperfine, evil-helix, bacon, cargo-info, fselect, ncspot, rusty-man, delta, ripgrep-all, tokei, wiki-tui, just, mask, mprocs, presenterm, kondo, bob-nvim, rtx, espanso.

Генерация последовательностей случайных чисел с помощью DRAM — возможно ли это? Проверим с помощью RISC-V

На основе DRAM мы создали модель одноканального источника шума, который возвращает один случайный бит за один условный такт. Память разбита на два региона, которые не пересекаются. Первый отвечает за инициализацию одноканального сигнатурного анализатора (ОСА), который инициализирует второй подобный анализатор. Затем мы сможем взять другой регион памяти и заново инициализировать первый ОСА, что абсолютно случайным образом изменит выход второго ОСА. Такая схема позволит не перезагружать память после каждой генерации числовой последовательности — ведь в реальных проектах это, как правило, невозможно. 

Далее мы направляем данные из DRAM PUF в два подмодуля — постобработки, а также тестирования, анализа и оценки качества данных. Первый частично запускается на «железе», второй — на собранных данных на машине хоста.

Для постобработки мы протестировали шесть комбинаций. Последняя нам кажется наиболее перспективной:

• сырые данные,

• чистый корректор фон Неймана,

• одноканальный сигнатурный анализатор,

• чистый корректор фон Неймана + одноканальный сигнатурный анализатор,

• одноканальный сигнатурный анализатор + чистый корректор фон Неймана,

• многоканальный сигнатурный анализатор (МСА).

Зимняя школа RISC-V дала начало множеству интересных проектов. В отдельной статье мы рассказали об одном из них, где команда из БГУИР проверила гипотезу о наличии PUF в динамической памяти и создала модель одноканального источника шума. А затем реализовала постобработку и тестирование, измерила производительность генератора и оптимизировала код.

Новый тайпчекер для Python от авторов ruff и uv, написанный на Rust

Вышло видео про новый тайпчекер и lsp: ty (старое название red-knot) от авторов ruff и uv. Пока по первым впечатлениям – бомба! Не смотря на версию 0.0.0a8 🌚

Из плюсов:

• Быстрый

• На расте

• Куча новых фичей для типов

• Полная спецификация

• Интеграция с ruff и IDEшками

Из минусов:

• Пока есть баги (но их поправят, конечно же)

• Нет плагинов (и скорее всего никогда не будет)

• Софт от молодой и маленькой компании

• Как сделать поддержку ty и mypy вместе? А если использовались ty_extensions?

Обсуждение: а как вам проект? Успели попробовать?

Определение переменных и вызов функций в Rust

Взглянем на код:

fn main() {
	let a = 10;
	let b: i32 = 20;
	let c = 30i32;
	let d = 30_i32;
	let e = add(add(a, b), add(c, d));

	println!("(a + b) + (c + d) = {}", e);
}

fn add(i: i32, j: i32) -> i32 {
	i + j;
}

Определение функции начинается с ключевого слова fn. Точка входа в Rust-программы - это функция main. Она не получает никаких аргументов и не возвращает никаких значений.

В следующих строках let используется для привязки переменной. По умолчанию переменные неизменяемые, то есть предназначены только для чтения, а не для чтения-записи.

Также можно указывать конкретный тип данных разными способами:

1. Через двоеточие

2. Числовые литералы могут включать аннотации типов

В последней строке вызывается макрос println! для вывода текста.

В строках используются двойные, а не одинарные кавычки, а для символах используются одинарные.

И наконец, функция add имеет аргументы с указанными типами данных и возвращает нужный тип данных. Как вы видите, возврат значения происходит автоматически, для этого не используются ключевые слова по типу return.

Поговорим о создании переменных. В Rust они бывают мутабельными (mutable) или немутабельными (unmutable), то есть изменяемые и неизменяемые. Неизменяемые переменные можно сравнить с константами.

Разберем пример:

fn main() {
	let a = 10;
	a = 15;
}

Если мы скомпилируем данную программу, то получим ошибку:

error[E0384]: cannot assign twice to immutable variable `a`
  --> src\main.rs:25:5
   |
24 |     let a = 10;
   |         - first assignment to `a`
25 |     a = 2;
   |     ^^^^^ cannot assign twice to immutable variable
   |
help: consider making this binding mutable
   |
24 |     let mut a = 10;
   |         +++

Т.к. все переменные в rust изначально неизменяемые, то мы не можем изменить переменную. Компилятор нам подсказывает, что для изменения значений надо добавить ключевое слово mut.

Добавим:

fn main() {
	let mut a = 10;
	a = 15;
	println!(a);
}

Программа успешно скомпилируется и мы получим 15.

Но также существуют константы. Подобно неизменяемым переменным, константы — это значения, которые связаны с именем и не могут изменяться, но между константами и переменными есть несколько различий. Во-первых, нельзя использовать mut с константами. Константы не просто неизменяемы по умолчанию — они неизменяемы всегда. Для объявления констант используется ключевое слово const вместо let, а также тип значения должен быть указан в аннотации.

fn main() {
	const THREE_HOURS_IN_SECONDS: u32 = 60 * 60 * 3;
}

Имя константы - THREE_HOURS_IN_SECONDS, а её значение устанавливается как результат умножения 60 (количество секунд в минуте) на 60 (количество минут в часе) на 3 (количество часов, которые нужно посчитать в этой программе). Соглашение Rust для именования констант требует использования всех заглавных букв с подчёркиванием между словами. Компилятор может вычислять ограниченный набор операций во время компиляции, позволяющий записать это значение более понятным и простым для проверки способом, чем установка этой константы в значение 10 800.

Константы существуют в течение всего времени работы программы в пределах области, в которой они были объявлены. Это свойство делает константы полезными для значений в домене вашего приложения, о которых могут знать несколько частей программы, например, максимальное количество очков, которое может заработать любой игрок в игре, или скорость света.

Еще момент - в листингах выше мы не декларировали тип данных переменных.

Вообще, типизация в Rust несет полу строгий характер. Разработчик может не указывать тип данных. Это может укоротить код, если сама программа небольшая. Но всегда рекомендуется описывать тип данных, иначе могут возникнуть ошибки. Например:

fn main() {
	let mut a = 10;
	a = "hello"; // возникнет ошибка
}

Мы не можем поменять тип данных, которые хранятся в переменной. Обычно типы данных указывают так:

fn main() {
	let mut a: i32 = 10;
	a = 15;
}

Область видимости и затенение переменных в Rust

Затенение переменных

В Rust, также как и в большинстве ЯВУ, можно "затенять переменные", то есть создавать вторую переменную с таким же именем, используя значение первой переменной:

fn main() {
    let x = 5;

    let x = x + 1;

    {
        let x = x * 2;
        println!("The value of x in the inner scope is: {x}");
    }

    println!("The value of x is: {x}");
}

Эта программа сначала привязывает x к значению 5. Затем она создаёт новую переменную x, повторяя let x =, беря исходное значение и добавляя 1, чтобы значение x стало равным 6. Затем во внутренней области видимости, созданной с помощью фигурных скобок, третий оператор let также затеняет x и создаёт новую переменную, умножая предыдущее значение на 2, чтобы дать x значение 12. Когда эта область заканчивается, внутреннее затенение заканчивается, и x возвращается к значению 6. Запустив эту программу, она выведет следующее:

The value of x in the inner scope is: 12
The value of x is: 6

Область видимости

Связывание переменных происходит в локальной области видимости — они ограничены существованием внутри блока. Блок — это набор инструкций, заключённый между фигурными скобками {}.

fn main() {
    // Эта переменная живёт в функции main
	let long_lived_binding = 1;  
	let shadowed_variable = 1;  
	  
	// Это блок, он имеет меньшую область видимости, чем функция main  
	{  
	    // Эта переменная существует только в этом блоке  
	    let short_lived_binding = 2;  
	    let shadowed_variable = 2;  
	  
	    println!("shadowed variable: {}", shadowed_variable);  
	  
	    println!("inner short: {}", short_lived_binding);  
	}  
	// Конец блока  
	println!("shadowed variable: {}", shadowed_variable);  
	  
	println!("outer long: {}", long_lived_binding);
}

xan, волшебник CSV

→ https://github.com/medialab/xan

xan — это приложение командной строки, которое можно использовать для обработки CSV-файлов непосредственно прямо из шелла.

Написан на Rust, а значит — быстрый, почти не жрёт память и без проблем обрабатывает очень большие CSV-файлы (гигабайты). Способен выполнять некоторые задачи параллельно (за счет многопоточности).

Сделан для удобного просматра, фильтрования, фрагментации, агрегации, сортировки, объединения CSV-файлов и предоставляет большую коллекцию компонуемых команд, которые могут быть объединены в цепочку для выполнения широкого спектра типичных задач.

xan также использует свой собственный язык выражений, позволяя выполнять сложные задачи. Этот минималистичный язык был разработан специально для работы с данными в формате CSV и работает намного быстрее, чем обычные языки с динамической типизацией, такие как Python, Lua, JavaScript и т.д.

На картинке — код на Rust, и в нём затаилась ошибка. Я специально попросила её сделать моих коллег, разработчиков ИТ-компании «Криптонит».

Зачем? Чтобы потом попросить её найти и написать о ней в комментариях (ох, уж эти сммщики).

Итак, где тут ошибка?

СЕЙЧАС БУДЕТ СПОЙЛЕР!

Так в чём же ошибка?

В третьей строке возникает ошибка попытки доступа к элементу за пределами массива.
for i in 1..=numbers.len() выполнит итерацию по элементам, начиная со второго, а не с первого.

Ошибка заключается в попытке доступа к элементу с индексом [5] на последней итерации цикла. Такого элемента в массиве нет, в результате получаем аварийное завершение программы.

Также следует обратить внимание, что первый элемент массива с индексом [0] игнорируется. Это не является ошибкой с точки зрения выполнения программы, однако скорее всего является логической ошибкой в коде

Итак, в языке rust индексация элементов начинается с 0 и заканчивается len() - 1.
В массиве из 5 элементов допустимо обращение к [0], [1], [2], [3] и [4] элементам.

Рекомендуемый способ перебора элементов коллекции с автоматической индексацией на rust — использование цепочки вызовов iter().enumerate().

Вот как это выглядит

fn main() { 
    let numbers = vec![10, 20, 30, 40, 50];
    for (index, number) in numbers.iter().enumerate() { 
        println!("Элемент {index}: {number}");
    } 
}

Этот вариант позволяет также упростить выражение println, поместив печатаемые значения сразу в скобки на свои места. Это исключает возможность ошибиться в порядке печати значений и повысив наглядность кода.

А ты такой холодный: представим технологии Rust-дебаггеров в виде айсберга

На верхушке айсберга видим технологии DWARF, PTRACE и ELF, а внизу — набор более редких технологий. 

Сегодня будем говорить только о верхушке. Хорошая новость: чтобы понять большинство возможностей дебаггера, достаточно иметь представление об этих трех технологиях:

PTRACE — системный вызов, который позволяет одному процессу (tracer) управлять и исследовать другой процесс (tracee).  

ELF (Executable and Linkable Format) — формат исполняемых двоичных файлов. 

DWARF (Debugging With Arbitrary Record Formats) — стандарт, описывающий формат .debug_xxx секций в ELF.

Что касается «подводных» технологий, упомянутых на картинке: применяя закон Парето, можно смело сказать что 80% знаний необходимы, чтобы реализовать только 20% функционала (и не самого важного). Но если хотите узнать о них больше, напишите в комментариях.

Подробнее о PTRACE, ELF и DWARF, а также о функциях, которые они реализуют в отладчиках на Rust, читайте в статье.

На Medium появилась видимо интересная, и/или примечательная, member-only статья https://medium.com/@Aaron0928/rusts-downfall-from-rising-star-to-rejected-by-major-projects-c3263daf2e9e про, как видно по тексту ссылки, Rust downfall.

Это представляется мне отличным объектом приложения сил ищущих что бы такое с Medium перевести.

Downfall, в пределах доступного мне начала текста, обосновывается отказами ряда заметных проектов от использования Rust, первым из которых выбран https://daniel.haxx.se/blog/2024/12/21/dropping-hyper/ - отказ от от написаного на Rust бэкенда в curl. Каким образом указанный текст позволяет увидеть downfall - мне понять не удалось, скорее просвечивает ubiquitous presence. Максимум - доказательство существования столь кривого С кода к которому Rust с разумными трудозатратами не прикручивается.

Случай, ИМХО, крайне интересен, поскольку может указывать на то, что либо сам Rust либо его растущая популярность кому-то начинают мешать.

Вышел Rust 1.84. Стабилизировано

[resolver]
incompatible-rust-versions = "fallback"

Стабилизировано начало миграции на новый trait solver, что исправляет ошибки преимущественно теоретического характера, простых смертных просят не беспокоиться.

Добавлен strict provenance API, позволяющий превращать указатели в целые числа и обратно с особым изяществом.

Стабилизированы четыре десятка API и во всей троице Rust, Cargo и Clippy куча мелких изменений.

Подробности под катом на rust-lang.org. Телеграмм канала не держу, подписывайтесь куда нравится.

Не знаю на сколько это свежая новость ибо прочитал в новостях, но факт занимательный. JetBrains (опять) изменила лицензирование сделав IDE для Rust, JavaScript, C# и тестирования бесплатными для некоммерческого использования.

На сколько это следствие продвижения ИИ в средствах разработки - поди знай, но уж больно совпало по времени.

Всем привет! Кто хочет поучиться кодить на Rust присоединившись к Open Source проекту?
Проект rustsn представляет собой инструмент на языке Rust, который выполняет следующие функции:

• Генерация, компиляция и тестирование кода с использованием моделей машинного обучения (LLMs).

• Разрешение зависимостей.

• Предоставление объяснений существующего кода с помощью встраиваний (embeddings).

https://github.com/evgenyigumnov/rustsn

Представлен выпуск Aura 4.0.0. Это проект пакетного менеджера для дистрибутива Arch Linux, расширяющий возможности штатного пакетного менеджера Pacman.

Проект создан в 2012 году и изначально был нацелен на предоставление средств для сборки пакетов для репозитория AUR (Arch User Repository), применяемого для распространения сторонними разработчиками своих пакетов, не входящих в основные репозитории дистрибутива Arch Linux.

Код проекта распространяется под лицензией GPLv3.

Кроме специфичных для AUR функций в Aura также предоставляются и другие возможности, расширяющие функциональность Pacman (в настоящее время только 1/3 расширенных возможностей Aura связаны с AUR). Например, доступны средства для наглядного анализа зависимостей, работы со снапшотами наборов пакетов (для сохранения и восстановления состояния), управления остаточными зависимостями и отката отдельных пакетов или всей системы на прошлые версии.

Aura полностью обратно совместим с Pacman и поддерживает все его команды и опции. Связанные с AUR дополнительные возможности вызываются через указание опции командной строки «‑A», а средства работы со снапшотами и версиями через опции «‑B» и «‑С», не пересекающиеся с опциями Pacman.

В Aura 4.0.0 переведена вся кодовая база с Haskell на язык Rust. Смена языка позволила значительно повысить производительность, упростить установку, задействовать готовые Rust-биндинги к libalpm, сделать проект более привлекательным для новых разработчиков.

Источник: OpenNET.

Проект Redox OS, представляющий собой операционную систему с открытым исходным кодом, написанную с нуля на языке программирования Rust, теперь имеет работающий веб-сервер, среди прочих улучшений, добавленных в код проекта в течение июля.

Среди заметных новых программных работ в Redox OS — запуск Simple HTTP Server в качестве первого веб-сервера (HTTP) для платформы. Сам Simple HTTP Server также написан на Rust. Также ведутся постоянные усилия по переносу Apache HTTP-сервера в Redox OS.

Ещё одним важным достижением приложения является программа wget, которая теперь работает в Redox OS. Также была проделана большая работа по запуску настольных приложений COSMIC в Redox OS, внесены улучшения в системы сборки, продолжалась работа по созданию более сложных программ в Rust, улучшение ядра ARM64, улучшения UEFI и различные исправления драйверов.

Разработчик Химаншу Сингх (Himanshu Singh) представил простую версию использования команды grep для Rust (minigrep) и объяснил свои действия в нескольких коммитах.