YHK - yet another hacker news clone

It gets it right after a few attempts.

The hard reality is none of them.

We will have some kind of type system/profs to help drive LLMs output, and those that still will have a job as system architects or whatever, will generate applications directly.

And just it happens with optimising compilers, there will be a way to generate some kind of intermediate representation, like the -S switch, but that is it.

Generating source code for 3 GL languages is an intermediate step.

Who thinks otherwise should spend sometime looking into papers of AI role in compiler development.

For example,

"CGO 2022 Keynote: Compiler 2.0"

https://www.youtube.com/watch?v=w_sX9aZoZxg

"Machine-Generated, Machine-Checked Proofs for a Verified Compiler"

https://www.youtube.com/watch?v=Dmt0h99iOmM

For instance

   ; Sysv native vectors. Initializer values require matching [].
   (mut x (the v64 [10 20]))
   (set x (+ x 5))
   (at x 0 17)
   (print (at x 1))
   (print (all (= x (the v64 [17 25]))))

   ; Parameter and result types can be written inline
   (fn add4 ((a w64) (b w64)) -> w64 (+ a b))
   (let ((result (add4 (the w64 [1 2 3 4]) (the w64 [10 20 30 40]))))
      (print (at result 3)))

   ; helpers reused below
   (fn inc (x) (+ x 1))
   (fn dbl (x) (* x 2))
   (fn sq  (x) (* x x))
   (fn pair (a b) (+ a b))
   (fn add3 (a b c) (+ a b c))
   (fn dv (a b) (/ a b))
   (fn id (x) x)
   (fn zero (x) 0)

   ; |> : pipe a value left-to-right through functions.
   (print (|> 5 inc dbl sq))                ; => 144   (sq(dbl(inc 5)))

   ; >> : left-to-right compose; << : right-to-left compose.
   (print ((>> inc dbl) 5))                 ; => 12    (dbl(inc 5))
   (print ((<< dbl inc) 5))                 ; => 12    (dbl(inc 5))

   ; fmap / <$> : apply f, then g  (same as >>).
   (print ((fmap inc dbl) 5))               ; => 12
   (print ((<$> inc dbl) 5))                ; => 12    (11 on sysv: (inc (dbl 5)), function-first)

   ; <*> (and its alias <>) : the S combinator, (f x (g x)).
   (print ((<*> + (lambda (x) (+ x 2))) 5)) ; => 12    (5 + (5+2))

   ; <&> : flipped fmap, a(b x).      <**> : flipped S, (g x (f x)).
   (print ((<&> inc dbl) 5))                ; => 11    (inc(dbl 5))
   (print ((<**> (lambda (x) (+ x 2)) +) 5))   ; => 12 (5 + (5+2))

Case in point: claude code is in the bun runtime of JS. Not in any fancy optimized binary

The current slop-code though ... I don't think many would miss it.

Others "heroin", as analogy, isn't one convincing to get into the slop addict scene really, in my opinion.

Also there is the part that why not generate machine code directly, where some always jump to answer "but non-determism!", well we have survived thus far with non-determinism in JIT compilers, tracing GC implementations, PGO metadata outcomes in AOT compilers, integration of machine learning in optimising compiler passes, how shader code executes in actual hardware,... the determinism ship is long gone.

So yeah, sad state of affairs, however the pandora box is open, is like Assembly devs wishing that compilers would just be a fluke and everyone would be shortly back into macro assemblers.

I don't love it, but it's my job now and I would prefer keeping it.

I'm not breaking any new ground with the project I'm in - just serving our users and there's a lot of stuff requiring improvement that would normally take a great deal of time to finish if it weren't for LLMs.

For my own things I would rather not use LLMs, but it's tempting, considering how little time I have for such activities nowadays.

I really love it. It takes lots of tedious work (find which obscure function to use in obscure documentation) and I can focus on more creative stuff: algorithms, design, research.

I’ve switched one of my projects to Go and it took a day for Opus to do the port and another couple of days to finish the features I wanted. I’ve never liked the language and still use Rust in plenty of places, but I can’t argue with how much faster iteration is.

One of my spare time projects is a "prompted" 3D modeling app that is now (incl sub-crates I maintain) about 500k lines of Rust.

The link stage is the longest. An incremental build (w. sccache+mold) where I changed a few source files is done and runs after maybe 20s max on my 2022 Rhyzen 6800H-powered laptop.

I think this is acceptable when working on that kind of project.

For games where this matters I usually prototype in some other language first, TS, Python, Lua, whatever then translate to Rust when game mechanics and magic numbers are settled.

Or you simply put those into a config file that gets watched by the game.

At work we have an image manipulation crate that takes like 30mins to 'dev' and about an hour to 'release' build.

The WASM version takes even longer, about 2h, and needs like 55GB RAM during build.

But that crate has only to be built once a month.

And if it mattered we could split it because it's a metacrate made of ~20 sub-crates.

Yeah, it would be nice if Rust were even faster (I remember compile times almost a decade ago, when I started using it)!

But I think for the typical use cases where you would (should!) reach for it, it's quite ok already.

And if not you can work around it quite painlessly.

[0] https://mojolang.org/

[1] https://en.wikipedia.org/wiki/Chris_Lattner

If you have reason to downvote, present it.

Such as it is - I doubt it, I couldn’t find any papers, so either it goes against someone’s religion or feel free to present your proof where any of the traits of Rust the language has been proven to actually benefit LLM code generation.

Error messages are mostly useful; compilation is quick (relative to an LLM); memory is not really optimal in most cases, but it's "good enough" and the language puts up a lot of guardrails around the programmer to keep them on the path to accidental success in this regard; the training data is full of .NET code; there's a well defined set of ways of working & best practices with .NET; types are explicit.

This is the antithesis of the idea that more powerful languages are better but it makes sense. For humans, it costs a lot for the language to get in the way all the time. Yes, a constraining language prevents you from writing errors but it also interrupts flow, forces you to describe processes that are meaningless at the application level, and usually is more verbose. But for an agent, the marginal cost of an additional line of code is less. Both the literal cost but also the opportunity cost.

Its not that Rust is a good or bad language per se, its just that agents don't care about ergonomics while humans do. And when you don't have to care about ergonomics this lets you push the tradeoffs way outside the range that would be even remotely acceptable for us. The flip side is that so far, we are in the mix so you can't go all the way to constraints... not that I can imagine what that would look like.