#rust

We're not done with point clouds https://lobste.rs/s/ctwrrt #performance #rust https://claytonwramsey.com/blog/mvt/

Tail-Call Interpreters in Rust - Jimmy Ostler https://lordgoati.us/blog/tail-call/ #HackerNews #Tech #Rust

An alias-based formulation of the borrow checker (2018) https://smallcultfollowing.com/babysteps/blog/2018/04/27/an-alias-based-formulation-of-the-borrow-checker/ #HackerNews #Tech #Rust

Чудовий, здоровий погляд на використання великих мовних моделей (ВММ a.k.a. ШІ) від автора політики щодо ВММ проєкту Rust. Думаю, це можна застосувати не тільки до розробки софту. Я радий знати, що спільнота проєкту Rust дивиться на це саме таким чином. Загалом, ця політика зосереджена на розумінні і сприянні у тому, щоб у нас була ментальна модель нашого коду, а не лише артефакти, які механічно виконують правильні дії. Основне питання – довкола чого і яких цінностей люди збираються разом, щоб працювати над проєктом, що́ вони хочуть спільно накопичувати й будувати, і що очікують одне від одного, а не у тому, добрий чи поганий код геренують ВММ per se. Думаю, більшість авторів пропозицій (змін до) коду, які використовують ВММ, переконані, що вони щиро допомагають, але для нас сам код є найменшою, і в певному сенсі найменш важливою частиною пропонованих змін. Нас значно більше хвилює те, чи розуміє автор/ка, що́ цей код робить, чи роздумує він/вона над тим, як цей код буде змінюватися у майбутньому, і чи приймає усвідомлені рішення про те, як цей код має виглядати. Сам по собі код ніяк не сприяє жодній з цих речей. Тобто ціннішою за код є когнітивна участь, усвідомлене прийняття рішень людиною по той бік екрану. Код завжди можна переписати, але цього неможливо зробити без достатнього розуміння самої проблеми, того, як саме ми її вирішуємо, і як це рішення буде жити довготерміново. Ми часто зіштовхумося з ситуацією, коли людина відповідає на коментар, копіюючи його у ВММ і вставляючи назад її відповідь. Скажу прямо: це марна трата часу усіх залучених. Якщо б нам була потрібна відповідь ВММ, ми б самі запитали. Ми хочемо почути вашу думку, а не думку машини. Мене турбує асиметрія зусиль і відповідальності, яка тут виникає: той, хто називає себе автором, з допомогою машини дуже швидко створює щось, що потім хтось інший має повністю «перетравити» і зрозуміти, щоб приймати усвідомлені рішення і відповідати за це перед кінцевими користувачами і всіма іншими учасниками проєкту. Ще з давніх до-ШІшних часів я пригадую, як мене дратувало зловживання машинним перекладом окремими авторами в українській Вікіпедії, а особливо коли це ще й було порушенням авторського права (я нерідко вилучав такий переклад). Мені здається, тут щось подібне – нагенерувати щось машиною можна швидко, але хто буде за це відповідати? Хто хоча б раз уважно прочитає це повністю, перш ніж віддавати іншим? Недавно спостерігав, як один розробник зіштовхнувся з нагенерованою ВММ пропозицією змін до свого проєкту. Кінець кінцем він просто переробив все самостійно. Не тому, що код був якимось докорінно неправильний, а тому що це був не той код, який він хотів бачити в своєму проєкті («хто таке пише?»), і він не бачив сенсу казати про це «автору»: Це важливо не тому, що я не готовий прийняти код, створений ВММ. Але через це мені складно зрозуміти, чи є сенс писати автору мої побажання щодо коду, чи простіше переробити це самому. Тобто проблема не стільки в самому коді, скільки у способі взаємодії і очікуваннях одне від одного. Також тут виникає ряд інших етичних питань – наприклад, якщо людина створила з мінімальними зусиллями 100 пропозицій коду з допомогою ВММ, 25 з яких потім опрацювали і довели до пуття інші (решту 75 викинули), а потім ця сама людина в своєму CV подасть список з цих 25 змін як своє індивідуальне досягнення – наскільки це чесно? Ніхто крім автора не зобов'язаний читати вивід ВММ, за винятком добровільного вибору: вивід ВММ заборонений в публічній документації, описах пропозицій змін, а також коментарях на GitHub, якщо він не є явно промаркований¹. Рецензенти не зобов'язані читати ВММні пропозиції змін, якщо вони не бажають. Вважаю, що це чудовий принцип – він відразу чітко декларує рівень очікуваної залученості інших до створеного кимось ВММного вмісту, на противагу вмісту, артикульованого самою людиною безпосередньо. Ви можете генерувати ВММ-ний вміст, якщо тільки ви його бачите, без розкриття [факту використання ВММ], поки ви не публікуєте його де-небудь з очікуванням, що ми будемо його читати чи рецензувати. Це справедливо. При тому зверніть увагу, що політика не містить категоричної заборони на використання ВММ для генерування самого коду: Узгоджений заздалегідь, некритичний, високоякісний, добре відтестований і добре відрецензований код, який початково був створений ВММ, дозволяється, з розкриттям [факту використання ВММ]. Отже, це не проблема коду самого по собі, а питання презумпцій щодо того, наскільки кожен/на з учасників залучені когнітивно. Код, який потрапляє до користувачів і еволюціонує, стає кращим і якіснішим протягом десятиліть, – це вже результат усієї цієї взаємодії і інвестованого спільного [когнітивного] капіталу. 🐨 -- ¹ Останнє стосується тільки коментарів на GitHub. #Rust #NoAI

Schiff! @FotoVorschlag@mastodon.social #ship #iceland #rust #fotoVorschlag #landscapephotography

📊 HWall: Un monitor hardware promitător scris în Rust, conceput special pentru Linux!Proiectul HWall aduce o abordare modernă și extrem de detaliată pentru monitorizarea componentelor hardware sub Linux. Inspirat din structura ierarhică a cunoscutului utilitar de Windows HWiNFO64, HWall combină citirea senzorilor în timp real cu un design curat și performanțe ridicate datorită limbajului Rust.✨ Principalele caracteristici ale HWall:🖥️ Interfață dublă (GTK 4 & CLI):• Oferă o interfață grafică modernă bazată pe GTK 4, dar și un utilitar complet în linie de comandă (TUI/CLI) capabil să genereze rapoarte sau să transmită date în flux continuu (JSON Lines).📈 Senzori în timp real & Grafice interactive:• Monitorizează temperaturi (CPU, placă de bază, GPU), viteze ale ventilatoarelor, tensiuni, frecvențe, consum de energie, grad de utilizare și trafic de rețea.• Păstrează un istoric în memorie pe care îl afișează sub formă de grafice interactive (cu funcții de zoom, inspecție la hover și export în format CSV/JSON). 🚨 Sistem avansat de alerte:• Permite configurarea pragurilor de avertizare și critice pentru fiecare senzor în parte, având setări de cooldown și hysteresis pentru a evita alertele false cauzate de scurte vârfuri de temperatură. 🛡️ Abordare 100% Read-Only (Siguranță pe primul loc):• Aplicația nu încearcă să modifice turația ventilatoarelor sau frecvențele, concentrându-se exclusiv pe raportarea sigură a datelor expuse de kernel-ul Linux, sysfs, lm-sensors, smartctl sau utilitarul nvidia-smi.🌐 API HTTP integrat:• Include o funcție serve prin care poate expune local datele senzorilor sub formă de API HTTP JSON, facilitând integrarea cu alte aplicații sau scripturi de monitorizare.⚠️ Stadiul actual al proiectului:Fiind în faza incipientă de dezvoltare, HWall necesită compilare din surse folosind Rust 1.92+ și librăriile de dezvoltare GTK 4.8. O opțiune excelentă pentru utilizatorii de Linux care își doreau un echivalent modern, sigur și nativ pentru HWiNFO64! 🚀 #HWall #Rust #Linux #HardwareMonitor #OpenSource #GTK4 #LinuxDesktop #TechNews #FOSS

It's Friday again, so it's time for another update on the work on Diesel, a ORM and query builder for Rust. I published Diesel 2.3.12 today, which bumps the maximal supported libsqlite3-sys version to 0.38 and fixes an precision issue with Mysql's TIME types. See the release announcements for more details: https://github.com/diesel-rs/diesel/releases/tag/v2.3.12 We received no new bug report, but 10 new PR's this week. Several of the new PR's seek to add large new features so this required quite a bit of review time. Any help with reviewing changes to Diesel is welcome. #rust #rustlang

Introducing Kitesurf: The agent-first browser that runs in V8 isolates on Cloudflare Workers https://lobste.rs/s/9bxkgi #browsers #rust #vibecoding https://blog.cloudflare.com/kitesurf/

A Vision for Cargo https://lobste.rs/s/mgr9lc #rust https://epage.github.io/blog/2026/08/cargo-vision/

rust-lang/rust is adopting an LLM policy If you personally use LLMs and want to contribute to the Rust toolchain, you *really* should read it. The summary is "It's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to *create*." Effectively, no other human should see LLM output, unless they ask for it, and LLM usage shall be disclosed. https://blog.rust-lang.org/inside-rust/2026/08/05/rust-langrust-is-adopting-an-llm-policy/ #RustLang #Rust

rust-lang/rust is adopting an LLM policy via @wezm@mastodon.decentralised.social https://lobste.rs/s/czvkjy #rust https://blog.rust-lang.org/inside-rust/2026/08/05/rust-langrust-is-adopting-an-llm-policy/

Don't stop early: Case-folding source code at memory speed via @fanf@mendeddrum.org https://lobste.rs/s/qsgcgz #performance #rust https://github.blog/engineering/architecture-optimization/dont-stop-early-case-folding-source-code-at-memory-speed/

Enabling the next iteration of the borrow checker on nightly https://lobste.rs/s/skft2i #rust https://blog.rust-lang.org/2026/08/04/enabling-polonius-alpha-on-nighty/

The next iteration of the #Rust borrow checker is coming! #rustlang Whaaaaaat? https://blog.rust-lang.org/2026/08/04/enabling-polonius-alpha-on-nighty/

I’m a Rust compiler maintainer looking for full-time remote employment　involving Rust-related open-source work. While I’m currently employed as a Staff Software Engineer, I’d like my next role to include time for upstream Rust　compiler contributions. I’m based in Kyoto and am not looking to relocate, but I can travel　occasionally. Introductions and boosts would be appreciated. https://tako8ki.com/posts/looking-for-a-new-role #rust #opensource #getfedihired

BorrowSanitizer https://lobste.rs/s/jkv2du #rust https://borrowsanitizer.com/

Branchless Rust: Making a Filter 4x Faster by Removing an if https://lobste.rs/s/zhfwxt #performance #rust https://www.greyblake.com/blog/branchless-rust/

More technical #rust #GameDev update where I primarily cover migration to #bevy 0.19 and how much I like bsn. I do also cover a 3D building I/O visual issue where buildings now properly have dark portals #Satisfactory style. https://exofactory.net/blog/2026-08-02/

Rust: Don't Panic https://lobste.rs/s/qpubrj #video #rust https://www.youtube.com/watch?v=usRlRCNIOG0

Rust Project Goals: Immobile types and guaranteed destructors https://lobste.rs/s/sp2wji #rust https://github.com/rust-lang/rust-project-goals/blob/main/src/2026/move-trait.md