I am using local LLMs and Go has a bunch of strengths where smaller contexts are concerned; less complicated flow of control being one of them.
And the things that we do to manage this, that are symbolic or based on visceral real-world analogy, are good for us and bad for them.
Go is kind of in the middle, in the way that many vaguely Wirth-like and CSP-like languages possibly are, I guess.
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?
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.
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.
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.
"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.
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.
If 3 GL code has to be generated, my option list won't certainly have Go on it.
In case you answer there don't fit the same purpose, there are tiny baggers that replace shovels altogether.
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.
Letting it generate machine code directly would be the opposite of that.
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."
Binary bloat is not just about size; it impacts startup time and icache. It’s basically the speed of light launch time.
So you’re telling me rust is not good for UNIX style tools.
If you code in Go, the code is more high level, prettier, simpler.
If you code in Rust, the code is more robust, efficient, faster.
Both are important for LLM, why can't we have a high level, simple language that is also robust, efficient and fast? =)
I think many variants from Rust can be stripped to make it simple, especially in type system, which is way more complicated than go.
LLM can generate very cryptic rust code.
It's really great fun to build stuff in Crystal, I don't have anything prod-grade yet to say how it scores there but the community seems to be happy about that too.
Expressive and type safety of a functional language, without the odd semantics of Haskell, where laziness can make performance difficult to predict and purity can make simple things like IO difficult to understand.
I' just starting OCaml, so can't really compare, but it seems a good progress there.
Go is about as far as you can "go" to the efficiency end without becoming Rust. It's a low-overhead language (like C) but with a GC that ensures memory safety. If you want to manage memory yourself and still prove safety it gets very complicated, as we see in Rust.
First, I like programming and don't want to stop doing it just because a machine can do it too. Second, I'm pretty sure atrophied coding skills will make me worse at directing the machines, thus worse at what seems to be "the job" these days.
In theory wouldn’t atrophied coding skills not matter if models are sufficiently good at coding? I mean isn’t whats left just design and architecture and testing?
Sure, if LLMs are producing shit code you need to have an understanding of what it should do instead. But I think that day is already gone.
Its hard to think of a skill that you’d need to build with an LLM that requires writing meaningful amounts of code by oneself. From my end all the complexity is business logic and system design.
I am begging HN users to understand that some people enjoy writing software themselves
No, I didn't. I claimed that if my coding ability atrophies, I expect that my ability to code through LLMs will decrease. And this is an outcome I want to avoid for the stated reasons and others.
That said, I get your point: maybe "the thing writing the code" will be as abstract as "the thing moving the electricity through transistors" at some point. And maybe I will be wrong about coding skill translating to good agent-herding skill. But I don't think I'm wrong now.
Please reread my comment. That’s not what I’m addressing.
“Programming” is a bit loaded. Do you mean thinking through and typing everything out yourself?
What design skills specifically can you only develop from continually programming in this way?
Personally I’ve found the opposite to be true. As writing out code myself has shrank to nearly 0, I now have a much shorter feedback loop on design. You get a lot more repetition and feedback when that’s basically all you are doing.
Weeks and month for to wait for a feedback in developing software? Are you the sloth in zootopia?
The longest cycle for feedback for me has only been hours. And that was about redesigning the core architecture of an app. Otherwise, it’s like 10 minutes cycle if it’s edit-compile-run, 5 minutes if it’s REPL (lisp, bash, python,…).
As I write code myself I continously take into consideration stuff like following the consistency of the entire design, whether what I'm doing is efficient, etc. LLMs are terrible at this and I don't see how you could develop such skills by prompting only.
For example, I would never produce designs that require degenerate db access patterns (linear scans, etc.). Everything I write myself always takes into account using db & network efficiently from the ground-up. Every query is an index lookup, every api request is rate limited, everything is batched and cached, so on and so forth.
LLMs meanwhile don't care about any of this. I just had Claude happily try to fetch youtube page html because the api didn't expose something. Great idea, I'd love to be banned by google for scraping.
Designing with performance in mind is black magic too, I need to notice myself that stuff that I think has no reason to be slow (pretty much nothing does) is slow and hammering the llm to finally come up with a non-stupid design that's not ridiculously slow and wasteful. Yeah, why don't we pull 2.3mb of html to update a list, sounds good.
Agents make it too easy to gloss over too much. They're great at work where i care about productivity but I've zero interest at home where the point is learning and having fun
The few times I've needed a language without a GC and used Rust and C as target languages, I've reviewed the code less and enjoyed it less.
JIT and AOT compilers, REPL development, bleeding edge GC implementations, Java, Scala, Kotlin, Clojure, C#, F# to chose from, and modern IDEs inspired by Smalltalk/Lisp Machines experience, batteries included backed and frontend development frameworks.
I hope you're not still doing this, it's nothing to brag about.
Unfortunately, the world makes it hard to keep that cycle, and so instead I mostly do 17 hours awake / 7 asleep, which makes me feel constantly tired (though less tired than 16/8 at least).
Why? Because I don’t give time to wait for code to compile on my time and I don’t have time for people to learn a new language for review at work.
Life is good! Would recommend that split.
In what sense? Go has a GC and binary sizes are relatively pretty huge. Its closer to Java and C# than C.
So yea hopefully a nice new addition but only my prompts now matter. So need to make sure they pickup on the new API.