EYG Bets the Hard Part of Programming Isn't Syntax

Every few years someone announces a programming language "for humans," and it almost always means the same thing: friendlier keywords, maybe blocks you drag around. EYG — "Eat Your Greens," from longtime Gleam community member Peter Saxton — is more interesting than that, because its diagnosis is different. Saxton's argument is that non-professional programmers don't actually struggle with logic. Conditionals, loops, variables — the people he calls "makers" handle those fine, in spreadsheets, every day. What kills their projects is everything around the logic: deployment, dependency management, environment configuration, the silent contract between a script and the machine it runs on.

That's a sharper observation than the usual end-user-programming pitch, and EYG's design follows it consistently. Whether the language finds the audience it's aimed at is a separate question — and I don't think it will, at least not the advertised one. But the pieces it assembles are worth your attention anyway.

What EYG actually does

EYG is a statically typed functional scripting language with three load-bearing decisions.

First, managed effects. Every side effect a program can perform — fetch a URL, prompt the user, resolve DNS — appears in its inferred type. You perform an effect; a runtime either provides it or refuses to run the program, and you can handle effects to intercept them, which gives you test doubles without a mocking framework. Crucially, the full effect surface of a program is statically inferable before execution. You can look at a script you didn't write and know, with compiler-grade certainty, that it can hit the network but can't touch your filesystem.

Second, content-addressed, immutable dependencies. Dependencies are identified by hash rather than by name-plus-version-range, which dissolves the entire category of resolution conflicts, lockfile drift, and left-pad-style mutation. If you've watched Unison over the past few years, this is familiar — Unison pioneered storing code as content-addressed definitions — but EYG pairs it with a conventional curly-brace syntax and a tree-based intermediate representation as the stable interface, so text, structural editors, and other projections are all just views over the same AST.

Third, a sound structural type system with full inference. No annotations required, no nominal ceremony where you model your domain up front — a deliberate departure from Gleam's nominal types, and a sensible one for glue code, where the shapes of your data are dictated by whatever API you're consuming. The site makes the Elm-style claim that well-typed programs never crash. Sound row typing over records and effects makes that claim more credible than it usually is, though "never" is doing marketing work: a sound type system rules out a class of crashes, not misbehavior.

The implementation, fittingly, is written in Gleam, with a JavaScript interpreter that runs in the browser and on servers, a CLI installable via a curl one-liner, and a JSON specification of the evaluation rules that doubles as a conformance suite for alternative runtimes.

The graveyard problem

Here's the skeptical case, and the Hacker News thread on Saxton's post made it loudly: languages aimed at non-programmers have a century of half-successes that all curdled into professional tools. COBOL was for business people. SQL was for analysts. Visual Basic, AppleScript, HyperCard — each found real users, then either professionalized or died. The one durable exception is the spreadsheet, and Saxton himself points to Excel as the most successful programmable environment ever built. Excel won not because its formula language is pleasant but because it deleted operations entirely: no deploy step, no dependencies, no environment. The program lives in the document.

By that measure EYG is aiming at the right target — it's trying to give scripts the operational weightlessness of a spreadsheet formula. But the current on-ramp undercuts the pitch. A maker who won't learn systemd is not going to pipe curl into bash, and the package-sharing hub is still in closed beta. Darklang chased the same "deployless" dream with a fully hosted editor and still couldn't convert the mainstream. The gap between EYG's philosophy and its packaging is exactly the gap that has swallowed every predecessor.

The audience that's actually showing up

Which brings me to the tell. The GitHub repo's current framing isn't "for humans" at all — it's "the safest scripting language for you, or your agent," positioned as a typed replacement for bash and make, with scripts as plain (List(String)) -> Integer functions.

That repositioning is quietly the strongest version of the idea. The properties Saxton designed for makers — statically inferable effects, deterministic execution, immutable dependencies, soundness without annotations — are precisely the properties you want when an LLM is writing the script. Today, when a coding agent generates a shell script, your options are reading it carefully or YOLO. An EYG script arrives with a machine-checked manifest of everything it can do, and the runtime enforces it. That's capability-based sandboxing at the language level, no container required. Deno's permission flags gesture at this; effect typing does it with per-program granularity and static verification.

If I were betting on where EYG lands, it's not aunts automating their greenhouses. It's developers — and their agents — using it where bash's failure modes are intolerable: CI glue, cron jobs, webhook handlers, the scripts that quietly run your infrastructure and explode on an unset variable.

Should you touch it?

Not for anything you'd page someone over. This is a small project — a few hundred GitHub stars, packages marked unpublished, runtimes for CLI, Arduino, and integration platforms still in development. The risk isn't that it breaks; deterministic semantics and a spec-as-test-suite are more rigor than most young languages manage. The risk is that it stalls, as one-person languages usually do.

But the design is a coherent preview of ideas that are coming regardless. Unison proved content-addressed code works. Effect systems are moving from research into practice. EYG's contribution is combining them in a scripting-sized package and pointing them at ops pain instead of syntax aesthetics. Spend an afternoon with it — write a small glue script, watch the effect types materialize without a single annotation — and you'll return to your shell scripts newly annoyed. That annoyance is the point, and some language you use in 2030 will be built on it.