libLogit

Beta Language Intake

This list ranks likely post-Alpha bindings by user value, ecosystem fit, implementation cost, package distribution difficulty, and conformance risk. It is a planning guide, not a promise that every language ships in the first Beta.

v1 Beta is contract-first. A language counts only when it implements the shared LOGIT contract, ships usable install instructions, passes conformance checks, and has enough package/release evidence to be maintained.

Support Tiers

Tier Meaning Counts Toward Beta
Supported Alpha baseline Existing MVP binding that already proves the Alpha contract and is a candidate for Beta stabilization. Yes, after Beta gates pass.
Incubating Beta candidate A planned or partial binding that should follow the Beta playbook before it can be called supported. No.
Future/community binding A language with user demand or strategic value but no release commitment. No.

Supported Alpha Baseline

These bindings exist in the current Alpha matrix and are the first candidates for Beta stabilization:

Language Current Role Beta Stabilization Focus
Python Reference implementation. Keep as the behavioral reference for config, SQLite, viewer, retention, buffering, redaction, and failure policies.
C++ Native object API and CMake install/export path. Stabilize installed include layout, package docs, fixture parity, and path behavior.
C Native procedural binding. Tighten lifecycle, config adapter, and fixture reporting.
C# Managed .NET binding with NuGet metadata. Finalize package install docs, config-loaded examples, and fixture parity.
Java JVM binding with Maven metadata. Finalize Maven install docs, jar verification, and fixture parity.
JavaScript Node binding with npm metadata and installed-tarball smoke coverage. Stabilize package import shape, TypeScript declaration path, and fixture parity.
Go Go module/package docs. Finalize module path, examples, config adapter, and fixture parity.
Kotlin JVM companion package. Keep aligned with Java while preserving idiomatic Kotlin usage.

Incubating Beta Candidates

Priority Language Why It Matters Main Risk Suggested First Artifact
1 TypeScript Builds directly on JavaScript and gives typed Node users a better SDK surface. Keeping JS and TS docs/packages aligned. npm package with generated declarations or source TypeScript.
2 Rust-style API Strong desktop/service demand and good fit for structured logging concepts. Ownership and async expectations may push beyond core Beta semantics. Crate with sync file/console sinks and fixture runner.
3 Swift Important for macOS desktop apps and future Apple-platform reach. Package and platform testing require macOS hosted coverage. Swift Package Manager module.
4 PHP Useful for broad web hosting adoption and simple file logging. Runtime versions and deployment environments vary widely. Composer package.
5 Ruby Good ergonomics for DSL-like LOGIT setup and scripting users. Smaller modern demand than TypeScript/Rust/Swift. RubyGem.
6 Scala Extends JVM coverage for teams that want functional or typed APIs. Java/Kotlin bindings may already satisfy many JVM users. Maven/Gradle artifact wrapping Java semantics.
7 Dart Gives Flutter desktop projects a route into the SDK vision. Non-desktop targets may need separate path and storage rules. pub.dev package focused on desktop first.
8 Objective-C Complements Swift for older macOS/iOS codebases. Demand may be limited and packaging is less uniform. Source package or CocoaPods proof of concept.
9 Delphi/Object Pascal Relevant for Windows desktop applications. Toolchain availability and CI setup may be difficult. Source vendoring package with examples.
10 Ada Valuable for high-assurance/native systems and already has sketches. Needs modernized object model, v2 config, packaging, and Ada CI tooling. Alire or source-vendored package after fixture runner exists.

Future/Community Pool

Future requests should be collected with the same intake template rather than being added straight to the supported list. Possible future families include additional JVM/.NET languages, shell-oriented bindings, Lua, Perl, R, Julia, Elixir, Erlang, Haskell, F#, and platform-specific wrappers.

Ranking Criteria

Criterion Meaning
User demand Likely number of users who would benefit from native-feeling logging.
Ecosystem fit How naturally LOGIT maps to common language patterns.
Implementation cost Expected effort to build, test, and maintain the binding.
Distribution difficulty Package publishing, binary compatibility, runtime requirements, and CI cost.
Conformance risk Likelihood that language semantics make the shared contract difficult to preserve.

Intake Workflow

  1. Open a binding proposal using docs/bindings/new-language.md.
  2. Classify it as incubating or future/community.
  3. Confirm the target package artifact and minimum runtime version.
  4. Implement blank LOGIT construction and direct logging.
  5. Implement structure-fed and config-loaded setup.
  6. Add console and local file output.
  7. Add a shared fixture runner.
  8. Add package metadata and one direct plus one config-loaded example.
  9. Add hosted CI only after local verification is stable.
  10. Promote to supported only when the Beta playbook gates pass.

Beta Cut Line

The first Beta should prefer fewer well-verified bindings over many partial ones. A binding should not count toward Beta readiness until it has install instructions, conformance coverage, package/release evidence, documented limitations, and a clear maintenance owner.