Babashka is a native Clojure interpreter for scripting, compiled with GraalVM native-image to produce a self-contained, fast-starting binary (`bb`). In production, it serves as a replacement for bash or Python scripting in Clojure, offering a REPL, task runner, nREPL server, HTTP client/server, process spawning, file I/O, database access via JDBC, and foreign function interface (FFI) to C libraries. The architecture is a monolith with modular feature flags: environment variables such as `BABASHKA_FEATURE_CSV` or `BABASHKA_FEATURE_JDBC` control which optional libraries (XML, YAML, CSV, Transit, http-kit, spec, logging, etc.) are compiled into the binary. The core interpreter is SCI (Small Clojure Interpreter), extended with a rich set of built-in namespaces that wrap popular Clojure libraries. Build scripts and CI pipelines automate testing on Linux, macOS, and Windows, and the project maintains an extensive library compatibility test suite with over 100 third-party Clojure libraries pinned to specific git SHAs. The codebase demonstrates exceptional craftsmanship: the JLine-based REPL with inline autosuggestion and eldoc, the FFI trampoline dispatch, the custom GraalVM features for binary size optimization, and the deftype map interface support are all non-obvious solutions to real problems in building a scripting runtime on the JVM. While primarily an application, the repository also contains a valuable data asset in `test-resources/lib_tests/bb-tested-libs.edn`, a curated registry of library compatibility that could support research on Clojure library portability.
Neon is a Rust framework for building safe and fast native Node.js addons via the Node-API (N-API). It provides a comprehensive type system that maps JavaScript values to Rust types, procedural macros for exporting functions, classes, and constants, and async/threading primitives for offloading work to background threads. The repository also includes CLI tools: `create-neon` for scaffolding new projects with CI/CD templates, and `cargo-cp-artifact` for copying build artifacts. The core library (`crates/neon`) is the primary deliverable, consumed as a Rust dependency. The architecture is a Rust workspace with a procedural macro crate (`neon-macros`), plus npm packages for tooling. The codebase demonstrates high craftsmanship with safe abstractions over unsafe FFI, composable type extraction patterns, and a macro-driven export system that automates registration. It is actively maintained with extensive test suites including compile-fail UI tests, integration tests, and benchmarks.
This repository contains the source code for Comprehensive Rust, a multi-day Rust course developed by the Android team at Google. It is structured as an mdBook with slides, speaker notes, interactive code examples, and exercises. The course covers Rust fundamentals, Android and Chromium integration, bare-metal development, concurrency, async, unsafe Rust, and idiomatic patterns. The codebase includes custom mdBook preprocessors (mdbook-course for structured course scheduling, mdbook-exerciser for extracting exercise starter files), a developer automation tool (xtask), and a comprehensive CI/CD pipeline that builds the book in multiple languages, runs Rust tests via Bazel and Cargo, and performs browser-based WebDriverIO tests. While the primary output is educational content, the tooling infrastructure is well-engineered and demonstrates reusable patterns for structured documentation and exercise management. The repository is actively maintained with frequent commits, issue triage, and translation support for over 17 languages.
Kagome is a self-contained Japanese morphological analyzer written in pure Go. It provides tokenization with part-of-speech tagging, multiple segmentation modes (normal, search, extended), and dictionaries embedded in the binary for easy deployment. The system includes a CLI tool with subcommands (tokenize, server, lattice, sentence), a RESTful API server mode, WebAssembly support for browser use, and C library API for FFI integration with languages like Python and PHP. The architecture centers around a lattice-based Viterbi algorithm for tokenization, with clean separation between tokenizer logic, dictionary handling, filtering utilities, and interface layers.
Ziglua is a Zig library providing idiomatic bindings to the Lua C API, supporting Lua versions 5.1 through 5.5, LuaJIT, and Luau. It compiles the chosen Lua runtime from source at build time and exposes nearly the entire C API through a safe, Zig-native interface. The library leverages Zig's features such as slices, enums, optionals, and error unions to reduce memory unsafety and improve ergonomics compared to raw C bindings. It also includes a set of higher-level utilities like `wrap` for converting Zig functions into Lua-callable closures, `Buffer` for efficient string construction, and `toAny`/`pushAny` for automatic Lua–Zig serialization of common types. Architecturally, Ziglua is a single Zig module (`zlua`) that can be imported by any Zig project. The build system (`build.zig`) handles fetching the Lua source code, applying necessary patches, and compiling it as a static or shared library. Bindings are generated via Zig's `translate-c` tool from the Lua C headers, with additional manual Zig wrappers in `src/lib.zig`. The project is well-tested across multiple platforms (Linux, macOS, Windows) and supports Lua version selection, allocator integration, and both embedded and shared-library usage. Ziglua is actively maintained against Zig's master branch, with documented API and a clear changelog.
JNA (Java Native Access) is a Java library for calling native shared libraries without writing JNI glue code. Instead of manually implementing native methods, developers declare `Library` interfaces or use `Native.register` direct mapping; the runtime proxies those calls through `NativeLibrary`, resolves symbols, and dispatches through a native JNI bridge backed by a vendored libffi copy. The core also supplies memory management (`Pointer`, `Memory`, `Structure`, `Union`), callbacks via native trampolines, string/array marshalling, custom type converters, and Windows stdcall/UNICODE mapping utilities.
This is a Rust language binding for the Godot 4 game engine, implemented as a GDExtension library. The repository provides a comprehensive, safe, and idiomatic Rust API to define Godot classes, methods, signals, properties, and async tasks. It consists of multiple interdependent crates: `godot-bindings` for locating the Godot binary and loading API JSON, `godot-codegen` for generating Rust FFI wrappers and core mappings from Godot's extension API, `godot-core` containing built-in type wrappers (Variant, Vector2/3/4, Color, Basis, etc.), object model (`Gd<T>`, `Base<T>`, `DynGd<T>`), signal system, property registration, and conversions, `godot-ffi` for low-level FFI type definitions and binding storage, `godot-macros` providing procedural macros (`#[derive(GodotClass)]`, `#[godot_api]`, `#[func]`, `#[signal]`, `#[var]`, `#[export]`), and `godot-cell` for safe interior mutability (`GdCell`). The codebase is heavily code-generated, extensively integration-tested inside a real Godot process, and includes benchmarks, hot-reload support, and a complex build pipeline. It is a tightly coupled framework that mimics Godot's object-oriented model in Rust with careful safety and thread-safety considerations. The design shows high craftsmanship in FFI abstraction, type conversion traits, and macro-driven registration, but also carries technical debt due to version-specific conditional compilation and deep dependencies on Godot's runtime layout.
This repository provides safe, idiomatic Rust bindings to the MuPDF C library (Artifex Software), enabling programmatic reading, rendering, creation, and editing of PDF and other document formats. It is a library crate organized as a Cargo workspace with three sub-crates: `mupdf` (high-level API), `mupdf-sys` (FFI layer that compiles MuPDF from source), and optional font crates (`mupdf-fonts-droid`, `mupdf-fonts-noto`, `mupdf-fonts-sil`). The architecture is a classic FFI wrapper: `mupdf-sys` exposes raw C functions via `bindgen`, while `mupdf` provides safe Rust types (`Document`, `Page`, `Pixmap`, `PdfDocument`, `Shape`, etc.) with automatic resource management, error handling, and thread-safety checks. Key entry points include `Document::open()` for loading files, `Page::to_pixmap()` for rasterization, `Shape` for programmatic drawing, and `PdfDocument` for PDF-specific operations like annotation manipulation, form filling, and incremental saving. The library supports extensive feature flags (e.g., `js`, `xps`, `svg`, `tesseract`, `docx-output`) that control which MuPDF subsystems are compiled. The codebase demonstrates high craftsmanship through its safe wrapper patterns, builder-style APIs (e.g., `Shape`), extensible trait design (`FontLoader`, `NativeDevice`), and comprehensive test coverage including snapshot-based rendering tests and link extraction round-trip tests. It is not a data research project; it is a software library for document processing.
Rustler is a Rust library for writing safe, efficient Native Implemented Functions (NIFs) for the Erlang VM (BEAM), primarily used from Elixir. It provides a high-level, type-safe API that abstracts away the low-level C NIF interface, allowing developers to write NIFs in idiomatic Rust with automatic encoding/decoding of Erlang terms. The architecture consists of three main crates: `rustler` (core runtime and type system), `rustler_codegen` (procedural macros for NIF export and derive traits), and `rustler_mix` (Elixir Mix integration for building and loading NIFs). Key entry points include the `init!` macro to register NIFs, the `#[nif]` attribute macro to define functions, and derive macros like `NifStruct`, `NifMap`, and `NifTaggedEnum` for automatic term conversion. Data flows involve Rust functions receiving decoded Erlang terms (via the `Decoder` trait) and returning encoded terms (via the `Encoder` trait), with support for complex types, resources, threading, and serde serialization. External dependencies include the Erlang/OTP NIF API (dynamically loaded), the `inventory` crate for static registration, and optional `serde` and `num-bigint` crates.
This repository provides **pgrx**, a framework for writing PostgreSQL extensions entirely in Rust. It includes a CLI tool (`cargo-pgrx`) for project scaffolding, building, testing, packaging, and schema generation. The core library (`pgrx`) offers safe Rust wrappers for PostgreSQL internals: memory contexts, SPI (Server Programming Interface), arrays, triggers, aggregates, GUCs, datetime types, and more. Procedural macros (`#[pg_extern]`, `#[pg_trigger]`, `#[pg_aggregate]`, `#[derive(PostgresType)]`, etc.) automatically generate SQL DDL and Rust boilerplate, enabling a pure-Rust extension development experience. The framework supports PostgreSQL versions 13 through 19 via feature-gated FFI bindings in `pgrx-pg-sys`, which uses `bindgen` to produce per-version Rust declarations. SQL schema generation is handled at compile time by `pgrx-sql-entity-graph`, which embeds metadata in the shared library's binary sections. The architecture is modular: the `pgrx` crate re-exports public API, `pgrx-macros` provides proc macros, `pgrx-pg-sys` contains raw FFI bindings, `pgrx-sql-entity-graph` handles SQL generation, and `cargo-pgrx` is the CLI frontend. Example extensions in `pgrx-examples/` demonstrate features like custom types, background workers, logical decoding, and SPI usage. A comprehensive test suite in `pgrx-unit-tests/` includes compile-fail tests, property-based tests (via `proptest`), and integration tests that run against real PostgreSQL instances. Key external dependencies include the PostgreSQL development headers (for `pg_config` and C API), `libclang` for bindgen, and Rust ecosystem crates such as `serde`, `syn`, `quote`, `clap`, `ureq`, and `criterion` (for benchmarking). The framework is designed for extension authors; it is not a data analysis or research project.
objc2 is a Rust library that provides safe, idiomatic bindings to Apple's Objective-C runtime and a vast portion of its system frameworks (Foundation, AppKit, Metal, CoreFoundation, and hundreds more). The core crate wraps the Objective-C runtime with type-safe message sending, class definition, reference counting via Retained<T>, and protocol support. Around it, the workspace includes supporting crates for Objective-C blocks (block2), Grand Central Dispatch (dispatch2), a header translator that auto-generates Rust code from Apple's SDK headers, and a documentation parser (apple-doc). The architecture is a large Rust workspace (hundreds of crates) with a clear separation: a lightweight runtime layer (objc2-encode, objc2-exception-helper, objc2-proc-macros), the main objc2 crate with macros and runtime types, and generated framework crates that follow a uniform pattern (extern_class!, extern_methods!, etc.). The project places heavy emphasis on safety and correctness, employing compile-time encoding verification, fuzz testing, assembly-level baseline tests for optimized message sending, and UI tests to catch type errors at compile time. Despite its complexity, the code exhibits strong craftsmanship: the macro infrastructure is well-organized, memory management is carefully designed (two-phase initialization, drop flags, Writeback helpers), and performance-critical paths use inline assembly for retain/autorelease optimization. The project is actively maintained with a modern toolchain, CI against multiple runtimes (Apple, GNUstep, ObjFW), and thorough documentation. It stands as the most comprehensive Rust-to-Objective-C bridge available, suitable for building native macOS/iOS applications entirely in Rust.
This repository is a PHP implementation of the Pact contract testing framework, enabling consumer-driven contract testing for APIs and microservices. It allows developers to define expected interactions in consumer tests (generating Pact files) and verify provider compliance against those contracts. The library supports multiple transport protocols (HTTP/REST, gRPC, message queues) and data formats (JSON, XML, CSV, Protobuf, etc.) through a plugin architecture. It uses FFI to interface with a Rust-based Pact core and includes a mock server for simulating providers during testing. The codebase features a well-structured domain model, extensive matcher/generator system, and comprehensive compatibility suite validating adherence to Pact specifications v1-v4.
This is a Rust library that provides safe, idiomatic bindings over the C library librdkafka, enabling Rust applications to produce and consume messages from Apache Kafka. The architecture is a thin wrapper: it exposes a high-level typed API (producers, consumers, admin client, transactions) while delegating all network I/O, partition management, and protocol handling to librdkafka. Key entry points include `ClientConfig` for building clients, the `Consumer` and `Producer` traits, and concrete implementations (`BaseConsumer`, `StreamConsumer`, `BaseProducer`, `FutureProducer`, `ThreadedProducer`). Data flows through a polling loop that dispatches events (delivery reports, rebalance notifications, log messages) to user-provided `ClientContext` callbacks. External dependencies are the librdkafka native library (bundled via submodule or system) and optional async runtimes (Tokio, smol, async-std). The library is heavily used in production Rust Kafka deployments.
jlrs is a Rust library that provides safe, high-performance bindings to the Julia C API, enabling both embedding Julia within Rust applications and exporting Rust functions as Julia modules (via ccall). The architecture is modular, with separate crates for raw FFI (`jl_sys`, `jlrs_sys`), a proc-macro crate (`jlrs_macros`) for derive macros and the `julia_module!` macro, and the main `jlrs` crate offering managed types (`Value`, `Array`, `DataType`), memory safety through scoped GC frames, and multiple runtime modes (local, async via tokio, multi-threaded). The library handles Julia’s garbage collector carefully with custom GC-safe locks and fast thread-local state, and supports advanced features like static arrays, ndarray integration, and opaque Rust types managed by Julia. Key entry points are the `Builder` struct for initializing Julia, runtime handles (`LocalHandle`, `AsyncHandle`, `MtHandle`), and the `julia_module!` macro for exposing Rust code. The codebase is well-tested with integration tests, benchmarks, and CI across Julia LTS and stable versions on Linux, macOS, and Windows.
This repository is a Ruby gem (polars-df) that provides a high-performance DataFrame library by binding to the Rust-based Polars engine. It serves as a native extension, allowing Ruby developers to perform ETL, data transformation, and analytics tasks with Rust-level speed while maintaining Ruby syntax. The architecture consists of a Rust core (ext/polars) handling computation and memory management, wrapped by Ruby modules (lib/polars) that expose a fluent DSL for data manipulation. It supports both eager (DataFrame/Series) and lazy (LazyFrame/Expr) evaluation modes, with extensive I/O capabilities for formats like CSV, Parquet, and Arrow, as well as cloud storage and database integration. The codebase demonstrates strong engineering practices, utilizing the `magnus` crate for safe Ruby-Rust FFI and implementing complex type conversion logic to bridge the two languages. It includes comprehensive test suites and CI pipelines for cross-platform compilation. However, the tight coupling to the upstream Polars Rust library introduces maintenance overhead, as breaking changes in the Rust core require synchronous updates to the Ruby bindings. Several features, particularly around cloud catalogs (Iceberg, Delta) and advanced selectors, are marked as experimental or contain incomplete implementations (Todo blocks), indicating an active but evolving codebase. For AI agents and engineers, this library is the primary tool for data engineering within the Ruby ecosystem where performance is critical. It is suitable for building data pipelines, analytics services, or backend systems that require efficient data processing without leaving the Ruby environment. The presence of `unstable` markers and `Todo` blocks suggests that while the core functionality is robust, some advanced features should be used with caution in production environments.
Fonnx is a Flutter plugin that enables cross-platform, on-device machine learning inference by wrapping the ONNX Runtime engine. It provides a unified Dart API that abstracts away the complexities of native FFI (for iOS, Android, macOS, Windows, Linux) and WebAssembly (for web), allowing developers to run models like OpenAI Whisper, Silero VAD, Magika, and various text embedding models without cloud dependencies. The codebase exhibits high software craftsmanship. Its architecture uses conditional Dart imports to cleanly separate native and web backends, employs Dart isolates for offloading heavy inference tasks, and implements a custom RPC protocol for web workers. A standout feature is its robust native memory management, including a C finalizer tested with sanitizers to prevent leaks during Flutter hot-restarts. While primarily a software library, it bridges the gap between ML research and production by bundling specific, optimized ONNX models and providing a deterministic test corpus with golden outputs. It is an excellent resource for Flutter developers building privacy-focused, offline-first AI applications, though its reliance on pinned native assets and specific build tooling introduces a moderate technical drift risk.
This repository is a Rust SDK/framework for building Redis modules, not an end-user application or data/research project. The workspace is organized as a library crate (`redis-module`) plus proc-macro helper crates (`redismodule-rs-macros`, `redismodule-rs-macros-internals`) that wrap the Redis Modules C API. Build code consumes vendored `redismodule.h` through `bindgen`, and the public API provides safe `Context`, `RedisKey`, `RedisString`, `RedisValue`, `RedisModuleIO`, configuration, key cursors, timers, blocking clients, thread-safe contexts, and command/info-handler registration. `redis_module!` and `#[command]` are the main module entry points; the included examples are small runnable modules, and integration tests spawn real `redis-server` processes to exercise them. Architecturally, the crate uses an unsafe FFI layer (`src/raw.rs`) underneath higher-level modules (`src/context/`, `src/key.rs`, `src/configuration.rs`, `src/io.rs`), and uses `linkme::distributed_slice` plus procedural macros to collect command, event, info, and defrag handlers. API-version compatibility is handled by feature flags (`min-redis-compatibility-version-6-0` through `8-0`) with a manual mapping table in `redismodule-rs-macros-internals/src/api_versions.rs`. The vendored C header includes Redis Labs / BigRedis extensions, reflecting production use inside Redis Enterprise modules. External build dependencies include `bindgen`, `cc`, libclang, and a Redis-compatible server for tests. The codebase is well structured for a low-level FFI SDK and contains several genuinely reusable patterns, but it has meaningful caveats: generated bindings are not committed, `bindgen` is pinned to an old version, the manual API-version table must be kept in sync as Redis evolves, and the FFI layer is necessarily large and unsafe. Overall it is an actively maintained, professional-quality SDK with a few deprecated APIs and some fragility around version-gated calls.
This repository provides Rust bindings to Apple's Security.framework, enabling safe access to Keychain services and TLS/SSL functionality. It consists of a safe wrapper crate (`security-framework`) built upon raw FFI bindings (`security-framework-sys`), with platform-specific implementations for macOS. The library employs idiomatic Rust patterns such as the builder pattern for configuration, Core Foundation type wrappers for automatic memory management, and zero-cost abstractions using `PhantomData`. Examples demonstrate TLS client connections and Keychain password operations. The architecture separates unsafe FFI bindings (generated via `ctest2` from Apple headers) from safe abstractions. Key components include Keychain item management (search/add/update/delete), SSL/TLS client/server contexts, certificate handling, and cryptographic transforms. The project is actively maintained with recent commits, includes test harnesses for iOS and system validation, and shows awareness of API evolution through deprecation markers.
FTorch is a production-stable Fortran library that enables direct coupling of PyTorch machine learning models to Fortran scientific codes without requiring a Python runtime. It provides a comprehensive Fortran interface to LibTorch (PyTorch's C++ backend) for tensor operations, model inference, automatic differentiation, optimizers (SGD, Adam, AdamW), and loss functions (MSE, cross-entropy). The architecture uses a three-layer design: Fortran modules with derived types (torch_tensor, torch_model, torch_optim) that call a thin C API (ctorch.h/ctorch.cpp), which in turn wraps LibTorch. This layered approach isolates Fortran code from C++ ABI changes and allows the library to be built as a shared or static library with CMake, supporting CPU, CUDA, HIP, XPU, and MPS backends. The library includes extensive examples covering tensor manipulation, simple neural networks, ResNet-18 inference, batching, multi-I/O, looping, multi-GPU, MPI parallelism, autograd, and full training loops. Unit tests use pFUnit and integration tests are built from examples, with CI testing across multiple compilers (gfortran, ifx, flang) and platforms. A Python utility package (ftorch_utils) provides model conversion (PyTorch to TorchScript) and validation. FTorch is published in the Journal of Open Source Software (JOSS) and is used in several HPC climate and fusion simulation codes (E3SM, CAM, ICON, UKAEA). The codebase demonstrates strong engineering practices: fypp code generation reduces boilerplate for multiple tensor ranks and data types, C interoperability is handled cleanly via iso_c_binding, and finalizers ensure automatic resource cleanup. However, there are some maintenance risks including reliance on fypp preprocessing, a large CI matrix, and the need to track LibTorch releases. A legacy API (torch_tensor_from_array_legacy) is still present but deprecated. Overall, FTorch is a well-crafted, domain-specific library that fills a critical gap for Fortran-HPC users needing ML integration.
This repository provides a cross-platform C++ tokenizer binding library that wraps HuggingFace tokenizers (via Rust), SentencePiece, and a custom RWKV world tokenizer. It exposes a common abstract interface (`Tokenizer`) with factory methods to create instances from in-memory blobs (JSON, SentencePiece model, BPE vocab/merges, RWKV model). The architecture is a static library with a C FFI layer (`tokenizers_c.h`) and a C++ wrapper (`tokenizers_cpp.h`). The Rust component (`rust/src/lib.rs`) implements the C bindings for the HuggingFace tokenizers crate, while the C++ source files (`src/`) provide implementations for SentencePiece and RWKV. The project also includes a JavaScript/WebAssembly binding via Emscripten (`web/`). Key entry points are the factory functions in `tokenizers_cpp.h` and the `example/example.cc` demonstrating usage. External dependencies include the `tokenizers` Rust crate (v0.21.2), `sentencepiece`, `msgpack-c`, and for the web build, Emscripten. The codebase is well-structured, with clean abstractions and support for multiple platforms (iOS, Android, Windows, Linux, Web).