HN user

mccoyb

1,270 karma

5th year MIT PhD student. I work on programming languages and systems.

https://github.com/femtomc

Posts2
Comments231
View on HN

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 ..."

Yes, I am familiar with that experience.

It does feel like there are a lot of parallels between usage of AI and psychedelic experiences:

- novices love to talk about the act itself

- mostly inscrutable, and the artifacts of the experience are not fully understood by the beholder

- pumped by a similar new age tech crowd of optimaxxers who haven’t realized that this mode of thinking alone is not all you need

slow and careful reflection has never been more important.

Fable 5 Is Back 21 days ago

By the gods! The next 20 minutes will be the most consequential of my life ...

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.

The Coming Loop 30 days ago

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.

If the March leak of Claude Code was Mythos / Fable in preview ... I'm not sure I'm that worried about AI capabilities.

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"?

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.

Best of luck.

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.

Mechanics that I found in the binary with a few agents, more information than I could glean from the GitHub page or the docs:

- 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.

Hoping to understand this better:

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)

This language, README, website has been written by AI agents.

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 ...

Can you say a bit more about this?

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.

I struggle with these world models from the perspective of video games (so this post is a particular perspective).

I'm not a game developer myself, but some of my favorite games carry a deep sense of intentionality. For instance, there is typically not a single item misplaced in a FromSoftware game (or, for instance, Lies of P -- more recently). Almost every object is placed intentionally.

Games which lack this intentionality often feel dead in contrast. You run into experiences which break immersion, or pull you out of the experience that the developer is trying to convey to you.

It's difficult for me to imagine world models getting to a place where this sort of intentionality is captured. The best frontier LLMs fail to do this in writing (all the time), and even in code, and the surface of experiences for those mediums often feel "smaller" than the user interaction profile of a video game.

It's not clear how these world models could be used modularly by humans hoping to develop intentional experiences? I don't know much about their usage (LLMs are somewhat modular: they can produce text, humans can work on it, other LLMs can work on it). Is the same true for the video output here?

All this to say, I'm impressed with these world models, but similar to LLMs with writing, it's not really clear what it is that we are building towards? We are able to create less satisfying, less humane experiences faster? Perhaps the most immediate benefit is the ability for robotic systems to simulate actions (by conjuring a world, and imagining the implications).

In general, I have the feeling that we are hurtling towards a world with less intentionality behind all the things we experience. Everything becomes impersonal, more noisy, etc.

Aperio Lang 2 months ago

Can we not post LLM generated prose on topics as subtle as programming language design? Am I alone when I see this type of stuff and immediately react in anger?

These things are not good technical writers - so why do people keep doing this? It is not possible to take a proposal seriously from a scientific perspective if the arguments are written by LLMs, I'm sorry, it's just terrible writing, terrible argumentation.

Every language designed before 2023 was optimized for a single tradeoff: minimize friction between human cognitive capacity and machine execution. Assembly to C to managed runtimes to DSLs were different points on the same line. In an LLM-driven workflow, those languages don’t get cheaper to use — they get more expensive.

What does this mean? Why do they get more expensive? The claim is "the cost just hides in the LLM’s token count, its retry rate, and the latency it eats per turn" -- what is the cost? Am I supposed to infer what the fuck you are talking about?

Why don't you send the prompt for your programming language instead?

Also, the concept of "locus" has already been invented, it goes by the name of "entity" in the syndicated actor model: https://syndicate-lang.org/

I don't want to be seen as being a hater for LLM-driven language design -- totally go for it! I'm not sure if this language is by OP (if not ignore), but my advice is take some time to sharpen up the writing and argumentation or else you risk not being taken seriously.

It has now become fashionable to dress oneself in the garb of science to sell dev environments ... for agents.

It has now become fashionable to claim much, and furnish little.

It has now become fashionable to fail to understand or state the core of your proposal in as few words as possible: instead of "genetic algorithm applied to the space of harnesses, parallelized by our infrastructure" we get "Three swaps. Same orchestrator. Same dashboard. The wiring is the thing."

We're cooked chat.