Defining the Rust 2024 edition

Posted Jan 31, 2024 16:40 UTC (Wed) by paulj (subscriber, #341)
In reply to: Defining the Rust 2024 edition by farnz
Parent article: Defining the Rust 2024 edition

I don't think it is just a C problem. I think it's a wider cultural problem in tech.

I think there was actually a moment in tech, in the mid-90s, where a bunch of engineers /did/ think about stability. And they /did/ bring in tools and processes to try tame some of the dependency and stability issues that had been seen. We got tools to at least define C interfaces and manage their stability - even if the default wasn't ideal, as you say (also, unfortunately GNU libtool went with soname versions as the recommended approach rather than symbol versioning - and soname versions just.. doesn't work - I fear this damaged the FOSS side). We got social processes to manage stability, both in some tech companies and in a (v small) number of FOSS projects (Glibc, on top of symbol versioning; Linux, of userspace API and ABI). You could argue Linux distros and packaging tools also played a significant part in trying to manage stability and tame the hell of dependencies without such management.

Sadly, we seem to have lost the drive - collectively - to manage stability.

We see many projects just ignoring tooling and packaging approaches to managing stability, and just... vendoring the fsck out of everything and giving users "wget | bash" scripts. And this has become very normalised. And the more projects do this, the more unstable everything becomes and hence the more other projects do this, because they can't rely on stability of stuff either and have to vendor.

And it's not just FOSS, this happens internally in proprietary corps too. With internal projects sucking in external and internal repos into big blobs. Even checking in .sos into build directories for various platforms and arches cause they can't figure out anything more reasonable. Cause nobody has the time to care about managing stability and dependencies, and the resulting industry wide mess means it's too complicated to even start to figure it out.

But wait, I know the answer, let's ship a script that builds container images that contain our build, so it can build...

It's really awful, and it seems to be getting worse.

Defining the Rust 2024 edition

Posted Jan 31, 2024 17:27 UTC (Wed) by farnz (subscriber, #17727) [Link] (3 responses)

The only part of it that I see as a "C problem" is the idea that C inherently has a stable ABI for dynamic linking, while other languages don't. That's a false statement - it's a historical coincidence that as engineers at Sun build what became ELF dynamic linking, they built something that assumed that if you hadn't put the effort in to first limit symbol exposure (SunOS 4.0) and then version your stable ABI (Solaris 2.5), the "right" thing to do was to expose everything as-if it's a stable ABI, rather than hide everything by default and require you to explicitly expose a stable ABI to dynamic linking.

With engineering discipline, you can work well in the Solaris 2.5 model of a version script indicating exactly what symbols are part of your stable ABI, and what symbols are internal, combined with a static library and source code that provides a "useful" stable API on top of the stable ABI (but where the ABI of the static library and matching source is itself unstable). But we don't do that for any language; Rust, Go, C++ et al merely expose that our "stable ABI" trickery is not engineered in, but something that only exists for C because there's a lot of invisible work done to hide the fact that the libraries don't have a stable ABI by default.

Defining the Rust 2024 edition

Posted Jan 31, 2024 17:44 UTC (Wed) by paulj (subscriber, #341) [Link] (2 responses)

We're agreed by and large. Particularly on stability - managing it - being work. And yes, it's "harder" work than 99.999% of the tech world wants to do. I'd quibble it's /that/ hard though. It can be done. It wasn't that hard in Sun. It was just a /modicum/ of care for daily engineering. An extra topic of review and documentation at points when adding/removing major software components that triggered "architecture review committee" processes.

It was a little bit of sound engineering work, and quite manageable.

Really, where we are today, it's largely a cultural thing - we just don't want stability. Or more precisely, we want stability from everyone else's software, but we don't want to held to that ourselves. We - as an industry - are largely a bunch of degens who just want to slap code around, and not be held responsible much later. Either because we work in some big-walled-garden tech corp, and all that matters is throwing enough code around to get past the next performance review; or because we work somewhere where managers are putting pressure on you to get that next hacky-bug-fix or half-arsed-feature-update shipped to the customers, so that you can move onto the next hacky-bug-fix or half-arsed-feature-update.

Sorry... I've become very cynical. But then, I've been watching some of the videos of testimony from the UK Post Office scandal, particularly the software engineer describing the code issues and practices and.. I really am not being cynical, we really are just a completely degenerate industry.

Defining the Rust 2024 edition

Posted Feb 1, 2024 10:59 UTC (Thu) by farnz (subscriber, #17727) [Link]

See also a subset of the fuss around the EU's Cyber Resilience Act; not the people talking to MEPs and national Commissioners about getting the details right (e.g. ensuring that I can't be held liable if you use my software for a purpose I did not advertise it as suitable for), but the people arguing that any form of liability for defects in software will destroy the software industry completely. In effect, they're saying that the software industry (including embedded) cannot exist if software vendors can be held liable for faults in the software they sell.

Defining the Rust 2024 edition

Posted Feb 1, 2024 16:09 UTC (Thu) by Hattifnattar (subscriber, #93737) [Link]

It may be just the fact that a lot more people joined the ranks of programmers.

Early on, programming was an elite undertaking, with people practicing it having a mindset closer to scientists. It was elite job, commanded elite compensation (not necessary monetary, esteem too). The "industry" also had been largely driven by people with more-or-less engineer or scientist mindset.

Now software is a real and huge industry, programmer work is commoditized, the whole thing is more and more run by people with "financist" and/or "bureaucrat" mindset, "buccaneer" in the best case.

There are still "islands of quality" in this mess, mostly dealing with foundations. But they cannot completely isolate themselves from the overall dynamics. However, understanding it can can help to draw some boundaries and do better in specific areas/projects etc.