The (successful) end of the kernel Rust experiment

[SiliconWizard]

Anyway, we're IMO in a clear "software crisis" and I don't see this crisis ending anytime soon.

Incidentally, this term was first used (AFAIK) by Chris Strachey at a NATO software workshop in 1968.  So it's existed for roughly the same amount of time as modern programming.

In which case does it still count as a crisis if it's run longer than people's careers?

Of course it has, software is inherently a complex beast that is hard to tame.
Software has been in a "crisis" state ever since it's become unavoidable, not just because it's hard to get right per se, but because it's hard to get right and we can't do without it.

The late 60's "crisis" was a bit different though, although for the same root "complex beast" reasons. At the time, the main battle was about using structured programming and proper engineering principles in software, which was still absolutely not a given in the late 60's.

These days, we've long been past that question of structured programming, but software has become orders of magnitude more complex, and the question of using "proper engineering principles" is still there, more than ever.

IMO, the underlying cause is the lingering belief that software changes have virtually zero cost, which is completely bogus in any real-life setting, and which still makes software not really adopt sound engineering approaches. With "physical" engineering, you have little choice: if parts are inadequately sized, it just won't fit - or circuits will blow up. With software, the general unfortunate consensus is that it's so "soft" that releasing buggy software doesn't matter much as it's "easy" to fix later on, and it's worsened as updating in the field, especially since the democratization of the internet, has become cheap and easy (while it could be very expensive back in the days). Now of course, software bugs can have very real, physical consequences, but it's still considered secondary compared to the direct consequences of badly designed hardware. And all users of software have even become used to bugs and don't seem to care much as long as there's a promise of future fixes, which may or may not happen.

To sum it up, software is in a kind of constant "crisis" because there's almost zero incentive to get out of it.

[tggzzz]

To sum it up, software is in a kind of constant "crisis" because there's almost zero incentive to get out of it.

I disagree.

Nowadays the problems successfully addressed with software are much more complex than they were back in 1968. That has been enabled by the addition of various types of "higher level abstractions" that enable understanding and reasoning, without becoming bogged down in the horribly awkward details inherent in the lower level abstractions. The same is true for electronics, but the abstractions and technology are completely different.

Hence there is a reasonable argument that the tasks addressed with software become ever more complex, up until the point at which the relevant software abstraction "runs out of steam" and yet again "software is in crisis".

Introduction of new abstractions allows contemplation and implementation of ever more complex systems.

To be a little more concrete...

• the first HLLs meant removed the need to think about registers
• HLLs containing abstractions removed the need for goto
• synchronisation primitives enabled reliable multithread and multicore processing
• sockets and RPC enabled distributed applications
• GCs removed the need to track every memory allocation/deallocation
• Rust's memory models do the same, in a different way with different tradeoffs

Of course there will always be people who want to program at lower abstraction levels, for better or worse reasons.

[paulca]

It's self leading and self deprecating.

Software Engineering = Finding ways to not need software engineers.

[tggzzz]

It's self leading and self deprecating.

Software Engineering = Finding ways to not need software engineers.

What is "it"?

Catchy sounding nonsense.

[Siwastaja]

It's self leading and self deprecating.

Software Engineering = Finding ways to not need software engineers.

There are two types of engineers (software or otherwise):

Those who consider adding automation and solving problems as a threat for their job security.

And those who think that once we solve problems and automate them, we can just move into new, even more interesting problems, and do very nice things.