A few good ideas in programming languages

For pedantry, should we note that design by contract came all the way from Eiffel ?

(But it's possible that even less people ever wrote Eiffel than D, so, who knows)

> Borrow Checking

It's very confusing name for this feature. It suggest that some sort of borrowing takes place and that it's just an optional check, which isn't the case. It should be named something like "enforced static usage analysis" instead.

In my programming language I have similar mechanism. But it isn't just checking, since it affects code generation by tracking which variables are still in use and which can be destroyed.

I didn't expect this to get posted here. Long time lurker here.

I'm really interested in programming language design and ergonomics. What niche PL features would you like to see have more adoption?

If you're serious about doing OO with static typing as well as (of course) mutability, you basically have to have something like flow typing to keep away the circle/ellipse nonsense. (In so far as flow typing is really static typing at all!)

Nice list. I have a new language I'm working on (called Zena: https://zena-lang.dev/) with all of these in some form:

If you have static types and unions, control-flow analysis and narrowing is critical for avoiding an excessive amount of casts - and if you also have pattern matching, you get very nice style where a type-check, state extraction, and branch are all one expression.

Borrow checking. Zena is a GC'ed language, but it runs in Wasm and lots of Wasm resources are external, so Zena has affine types and second-class values for managing resources and disposing of them when no longer used. GC + borrowing is a great combo because you don't need borrowing for everything and lexical lifetimes with a few escape hatches cover most things. The ownership system is also great for modeling structured concurrency.

I'm working on contracts after borrow checking is complete. My impetus there is AI-generated code. If humans still review at all, reviewing the contacts more than the implementations makes managing large amounts of changes easier.

I'd like to see a few more good ideas spread:

Formal verification. Contracts should be a good stepping stone into a spec language, from there a proof language and checker. This should also be good for AI-generated code.

Numeric unit types / units of measure with dimensional analysis. We should be able to say that a variable isn't just a f64, but a f64 of meters, and when divided by seconds, give a velocity. I don't know why this hasn't made it into more mainstream languages, but it seems like it makes programs more clear, not just statically safer. For synax, my plan is to parameterize scalars by units, like f64<m> vs f64<s> and have units like `m` and `s` be associated with dimensions like `length` and `duration`.

Async cancellation. I added cancellation as a first-class language concept in Zena so that it can be handled like exceptions, but aren't exceptions. It extends try/catch to try/catch/cancel/finally. When a task is canceled, a cancellation unwinds the stack starting from the next suspension point (await). The benefit here is that you don't have to remember to check for cancellation in async functions - they're all cancellable.

I know it's controversial but I really do love C++26's contract assertions.

I find they enable you, your consumers, IDEs, agents, etc understand the contracts of a method far faster, as it means you don't actually have to read the full method body. If the pre condition is correct and the post condition fails then you can be fairly sure the bug report goes to whoever owns that method, as either the precondition is wrong or the method is wrong.

Borrow checking (as frustrating as it is) is a good idea. I never knew about invariants in D, and now I want them in my language 's classes!

But flow typing? That seems like a footgun...

A genuine question: is the first point (flow typing / type narrowing) a subset of or intersection with or just an alias to SSA (static single assignment)? I'm playing with a small interpreted language implementation that is based on Lua, and have reached a point where I want to implement a single-pass SSA (there is a nice short CS paper on this), but cannot get my head around all the concepts, even if I need proper SSA for Typescript-like usability.

This "flow typing" looks very intriguing to me: So, in s sense, what we know as "dynamic typing" is more precisely describable as "runtime" (not compile-type) dynamic typing?

    out (; balance == balance + amount) // checked after method returns

Completely free flow typing is risky in terms of interpretability, but type narrowing - var a : supertype; if (a is subtype) { // a is known to be subtype }, or type case, saves boilerplate in any OOP language.

How does contract programming differ from refinement types?

I feel like languages are playing around different paints if coat mostly, and not trying to build more meaningful programming experiences.

I'd love to see a language whose pitch is that they have very next level stdlibs builtin. Effect for example is basically a mini stdlibs unto itself. It would be amazing to see such a principled deliberate craft applied to a language. Scope, layers etc etc etc etc: make visible, make first-class the actual pieces of computing, make them part of the language, explicitly modelled.

I'm also super excited for Zena, which just got announced yesterday! A typescript alike that compiles to wasm, and which really leans in to modern wasm, such as gc, wasi. A language that sits well at the cross-roads, that is excellent glue, that runs anywhere, that bridges other languages, is very compelling. https://justinfagnani.com/2026/09/09/zena-a-new-wasm-first-p...

Have there been any new good ideas in programming languages since LLMs came around? Or are we over that now..

I wonder how soon until we see a language designed for LLMs. I wouldn't be surprised if Anthropic or OpenAI were working on something like that.

No idea what it would look like, but it's pretty likely that "optimized for humans" and "optimized for agents" are not identical. For some class of problem, we really don't need people to be in the code, and I expect that surface area to continue to expand.

Something that is optimized for context efficiency, for example, would be huge. You can go hard on the formalism and correctness, to an extent that would be a pain in the ass for humans but LLMs don't care. Think Rust borrow checker but higher up the stack for a different class of correctness.