- 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: <a href="https://zena-lang.dev/" rel="nofollow">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: <a href="https://zena-lang.dev/guide/why-zena/#familiar-to-humans-and-to-agents" rel="nofollow">https://zena-lang.dev/guide/why-zena/#familiar-to-humans-and...
along with a doc in the repo on this topic: <a href="https://github.com/elematic/zena/blob/main/docs/design/ai-first-language.md" rel="nofollow">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.
Oops, the quick-reference is wrong. The other docs correctly say that default floats are f64. Default int is i32 though. Fixing it.
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.
spankalee · · focus · HN ↗
---
- 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: <a href="https://zena-lang.dev/" rel="nofollow">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: <a href="https://zena-lang.dev/guide/why-zena/#familiar-to-humans-and-to-agents" rel="nofollow">https://zena-lang.dev/guide/why-zena/#familiar-to-humans-and...
along with a doc in the repo on this topic: <a href="https://github.com/elematic/zena/blob/main/docs/design/ai-first-language.md" rel="nofollow">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.
nh2 · · focus · HN ↗
> integer literals become i32, float literals become f32
Don't use the shitty small sizes that have introduced countless bugs over the last decades, as a language default.
Especially if you care about correctness.
i32 is all over the examples.
Use 64 bits, like Python and Haskell; even JavaScript and thus TypeScript got floats right defaulting to f64.
spankalee · · focus · HN ↗
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.