beskid

A language and platform built for the code you ship every day—not only for kernels and firmware.

Readable semantics, compile-time power, and native output—without reflection, IL, and core-library features pretending to be the language.

Platform specification Language semantics Read the Book Download CLI

examples/modules.bd

pub mod net.http;
use net.http.Client;

type ClientConfig {
    string endpoint,
}

Client make_client(ClientConfig config) {
    return Client { config: config };
}

Why another language?

Corporations still default to Java and C# / .NET for enterprise software. Beskid exists to break that duopoly—to be a language you reach for when you need to ship services, CLIs, and platforms quickly, without inheriting a VM-shaped abstraction stack.

	C# / .NET	Java	Beskid
Why corps pick it	The default enterprise stack—familiar hiring, tooling, and vendor gravity.	The other default—JVM ecosystems, long-lived services, massive libraries.	An alternative for teams that want to ship without automatically defaulting here.
Runtime model	VM plus layers—the abstraction stack is a smoking gun waiting to fire.	JVM weight and bytecode indirection; strong ecosystem, heavy runtime story.	Native and AOT-first direction—machine code as a clear path, not a late bolt-on.
Reflection & codegen	Heavy reflection; incremental source generators with weak, frustrating APIs.	Annotations, bytecode patterns, ceremony around metaprogramming.	Compile-time analysis, compiler mods, and codegen when the compiler should answer.
Platform shape	Visual Studio–centric; platform pace tied to Microsoft’s roadmap.	Maven/Gradle ceremony; Oracle/Open ecosystem politics at scale.	CLI, pckg registry and UI, LSP, VS Code extension, and a normative platform spec as ADR.
Daily-driving fit	Strong inside enterprise walls; friction when the runtime works against you.	Strong in big orgs; ceremony and JVM overhead for small, fast-moving work.	Microservices, terminals, and internal tools—patterns for code you ship every week.

Why corps pick it

C# / .NET: The default enterprise stack—familiar hiring, tooling, and vendor gravity.
Java: The other default—JVM ecosystems, long-lived services, massive libraries.
Beskid: An alternative for teams that want to ship without automatically defaulting here.

Runtime model

C# / .NET: VM plus layers—the abstraction stack is a smoking gun waiting to fire.
Java: JVM weight and bytecode indirection; strong ecosystem, heavy runtime story.
Beskid: Native and AOT-first direction—machine code as a clear path, not a late bolt-on.

Reflection & codegen

C# / .NET: Heavy reflection; incremental source generators with weak, frustrating APIs.
Java: Annotations, bytecode patterns, ceremony around metaprogramming.
Beskid: Compile-time analysis, compiler mods, and codegen when the compiler should answer.

Platform shape

C# / .NET: Visual Studio–centric; platform pace tied to Microsoft’s roadmap.
Java: Maven/Gradle ceremony; Oracle/Open ecosystem politics at scale.
Beskid: CLI, pckg registry and UI, LSP, VS Code extension, and a normative platform spec as ADR.

Daily-driving fit

C# / .NET: Strong inside enterprise walls; friction when the runtime works against you.
Java: Strong in big orgs; ceremony and JVM overhead for small, fast-moving work.
Beskid: Microservices, terminals, and internal tools—patterns for code you ship every week.

The Beskid Principle

Six commitments that follow from that audit—not marketing pillars, but how Beskid is supposed to behave as a language and platform.

Language features stay in the language

Dependency injection, metaprogramming, and other cross-cutting concerns belong in semantics and the compiler—not as opaque layers in a runtime-shaped core library.

Compile-time over reflection

Prefer verifiable build-time analysis and codegen over runtime inspection and fragile incremental generator APIs that slow you down when you need answers from the compiler.

Native direction, not a CIL detour

Target efficient machine code with AOT as a clear path from the start—escape the overhead and late-stage surprises of a virtual machine and intermediate language stack.

Built for daily driving

Microservices, terminal tools, and internal platforms deserve simple patterns and structure—without choosing between “systems-only” languages and ecosystems that cap out at medium scale.

A whole platform experience

CLI, package registry and UI, LSP, and a VS Code extension are part of the product—not afterthoughts—so teams can adopt Beskid as a community, not a lone compiler binary.

Spec as source of truth

The platform specification is the living ADR for the language: normative decisions, vision, and implementation alignment in one tree on main—so contributors and maintainers share the same map.

Let's talk about .NET

Beskid did not start as a language war—it started as an audit. .NET taught the industry a lot about developer experience. It also accumulated performance and platform debt that shows up the moment you leave the happy path.

What .NET did right

What .NET got wrong — performance and tech debt

Ergonomic APIs and language features that respect daily work.
LINQ, async/await, records, and pattern matching keep service code readable without ceremony for every line.
Readable syntax with a coherent object model.
C# reads like intent—properties, namespaces, and nullable reference types are easy to teach and review in PRs.
- C# programming guide
- Nullable reference types
Developer experience in CLI and tooling is a high bar.
dotnet CLI, NuGet, project files, test discovery, and first-class Visual Studio / VS Code debugging set expectations Beskid should meet or beat.

Reflection-heavy libraries fight Native AOT instead of compiling cleanly.
Microsoft’s AOT guidance: walking Type graphs (typical of reflection serializers) is not supported—you must know code at compile time.
Incremental source generators became a bottleneck, not a relief.
Weak generator APIs and pipeline friction push teams back toward runtime reflection when compile-time answers should be native.
Startup and codegen costs can invert common assumptions.
One-time source-generated methods can lose to reflection because each path still pays JIT compile cost on startup.
- JIT vs one-time source-generated methods (dotnet/runtime#126541)
- Too many methods JITted on startup (dotnet/runtime#85791)
Native AOT is a late constraint bolted onto a reflection-first stack.
ASP.NET Native AOT drops or warns on controllers, Razor, session, and other MVC-era surfaces—trim/AOT warnings become a second product.
- ASP.NET Core support for Native AOT
- Native AOT deployment overview
Platform features live in Microsoft.Extensions.* layers, not language semantics.
Dependency injection, hosting, and configuration are framework contracts—not things the compiler can verify as language rules.
CIL and VM indirection remain the default tax on performance-sensitive work.
Even when AOT works, teams inherit decades of abstraction shaped for a different deployment era than edge services and tight CLIs.

Already better than C#

Not everywhere—C# still wins on ecosystem size and library mass today. Where Beskid already ships code—not slideware—the compiler lowers to Cranelift object files, resolves host/DI graphs before launch, runs Mods with generation-checked syntax pipelines, schedules cooperative fibers over a syscall pool, and collects heap objects with a Go-style concurrent mark-and-sweep GC in the `abfall` runtime.

.NET centers on `Microsoft.Extensions.DependencyInjection`: `ServiceCollection` registration, `BuildServiceProvider()`, and `GetService` resolution at runtime—generic closure caches, scope checks, and optional feature flags in hosting assemblies.

Beskid hosts are syntax: `registry { single SqlStorage for IStorage; }`, `startup(...)`, and `launch AppHost(args)`. `resolve_composition` merges the host inheritance chain (`merge_host_registries`, `merge_host_scopes`), builds a `ServiceContainer`, and topologically sorts registrations before any machine code is emitted.

Missing services, plural inject ambiguity, and lifetime override conflicts are `CompositionIssue` diagnostics in analysis—not exceptions thrown from a built container on first request.

Further reading

C# — Generic host + DI

Program.cs

var builder = Host.CreateApplicationBuilder(args);
builder.Services.AddSingleton<IConfiguration, AppConfig>();
builder.Services.AddSingleton<IStorage, SqlStorage>();
builder.Services.AddSingleton<IStorage, FileStorage>();
using var host = builder.Build();
await host.RunAsync();

Beskid — host + launch

app.bd

host AppHost(string[] args) : ConsoleHost {
    registry {
        single AppConfig for IConfiguration;
        single SqlStorage for IStorage;
        single FileStorage for IStorage;
    }
    startup(IConfiguration config, IStorage[] storages) {
        for s in storages { s.Open(config); }
    }
}
fn main() { launch AppHost(args); }

C# `IIncrementalGenerator` runs inside Roslyn, observes syntax via `IncrementalGeneratorInitializationContext`, and emits text with `AddSource`—downstream compilations must re-parse generated `.g.cs` files and fight cache invalidation across IDE keystrokes.

Beskid Compiler Mods compile as their own AOT Mod targets (`MOD_BUILD_PHASE_ORDER` through `aot.emit_object`). Generators implement SDK contracts and return structured syntax edits through `SdkSyntaxPipeline`, validated against the current `SyntaxSnapshot` generation.

The host re-parses merged syntax under `syntax_generation` phase boundaries instead of treating generated text as an opaque `#line` patch—semantic analysis always sees a single checked program before `lower`.

Further reading

C# — incremental generator sketch

RepoGenerator.cs

[Generator(LanguageNames.CSharp)]
public sealed class RepoGenerator : IIncrementalGenerator {
    public void Initialize(IncrementalGeneratorInitializationContext ctx) {
        ctx.RegisterSourceOutput(
            ctx.SyntaxProvider.CreateSyntaxProvider(...),
            static (sp, ct) => sp.AddSource("Repo.g.cs", "// emitted text"));
    }
}

Beskid — Mod generator contract

mods/RepoGen.bd

// Mod package (project.type = Mod) — AOT build + mod.descriptor.json
use Beskid.Compiler.Collect;

pub type RepoGen : Beskid.Compiler.Collect.Generator {}

GeneratedSyntaxContribution Generate(GenerationRequest request) {
    // Query + typed emit; host merges items — no AddSource("*.g.cs")
    return GeneratedSyntaxContribution {};
}

// contribution item (module level), e.g. from Generator:
extend type Order {
    pub unit EnsureRepository() { }
}

A minimal .NET generic host still expands into IL with `IServiceProvider` locals, virtual calls through hosting extension methods, and—when async is involved—nested state-machine types even for straight-line startup code.

Beskid launch lowering emits ordinary functions and static data: composition produces a `BindingPlan` consumed by codegen, field `inject` sites become direct loads/calls, and heap pointers go through `alloc` plus `gc_write_barrier` when stores can hide objects during marking.

The same `beskid_codegen` → Cranelift path compiles app logic and runtime builtins; there is no second VM-specific instruction set to optimize away later. Excerpts below are illustrative; real binaries depend on inlining and debug profile.

Further reading

IL — illustrative DI + host path (excerpt)

Program.il

.method public hidebysig instance void Run() cil managed
{
  .locals init (
    [0] class IServiceProvider provider,
    [1] class IConfiguration config,
    [2] class IStorage[] storages)
  IL_0000: call class ServiceCollection class Program::CreateServices()
  IL_0005: callvirt instance class IServiceProvider ...::BuildServiceProvider()
  IL_000a: callvirt instance object IServiceProvider::GetService(class IConfiguration)
  // ... many more calls for scopes, arrays, IDisposable checks
}

Native — illustrative Beskid lowering (comments)

app.s (conceptual)

; launch AppHost — no ServiceProvider type
app_host_init:
    lea     rdi, [rel registry_vtable_sql]
    call    SqlStorage_open
    mov     [rel aggregator_storages], rax
; field inject offsets known at compile time
Aggregator_Process:
    mov     rax, [rbx + 24]    ; inject IConfiguration

Native AOT for .NET is a publish profile layered onto a reflection-first BCL: trim analyzers, feature switches, and component support matrices gate what can ship.

`beskid build` walks the same pipeline ids as the spec (`lower` → `codegen_clif` → `aot.emit_object` → `aot.link`). `beskid_aot::BeskidObjectModule` lowers each `CodegenArtifact` function through Cranelift into a PIC object file, then links the prebuilt runtime—no intermediate language in the hot path.

JIT (`beskid_engine`) reuses the same CLIF lowering for dev runs; AOT is not a separate language mode, just the normal artifact path with a platform linker at the end.

Further reading

C# — publish profile mental model

publish

// dotnet publish -r linux-x64 -p:PublishAot=true
// + trim warnings, reflection analyzer, feature switches
// + library support matrix per component

Beskid — build target

Project.proj

// App target — AOT backend in build pipeline
target app App {
    backend Aot
}

C# `async/await` lowers to `IAsyncStateMachine` types with `MoveNext` state machines and `Task` allocations; every await is a compiler transform, not a lightweight stack switch.

Beskid `spawn` is analyzed in `beskid_analysis` and lowered to `fiber_spawn` / `fiber_spawn_with_cancel_slot` builtins (`beskid_runtime::scheduler`). The scheduler is cooperative M:N: `corosensei` stacks, a run queue, and `processor_count()` aligned to available parallelism.

Blocking work uses `syscall_pool`: the current fiber parks, a worker thread runs the syscall/body, then `wake_fiber` resumes the coroutine—same ergonomic “write blocking code” story as Go, without adopting Go's whole runtime or conservative GC tradeoffs here.

Channels, mutex, wait-group, and cancel propagate through split ABI status/value builtins (M1–M6 in `CONCURRENCY_STATUS.md`); there is no `async` keyword or state-machine codegen path in the compiler.

Further reading

C# — async expands to state machine

Worker.cs

public async Task RunAsync() {
    await DoWorkAsync();
    // compiler generates IAsyncStateMachine + MoveNext
}

Beskid — spawn + channel

worker.bd

fn Run() {
    Fiber<void> f = spawn { Process(); };
    Channel<int> ch = Channel<int>.Create(64);
    f.Join();
}

async/await is ergonomic until it isn't: forgotten ConfigureAwait in libraries, sync-over-async deadlocks on UI threads, exception stacks split across awaits, and analyzer churn on ValueTask vs Task.

The Beskid compiler has no async/await lowering pass—suspension is explicit via fiber yield, channel receive, and syscall parking. Failures return through `Result` and channel status codes, not task exception aggregation.

That removes an entire class of IL and debugging surface area: no state-machine types in metadata, no continuation marshaling back to a captured `SynchronizationContext`, and no “blocked thread pool thread” failure mode from `.Result` on a UI handler.

Further reading

C# — classic deadlock shape

UiThread.cs

button.Click += async (_, _) => {
    var data = GetDataAsync().Result; // sync-over-async
};

C# DI failures often surface at runtime: missing registration, captive dependencies, wrong lifetime—discovered in staging or production via `GetService` / `GetRequiredService`.

`beskid_analysis::composition::resolve_composition` runs in the `composition.resolve` pipeline phase: it builds the launch host chain, merges registries and scopes, validates scope trees, resolves `inject` fields into a dependency graph, and emits `CompositionIssue` diagnostics (duplicate launch hosts, lifetime override conflicts, unresolved inject) before codegen.

Successful resolution produces a `BindingPlan` and `CompositionSnapshot` with topo-ordered registration init—lowering wires real calls, not a runtime `IServiceProvider` dictionary lookup in the hot path.

Further reading

Beskid — override lifetime check

hosts.bd

host Child : Parent {
    registry {
        transient Logger for ILogger; // error if parent had single
    }
}

Beskid

Beskid

Beskid

beskid

beskid

Why another language?

Why corps pick it

Runtime model

Reflection & codegen

Platform shape

Daily-driving fit

The Beskid Principle

Language features stay in the language

Compile-time over reflection

Native direction, not a CIL detour

Built for daily driving

A whole platform experience

Spec as source of truth

Let's talk about .NET

What .NET did right

What .NET got wrong — performance and tech debt

Already better than C#

App startup: registry vs ServiceCollection

Compiler Mods vs IIncrementalGenerator

What lands in the binary

Why AOT + language features beat corelib composition

AOT as the default build path

Concurrent mark-and-sweep GC (shipped)

Fibers instead of async state machines

async/await foot-guns

Compile-time DI graph

Deterministic mod scheduling