Here's an example where innocuous decisions can lead to needlessly complex software.
Let's say you're working on some software and you decide to use asprintf, a GNU extension. It's a fairly benign extension, after all, and clearly useful. You might not even notice it's an extension because someone on stackoverflow told you to add -D_GNU_SOURCE to your build 30 problems ago. Your system is glibc anyway.
Now your program doesn't work on musl libc, which eliminates Alpine and Void Linux. It also no longer works on newlib, so that's most embedded devices out. Linux is the only system which ships glibc, so it's also done for on BSD, Minix, and so on. The next big operating system will have to resort to reverse engineering glibc to support your program, since asprintf isn't defined by any standard.
That was just one small, seemingly benign change. What if, knowingly or not, you've made dozens of such changes in your project? What if you pull in a dependency which has made similar concessions? What about transitive dependencies? What if we build an entire industry of computers on the shoulders of software which has made these little compromises, all the way down?
If we're ever going to make it out of this mess, we have a responsibility as programmers to strive for simple software, to dig our way out of this enormous hole we've put ourselves in. The only way up is to become more simple, not more complex.
This is why I see languages like Rust, systems like Fuchsia, and so on - as if they were handing out shovels.
@epicmorphism @sir @amdg2 MIR (it's intermediate representation) is also formally verified (or at least most of it is?)
And for what I used it for, Rust's complexity allowed me to write simpler software than C or C++.
And the memory safety benefits it brings are not negligible. Now that we have rust we can actually see how linear types are used in practice, and the next implementation can learn from that and simplify things. But we needed a language people actually used to get there.
@sir > Rust does not have a spec, nor multiple implementations.
True, we are looking at facts here.
> It comes down to complexity and the value of choosing the simplest options in the simplest environments.
Yes, we agree, but how does this relate to Rust being "needlessly complex"
Did you consider all the magic that is happening in the processor and C compiler to make you write your program as if it was running on good old PDP-11? Isn't this overly complex?
@amdg2 I never said C was perfect, in fact it's far from it. Instead what I said is that Rust is also bad. You don't get to say "but C is bad!" to justify some other language also being bad
@sir seems legit. Then what do you consider good ?
@amdg2 there are no good programming languages, just varying degrees of bad. IMO Go is probably one of the least bad, but I still have serious problems with it. I still prefer C over Rust as well, though again it's not like C is good.
@sir mmmh, that explains some rant of yours 😅
cmpwn.com is a private Mastodon instance for friends of SirCmpwn.