It's simple enough: If you don't use it, you lose it.
The more you have, the more there is to lose and the longer it may take.
But skills and knowledge fade, just as easily as fitness, or a tan.
It's an insidious rule too. Insidious in the sense that you may not realise you're not exercising a skill. You may think that your just doing it slightly differently, but you will adapt. In whatever way you made your life easier, that's where you'll pay, in strength, fluency, depth, whatever.
The key is, as you said, practice. I think it's fine to use AI to write code for you, as long as you occasionally force yourself to write code manually. Not only does it help you retain your skills, but it feels more satisfying than prompting, even if arduous.
"With that said, permacomputing is an anti-capitalist political project. It is driven by several strands of anarchism, decoloniality, intersectional feminism, post-marxism, degrowth, ecologism."
They are post-modernist, collectivist, marxist. I couldn't get behind that.
That ideology is arguably the most destructive in human history.
I'll bite. The first language I could "just write" in was C. I had internalised the language and its standard lib and didn't need the internet to work with it.
Rust is pushed by many as the replacement to C, because of the memory safety guarantees. I'm sympathetic. I worked with Haskell for a time, so I get it. But Rust seems quite complex. There are so many language features that there's memes about it. There's also the friction and learning curve.
So, for fun, I choose zig because, like C, I can hold most of the language in my head and "just write." I choose zig because it does a great deal to help me write correct and highly performant code. I can use arena allocators and defer and cure my code of many memory issues. Then there's the various language rules around pointers (optionals, slices, etc) that help me write correct code. There's the built in testing and the test allocator. I love that comptime and the build system are not special cases, but rather are just garden variety zig. I love the simplicity and elegance of it all.
I also choose zig because I prefer the liberty it affords me. I am responsible for each and every allocation. It appeals to my libertarian sensiblities.
> The first language I could "just write" in was C. I had internalised the language and its standard lib and didn't need the internet to work with it.
I bet $4.20 you didn’t write C. You wrote something C-like which the compiler didn’t reject because the C standard has a gigantic surface of ‘undefined behavior’ which means once your program does one thing out of spec it isn’t C anymore silently.
> There are so many language features that there's memes about it.
Like many memes, these are misleading. Rust is a solidly medium-sized language; smaller than Python, certainly, though with a perilously steeper learning curve than Python.
Rust-the-language may be medium-sized. Rust-the-stdlib though?
The Rust stdlib has a lot of essential low-level types needed for adding a 'semantic layer' on top of the language so that the language user can exactly 'express intent' (types that arguably should be language features instead). Just look at all those detailed methods needed to make RefCell work, and what does 'into_inner' or 'undo_leak' even mean?
E.g. what's a single concept in C (e.g. "the pointer") easily has a dozen specialized equivalents in Rust, just because Rust needs the additional information to do its memory safety magic correctly.
The entirety of Rust and its stdlib has a huge 'semantic surface' compared to most other languages (even C++), and I think this difference in the semantic surface size to other languages is exactly the one thing that either attracts or repels people to/from Rust ;)
> what's a single concept in C (e.g. "the pointer") easily has a dozen specialized equivalents in Rust
That "the pointer" is a single concept in C is the root cause of absurd numbers of bugs over the history of C.
The questions of how long the memory a pointer points to lives, what threads it is safe to access from, and how it is allocated and destroyed all still exist in C. Those answers are just implicit rather than explicit like they are in Rust. It's not like Python/etc where you don't have to worry about these things.
In general I agree, but this topic is IMHO exactly what separates the Rust lovers from the Rust haters ;) E.g. how strong is too strong when it comes to type systems. Rust afficionados generally seem to tend towards 'the stronger the better', and accepting the downside of a fairly rigid code base.
I prefer a middle ground between strong and weak typing (but yeah, C is arguably too weakly typed, but the exact sweet spot is different for every programmer).
A reasonably smart C compiler that has visibility on all code in a project could theoretically infer a lot of the same semantic details that must be manually provided in Rust by looking at how the pointer is used in the wider codebase (basically what static analyzers are doing by reconstructing control flows). Of course such an extensive analysis would result in even worse compile times than Rust ;)
Of all the things I expected to read today on HN, "I chose a programming language that appeals to my political leanings" was certainly not one of them.
With the use of quotes there, you've put those words in my mouth. I didn't say that.
What I am trying to express with the statement you refer to is that zig appeals to me on an aesthetic level. It suits my tastes.
I mentioned liberty because I appreciate that zig allows me to have complete control of memory allocations, and gives me quite a deal of control over the metal. I like this and I like that I don't have to appease a borrow checker. Zig's compiler and type system is strict enough to guide me to correctness, but the experience, broadly, is not so onerous that programming becomes tedious and frustrating.
These qualities, I suspect, resonate with my individualistic tendencies.
With respect, it's difficult to interpret "libertarian sensiblities" as something else than "political leanings". Now "liberal" is a much more general -- I wouldn't necessarily call that political -- but what you said had a strong political connotation, hence my comment.
Your explanation lands otherwise. I can't relate to "I don't have to appease a borrow checker" though. That reads like a deliberately uncharitable read of what Rust's compiler is doing. That being said, it's definitely not for everyone.
I tried Zig. Loved it. But then after a few weekends I said to myself: "Wait a bit. I've been down this path before with C and C++. I know exactly where it ends." -- and bailed.
To me these days low-level programming is basically: either go all the way, or don't go at all. Sadly Rust is not like, going really all the way, but it's IMO the closest we got. And before somebody starts enumerating obscure languages that barely have a community: I include multi-axial evaluation here i.e. PL features, stdlib, ecosystem, richness of education (Rust has _a lot_ of good books and courses), and others I am surely forgetting at the moment.
Zig is great. But I'll not take marginal improvements anymore. Not in my personal life and not in my work. I'll get big ones, or not get them.
Since we are explaining philosophies, now without political undertones: that's mine.
Yeah, nah. Not so sure about that. I love zig, and I appreciate the rigour, care and thought that goes into the language and it's libs. What Andrew Kelley and the team are doing is excellent work, creating a useful, simple language with which to write efficient, correct programs.
His politics don't matter to me. Hell, if the politics of technologists dictated whether I used their products, I'd have to go live in the wilds, without any tech. :-)
It's not particularly revelatory to point out that this project has been generated largely by LLM (claude most likely, given the CLAUDE.md in the repo).
I wonder if this is just what we get now: low quality code, expressed rapidly. We are excited by the promise only to be disappointed by the reality of the implementation.
There are still a few new things around that are carefully and thoughtfully developed and put out into the world. zig itself. MitchellH's ghostty. And there's still all the older foundations of really wonderful, robust, software created by people like Linus Torvalds and couple of generations of open source devs, that applied great skill, ingenuity and hard work to produce the very best software.
But I fear that I'm in for a period of lamentation as we get wave after wave of promising sounding developments, but where the reality is low quality, LLM generated crap that you really shouldn't use if you want secure, stable performant, production-ready software.
Seems like perhaps we've been through a golden age of really great software and that now it's coming to a close.
We're in the messy transition period where our old indicators of a promising GitHub project are too easily replicated by someone letting Claude Code run for a few days.
A year ago it would have taken someone months of nights and weekends effort to get this much code up and running. That person would have developed a good intuition for the architecture and where it should go.
Now Codex or Claude can bang it out in a couple days. You can try to have it do spec documents, code reviews, and cleanup passes but with today's tools these projects reach a point where it's just a swirling mess of pieces duct taped together in a way that passes tests. In my experiments, you quickly reach a point where the usable context depth (which is less than the 1M limits) keeps overflowing before you can get usable refactors in, and you're just going in circles. I know it's theoretically possible to avoid these problems, but in practice you get spaghetti projects like this.
I don’t know, GPT-5.5 has been very effective for me. It’s not perfect but the quality of refactoring it can do is awesome.
Previous models both GPT and Claude would struggle with the larger picture more. Pretty quickly they’d do one off hacks. Eventually they’d code themselves into a wall if you weren’t careful.
Haven’t hit that wall with GPT-5.5 yet. New changes or improvements on a GUI library I’m building seem to be constant in time per feature.
Though I’m talking only 10k’s of LOC. Also I’m using Nim which is both strongly typed and concise.
I’m seeing a similar improvement with Opus 4.8, which is acting like an engineer that cares about correctness. The harder the problem the better it seems to do.
I think a golden age of software is just starting for indie software. It’s just going to take a while to see the first really good results.
I'm wanting to build pieces of software that I've been wanting and often working on for years. These new models are making it possible for me to scale my work to build it.
Yeah, I'm aware. MitchellH posts about it quite a bit, most recently about AI "psychosis". Also, much of ghostty was created without the use of AI, I think. More recently, they've been using it to find bugs, improve performance, and generally refine and enhance ghostty and libghostty.
The LLM is the finishing tool, not the architect or core developer.
To be fair, "excited by the promise only to be disappointed by the reality of the implementation" describes ~95% of my experiences with all software over the last 20 years. In fact only a few exceptions really come to mind - git, treesitter, ffmpeg, and sqlite.
Yeah, maybe it's rose coloured glasses on my behalf. Those examples you mentioned, I would 100% agree with. It's some of the best software out there. And yeah, there's probably always been rubbish about.
I guess I hope that the good stuff keeps coming and the dross falls away. More signal, less noise.
I do agree with you though. It feels like the industry has steadily been getting worse, AI is just like pouring kerosine on the fire. I'm almost embarrassed to call myself a software engineer now.
On a small bright note, I've gotten AI to help me produce some of my best work over the last couple of months. It may enable sloppy behavior, but it doesn't require it. I have hope that serious work will win out in the end, and that sheer human effort is still the differentiator.
Yeah, there was a good article on here the other day where the author suggested going slower with AI and using it to help produce higher quality output. I think the idea is to be quite "hands on", coding much in the old way, but to use AI to help with, for example, test coverage, error mode detection and handling, refinement of the solution/feature, etc.
At least that's how I read it. :-) I'm learning that there's a place for the LLM but it's the sandpaper, not the chisel.
lol I'm more speaking to reliability than the quality of the interface. git and ffmpeg are not exactly known for the most intuitive API surface, but I don't think I've ever encountered a bug with them in my 17 years. That's a pretty extraordinary thing when you think about it.
Fair point. My problem with git is actually mostly the flaw in the object model itself, more than the dismal API. The fundamental mismatch between "to get a clean history you have to edit/destroy history with squashes and rebases and whatnot" and "editing history destroys the ability to do comparisons of two branches, which basically ruins half of git's functionality from top to bottom when you encounter that problem".
Like even the basic question of "hey did I already merge this branch?" becoming unknowable if you autosquash-on-merge is just nasty.
I've got a million ideas on what the "correct" fix for that problem might be, but imho it's a flaw deep in the heart of git that creates a massive amount of pain.
But I'll give it credit for being rock solid and blazing fast, as you say.
> Gooey is in better shape than most ~140 KLOC Zig codebases — every directory has a mod.zig, namespaces are layered, and core/interface_verify.zig provides compile-time platform-backend checks. But the architecture has drifted in a few
I too have used AI to plan cleaning up its own mess, and this self-congratulatory prose is extremely consistent ("every directory has a mod.zig", whoop dee woo!).
In my experience, AI is largely incapable of fixing its own mess to an actually competent degree (and full disclosure: I still ask it to, not pointing fingers here) and it's probably due to it walking on egg shells around its own feelings. I've had to tell it to completely change course during cleanup at least 30 times this week.
I find it quite dishonest as github stars used to be (and maybe still are?) the measure of an open source project popularity, and these big, flashy LLM generated repos seem to always get a bit of attention
Have seen it from jobseekers trying to boost their profile with fake projects, founders trying to make their product more attractive to VCs, consultants trying to advertise their services...
I don't always have time for OSS, but every PR I've ever sent has always been hand written, and tested, and has taken into consideration the project coding style and architecture choices – I don't like this new world where developers can't even be bothered to write the docs.
Have you found evidence that the code is actually low-quality, or is that just an assumption based on the fact that it's evidently largely LLM-generated?
Tbh, the link itself sounds like LLM as well, spotted a few emojis in there. I suppose I could be wrong, but I feel like we're all getting good at sniffing generated language.
You don't think people have anything to do with the poor implementation?
The Golden Age of software already happened? Uh huh, right.
This comment reminds me of how people used to speak of Geocities and the early Internet.
On the other hand, I have quite the visceral reaction to the name because of the influence Hegel had on Marx, and subsequent 20th century critical theorists.
The more you have, the more there is to lose and the longer it may take. But skills and knowledge fade, just as easily as fitness, or a tan.
It's an insidious rule too. Insidious in the sense that you may not realise you're not exercising a skill. You may think that your just doing it slightly differently, but you will adapt. In whatever way you made your life easier, that's where you'll pay, in strength, fluency, depth, whatever.