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.
use Concurrency.Fiber;
use Core.Results;
i64 Answer() { return 42_i64; }
i32 Main() {
Fiber<i64> worker = spawn Answer();
return match worker.Join() {
Result::Ok(value) => i32(value),
Result::Error(_) => 1,
};
}
use Concurrency.Channel;
use Concurrency.ChannelError;
use Core.Results;
Result<Channel.SendOk, ChannelError> Publish(Channel<i64> messages) {
return Channel.Send<i64>(messages, 42_i64);
}
i32 Main() {
Channel<i64> messages = Channel.Create<i64>();
let sender = spawn (() => Publish(messages));
let received = Channel.Receive<i64>(messages);
let joined = sender.Join();
Channel.Close<i64>(messages);
return match received {
Result::Ok(value) => i32(value),
Result::Error(_) => 1,
};
}
type Logger {}
type Worker { inject Logger logger; }
host AppHost() {
registry {
single Logger;
single Worker;
}
startup() {}
dispose() {}
}
i32 Main() {
launch AppHost();
return 0;
}
// Excerpt: the caller opens and closes the TCP stream.
use Core.Results;
use Http.Client;
use Http.Errors;
use Http.Types;
use Network.Tcp.TcpStream;
pub Result<Response, HttpError> Get(TcpStream stream) {
Request request = Request {
method: "GET",
target: "/",
headers: [Header { name: "Host", value: "loopback.test" }],
body: [],
};
return Client.Send(stream, request, Types.DefaultLimits());
}
From the blog
Release notes, compiler work, and the decisions behind the next version.
A preview of reactive properties, the trade-offs behind their design, and the compiler, tooling and runtime work carried into the 0.7 roadmap. Familiar accessors, explicit observation, and costs the AOT compiler can account for.
Read the postThe planned final 0.6 update focuses on useful diagnostics, a responsive editor, predictable runtime behavior and simpler local collection code. Implementation is in progress; this is a roadmap, not a release announcement.
Read the postAn engineering report on the 0.6.6 parallel runtime: isolates, transfer classes, ports, parallel sequences, incremental collection and Rust Glue, with qualification still separate from publication.
Read the postCorporations 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. |
Six commitments that follow from that audit—not marketing pillars, but how Beskid is supposed to behave as a language and platform.
Dependency injection, metaprogramming, and other cross-cutting concerns belong in semantics and the compiler—not as opaque layers in a runtime-shaped core library.
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.
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.
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.
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.
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.
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.
LINQ, async/await, records, and pattern matching keep service code readable without ceremony for every line.
C# reads like intent—properties, namespaces, and nullable reference types are easy to teach and review in PRs.
dotnet CLI, NuGet, project files, test discovery, and first-class Visual Studio / VS Code debugging set expectations Beskid should meet or beat.
Microsoft's AOT guidance: walking Type graphs (typical of reflection serializers) is not supported—you must know the code at compile time.
Weak generator APIs and pipeline friction push teams back toward runtime reflection when compile-time answers should be native.
One-time source-generated methods can still lose to reflection, because each path pays JIT compile cost on startup.
ASP.NET Native AOT drops or warns on controllers, Razor, session, and other MVC-era surfaces—trim/AOT warnings become a second product.
Dependency injection, hosting, and configuration are framework contracts—not things the compiler can verify as language rules.
Even when AOT works, teams inherit decades of abstraction shaped for a different deployment era than edge services and tight CLIs.
Concrete differences, with their limits: current source supports native AOT application builds, compiler-checked host composition, Compiler Mods, cooperative fibers and typed networking/HTTP. Incremental collection and parallel isolates are separate 0.6.6 candidate engineering, not a confirmed public release. Reactive properties remain a 0.7 proposal. C# retains a much larger ecosystem; this is an architectural comparison, not a speed ranking.
