标签：#Rust

GitHub热门项目 | A fast static site generator in a single binary with everything built-in. https://www.getzola.org | Stars: 17,298 | 9 stars today | 语言: Rust

GitHub热门项目 | Fully transparent SSH, HTTPS, Kubernetes, MySQL and Postgres bastion/PAM that doesn't need additional client-side software | Stars: 7,464 | 10 stars today | 语言: Rust

GitHub热门项目 | dev tools, env vars, task runner | Stars: 31,835 | 264 stars today | 语言: Rust

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,

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

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

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

GitHub热门项目 | Fast, disk space efficient package manager | Stars: 35,977 | 15 stars today | 语言: Rust

GitHub热门项目 | Tantivy is a full-text search engine library inspired by Apache Lucene and written in Rust | Stars: 15,644 | 11 stars today | 语言: Rust

GitHub热门项目 | A super fast Graph Database uses GraphBLAS under the hood for its sparse adjacency matrix graph representation. Our goal is to provide the best Knowledge Graph for LLM (GraphRAG). | Stars: 5,224 | 252 stars today | 语言: Rust

GitHub热门项目 | A fast, standalone terminal music player in Rust: native Spotify streaming plus local, Subsonic, radio, and YouTube sources. | Stars: 1,134 | 2 stars today | 语言: Rust

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

GitHub热门项目 | Neon: Serverless Postgres. We separated storage and compute to offer autoscaling, code-like database branching, and scale to zero. | Stars: 22,741 | 15 stars today | 语言: Rust

GitHub热门项目 | ⚙️🦀 Build modular and scalable LLM Applications in Rust | Stars: 8,149 | 12 stars today | 语言: Rust

GitHub热门项目 | Fast Rust library for PDF inspection, classification, and text extraction. Intelligently detects scanned vs text-based PDFs to enable smart routing decisions. | Stars: 6,819 | 1,769 stars today | 语言: Rust

If you're running local models through Ollama and tired of Python's overhead, check out langchain-rust . It's a full LLM framework in pure Rust that works great with local models: Ollama support — first-class integration with tool calling, vision, and streaming 9 vector store backends — InMemory, SQLite, Qdrant, ChromaDB, Redis, PGVector, MongoDB, Pinecone, FileVectorStore BM25 keyword search — with Chinese/English tokenization, no external dependency Hybrid retrieval — BM25 + Vector with RRF fusion for better recall GraphRAG — Knowledge graph construction + community detection, all local CorrectiveRAG — Self-correcting retrieval with hallucination detection Code Interpreter — LocalSandbox (subprocess), E2B cloud, or WASM sandbox LocalEmbeddings — Run embeddings without calling an API Plus: LangGraph workflows, MCP client/server, 7 memory types, guardrails, and 12+ built-in tools. Single binary, no virtualenv, no pip conflicts. Just cargo add langchainrust and go. GitHub: https://github.com/atliliw/langchainrust Docs: https://docs.rs/langchainrust

How I implemented wmiexec from scratch in Rust — DCOM activation, OXID resolution, and MS-WMIO object marshaling — by using impacket not as a library but as a debugging oracle, and diffing my wire bytes against it until a Windows DC accepted them byte-for-byte. This is a build log from ADhammer, an Active Directory audit + validation toolkit I'm writing in Rust on a from-scratch DCE/RPC · NTLM · SMB2 · Kerberos stack (think "impacket for Rust"). The whole project is built with Claude Code, and this post is the single best example of what that actually looks like — not autocomplete, but a tight loop of hypothesis → capture live traffic → diff → fix against a real domain controller. The goal: wmiexec, from scratch wmiexec is the classic "quiet" remote-code-execution technique: instead of creating a service (psexec/SVCCTL) or a scheduled task (atexec), you talk to WMI over DCOM and call Win32_Process.Create. No service-install event, different host telemetry. Under the hood it's three stages, each a different flavour of pain:

Every year, developers ask the same question: "Which programming language should I learn next?" And...

Full title: [Advanced Rust] 2.3. API Design Principles of Unsurprising Pt.3 - Implementing serde Serialize and Deserialize Traits, and Why Copy Is Not Recommended 2.3.1. It Is Recommended to Implement Serialize and Deserialize in serde Serde is the core Rust library for serialization and deserialization : Serialization : converts a Rust struct or enum into a string or binary representation such as JSON or YAML Deserialization : parses a string or binary representation such as JSON or YAML back into a Rust struct or enum Serialize and Deserialize are both traits from the serde crate. Serialize Trait The Serialize trait allows a type to be converted into a serializable data format such as JSON, YAML, or TOML. Its main methods include: serialize_bool serialize_i32 serialize_str serialize_struct These are methods on the Serializer (and related) traits that a Serialize implementation calls; the Serialize trait itself only requires serialize . Its definition is: pub trait Serialize { fn serialize < S > ( & self , serializer : S ) -> Result < S :: Ok , S :: Error > where S : Serializer ; } Here is an example showing how to implement Serialize manually: use serde :: ser ::{ Serialize , SerializeStruct , Serializer }; struct Point { x : i32 , y : i32 , } impl Serialize for Point { fn serialize < S > ( & self , serializer : S ) -> Result < S :: Ok , S :: Error > where S : Serializer , { let mut state = serializer .serialize_struct ( "Point" , 2 ) ? ; state .serialize_field ( "x" , & self .x ) ? ; state .serialize_field ( "y" , & self .y ) ? ; state .end () } } serializer.serialize_struct("Point", 2)? creates a struct serializer state, and 2 is the number of fields state.serialize_field("x", &self.x)? serializes the struct fields one by one state.end() finishes serialization Deserialize Trait The Deserialize trait allows Rust types to be parsed from various data formats. Its main methods include: deserialize_bool deserialize_i32 deserialize_string deserialize_struct These are

Full title: [Advanced Rust] 2.2. API Design Principles of Unsurprising Pt.2 - Implementing Clone, Default, PartialEq, PartialOrd, Hash, Eq, and Ord 2.2.1. It Is Recommended to Implement the Clone Trait and the Default Trait Clone Trait The Clone trait in Rust allows an implementer to explicitly create a deep copy of itself through the clone method, as opposed to the by-value copy provided by the Copy trait. Example: #[derive(Debug, Clone)] struct Person { name : String , age : u32 , } impl Person { fn new ( name : String , age : u32 ) -> Self { Self { name , age } } } fn main () { let person1 = Person :: new ( "John" .to_owned (), 25 ); let person2 = person1 .clone (); println! ( "{:?}" , person1 ); println! ( "{:?}" , person2 ); } The Person struct implements the Clone trait In main , person2 clones the data from person1 because it implements Clone Output: Person { name: "John", age: 25 } Person { name: "John", age: 25 } Default Trait The Default trait in Rust allows a type to define a default value and return that default instance through the default() method. Example: #[derive(Default)] struct Point { x : i32 , y : i32 , } fn main () { let p = Point :: default (); println! ( "Point is at ({}, {})" , p .x , p .y ); } Output: Point is at (0, 0) 2.2.2. It Is Recommended to Implement the PartialEq , PartialOrd , Hash , Eq , and Ord Traits PartialEq Trait PartialEq provides support for the == and != operators, allowing custom types to participate in partial equality comparisons. Example: #[derive(Debug, PartialEq)] struct Point { x : i32 , y : i32 , } fn main () { let point1 : Point = Point { x : 1 , y : 2 }; let point2 : Point = Point { x : 1 , y : 2 }; let point3 : Point = Point { x : 3 , y : 4 }; println! ( "point1 == point2: {}" , point1 == point2 ); println! ( "point1 == point3: {}" , point1 == point3 ); } By implementing PartialEq , we can compare whether two structs are equal Output: point1 == point2: true point1 == point3: false PartialOrd , Eq , and Ord Trait