Compare Tables Are Propaganda. Here Is Ours.

Every language landing page has a comparison table. It is the most predictable genre in developer marketing. Three columns. Rows for performance, safety, ecosystem, tooling. The author’s language wins every row that matters and “respects” the competition on the others. The table is propaganda, and everyone knows it. The only question is whether the propaganda is honest about being propaganda.

The Beskid landing page has a comparison table. It is not subtle.

The commit that built it — c92d17dd — says “redesign landing and downloads surfaces.” The diff was not a redesign. It was a statement of position. The landing page declares what Beskid is, who it is for, and — just as importantly — who it is not for and why. The commit that followed two days later — a4e7f1b8 (“add .NET audit sections to landing page”) — added the two lists that sit below the comparison table: “What .NET did right” and “What .NET got wrong.” The commit message for that one was almost apologetic: “this feels combative but honest is better than diplomatic.” It was the right call. The audit sections are now the most-linked part of the landing page because they answer the question every .NET developer asks when they first hear about Beskid: “Why would I leave .NET for this?”

The structure of the page is a ladder. Hero at the top: a code sample, not a slogan. pub mod net.http; — a module declaration, not hello world. The deliberate choice: show the syntax that matters, not the syntax that is easy. Module declarations are how Beskid programs begin. Showing one says: this is a language for building systems, not for printing strings. The download button as a ghost variant — present, accessible, not pushed. Beskid is not trying to maximize installs. It is trying to maximize informed installs.

Then the comparison table. The rows: “Why corps pick it,” “Runtime model,” “Reflection and codegen,” “Platform shape,” “Daily-driving fit.” These are not the rows you see on most language comparison pages. Most pages compare performance benchmarks, package counts, and Stack Overflow questions. Beskid’s table compares decision criteria: why does an engineering team choose this language? What does the runtime actually do? Can you generate code at build time or are you stuck with runtime reflection? What does the platform include beyond the compiler?

The answers are partisan. .NET’s row under “Why corps pick it” says something about enterprise ecosystem and Microsoft support. Java’s row says something about the JVM’s maturity and the breadth of available libraries. Beskid’s row says something about owning your toolchain and not betting your architecture on a vendor’s roadmap. The table does not pretend to be fair. It tells you whose side it is on: the side of teams that have been burned by vendor deprecations, runtime version conflicts, and the gradual realization that “supported” means “supported until our strategy changes.” The row for “Platform shape” is particularly revealing. .NET’s answer describes the ASP.NET pipeline, Entity Framework, and the broader Microsoft ecosystem — a platform that solves problems for you, at the cost of solving them the Microsoft way. Beskid’s answer describes a standard library, a build tool, and a package manager — a platform that gives you components and gets out of your way. The difference is philosophy made concrete. One row. Three sentences. The entire argument for Beskid in microcosm.

Below the comparison table: the .NET audit. Two lists. “What .NET did right” and “What .NET got wrong.” The “right” list is genuine — LINQ, async/await, the CLR’s JIT, the tooling ecosystem. Beskid exists because .NET got enough things right that leaving it was painful. The “wrong” list is specific: AOT compilation that arrived a decade late and still has caveats, reflection-based serialization that kills startup performance, a component model that assumes the framework owns the process lifecycle, an ecosystem that treats native interop as a last resort. Each item is cited. Each citation is a scar.

This is the opposite of most language landing pages. Most pages say: “Our language is great! Here are the features!” The Beskid page says: “Here is what we left. Here is why we left it. Here is what we built instead. Judge for yourself.” The “already better” section — added in commit d9c3f5e2 (“add already-better section with verifiable claims against Platform Spec”) — lists things Beskid does that .NET cannot do without breaking changes: file-scoped modules, zero-cost FFI, AOT-first compilation, a GC model that doesn’t assume it owns the heap. Each claim is linked to a specific section of the Platform Spec. The “file-scoped modules” claim links to Spec §3.2. The “zero-cost FFI” claim links to Spec §7.1. The section is not arrogant. It is precise. Each claim is verifiable against a normative document that the compiler is tested against. The landing page is not saying “trust us.” It is saying “here is the spec, here is the compiler, go verify.”

The six principles close the page: ownership without garbage, concurrency without accidents, native without FFI pain, modules without namespaces, errors without exceptions, platform without vendor lock-in. Each principle is a direct answer to something that went wrong in the .NET ecosystem. Ownership without garbage answers the GC pause problem — the author once spent a week tracking down a latency spike that turned out to be a gen-2 collection firing during a request handler. Concurrency without accidents answers the async void problem — the author once crashed a production server because an async void method threw an unhandled exception and the runtime had nowhere to route it. Native without FFI pain answers the P/Invoke problem — the author once wrote 200 lines of marshaling code to call a 20-line C function. Each principle has a scar behind it. The landing page doesn’t show the scars, but the Book does. The principles are cross-referenced to the Book chapters that tell the full story. The principles are not aspirational. They are design constraints that every commit is measured against — and CI enforces that measurement.

The philosophy behind the landing page is simple: don’t pretend to be neutral. Beskid exists because .NET failed at specific things. Java failed at specific things. Rust succeeded at specific things but introduced different problems. Naming the failures and successes is more honest than pretending all languages are equally valid choices in some abstract design space. They are not. A language is a set of tradeoffs, and the tradeoffs have consequences for the people who use it. The landing page tells you what tradeoffs Beskid made and why.

The code sample in the hero deserves attention. It is not fn main() { println!("Hello, world!"); }. It is not a Fibonacci function. It is a module declaration with an HTTP import: pub mod net.http;. The message: Beskid is for building networked systems. The first thing you see when you visit the landing page is the syntax for importing the HTTP library. If that doesn’t interest you, Beskid might not be for you. The page is filtering, not persuading. It wants the right users, not the most users. This is also why the download button is a ghost variant — present, accessible, not pushed. The commit that made that choice (c92d17dd) had a commit message body that read: “Primary CTA should be ‘Read the Book,’ not ‘Download.’ Downloads without understanding produce bad bug reports.” The landing page is an intake filter. It tells you what Beskid is, what it costs, and who it hurts. If you’re still reading after the comparison table, you might be the target audience. If you left after the hero code sample, you were never going to be happy here anyway.

Cross-reference Book chapter “Current state of languages” — the chapter expands on the comparison table with deeper analysis of each language’s design choices and their consequences. The landing-tile-sections.ts component that renders the six principles on the landing page. The compare table is propaganda, but it is propaganda with a bibliography. Every claim traces back to a specific experience, a specific commit, or a specific section of the Platform Spec. Compare tables are propaganda. At least ours cites sources.