_sh

As a developer of desktop applications as well, I've asked myself these same questions. While I don't have any definitive answers for you, I'll share my thoughts.

If you consider that an ecosystem evolves to the constraints of its environment, even from their pre-history at Xerox Parc, early GUI frameworks were incredibly constrained. But I think the most important constraint in their development was object orientation. Smalltalk blazed the trail for GUI programming, everyone else following after modeled their systems in that way. Object orientation became the most expressive way to program a hierarchical widget system (which most desktop systems are). Even early Windows HWND-style programming emulates virtual dispatch in non-object oriented C (also 'gobject').

In response, a vast body of knowledge and techniques around object orientation were amassed to mitigate these constraints as the ecosystem matured through the 80s and 90s. Not just patterns like MVC, Flyweight, Command et al, but also structural techniques like the event loop.

> Eventually, somewhere near the end of the 90s/middle of the 2000s, most of these things were "solved" for desktop/native, or put less charitably, they stopped changing.

So at the end of the 90s/middle of the 2000s the web browser grew out of being a document viewer into a very constrained widget kit, but the programming model was not object oriented and so the 'solved' problems needed to be solved again for a new set of constraints. Few of the traditional techniques applied, and the old object oriented way was either adapted (e.g. data binding became Redux, Flyweight/Prototype became templates) or disposed. Personally I find it a bit of a waste, but I don't expend any energy in the new ecosystem, so I don't want to be too judgy.

But I don't think desktop widget kits 'stopped changing', and are cherry-picking ideas from the browser, like 'declarative' (XAML, QML, etc) and 'responsive' (widget containers that re-flow the viewport for phone/tablet orientation etc). I hope I haven't misunderstood your question and wasted everyone's time.

Interesting... How do you schedule this? If the queue is empty, do you back off and retry later, or spin the query until it returns a queue item, or some other way? It's a nice approach.

Thanks so much for your comment. I've just read (and played around with) your waveguide synthesis article, which led me down the rabbit hole of Sporth, ChucK, Soundpipe and now I find myself really excited looking over the contents of the "Physical Audio Signal Processing" book. I am going to learn a lot of new stuff today, thanks!

SNOBOL!

> why shouldn't I expect to be using these programs in 50 years?

No reason at all, if they still solve the same problem, they're still the best solution. The problem with 'problems' though, is that once they're cornered they tend to change into a whole new problem. A nasty one the current solution won't work for, usually.

There are a couple of ways to look at this. Philosophically, to pick any one of your examples, my emacs is version 26.1. Is this the same software as emacs 15.10 released April 1985? Will a perl 6 program run on perl 5? Am I the same person I was 5 years ago?

Another take: what is the ratio of the same software still in use after, say, 10 years to all software in use? I would argue that more than 99% of all software (e.g. by version number) is no longer in use after a mere 5 years. Software is inherently disposable, let's not pretend we're building bridges that will stand for generations.

My point is that developers (I'm one) have a hard time with the qualities of software: we don't understand the nature of software change, and bicker about what bumping a semver number means, and we fight its disposable nature by engineering it to the point where it could run for a decade (it won't).

My thoughts on the philosophical aspects of the article don't really relate to Rust.

> These values reflect a deeper sense within me: that software can be permanent

Maybe it can be permanent, but it shouldn't be. Software is disposable and all the time developers are mistakenly fighting this aspect of its nature instead of embracing it. Great software is malleable and develops, over time, to adapt to the human that is using it. But it is impermanent--parts are snipped off here, fleshed out there, nothing stays the same, it is obsolete as soon as it is released. Don't delude yourself that your software will run for a thousand years, be like Warhol and celebrate the ephemera that is pretty much every program ever written.

> I have believed (and continue to believe) that we are living in a Golden Age of software, one that will produce artifacts that will endure for generations

Museum pieces, sure, but do we still want to be using generations-old software in the years to come? Hope not. Times change, needs change, and software that doesn't change is replaced by software that does, and quick. What about such monumental artifacts as 'cc', 'awk', or even the UNIX kernel? For years they have dominated the landscape, they are the Ozymandias, the King of Kings. If we are still clinging to these titans in another 20, 50 years, is that a good thing?

...like all Linux installs will eventually be replaced by BSD? I don't think the big, complex picture of technology licensing can be reduced as flippantly as that.

"Fast is my favourite feature" --Someone, maybe from Google? Not sure.

Hey no problem, just add -Werror to your compiler flags (C/C++/Java) or '<TreatWarningsAsErrors>true</TreatWarningsAsErrors>' to your csproj (C#).

You're right, but there is a lot of misunderstanding around this end of the market, mainly because advances have blurred the traditional segmentation. When talking about ARM, the 'M' in Cortex-M means 'microcontroller' whereas the 'A' in Cortex-A means 'application'. Cortex-A systems are often at the centre of 'System-on-Chips' and will run linux, and indeed the NT kernel as well, as they are bundled with enough RAM and fairly modern peripheral interfaces such as HDMI.

Cortex-Ms typically can't run linux (excepting uClinux) as they don't have the RAM and typically don't need to as they address a different need (dedicated function instead of general-purpose compute), and have far fewer peripheral interfaces. It used to be all about power profile, but the recent SoCs are getting pretty competitive there as well.

But as I said the traditional segmentation at this end of the spectrum is being re-cast seemingly every second week, and so terms such as 'microcontroller' are becoming less meaningful all the time. And who the hell can agree on just what 'embedded' means these days?

Embedded developer here, ARM Cortex-M4 microcontrollers. I've been keeping an eye on Rust for the embedded space and although there has been a lot of movement in that area--particularly in the last couple of months--I'm not sure the value proposition fits the microcontroller market, where of course C is king.

While Rust has much to offer as a programming paradigm in general, the main value is in the borrow-checker (the linked transcript cites 'memory bugs' as the most common class of bugs). Embedded software practitioners long ago abandoned dynamic memory allocation and with it the 'use-after-free' and 'out-of-bounds access' bugs, instead re-defining the problem as one of latency (e.g. you'll need to process that static buffer before it gets re-used by your UART interrupt). Take away the borrow-checker, and Rust looks less compelling.

In time, Rust will find its niche in the embedded space, most likely occupying the high-level RPi/BBB/iMX SoC layer and perhaps working its way down to microcontrollers. As wiremine points out, it will require vendor support--moving away from your vendor's toolchain is a world of hurt that seasoned embedded developers just won't even consider. Pragmatism reigns: time-to-market and a cheap BoM are the main metrics, programming language a distant 10th.

Electron sits in the same hybrid space as Cordova/Phonegap, and will suffer the same fate once React Native, or something similar, starts eating its lunch.