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.


@sir I don't understand what is the link between your reasoning on GNU extensions (which is valid) and Rust language...

Rust is clearly documented and spec will come later to help implement compilers. Meanwhile it is ported to various operating system already and is clearly good at handling FFI and differences between the language version.

@amdg2 Rust does not have a spec, nor multiple implementations. It comes down to complexity and the value of choosing the simplest options in the simplest environments.

@sir @amdg2 it doesn’t have a spec yet, but people are working on it and they are paying a lot of attention to have a reasonable specification that is not ambitious and that provides strong guarantees in the case of unsafe rust

C has a spec, but it’s ambiguous and often ignored by people

@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.

Sign in to participate in the conversation
Diaspodon est une instance majoritairement francophone et généraliste. Aucun contenu du fédiverse n'est filtré par une décision d'administrateur ou de modérateur.