I miss the very calming, cold, solid, metal feeling of desktop software.
Log back in after a vacation, and everything's still there.
A window with "maybe" resizable panels and a menu, and that's it.
The Web used to be the "documents."
For a technology that's been built for documents, all the navigation, footer, and header of any modern app feel like a "hack" compared to elegance of what desktop used to be.
In an old-fashioned desktop application, anything that gets "synchronized" is by choice, and rather feels like magic.
In a web app, even the UI is not a given.
We are forced to stay logged to an "Massively Online Revenue Platform Generation" games, and it keeps getting disconnected, and is laggy.
So "Let's replace the Cloud with self-hosted alternatives," right?
-- Good luck with added effort and complexity of config, maintenance, network, db, bugs, updates, and the pain of "admin accounts" in first setup.
We used to have the client and server functionality baked together in any major desktop software that used to connect to FTP, IRC, P2P, Mail, and to each other.
Today it's accounts...
Accounts.
It's accounts all the way "up."
We used to own the data, and the software.
Now it's full-scale surveillance and dispossession.
I've learnt this the hard way. The most important thing is to get you to click.
Sometimes I'll first iterate over the title before even writing on substack.
I have learned that too. If you write about C, almost no one clicks. It is not new, it is not flashy, and it does not promise easy results. Yet almost everything still runs on it. The quiet parts of computing rarely get attention, even though they keep everything working.
I still write about C anyway. It may not trend, but it lasts.
I'm sure I'm not alone - after decades - already knowing far too much about C, so that any article I'm likely to read either I'm like "No, that's wrong and I even understand why you thought that, but it's still wrong" or I just nod along and sigh.
I spent a substantial fraction of my professional career writing C, and I remain interested in WG14 (the language committee) and in several projects written in C though I avoid writing any more of it myself.
The reason it's so widespread is called "Worse is Better" and I believe that has somewhat run its course. If you weren't aware of "Worse is better" a quick Google should find you the original essay on that topic years back.
In contrast when I read an article about say Zig, or Swift, I am more likely to learn something new.
But I can certainly endorse your choice to write about whatever you want - life is too short to try to get a high score somehow.
Thanks for sharing your thoughts. I have never deployed any production C code and I would not choose C for professional work either, but learning it, with all its rough edges, has made me a better engineer. It helps me understand how things really work under the hood. No pain, no gain.
Maybe I am biased, but for professional work, I stay with Go. I have built large distributed data systems that handle hundreds of millions of business transactions daily, and Go has been steady and reliable for that scale. Its simplicity, strong concurrency model, and easy deployment make it practical for production systems. I still enjoy exploring Zig and Rust in my spare time, but for shipping real systems, Go continues to get the job done without getting in the way.
> I still write about C anyway. It may not trend, but it lasts.
> I have never deployed any production C code and I would not choose C for professional work either
What do you write about C, if not for practical usage in the industry? Can you post some links?
FWIW, since you seem interested, here are some blog posts of mine specifically about practical usage of C, some of which got a little discussion here on HN in the past:
> I'm sure I'm not alone - after decades - already knowing far too much about C, so that any article I'm likely to read either I'm like "No, that's wrong and I even understand why you thought that, but it's still wrong" or I just nod along and sigh.
If you have some spare time, I would really like to hear more about your experiences. It sounds like you have worked with C for a long time, and that kind of insight is hard to find now.
Most people around me started with JavaScript or TypeScript as their first language, and for many, that is still all they know. I mean no disrespect, it is just how things are today. It would be great to hear how your view of programming has changed over the years and what lessons from C still matter in your work today.
> It sounds like you have worked with C for a long time, and that kind of insight is hard to find now.
I've already replied to you in a sibling post, but I have been writing in C since the mid-90s; there's really not that much insight you get specifically to C.
An alternative view of "not new and flashy" is "known and expected", which not 100% of C conversations have to be. Just look at the excitement around Fil-C lately!
Oh, and I just submitted a link to my article about C. I am pretty sure no one will click it.
Articles about C never get much traffic, but that is fine. I wrote it because I care about how things really work, not because I expect it to trend. If even a few people read it and see the beauty in the old language that still runs the world, that is enough.
thanks, i enjoyed reading it (though a bit lengthy).
what gets me personally is what you describe at https://github.com/little-book-of/c/blob/main/articles/zig-i... - zig is made to feel easy and modern for people who don't know any better, and it does this well. But as soon as you actually need to do complex stuff, it gets in the way moreso than C and it's current environment/ecosystem will.
And to be fair, as much as I enjoyed writing in C in my younger years - I only use C when I actually need C. And asm when I actually need asm. Most of my code now uses higher level languages - this puts zig into such a niche.. it feels like golang to me: the cool language that isn't really solving as much of a need as you'd think.
I don't think zig is that much more complex than golang, with a (currently) crappier standard library. The bonus being you leave no performance on the table. I wonder if it would work with devops, where both c++ and rust fails.
And I want to clarify again, these are just personal notes written with some help from LLMs. They may contain mistakes, so please read them with curiosity, or feel free to skip them altogether.
I mean, if you embed Zig in a larger C++, Rust, or Python project, coordinating the build systems can be difficult. Zig prefers to manage the entire pipeline itself, so mixing it with other compilers and dependency managers can require workarounds. In my opinion, the only practical way to do this is by exposing C interfaces.
Honestly this (the fact it is being massively upvoted) looks a lot more like paid promotion. Not the first time and not the only example of submission btw.
So, “Let’s build carbon-titanium-foldable bicycles instead of bloated modern cars, and still get from A to B?”
How many mainstream online platform users care about the difference in KB in their experience, anyway?
The sites in the list are hobbyist clubs with a technical point of view, which wouldn’t make sense for a mass media outlet with millions of daily traffic, and real interdepartmental complexity and compliance issues to deal with.
> Let’s build carbon-titanium-foldable bicycles instead of bloated modern cars, and still get from A to B?
Yeah, that sounds awesome.
Nobody _needs_ to run a 4-minute mile, or win a chess tournament, or climb a mountain, or make the most efficient computer program. They're still worthwhile human endeavors.
I have came to the understanding that the things that we'd like to keep track of as "todos" are more like "issues," than specific and physical actions.
The "tasks" are only meant for the day, maybe drafted daily and be disposed of and forgotten in a post-it notes fashion.
The issues, then are more like a backlog of requirements, a call to duty, like "briefs on the mission."
The "issues" are the question; and neither todos, nor tasks are the answer.
It is robotic to compile and keep track of a set of "actions to be done" several days into the future, but those todo.txt's as a database can be treated as valuable asset, as a "documentation of scope," for a team-of-one, or many.
Hence the treatment of those not as "todos" as issues, with their shifting nature of requirements and many ways of resolution.
Such a database deserves reinventing because nothing else can be as tailored and as diamond-cut as the one that's been built by you.
Your approach on "issues" is fascinating! It certainly sounds like you're talking about almost tracking tickets...you know like for a dev or tech support team...Because my experience is that often tickets are not a one-and-done thing. Often enough, they require a little more folow-up, and i myself like to add comments along way towards the progress of completion...so, yeah, your approach sounds alot like tracking tickets...which in itself is NOT bad at all. The only concern is that tracking tickets often requires some pretty robust software/tool...so unless we're talking a kanban, the fear i would have is that the software/tool to use for tracking tickets might be too unwieldy for quick, let's say mobile tracking of progress...though i admit that may wrong on all thre above.
https://en.wikipedia.org/wiki/The_Protestant_Ethic_and_the_S...
It's one of the classic subjects in sociology,
https://oyc.yale.edu/sociology/socy-151/lecture-16