You knew exactly what you wanted, since you already built it. All decisions were already made, all tradeoffs reached. LLMs are definitely helpful, but try exploring something new with them and you'll slow down significantly.
I am a Freelancer who has worked the last ten years on Embedded/Containerized Linux Systems. Last project (~5y) included evaluating and moving an existing product from Linux Network Stack to high-performance DPDK based solution.
I have a weak spot for Go; In my free time I explore using it in an embedded context. Have a look at https://www.github.com/clktmr/n64
This just shows how bad search engines have become. About 15 years ago you could type fully worded questions into Google and would be pointed to the exact sentence of a website that answers your question. I happened so slowly, we were all frogs in boiling water.
An the same will happen to AI. We will remember these days as the golden age for AI, where you weren't required to prompt an AI three times before it answers with a non-ad response.
> Agents, by making it easiest to write code, means there will be a lot more software. Economists would call this an instance of Jevons paradox. Each of us will write more programs, for fun and for work.
There is already so much software out there, which isn't used by anyone. Just take a look at any appstore. I don't understand why we are so obsessed with cranking out even more, whereas the obvious usecase for LLMs should be to write better software. Let's hope the focus shifts from code generation to something else. There are many ways LLMs can assist in writing better code.
I've written a fair amount of code for EmbeddedGo. Garbage Collector is not an issue if you avoid heap allocations in your main loop. But if you're CPU bound a goroutine might block others from running for quite some time. If your platform supports async preemption, you might be able to patch the goroutine scheduler with realtime capabilities.
The thing is, you'll typically switch to master to merge your own branch. This makes your own branch 'theirs', which is where the confusion comes from.
The advent of coding agents killed Hacker News to some degree for me. Before I could always come here to get a pause from the hype, scandal and bait. Top comments were usually insightful; I really had this feeling to learn while browsing the feed. Today every brainfart about AI makes it to the frontpage. I know this sounds very dismissive, but most pieces really have no substance at all.
The good content is still there buts it drowns in noise and I'm not very good at filtering it out. I even suspect Hacker News is one of the prime advertisement targets of coding agent companies.
I would love to see if this is just my perception or if it can be found in the data.
It's probably in their interest to have as many vibed codebases out there as possible, that no human would ever want to look at. Incentivising never-look-at-the-code is effectively a workflow lockin.
It's pretty good at dead code elimination. The size of Go binaries is in large part because of the runtime implementation. Remove a bunch of the runtime's features (profiling, stacktraces, sysmon, optimizations that avoid allocations, maybe even multithreading...) and you'll end up with much smaller binaries. I would love if there was a build tag like "runtime_tiny", that provides such an implementation.
You don't know what you want. That's why asking questions doesn't work. You think you know it, but only after you've spent some time iterating in the space of solutions, you'll see the path forward.
Hey panos! I only had a short look at this for now, and it looks impressive! I'll have to dust off my Dreamcast and get this running.
I looked at gccgo when porting the runtime to n64, but at the time it wasn't updated since go1.18. Can we use Go Generics on the Dreamcast? I see that gccgo is obviously needed to support SH4.