Assuming the goal is to be able to write compute kernels and shaders in Zig - the concerns of writing (and especially optimizing) these programs are significantly different from high-performance CPU execution.

Mojo, for instance, has seemed to solve this problem (presumably: I haven’t studied the compiler myself, but this is a claim of theirs) but the community has implied that solving this problem required semantic and compiler design decisions different from the Zig compiler, especially around memory spaces, pointers, and origins.

Further: if you open up a modern tensor / GPU compiler (Triton, XLA, logical / scheduled kernel systems like Halide or Exo, or low-level kernel compilers like Mojo) — the optimizations and analyses which are performed on GPU kernel code are significantly different than CPU code

Is the end goal to write such a pipeline into the Zig compiler?

It seems possible to do this - but I’m not sure … it seems a bit hacky, or like one has to coerce existing Zig semantics to be repurposed for a job it was not designed for in the first place?

One alternative might be to use comptime to expose a kernel builder DSL, followed by a GPU compiler pipeline implemented in Zig (a completely separate compiler). This seems straightforward and allows you to implement and gain access to the specialized semantics / optimizations that you’d need for high-performance kernels?

I could absolutely be wrong, interested in thoughts.

Often, it takes 5-6 broken crappy versions of a thing until you understand that. There is no accelerating the 5-6 broken crappy versions - there’s no agent tech that’s going to help your meat brain avoid thinking time.

So most of my time is iterating between these two phases: I don’t understand what I want, I need to read and write and play with code, okay it’s been long enough I think I know what I want (it is extremely easy to deceive yourself) … okay now I do actually know what I want and I can write a loop.

Many people think they can jump ahead with agents. You cannot fake understanding or clarity. It is painfully obviously when someone skipped that meat brain understanding phase.

Seriously -- if you dig through that source code, and then listen to the messaging, it seems hard to keep a straight face.

Also, hasn't this company been claiming that almost all their code is written with AI for significantly longer than "post-Mythos internal preview"?

But that is not the same claim as “safe Rust can cause UB"

If you are claiming the latter, please provide a minimal safe Rust program that causes UB without unsafe, FFI, proc-macro tricks, compiler bugs, or an unsound safe API implemented using unsafe?

If you can produce such a program, of course you are right.

Your audience, or whoever you aim your work at, should be treated with respect. Otherwise, why should they give you the time of day? Why would you expect them to respond positively to effort alone when effort (in code and in shit prose) is extremely cheap right now? Their time is not cheap ...

When I read the documentation, and it is extremely clear that you haven't taken the time to clarify your ideas, when much of it is LLM prose, when much of the content introduces highfalutin ideas without motivation, blending categorical concepts (which, by the way, should never be mixed with vague prose claims about the language), violating my reader context model, preventing me from understanding what problem exactly your language design is solving (where is that problem stated clearly?), it is a waste of my time.

> The work took 3 weeks in total ... it's worth a look, and I hope it will win some converts, and that someone will want to help me with its development.

You've gone too fast, too much is vague, nothing is clear.

I'd delete everything, start over, and try and explain just one of the ideas clearly. Seriously. This sounds harsh, but it's honestly the correct approach to something as subtle and nuanced as programming language design.

Safe Rust cannot cause undefined behavior ... static systems do not need to predict all runtime paths, presumably referring to the halting problem and Rice's theorem (or whatever the author intends this to mean, the writing is unclear): these systems prove properties for all accepted programs under a conservative model, which covers all allowed programs within the subset admitted by the model.

The guarantee that Rust provides are sound, and the claim depends on trust in compiler implementation and any `unsafe` code involved in used APIs, etc (which is not uncommon: the same thing is true for Lean's kernel, for instance).

As Pauli said, much of the writing is not even wrong ... many of the language critiques read like transcriptions of vibes derived from AI discussion: "C++ smart pointers with extra steps" -- this is not a serious statement. I'm not even a serious user of Rust, but I know enough about the language design to understand how stupid this statement is.

So the goal seems to be: Java, but without nulls, erased generics, OOP, or the JVM.

Best of luck.

- A Chrome DevTools Protocol / Playwright client.

- macOS Seatbelt sandbox (--sandbox flag) with some special Node / v8 stuff.

- Sentry for crash reporting and Unleash for feature flags.

- A SKILL.md system mirroring Anthropic's skills convention.

- Subagents, an artifacts review workflow (slash commands), and conversation rewind.

- Telemetry redaction in several places (good?)

- go-git bundled in there.

- go-enry / linguist's entire language table: many file extension/syntax tags (Cairo, Stacks Clarity, Modelica, KiCad, etc.) bundled in there.

All in all, a 140 MB Go binary with its own browser control stack, sandbox, Git, language detector, skills runtime, and subagent system.

I'm good, I'll stick with pi and codex. Less is more my friends.

Right, as you said, you'd have to recompile dependents.

> Clojure's dynamism is granted by a great deal of both polymorphism and indirection, but this means LLVM has very few optimization opportunities when it's dealing with the LLVM IR from jank.

In my mind, what is happening here is you lower Clojure code into LLVM, with a bunch of runtime calls (e.g. your `jank::runtime::dynamic_call`) (e.g. LLVM invoking the runtime over a C ABI).

If that's true, are there any optimizations that LLVM helps out with? Perhaps like DCE? I can't tell immediately, curious about the answer

(question is obviously about the pre-IR state of things)

Very impressive if I'm wrong (hopefully some of the comments help you prune some of these smells, if you wish)

At one point, the author may have written a fair bit of code by hand (starting with a Crafting Interpreters project, and then adapting it recently using agents?). The commit history is very confusing.

The design of the VM is nearly identical to the clox interpreter in Crafting Interpreters. There's also a bit of Lua inspiration mixed in the instruction encoding.

Who is this language for? Who is the audience, and what does the author intend to convey to them?

There's a ton of features -- are they used consistently? We have function overloading and traits. We have optional type annotations and effects -- the effects are handled with a (fragile) multi-shot continuation implementation (at least copy Leijen or libmprompt! that code is out there, free to use, and robust!)

There are two parallel type inference systems in `src/types`. The type system which the language actually uses is not consistent yet (see e.g. `inference.c`: "recursive type: bind anyways")

With that being said, I'd take the cross platform claims with an extreme grain of salt ...

In particular, compare you JAX’s vmap — one model for vmap is that it is a program transformation on first order functions, that returns a first order function (“function” is a bit wonky here: but it’s JAX’s Jaxpr representation), but vmap itself is not a primitive in the Jaxpr language.

Is the same true here about map (can I think of it like vmap)? Or is it true that I can define higher order functions and Accelerate will handle them? What about functions with recursion?

Thanks! If you happen to see this - Futhark is very cool.