I find these blog posts (and the originals, with Anthropic's C compiler and Cursor's browser) somewhat funny, as if they have this enormous power to build ... but they can't build something unique or new. Like the software sucks, but look how powerful the process is (the models are indeed powerful).
And it's a bit of a shame: by virtue of their position (their embedding in the fabric of venture capitalism), it seems like they can only make a subset of things -- what they can make is dictated enormously by capital, as they are engines of capital.
Not sure the point I'm trying to make, I just find it amusing.
Perhaps the point is that it might be more worthwhile to give independent creators a billion dollars to play around with agent swarms if we want to keep diversity in the evolutionary algorithm that is the software industry high.
Very cool work Keno! Any place to find information about the Julia-specific concepts / features compared to MLIR?
Wondering if there are modeling or analysis modalities that don’t fit cleanly into MLIR concepts (understand that abstract interpretation on the IR comes with a unique set of concerns)
Perhaps the most telling part of this transcript is Tristan Hume, a prolific and talented programmer, and presumably an expert performance engineer, is repeatedly saying "this thing just doesn't work that well yet" or "it's just not there yet" and everyone else is kind of just fawning over it.
"It actually made something that worked. But when I tried using it, I found I didn’t like it. I need to wait for a Claude that has the taste ..."
Linda and Syndicate figured this out - it’s just that most engineers are not programming language designers or researchers, and most researchers are not designing robust scalable language implementations.
This is inspiring! At the same time, it’s not exactly clear to me how this is going to work in the long term without changes to the Zig language itself, questions below.
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.
Loops work when you spend the proper amount of time to understand what you want ahead of time. The prerequisite is clarity — enough clarity that you could write a careful specification that you could hand off to a junior colleague.
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.
I agree with you that my original message was sloppy, and also with your claim that full Rust has not been mechanically proven sound.
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.
I'm not sure where or how to convey this, because I've seen several of these languages designed with AI, documentation created using AI, etc -- posted on Hacker News in the last months or so, and I've responded to each one with roughly the same feedback (and I'm assuming good faith: that the intent is that the poster wishes to grow as a language designer).
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.
My feedback is that both the motivation and the language looks like someone who is confused about several concepts in programming languages.
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.
In summary, we present a system which actually doesn’t work because real experts looked through the thing our system produced and found that it was full of reward hacking, but of course we’re honest about this and we’ll adjust our metrics, and so we think it’s okay to just slop this out there because we’re honest and we will make promises to fix everything, and we also hope you like our attempt to gain notoriety for Meta AI.
https://github.com/femtomc