News for hackers. Stuff that matters.
Re:A New Go API for JSON by pjmlp on Wednesday November 04, 2026 @03:50PM (#50371316)
I would rather have LLM directly generate machine code, and best of all, macro Assemblers are blazing fast for decades.
Re:A New Go API for JSON by bayindirh on Wednesday November 04, 2026 @04:03PM (#50371489)
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.

Re:A New Go API for JSON by pjmlp on Wednesday November 04, 2026 @04:16PM (#50371653)
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.

Re:A New Go API for JSON by anthk on Wednesday November 04, 2026 @10:28PM (#50374776)
Like inform7 but irreproducible and shitter on every iteration.
Re:A New Go API for JSON by pjmlp on Thursday November 05, 2026 @12:50AM (#50375668)
Like JIT and PGO machine learning optimizer passes more likely.
Re:A New Go API for JSON by bayindirh on Thursday November 05, 2026 @04:57AM (#50377297)
ML driven compilers are different than LLM assembly generation, and former is more sound than the latter one. I believe we both have enough experience to understand that.

However, starting with LLMs directly generating machine code and moving to ML directed optimization passes, you're moving the whole stadium with a crawler-transporter, not only the goalposts.

Helping compiler in a well defined way, and working on IR or driving it repeatedly to optimize the output is one thing, generating machine code from a training set is other. Let's not mix them.

Re:A New Go API for JSON by pjmlp on Thursday November 05, 2026 @05:03AM (#50377339)
Yeah, well as mentioned, that is where it is going.

"Compiler 2.0: Building the Next Generation of Compilers with Machine Learning"

https://eecs.berkeley.edu/research/colloquium/compiler-2-0-b...

There are other researchers if you interest yourself on the matter.

Then the whole iPaaS agentic coding environments like Workato and Boomi, that even if they might generate 3GL as intermediate step, you don't get to see it.

Re:A New Go API for JSON by bayindirh on Thursday November 05, 2026 @05:39AM (#50377563)
Thanks for the link. I have also found a small trove as a warm-up. If anyone interested, here it is:

https://github.com/zwang4/awesome-machine-learning-in-compil...

Using small, purpose built ML "things" to make things better makes sense. We use them everywhere. I never argued against it, as well.

Re:A New Go API for JSON by politician on Wednesday November 04, 2026 @09:22PM (#50374311)
Use a working Go program as the prompt+oracle for cross-language port or direct generation.
Re:A New Go API for JSON by pjmlp on Thursday November 05, 2026 @12:52AM (#50375684)
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.

Re:A New Go API for JSON by loadatom on Friday November 06, 2026 @02:07AM (#50389128)
May I ask what your option list will be.
Re:A New Go API for JSON by kibwen on Wednesday November 04, 2026 @09:24PM (#50374319)
This is like saying that a strong man would rather dig a hole by hand than use a shovel. Programming languages are force multipliers, it makes absolutely no sense to bypass them just so you can vibe assembly directly.
Re:A New Go API for JSON by pjmlp on Thursday November 05, 2026 @12:51AM (#50375677)
Optimizing compilers were faced with the same disbelief by Assembly developers.
Re:A New Go API for JSON by kibwen on Thursday November 05, 2026 @07:37AM (#50378380)
In no sense is this "disbelief". You seem to be laboring under a fundamental misunderstanding of the role of structured programming languages.
Re:A New Go API for JSON by pjmlp on Thursday November 05, 2026 @07:50AM (#50378494)
I am already using a bagger, while you are arguing for electric shovels.

In case you answer there don't fit the same purpose, there are tiny baggers that replace shovels altogether.

Re:A New Go API for JSON by kibwen on Tuesday November 10, 2026 @05:47PM (#50447376)
> I am already using a bagger, while you are arguing for electric shovels.

This demonstrates that you continue to misunderstand the analogy.

Let's speak plainly. Someone who attempts to use LLMs to generate assembly directly will be outcompeted by someone who uses LLMs to generate code in a high-level language, which then uses an ordinary compiler to generate assembly. The value of a high-level language is that it defines a more constrained abstract machine than the machine that a CPU represents, which both humans and LLMs alike benefit from.

Re:A New Go API for JSON by dgb23 on Thursday November 05, 2026 @05:06AM (#50377355)
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.

Re:A New Go API for JSON by pjmlp on Thursday November 05, 2026 @05:09AM (#50377377)
Like a JIT compiler then.

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