Why DByte
A non-marketing selection guide: what v12 uniquely owns, what it deliberately lacks, and when another language is the better tool.
DByte is not positioned as a drop-in replacement for C, Rust or Zig. The useful question is whether its narrower contract matches the job.
use DByte when§
- You want byte-oriented hosted tooling and a language-owned path into deterministic i686 ELF.
- You value one canonical typed HIR across hosted/VM/native semantics.
- You are studying or building auditable low-level systems paths where object, linker and bare-metal boundaries are part of the project.
- You accept alpha scope and explicit missing features.
use a mature alternative when§
- You need a mature package ecosystem, production x86_64 application target, dynamic collections, owned String/Array, automatic Drop, concurrency, reflection or broad platform support today.
- You need established third-party libraries or stable production tooling more than DByte's narrow source-to-machine ownership.
comparison without marketing numbers§
| Question | DByte 12.0 answer |
|---|---|
| Primary differentiator | one semantic authority plus first-party object/archive/link/bare-metal lineage |
| Memory model | Copy/Move/Borrow/BorrowMut with lexical borrows; no automatic Drop in 12.0 |
| Generics | monomorphized; no traits/constraints/dictionaries/reflection |
| Current native app breadth | i686-oriented; x86_64 application target deferred |
| Ecosystem claim | none; package registry/lockfiles/third-party resolution are not v12 features |
performance claims§
No cross-language benchmark is published as release authority in the supplied v12 material. Therefore this manual does not say “faster than Rust/Zig/C”. See the benchmark ledger for the evidence policy.
SOURCE POLICY: release/tag documents define contracts; examples are copied from the supplied v12.0.0 package or explicitly marked as explanatory. Unsupported claims are not upgraded by prose.