Hacker News new | past | comments | ask | show | jobs | submit
citizenpaul | on: A new Go API for JSON
People are sleeping on Go as a LLM language of choice. Everyone trying to rewrite in rust which is fine and rust is fine. However its compile times are several orders of magnitude greater than Go. You can have LLMs write and compile 20 apps in the time one rust app compiles. I've got a Go personal project that would take hours for rust to compile, I can't imagine making the same velocity in Rust. Though I do see the workplace appeal of bringing back the xkcd "compiling" meme.

However it kind of makes me feel like my professional life was wasted and I don't really know what kind of future I have. One of Go's main points was you can pick it up in a weekend. What career moat do people like us have?

simlevesque | parent | next
My only issue with it is that you can't ship a wasm go app in under 2mb. With rust you can make it under 100kb.
xarope | root | parent | next
isn't that one of TinyGo's raison d'etre's? I've never tried wasm, but executables are typically a magnitude smaller than go's (assuming your go code is compatible with tinygo, of course)
groundzeros2015 | root | parent | next
Jeez, and I thought 100 KB was absurd.
| root | parent
{"deleted":true,"id":50372600,"parent":50371672,"time":1793832869,"type":"comment"}
pjmlp | parent
I would rather have LLM directly generate machine code, and best of all, macro Assemblers are blazing fast for decades.
dgb23 | root | parent | next
One of the best techniques for using LLM coding is to let it write programs that frontload and automate work in a repeatable and testable manner rather than letting it only do free form turns.

Letting it generate machine code directly would be the opposite of that.

pjmlp | root | parent
Like a JIT compiler then, where the generated Assembly depends on various parameters, where not two runs are the same, unless you manage to replicate the whole system state across them.

As for proven wrong,

"Frame was created over the past month largely via Claude Code. The Assembly code in all its glory can be found on GitHub."

https://www.phoronix.com/news/Frame-X11-Server-Assembly

bayindirh | root | parent | next
You can't PGO that code, though. Also, I'm not sure it can generate architecture specific optimized (-march, -mtune) code as well.

Considering it just pulls and remixes blocks, this is a very tall order for today's LLMs, and maybe a couple of generations as well.

Calling GCC/clang at the back and emitting ASM is both cheating and has no advantages whatsoever as well.

pjmlp | root | parent
That is fighting the last war on the early days of 5 GLs, and taken care by agentic runtimes.

This isn't futurology, besides a few projects that already came up on Phoronix and around here, with Assembly generation, there are enough SIGPLAN papers on ML driven compilers already.

loading story #50377297
loading story #50374776
kibwen | root | parent | next
This is like saying that a strong man would rather dig a hole with his bare hands than use a shovel. Structured programming languages are force multipliers, it makes absolutely zero sense to forego them just so you can vibe assembly directly.
pjmlp | root | parent
Optimizing compilers were faced with the same disbelief by Assembly developers.

Enterprise applications are already being vibe coded in iPaaS platforms, and as mentioned in other comments with LLMs in the picture, that is what compiler research is switching to.

politician | root | parent
Use a working Go program as the prompt+oracle for cross-language port or direct generation.
pjmlp | root | parent
I rather not, unless I have to.

If 3 GL code has to be generated, my option list won't certainly have Go on it.