There's an API: you can use Gemini with other harnesses. Isn't the situation exactly like Claude vs Claude Code?
11,928 karma · joined August 4, 2011
I use a mix of Fable 5.1, Opus 5.5, and Gemini 3.8 Flash and Gemini holds it's own. Especially in writing, frontend, and sysadmin work. agy for configuring a NixOS system has been truly incredible.
My understanding is that i32 and f64 literals are pretty common among the more modern languages because f64 isn't much slower than f32 on modern CPUs and f32 costs precision, but i64 is slower than i32 (especially multiplies and divides or on 32 bit hardware) and i32 costs range, not precision, and most uses don't need the extra range.
"Dart-style constructors, Swift-style pattern matching and Strings, Trio-style async cancellation, Scala-style sealed classes"
One reason I haven't explored that is that I want to tailor the language for the more constrained environment of Wasm GC first.
The one thing I do see sometimes is that agents sometimes don't take advantage of added features, but that's partially because the Zena code base doesn't use them as much yet. I'm working on skills and linter-based suggestions to use better patterns.
---
- Correct by construction: the language makes invalid states or programs hard or impossible to express.
- Statically established: types, proofs, and static analysis establish properties before execution.
- Runtime-enforced: memory management, isolation, capability boundaries, and other runtime enforced properties.
- Empirically validated: program validation through tests, property-based testing, and fuzzing.
---
Along with being familiar, so it's easy to generate, is a huge part of why I'm building Zena: https://zena-lang.dev/
I don't have the AI-first rationale put into the public docs well just yet, but I mention some of it here: https://zena-lang.dev/guide/why-zena/#familiar-to-humans-and...
along with a doc in the repo on this topic: https://github.com/elematic/zena/blob/main/docs/design/ai-fi...
In short, the more deterministic, automated, checks the better. AI can deal with a pedantic language. I intend to add statically verified structured concurrency, units of measure, contracts, and eventually more and more formal methods into the language so it can be a familiar TYpeScript-like base with as many static guarantees as we can fit in.
I also think that fine-grained isolation, which Zena gets via Web Assembly, is critical for limiting the capabilities of generated code and the blast radius of bugs, vulnerabilities, and non-aligned behavior.
I do have an optimistic hope that a language also optimized for humans, readability and simple semantics especially, has value in the future, even when most code is generated. We'll see about that.
If the military wants to use AI to autonomously kill people, they can - Anthropic is not stopping them - thy just can't with Anthropic's services.
The government retaliating by then claiming that any use of Anthropic is risk is an obvious farce. How would Anthropic be any less of a risk if they let Claude autonomously kill people?
You can argue that high-throughput / low-latency dev tools are one of these environments. I'm not so sure. I think a lot of JS tooling is written in slow JS and gets fast with a rewrite to another language largely because of better structure.
Some environments really are tougher though. I started using WebAssembly a lot a year ago and the story for JavaScript and Python is just pretty terrible. And for JS, the things that make it hard to run in Wasm aren't universally good things to have in the language in the first place. The extreme dynamism of JS is something that so much JS tooling tries to limit.
But I think a lot of the language is quite good, and that there are possible variants of JS that are great even. I started one I hope will fit that one day (https://zena-lang.dev) and the first use cases for me are all tooling to try to make sure it's at least good for that: self-hosted compiler, formatter, regex engine, JSON parser, etc. It's quite a bit like JS/TS, but fixes a lot of things and runs forward with features that will take JS many years to get to, if it ever does (ie, pipelines, pattern matching).
I'm hoping that WebAssembly can slowly continue to gain a place on the web so JS can give up its near monopoly there. We'll see!
It's not corporate lawyers who show up to protest new housing, it's retiree homeowners.
Housing right now is the opposite of a commodity: it's a boutique investment for individuals whose price is propped up by regulations that artificially limit supply.
"Apple framed WWDC 2026 around three pillars: platform improvements, trust and safety, and Apple Intelligence."
and it could have been mentioned in the launch announcement post.
If it's a stability release, then great! But that's not what they're saying. Stability is mentioned once regarding search only. Performance has a very small sub-section half way down the page. Where do they mention the CPU scheduler rewrite, or any of the under-the-hood changes you're talking about? You seem to expect people to know about these things from somewhere else.
It's like a fixed up TypeScript specifically tailored for Wasm GC that can produce very small and fast binaries, but also has features like pattern matching, ownership / borrow checking for resources, pipeline, tail call elimination, multi-value returns, direct WASI component integration and a lot more.
So `items.[Iterable.iterator]()` is invoking a symbol-keyed method.
It's declared like:
export interface Iterable<T> {
static symbol iterator;
[iterator](): Iterator<T>;
}
export MyArray<T> implements Iterable<T> {
[Iterable.iterator]() { ... }
}
I do want to add pure functions, especially for compile time constants. I want to add a macro system that can either run pure functions (on the AST or IR, not sure yet) at compile time, or run arbitrary code sandboxed in a Wasm module.
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'm building a new language with async/await and had to make a lot of these decisions, but I didn't have this organized of a framework to ground myself in. I'm happy to see it clearly that I choose mostly Trio with a bit of JavaScript.
My language (Zena's) async docs page: https://zena-lang.dev/guide/async/ I think I might do a pass and try to call out the decision points more explicitly.
fwiw, I found this post on cancellation by the author of Trio to be vey compelling: https://vorpus.org/blog/timeouts-and-cancellation-for-humans... and I based the cancellation design of Zena on it.
Edit to add: I do wish this included JavaScript's AbortSignal in the Cancellation section. Not because it's good, but because passing cancel tokens is a pattern that exists. There's also the dimension of who can cancel and, like AbortSignal, whether tasks have to opt-in to cancellation checks.
I'm building a new language and just a couple of days ago the concept of guard methods came up as I was trying to tighten up equality semantics to be more like Swift.
Things like Array.contains() only work if the element type implements the Equatable interface, so it would be a guard method. Maybe something like:
class Array<T> {
contains(value: T): boolean where T extends Equatable { ... }
}
class Array<T> {
contains(this: Array<T extends Equatable>, value: T): boolean { ... }
}
I'm making a whole new language to get around the problem you're talking about: it brings no runtime at all. One of my targets is a Sandstorm like system I've been slowly working on, but I'd love for it to be a fit for the actual Sandstorm successor.