标签：#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

GitHub热门项目 | Rust‑first, cross‑platform wgpu/WebGPU renderer exposed to Python for fast, headless 3D rendering. Built in Rust, shipped as Python wheels. | Stars: 558 | 10 stars today | 语言: Rust

GitHub热门项目 | A bunch of lints to catch common mistakes and improve your Rust code. Book: https://doc.rust-lang.org/clippy/ | Stars: 13,405 | 6 stars today | 语言: Rust

GitHub热门项目 | 🦎 a tool to build and deploy software on many servers 🦎 | Stars: 11,769 | 10 stars today | 语言: Rust

How a single contiguous allocation — and a type system that won't let you feed strings to a scaler — is the real reason datarust fits in 2.3 megabytes. In the last post I showed you the whole datarust workflow: impute, scale, one-hot, train a logistic regression, evaluate, and save it as JSON — all without a Python runtime in sight. The Docker image shrank from ~900 MB to ~8 MB, and the binary was 2.3 MB. But I skimmed over something important. I kept saying "the flat memory layout" as if it were a detail. It isn't. It's the whole bet. Every scaler, every encoder, every model, every metric in datarust runs on top of one data structure. If you understand that structure — why it looks the way it does and what it refuses to let you do — the rest of the library stops being magic. So let's zoom in. Meet Matrix . Two containers, on purpose Real data is mixed. Numbers in one column, strings in the next. In Python, everything flows through one giant numpy.ndarray or a pandas.DataFrame , and the type system just... shrugs. A string column next to a float column gets coerced into object dtype. You'll find out at training time, in the form of an error message three frames deep. datarust does the opposite. It splits your data into two types at the source: use datarust :: Matrix ; use datarust :: matrix :: StrMatrix ; let numeric = Matrix :: new ( vec! [ vec! [ 3.0 , 85.0 , 24.0 ], vec! [ 12.0 , 70.0 , 31.0 ], vec! [ f64 :: NAN , 95.0 , 45.0 ], ]) ? ; let categorical = StrMatrix :: from_strings ( vec! [ vec! [ "MonthToMonth" ], vec! [ "OneYear" ], vec! [ "MonthToMonth" ], ]) ? ; Matrix is f64 only. StrMatrix is strings only. They are different types , and the compiler will refuse to compile a program that hands a string column to a scaler. Not at runtime — at compile time. In the last post I called this "putting on glasses for the first time." Let me show you what it actually buys you. The ColumnTransformer API is built on that split: ct .add_numeric ( "scaled" , vec! [ 0 , 1 ],

I’ve worked with languages like JavaScript and Go , and I enjoyed both for different reasons. JavaScript gave me speed and flexibility. Go gave me simplicity and practical concurrency. Then I met Rust and at first, it felt difficult. But once I understood how Rust handles memory without a garbage collector , I fell in love with it. Memory Safety Without a Garbage Collector Most modern languages solve memory management with a garbage collector (GC) . A GC periodically finds memory that is no longer used and frees it automatically. Rust takes a different path: No runtime garbage collector No manual free() like in C Memory safety guaranteed at compile time (in most cases) Rust uses three core ideas: Ownership Borrowing Lifetimes These rules are checked by the compiler before your program runs. 1) Ownership: One Owner at a Time In Rust, every value has a single owner. When the owner goes out of scope, Rust automatically drops the value and frees memory. { let s = String :: from ( "hello" ); // s owns the string memory here } // s goes out of scope, memory is freed automatically This avoids memory leaks and double-frees in normal code paths, without needing a GC pause. 2) Borrowing: Use Data Without Taking Ownership Instead of copying or transferring ownership all the time, Rust lets you borrow references: Immutable borrow: &T Mutable borrow: &mut T But Rust enforces strict aliasing rules: Many immutable references OR One mutable reference Not both at the same time This rule prevents data races at compile time. 3) Lifetimes: References Must Always Be Valid Lifetimes describe how long references are valid. Often, Rust infers lifetimes automatically. When needed, you can annotate them. This helps prevent dangling references references to memory that no longer exists. How Rust “Behaves” in Practice When writing Rust, you feel the compiler acting like a strict mentor: “Who owns this value?” “How long does this reference live?” “Are you mutating while also sharing?” “Could th

Hi everyone! I just released v0.1.0 of Falco — a browser engine I've been building in Rust on nights and weekends. No WebKit, no Gecko, no Chromium — every module is written from scratch in ~36,000 lines. 🔗 GitHub : https://github.com/poxk/Falco 🔗 Releases (prebuilt binaries for Linux/macOS/Windows): https://github.com/poxk/Falco/releases/tag/v0.1.0 What's inside All modules are from scratch, with no dependency on existing browser engines: HTML5 ( html5/ + html.rs ) Tokenizer — all 80 states of WHATWG §13.2.5, including script-data escape/double-escape state machine, attribute parsing with duplicate detection, named + numeric character references with Windows-1252 quirks table Tree builder — all 22 insertion modes of WHATWG §13.2.6, stack of open elements with scope algorithms (default/button/table/select/list-item), active formatting elements list, adoption agency algorithm (8-iteration outer loop with full inner loop and bookmark tracking), foster parenting for table content XML parser — strict, with namespace bindings, CDATA, PIs Encoding detection — BOM, HTTP Content-Type charset, <meta charset> , <meta http-equiv> , heuristic UTF-8/UTF-16 detection, decoders for UTF-8 / UTF-16LE / UTF-16BE / Windows-1252 innerHTML/outerHTML serialization — void elements, <template> contents fragment, raw text elements, full attribute value escaping DOM ( dom2/ ) NodeRef = Rc<RefCell<Node>> with parent/firstChild/lastChild/previousSibling/nextSibling pointers per spec MutationObserver with observe()/disconnect()/take_records(), subtree ancestor matching, attributeFilter Shadow DOM — attachShadow() with open/closed modes, host validation, named + default slots, fallback content, slot distribution (flatten tree algorithm) Custom elements — customElements.define() with name validation, observedAttributes, lifecycle callbacks (connected/disconnected/adopted/attributeChanged/form-associated), pending upgrades, customized built-in elements (is="...") Accessibility tree — parallel tree

GitHub热门项目 | Terminal based IDE & text editor: easy, powerful and fast | Stars: 8,060 | 26 stars today | 语言: Rust

GitHub热门项目 | A cat(1) clone with wings. | Stars: 59,966 | 14 stars today | 语言: Rust

TL;DR — Fitz LiveViews is a real-time UI framework for Fitz , a compiled, gradually-typed language where HTTP, WebSockets, auth, and an ORM are part of the syntax. You write single-file components ( .fitzv ) with state / event / <template> , and the server renders HTML, diffs it, and patches the browser over a WebSocket — no JavaScript build step, no client framework . The same .fitzv can also compile to WebAssembly for offline, zero-round-trip widgets. There's a live component gallery, a course, and a full flagship app (an admin panel with auth + Postgres + Docker) already built with it. Repo : github.com/Thegreekman76/fitz-liveviews · Docs : thegreekman76.github.io/fitz-liveviews This is the first post in the FitzLiveViews series. I'll start with the pitch and the setup; the following posts build things. The problem Building a modern web UI usually means two languages, two type systems, and a build pipeline: a backend (Python / Node / Go) plus a frontend framework (React / Vue / Svelte) plus its toolchain (Vite / Webpack / Babel). You duplicate your types across the wire, you keep two mental models in sync, and node_modules grows a personality of its own. Phoenix LiveView (Elixir) showed there's another way: render on the server, push diffs over a WebSocket, and let the browser stay dumb. No client framework, no API to hand-write, no JSON serialization dance. Fitz LiveViews brings that model to Fitz — and adds a twist: the same component can also compile to WebAssembly when you want purely client-side, offline interactivity. What Fitz LiveViews looks like A component is a single .fitzv file — state, event handlers, and a template, like Vue or Svelte: 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 <