clktmr

There is so much wrong with this, I don't even know where to start. But most of all, why would OP think that anybody is interested in reading their "incomprehensible ramblings" (aka brainfart) regurgitated by an LLM? There is a reason your thoughts are unorganized: you haven't put much effort into understanding the matter.

Hard disagree. I still consider this an example of a very well written email https://news.ycombinator.com/item?id=23961036

Well it certainly depends on the recipient, but I will often take some time to make the email personal.

> I personally wouldn't care if it was AI-generated or not, as long as the content fit the latter category.

It's pragmatic. Linus once said, the reason C++ is not allowed in the kernel is to keep the C++ people out.

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

Location: Germany

Remote: Yes

Willing to relocate: No

Technologies: C, Go, JS, Lua, Embedded Linux, Yocto, RTLinux, Kernel, DPDK/VPP

Résumé/CV: https://timurcelik.de/cv2026en.pdf

Email: [email protected]

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.

> - he's labeled GenAI as nuclear waste (https://www.webpronews.com/rob-pike-labels-generative-ai-nuc...)

The whole article is an AI hallucination. It refers to the same "Christmas 2025 incident". The internet is dead for real.

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.

At least try a different question with similar logic, to ensure this isn't patched into the context since it's going viral.

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.

This is so ironic. Why would you add all these "features" to Go, if you're not interested in using the language at all?

There is also yaegi, a Go interpreter, which might be a better choice for small scripts than 'go run'.

https://github.com/traefik/yaegi

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.

This would also benefit the Embedded Go project, which uses similar modifications to the runtime.

https://embeddedgo.github.io/

Can you imagine their fork extending git with a feature which is incompatible to mainline git and then forcing user's to switch to their fork via github? I can, and it will give them the power to extinguish mainline git and force everything they want on their users (telemetry, licence agreements, online registration...). That might be the reason they're embracing git right now. The fork being open source doesn't help at all.

I'm not saying this shouldn't be merged, but I think people should be aware and see the early signs.

This is your daily Embrace, Extend, Extinguish reminder.

I can provide another POV to that story. We checked in as a family of four, and we're assigned seats in four different rows, with a two and a four year old. Only when entering the plane we had the possibility address this to a human and we were assigned new seats.

So this might be the reason you had to change seats.

I agree in general, but running git bisect on individual PR commits is just doing it wrong. There will always be commits that break stuff temporarily. Run git bisect only on the merge commits instead, which are typically already tested by CI.

You might want to take a look at the Analogue Pocket.

Very interesting! I would propose to add 'foot' to the list, which is also very performance oriented.

I feel this becomes more and more relevant again:

https://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/E...

Edit: To add on this, I think there is a lot of software that is written in a throwaway fashion (CRUD apps, shell scripts), where using LLMs might beneficial. But anything where correctness actually matters, why would I describe it in natural language only to then check the implementation?

The much more sensible use of LLMs to me is the other way round: creating ad hoc documentation for code that you can even ask questions. But that's probably not fundable by VCs on the same level.

There is also gokrazy[^1], which isn't focused on k8s, but on deploying on a rpi.

[^1]: https://gokrazy.org/