今日已更新 222 条资讯 | 累计 40667 条内容
关于我们

标签：#rust

找到 496 篇相关文章

AI 资讯

ratatop: the process table, and the parentheses that ruin everything

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is free and source-available on Github. Star git-lrc to help devs discover the project. Do give it a try and share your feedback. CPU, memory, disks and network were all "read a file, do some arithmetic, draw it". This one is different. It reads about 400 directories every tick, and it is the first box you can actually interact with. There is one bug in here that I would bet real money most /proc parsers have shipped at some point. Let me start there. The parentheses that ruin everything Here is a line from /proc/[pid]/stat : 125045 (cat) R 125025 125045 125025 0 -1 4194304 92 0 0 0 11 22 0 0 20 0 7 0 ... Space separated. Field 1 is the pid, field 2 is the process name in parentheses, field 14 is user time, field 15 is system time, field 20 is thread count, field 24 is resident memory. So you split on whitespace and index into the result. Obvious. Works perfectly. Until someone runs a process called my (weird) app . 42 (my (weird) app) S 1 42 1 0 -1 0 0 0 0 0 5 5 0 0 20 0 3 0 ... That name is three whitespace-separated tokens, so every field after it shifts by two. Your thread count is now reading someone's page fault counter. Your memory is reading a scheduling priority. Nothing crashes. The numbers are just quietly, confidently wrong. And the process name is fully user-controlled. Anyone can rename a thread to whatever they like. The fix is to not split the whole line at all. Find the last closing parenthesis, take the name from between the first ( and that, and only then split what remains: fn parse_stat ( raw : & str ) -> Option < Stat > { let open = raw .find ( '(' ) ? ; let close = raw .rfind ( ')' ) ? ; let name = raw .get ( open + 1 .. close ) ? .to_string (); // Fields resume at `state`, which is field 3 in the man page's numbering. let fields : Vec <& str > = raw .get ( close + 1 .. ) ? .split_whitespace () .collect (); let field = | number : usize | -> u64 {

2026-08-08 原文 →
AI 资讯

[Advanced Rust] 2.6. API Design Principles of Flexibility Pt.2 - Object Safety, API Design, and Generic Trait Methods

2.6.1. Object Safety When defining a trait, whether it is object-safe is also part of the unstated contract. Object safety is a concept in Rust related to trait objects . It determines whether a trait can be dynamically dispatched, that is, whether it can be used in the form of dyn Trait . Traits That Are Object-Safe Must Satisfy the Following Conditions (Based on RFC 255) All supertraits must also be object-safe If a trait inherits from other traits, then those supertraits must also be object-safe. It must not require Sized A trait cannot use Sized as a supertrait, meaning it cannot contain a Self: Sized bound, because the size of a trait object is unknown at compile time. It cannot have associated constants . It cannot have associated types with type parameters . All associated functions (methods) must satisfy one of the following rules : Dispatchable functions : They cannot have any type parameters, though lifetime parameters are allowed. They must be methods, and Self may only appear in receiver positions such as: &self &mut self Box<Self> Rc<Self> Arc<Self> Pin<P> (where P is one of the types above) They cannot require Self: Sized , otherwise the trait would only be usable for types with known size and object safety would be broken. Explicitly non-dispatchable functions : They may return Self , but such functions must require Self: Sized , so they cannot be called on trait objects and can only be used with concrete types. If you cannot remember all of the above, just remember object safety describes whether a trait can be safely turned into a trait object . What Object Safety Does If a trait is object-safe, meaning it satisfies all of the conditions above, then we can use dyn Trait to treat different types that implement the trait as a single generic type. If it is not object-safe, the compiler will prevent you from using dyn Trait . Object Safety and API Design When designing APIs, it is recommended to make traits object-safe, even if that slightly reduces con

2026-08-07 原文 →
开发者

Un dev loop tipo Vite para un lenguaje compilado: hot reload + preservación de state + manifest en vivo

Parte 13 de la serie Fitz . Se abre el capítulo del frontend: Fitz compila componentes .fitzv a WebAssembly, y este es el dev loop que hace que editarlos se sienta instantáneo — la misma experiencia "guardar y verlo" que te da Vite, sobre un lenguaje que compila a binario nativo. El setup: un lenguaje compilado con frontend Fitz es un lenguaje compilado — HTTP, async, Postgres, JWT viven en la sintaxis y emite un binario nativo vía Rust. La historia del frontend es un formato de componentes single-file, .fitzv (state + events + <template> , al estilo Vue/Svelte), que compila a WebAssembly : fitz build --bin web --target wasm-client # → target/wasm/web/{web.js, web_bg.wasm} Sin npm install , sin config de bundler, sin framework externo — el componente se vuelve un bundle WASM autocontenido (el demo del contador pesa 11.4 KB gzipped). Acá viene la objeción refleja: compilado = feedback lento . Editás, esperás una compilación entera, refrescás el browser a mano. Es lo opuesto a lo que un loop de frontend debería sentirse. Por eso Fitz tiene fitz dev . El loop Apuntá fitz dev a un bin wasm-client y deja de ser un compilador para ser un dev server: fitz dev # sirve en http://127.0.0.1:1234/ Qué hace: Rebuild incremental con wasm-pack --dev (sin wasm-opt ), reusando un crate estable así la cache de cargo queda caliente — el primer build compila las deps, cada save siguiente es de ~1-2 segundos . Un dev server que sirve el root de tu proyecto como python -m http.server : tu index.html , tu CSS, el bundle en target/wasm/<bin>/ . ¿Sin index.html ? Genera uno mínimo en el punto de mount . Auto-refresh del browser por WebSocket : guardás un .fitzv / .fitz / fitz.toml y la página se recarga sola. Sin F5 a mano. Guardás, y ~2 segundos después el browser muestra el cambio. En un lenguaje compilado. El detalle que importa: el state sobrevive el reload La mayoría de los hot-reload pierden tu estado en un reload completo — ibas tres clicks adentro de un contador, editás el template,

2026-08-06 原文 →
AI 资讯

Your first Fitz LiveViews component, twice: SSR and WASM from one source

TL;DR — A Fitz LiveViews component is a single .fitzv file. The interesting part: the same file compiles to two different targets with no rewrite. Server-rendered (SSR) — the server holds the state, renders HTML, and patches the browser over a WebSocket; best for shared, DB-driven, multi-user state. Client-WASM — the same component compiles to WebAssembly and runs entirely in the browser; best for offline, zero-round-trip widgets. This post builds a counter and ships it both ways. (Part 2 of the FitzLiveViews series — start here if you missed part 1.) In part 1 I made the pitch: real-time UI in one language, no JavaScript build. Now let's build something and ship it two ways from the same source. The component Here's a counter as a single-file component ( .fitzv ) — state, events, template, style: component Counter { state { count: Int = 0 } event increment() { count = count + 1 } event decrement() { count = count - 1 } event reset() { count = 0 } <template> <div id= "counter-app" > <p> Count: {count} </p> <button @ click= "increment" > +1 </button> <button @ click= "decrement" > -1 </button> <button @ click= "reset" > Reset </button> </div> </template> <style scoped > #counter-app { padding : 1.5rem ; font-family : system-ui ; } button { padding : 0.5rem 1rem ; margin : 0 0.25rem ; } </style> } state is the reactive data. Each event handler mutates it directly — no setState , no reducers. <template> is real markup; {count} interpolates and auto-escapes. @click="increment" binds a DOM event to a handler. <style scoped> is CSS namespaced to this component. If you've written Vue or Svelte, this is familiar — the difference is what happens next. Target 1 — server-rendered (over a WebSocket) The SSR target is the default. The component runs on the server; a tiny main.fitz wires it into an HTTP route (first paint) and a WebSocket route (the live layer): from fitz_liveviews import html_response , live_layout , LiveFrame , diff_html , component , dispatch_component_events

2026-08-06 原文 →
AI 资讯

[Advanced Rust] 2.5. API Design Principles of Flexibility Pt.1 - Contracts and More Flexible Interfaces with Generic Parameters

2.5.1. Code Contracts Your code, whether explicitly or implicitly, contains a contract. A contract has two sides: A contract is a requirement, which is a restriction on how the code is used A contract is a promise, which is a guarantee about how the code behaves When designing APIs, there is a useful rule of thumb: avoid imposing unnecessary restrictions, and only make promises you can keep . Why? Adding restrictions or removing promises requires a major semantic version change and may break other code When you first design an API, loosening restrictions and later adding extra promises is usually backward-compatible 2.5.2. Restrictions and Promises Common forms of restrictions in Rust are: Trait bounds Argument types Common forms of promises are: Trait implementations Return types Some Examples Let's look at an API evolving through three versions: fn frobnicate ( s : String ) -> String The first version takes a String and returns a String Its contract is that the caller performs allocation (because both the parameter and return value are owned, allocation is inevitable), and its promise is that it returns an owned String The problem with this function is that, without changing the signature, it cannot later be turned into a “no-allocation” function, because both the argument and return value are owned fn frobnicate ( s : & str ) -> Cow < '_ , str > The second version relaxes the contract a bit Its contract is that it accepts only a string reference, and its promise is that it returns either a string reference or an owned String , namely the Cow type This version is still somewhat rigid. For example, the argument is &str ; if I pass in a String , I still have to convert it first. Also, because the return value is Cow , it cannot return string-owning types other than String and &str (for example, OsString ) fn frobnicate < T : AsRef < str >> ( s : T ) -> T The third version relaxes the contract further Now both the parameter and the return value only require a type th

2026-08-06 原文 →
AI 资讯

Vercel Labs Ships Zero: A Graph-First Language Built So Agents Write the Code

Vercel Labs has introduced Zero, an experimental systems programming language aimed at AI rather than human users. It employs unique features like a specific toolchain contract and structured error messages. Reaching version 0.3.4, it compiles to native binaries for major operating systems. The language prioritizes size, speed, and agent usability, though it is still in development. By Daniel Curtis

2026-08-06 原文 →
开发者

Sellar un archivo para que nadie pueda discutir que no lo tocaste

Una discusión sobre un archivo digital casi nunca se pierde por lo que el archivo dice. Se pierde una pregunta antes: ¿Cómo sabemos que ese es el archivo que usted recibió, y no el que editó anoche? Si la respuesta es "confíe en mí", ya perdiste. Y da igual cuánta razón tengas en el fondo. Este problema no es exclusivo de un juzgado. Lo tiene el auditor que recibe un volcado de logs, el equipo que documenta un incidente, quien conserva la copia de un contrato firmado por correo. En todos los casos hace falta lo mismo: poder demostrar que un conjunto de bytes no cambió desde un momento determinado, y que lo demuestre alguien que no seas tú . Para eso escribí Tunjo : una herramienta en Rust que recorre un material en solo lectura, calcula su huella y firma un acta verificable por cualquiera. Por qué un árbol y no un hash Lo obvio sería concatenar todo y sacar un SHA-256. Funciona, y es inútil en la práctica. Cuando alguien discute un archivo —un correo concreto entre cuatro mil— con un hash único solo puedes ofrecer dos cosas: o entregas el conjunto completo para que se recalcule, o pides que te crean. La primera opción expone material que no tiene por qué exponerse; la segunda no es una prueba. Un árbol de Merkle resuelve exactamente eso. Cada archivo es una hoja, cada par de nodos se combina hacia arriba y queda una raíz. Para demostrar que una hoja pertenece a esa raíz basta con exhibir esa hoja y el camino de hashes hasta arriba: unos pocos kilobytes. El resto del conjunto no se toca. Dos detalles del árbol que no son opcionales: // Separación de dominio: una hoja nunca puede hacerse pasar por nodo interno. h . update ([ 0x00 ]); // hoja h . update ([ 0x01 ]); // nodo interno // Y la raíz ata el número de hojas. h . update ([ 0x02 ]); h . update ( n . to_be_bytes ()); Sin lo primero, un hash de hoja podría presentarse como si fuera un nodo del árbol. Sin lo segundo aparece la ambigüedad clásica de los árboles con número impar de hojas: dos conjuntos distintos pued

2026-08-04 原文 →
← 上一页 下一页 →