AdeshLang

1. Introduction

A program is a set of precise instructions. That idea is the whole premise of AdeshLang: the name is the goal. The language is designed for developers who want expressive syntax, predictable performance, and backend flexibility without sacrificing correctness^[1].

The project exists because the usual trade-off feels false. Scripting languages are easy to start but push correctness checks to runtime. Systems languages catch mistakes early but demand steeper up-front effort. AdeshLang's thesis is that one source language can serve both ends: a beginner writes an interpreted script immediately, while the same program later moves to a faster backend unchanged.

2. Design philosophy

• Clear instructions. The language prefers explicit code over hidden behavior. A program reads like the commands it is.
• Safety by default. Memory safety, ownership awareness, and clear type rules are central; the compiler and runtime cooperate to catch mistakes early^[1].
• Performance with flexibility. No program is locked to one execution strategy. Interpreter, bytecode, JIT, native, WASM, or GPU — chosen per need.
• Progressive learning curve. A first script in minutes; performance and compiler-level work available when the developer is ready.

3. Architecture

AdeshLang separates the source language from the execution model. The entire toolchain — lexer, parser, AST, IR lowerings, and CLI harness — is built in Rust^[2], which contributes its own zero-cost abstraction model to the project.

1. Source code
2. Lexer
3. Parser
4. AST
5. Semantic analysis
6. IR / Runtime model
7. Execution backend

This separation is what makes the language modular: the same program can be interpreted quickly during development, compiled for production, or adapted to specialized hardware^[1].

4. Type system

Types are static and checked at compile time. A typed parameter is part of the first program anyone writes:

fn greet(name: string) {
    print("Hello, ", name, "!")
}

fn main() {
    let user = "World"
    greet(user)

    for i in 1..5 {
        print("Count: ", i)
    }
}

The language supports functions, control flow, collections, objects, generics, async patterns, and more advanced features such as pattern matching and decorators^[1]. Because checking happens before execution, whole classes of runtime errors — a missing field, a wrong argument type — surface while the program is still being written, which is what makes large codebases predictable.

5. Memory safety model

AdeshLang pursues zero-cost safety: compile-time reference and borrow checking without garbage-collector pauses^[1]. Ownership-aware rules let the compiler reason about who holds a value and when it can be released. The practical consequences:

• No GC pauses in long-running programs, so latency stays predictable.
• Mistakes surface at compile time instead of as crashes or corruption in production.
• Safety is an abstraction the compiler verifies, not a runtime cost the program pays.

6. Execution backends

The backend matrix is one of AdeshLang's defining strengths — one source language, many execution strategies. Current status:

The tree-walk interpreter is the primary reflection of AdeshLang execution and standard library behavior^[1]. The Cranelift backend generates native code at runtime via function pointers; the project reports 10–230x speedups on suitable workloads^[1][3].

7. Related work

AdeshLang borrows deliberately and openly. From Rust it takes the compile-time ownership discipline and much of the toolchain implementation language^[6]. From Lua and Python it takes the idea that a first program should be three readable lines. From Swift and Go it takes the position that static types and approachable syntax are not opposites. The multi-backend strategy follows the pattern of MLIR^[4] and WASM^[5]: represent the program once, lower it many ways.

The difference is scope under one roof: most languages ship one or two execution models. AdeshLang treats the backend itself as the research object.

8. Status and limitations

AdeshLang is an experimental language. Syntax, APIs, and semantics evolve as ergonomics and architecture are refined^[1]. Backends beyond the interpreter are experimental or partial. The honest framing: this is a live research project in the open, not a finished product — and that is the point.

9. Future work

• Stabilize the Cranelift JIT, AOT, and bytecode VM backends toward parity with the interpreter.
• Advance the WASM and GPU / MLIR lowering paths^[4].
• Grow the standard library, including the built-in networking stack (TCP, UDP, HTTP, WebSockets, DNS, TLS)^[1].
• Improve diagnostics and tooling so the language keeps its beginner promise as features deepen.
• Onboard contributors — the compiler is open, and the project explicitly welcomes them^[2].

References

1. AdeshLang documentation — purpose, philosophy, and backends
2. AdeshLang GitHub repository (Rust toolchain)
3. Cranelift code generation library
4. MLIR — Multi-Level Intermediate Representation
5. WebAssembly specification
6. The Rust programming language