I'm with CleverLikeAnOx on this. I known it goes against the prevailing HN ethos, but more-features-more-monetisation does not necessarily produce the best product. (In fact, I don't think it will ever produce the best product.)
Think of those tools that you've really enjoyed using - perhaps the mid-range HP calculators, or a great fountain pen or knife, or even a spanner that just fits perfectly. These are all tools that have been designed with a clear idea of their purpose, and their design has focused on that purpose.
A great chef's knife doesn't incorporate a bottle-opener - that could be added but it would be a less usable knife.
Memorable products have long life-spans. Users treasure their fountain pen, often for life. I'm still disappointed at the loss of my HP11C. But who is going to mourn a programming language or front-end that drops out of favour because it's grown unusably big and cumbersome as the designers increase scope. When it comes to their next project, users will consider something cleaner, something that does all but only what they need.
Reminds me of a previous job where IT wouldn't let me install netcat, because "it hadn't been updated since like forever", my response: "because it's fucking done", I was eventually permitted to install it..
I had something similar when we had rewriten old application, and biggest change was move from WebSphere to Tomacat. First question we got was "What is missing in WebSpere?". Nothing is missing it had to much bloat we don't use.
I've given a talk at work about this one (but it ended up being more about people and kneejerk decision making processes where something cool is picked instead of something reliable), it resonated with a lot of people.
I'm still hoping to get to work with Go again sometimes, I think it embodies the adage pretty well in that it's resistant to change; I'm confident code written today in Go is still going to be the same and working in ten years' time, unlike any other programming language I've worked in.
I cannot stress enough how much I love this as well. This is what we need, all of us, all the time. It’s more common in traditional handcrafting and should be a guiding light for the future of tech.
Less is more. Less but better (to invoke Dieter Rams here). The goal should be a slow, incremental improvement over time, towards perfection.
Limited scope software simply exports functionality to a "de facto" support structure. An ecosystem as it were.
To get adopted, your "total experience" must be better the status quo.
So, authors of software need "de facto" integrations with other products. To handle features their product doesn't.
Unix utilities do "limited scope" brilliantly.
In, say, the Scala ecosystem... limited scope isn't so brilliant. Sometimes you just can't do limited scope.
Every year the "status quo" in software rises that much higher. Providing a better experience increasingly requires ever more resources to push a project to adoption.
> In, say, the Scala ecosystem... limited scope isn't so brilliant. Sometimes you just can't do limited scope.
As in Scala the programming language?
I find it is exactly the opposite. Scala is complicated and hard to learn, but if it can do anything well then it is allowing tools/libraries to be well-scoped and composed by the user.
To give an example:
In Scala there are 3 libraries:
- One for http requests
- One for async calls
- One for json (de)serialization
Those libraries don't know anything of each other and don't use the same interfaces/types, so by default you have to do some plumbing to make them work together.
But there are 2 more libraries:
- One that provides integration of http and json
- One the provides integration of http and async
As an end user that wants to build an async web app that uses json, you just have to add those 5 libraries and 5 imports and then everything just magically works out of the box. And it compile-time safe. No reflection or magic things happening. If anything doesn't work out, for example due to version differences, then it just doesn't compile and you adjust the plumbing yourself or update the libraries.
I seriously don't know any even half popular language that supports that. Take Rust for example. Rust has traits and allows you to make whatever types you have become compatible. But you can't write libraries on top of existing ones to do the plumbing for the user who then just picks the plumbing they like.
Which of these libraries does I/O, and why is it any of them?
In Zig, I am using a TLS library that does not perform I/O, it just writes to writers and reads from readers, so using it with io_uring or DPDK or send/recv or pcap files requires 0 additional work.
Depends on what you mean by IO. The http library can be used without IO (i.e. you give it a request and it gives you the response and potentially does some effect (but that's e.g. done through the async library). But it also includes functionality to bind to a port and listen to requests there in the way the async library (or maybe a streaming library) controls etc.
> In Zig, I am using a TLS library that does not perform I/O, it just writes to writers and reads from readers, so using it with io_uring or DPDK or send/recv or pcap files requires 0 additional work.
Of course. Now imagine you need backpressure (reactive streaming) and writer/reader interfaces don't support that. Can someone provide you a library that you import and then automatically the types of the TLS library change and it works with the new interfaces that it doesn't even know exist? Because that's what I'm talking about.
I/O usually means syscalls, I guess. If I install a library to encode and decode a protocol and it has no mode of operation that performs 0 syscalls, it is defective.
I'm not sure how "write does not even return until the writing is done" can avoid handling backpressure.
Unfortunately, I have had to add calls to flush() to the TLS library because it was not made with buffered writers in mind. I guess instead of writing flush() a couple of times I could have written a library that wraps a pair of buffered writer and reader in a new reader which flushes the writer if necessary when you read it and wraps the TLS library so that the passed-in reader and writer are automatically wrapped by that new reader. This sounds like a bit much though, since the whole task was to call flush a couple times only during TLS handshakes only if flush was defined.
> I/O usually means syscalls, I guess. If I install a library to encode and decode a protocol and it has no mode of operation that performs 0 syscalls, it is defective.
I agree, but that wasn't really the point that I was trying to make. Even without IO, there can still be different interfaces, such as specific interfaces for errors, attaching meta information like tracing, logging etc.
I don't know how ZIG solves that, but in Java this is a PITA because the language isn't capable enough - so everyone falls back to global runtime configurations, e.g. some file being somewhere that configures it. It doesn't compose and is super hard to debug. And that's just an example.
> I'm not sure how "write does not even return until the writing is done" can avoid handling backpressure.
That doesn't matter. The point is that you are using the reader/writer interface. So if you want to plug this library into another library that works with different interfaces then you now have to convert stuff around by hand all the time.
You could say that everyone should just use "standard" interfaces, but often they don't exist or lack certain properties or it's simply hard to standardize everything. Think about how many libraries for dates/times there are in Java or python.
EDIT: I can see that it might be a bit hard to wrap your head around what I mean because as developers (including myself) we learn to do plumbing all the time and it feels like you just have to do it in almost any language I always used.
This allows to provide the effect on the callsite. This could simply by "Id (which means regulary executed code) or it could be async, an error type, something with logging or a combination of all those and more at the same type. The library doesn't know and doesn't care, it only constraints the interface if it needs to.
More precisely, since the concept of typeclasses is modeled in Scala using values, it is a bit more powerful and expressive (but also harder to use correctly) than for example Haskells counterpart.
And to add more: typeclasses are usually not enough here, you also need higher kinded types or the whole thing is useless for a lot of meaningful abstractions (such as dealing with errors or async code).
> Limited scope software simply exports functionality to a "de facto" support structure. An ecosystem as it were.
Ok but now everyone who doesn't need that new better experience doesn't get their code broken anymore right? So it isn't a wash, we've gained a benefit.
This feels pointless. The world is in constant flux. There is nothing that’s ever perfect, or lasting, because the red queen keeps on running. Software should change to adapt, or it will become useless.
It's hard to think of any single tool which hasn't been superseded along some axis.
People still use pens, for example. But if they want to write 100 copies of the same page, they'd much rather use a printer. People use hammers, but if they want to hammer in ten thousand nails, they might start thinking about automatic tools.
They might, but the hammer works. If it's too slow... get a second hammer and person. The world's great monuments were made without automatic tools, just time, patience and many people.
It's not the fastest or easiest, but it works, it's reliable, and it's cheap.
Anyway, in the context of software, think of the unix commandline tools; simple, single-purpose tools, a lot of which aren't updated frequently. But using those as lego blocks is directly or indirectly responsible for the multi-trillion industry we're in.
Even they get rewritten and updated and 'bloated' all the time. Compare the original BSD or AT&T tools to the latest GNU tools and you will see that they have been reworked, tweaked and updated countless times with many many new features added. In fact when the GNU tools started to become popular they where regularly accused of unnecessary bloat and being against the spirit and philosophy of Unix.
> Even they get rewritten and updated and 'bloated' all the time.
"All the time" is a stretch. The basic UNIX commands date back to the 70s and while they have grown more and more options over time, change is slow (which is a wonderful thing, to be clear). Yes, there was grumbling when GNU started adding even more options but even that is now decades ago.
As a consumer of the tools (whether by hand or by shell script), they provide a stable base to build on. I have some shell scripts from ca.1990 which still work fine. It's very pleasing to be able to build on top of a solid foundation that just keep working for a long time.
But the pen you use today is quite different from a pen you would have used 100 years ago. Most people would not want to use 100 year old pen design as their 'daily driver'
The ballpoint pen was invented in 1889. A simple ballpoint from 1922 was not significantly different than any ordinary pen used today.
I can't think of a major advance in pen design since about 1965 (Fisher pressurized space pen) and I don't expect any major advances before 2065.
Gel inks? Smaller ball-bearings in the Uniball line? Erasable ink? Not much there.
Also anybody who calls a pen their "daily driver" is probably well served by a vintage fountain pen, a form that arguably was at its peak in the early 20th century.
Was you there Charlie? (That's a radio meme from the 1920's.) My father used fountain pens, good ones, but sooner or later there'd always be a mess. Ballpoint pens weren't practical until quite small ball bearings could be made very, very smooth and spherical. That didn't happen until the mid to late 1960s, when my father finally switched. Before then they were outrageously expensive and gave poor results. They really were very different from the ballpoint pens you can buy today, even if the basic principles are very similar. Mechanical pencils got used a lot, say for drafting, back then. Creating a nearly spherical ball bearing on a planet with gravity, electrostatic effects, noise, etc, etc, out of steel, the most elastic substance known, is no small feat.
It feels like the idea of refining something to the goal perfection is not mutually exclusive to the idea of being adaptable.
To me it implies that since the definition of perfection is always changing, you are continually altering course to get closer to where you want to be.
> there is a process in place to hand over the project to a trusted party in the worst case scenario.
Sorry for being a pedant, but it's hard to overstate how insignificant this timeframe is compared to "forever". Even if we talk about forever in practical terms of when the earth will be consumed by the sun or something like that. Why not just be honest and say "Built to last a lifetime"?
I have similar pedantic objections to that, since "a lifetime" isn't even well-defined. "Forever" might be an unachievable goal, but it's a goal which implies specific priorities.
Lifetime has been significantly cheapened and hollowed out as a meaning full word when it comes to products, thanks to the ever present unspoken "lifetime of the product". In the context of products if I think of "lifetime" as about 2 years, maybe a little less or more depending upon the company, but far less than a decade in all cases.
Side note: Proud to see more and more South African techies and their work becoming regularly visible on HN (other recent notable example includes Fynbos).
Fleeing your birth country to avoid national service, applying for citizenship in your new host country, and then never returning to your country of origin is a pretty strong signal. Naturalizing in yet another country is a fairly decent emphasis. Not sure what you're looking for. There is more to citizenship than holding passport you haven't used in thirty years.
Well, not living there, having other citizenships, and generally putting most of his eggs in the American basket would do it.
Generally speaking, I would also note that outside of the Americas jus soli isn’t the norm. In South Africa, jus soli is restricted to partial sanguinis laws where the parents of the individual concerned must be South African citizens or permanent residents.
Further, Elon has openly stated the aim to make humans multi-planet, holds multiple citizenships, and views government as a territorial monopoly on the initiation of violence. Based on these three things, I’d say he has little allegiance to any given country, and that he’s more of a nerd who just wants to do stuff without worrying about anything else.
While he'd definitely make a list of influential South Africans, he has not been part of the culture for a long time, let alone the local tech scene. He's known to not be the biggest fan of his origins.
The article is titled “Building software to last forever”, but the software is probably the least interesting part of making it endure (though it’s still important, for the reasons outlined in the article). Making the service last, that’s the tougher part.
For my part, I move ever more determinedly in the direction of self-hosting and actively avoiding becoming a single entity that can fail and take lots of people down with me—avoiding most of the scope of this article becoming applicable.
Yes, centralized is not forever. Forever is distributed (forever as long as anyone is keeping it going), or at least self-hosted (forever as long as I care to keep it going).
I have to say nothing to date has the charm of late 90's, early 00's internet but I'll admit bearblog comes close. I'm glad more people than just me appreciate simple websites.
If anyone has links for their personal sites/blogs, or anything in the vein of software development, feel free to share. I'm eager to build a bookmark folder of them to check in lieu of social media or youtube.
I've been following this project for a while and I love it. The only drawback I see is that writing maths equations is not easy. In my blog I use Mathjax, but I guess this is not possible in Bear because they want to do all the heavy processing server-side, and rendering LaTeX on server side using Mathjax is not trivial. Hopefully they'll find a solution to this issue, since I think a lot of people would then migrate their technical blogs to Bear.
A less stringent requirement would be to "build for longevity" and part of that could be planning for the end. Because things do end and that isn't always bad.
This is covered in the essay: There are processes in place to hand-off in the case of death, as well as plans of forming a foundation to take care of the project.
I love this. I wish more software was built with limited scope. Not every application needs to grow larger and change forever.