This is the first I've heard of the whole thing, so forgive me if I'm just bloviating.
As a political move to advance the cause of memory-safe languages, as Alex Gaynor clearly intends†, this is obviously kind of a fiasco.
The arguments about who's going to pay for safer software are uninteresting. It's like arguing over who is going to run into the burning building to save the baby. Put some liability laws in place and see what you get?
As for Rust not supporting "weird architectures", are y'all serious about being the new contender or not? C isn't going to give up the title without an epic fight. Love it or hate it, to a first approximation C is programming.
†I do not mean that in a negative way. FWIW I'm referring to https://www.usenix.org/conference/enigma2021/presentation/ga... which I just read. Personally, I'm at "Bargaining" stage, I think we can still "turd polish" C into something and Rust seems to me to be waaaaaaaay too complex (to replace C. It sure is fun though, eh?)
> As a political move to advance the cause of memory-safe languages, as Alex Gaynor clearly intends†, this is obviously kind of a fiasco.
I’m not sure about that: there’s been a few people vocally complaining but it doesn’t seem like they’re getting much traction. I’d see this working as well for other maintainers saying “people using hardware which has been dying since the 90s aren’t a major constituency and I’d like the huge safety and productivity benefits of Rust”.
I find it interesting that you describe Rust as too complex to replace C, when I generally see it as the reverse: I’ve written C off and on since the early 90s and it’s almost always felt like a chore because you have to do so much yourself that newer languages do for you. Rust hit a better comfort level after a couple hours because it was so much more productive that I could start making progress on design refactoring which had been postponed due to how tedious it would have been to do it before.
> I’m not sure about that: there’s been a few people vocally complaining but it doesn’t seem like they’re getting much traction.
You don't see the problem with that?
People (who already use a memory-safe language!) shouldn't be complaining when their crypto gets rewritten in a memory-safe language. If they are, someone shat the bed.
And if your users are complaining but getting no traction, that is a (second!) shitting of the bed.
> other maintainers saying “people using hardware which has been dying since the 90s aren’t a major constituency and I’d like the huge safety and productivity benefits of Rust”.
We all want safe software. People aren't upset by choices being added, they are upset about something they (thought) they had that has now been taken away. If you break a bunch of people's stuff and then tell them "fuck you, pay us" or "your platform isn't hip enough" it's kind of a dick move, eh? The "optics" are bad.
- - - -
In re: complexity of Rust vs. C: The measure of complexity of a system isn't the ergonomics of the tooling, it's the time/effort for a newbie to achieve competence, eh?
> People (who already use a memory-safe language!) shouldn't be complaining when their crypto gets rewritten in a memory-safe language. If they are, someone shat the bed.
Or they’re resistant to change and are going to complain about anything which means they have to learn something new. I mean, if you listened to the current crop you’d think that C builds worked perfectly everywhere whereas it hasn’t even been a week since I’ve to debug a C-based extension install on an Alpine container.
In reality, a large fraction of Python cryptography users switched without issues. They just didn’t take to the forums to say that it was working fine or that they were not unhappy because they didn’t derive some portion of their self image from mastery of a half century-old systems programming language.
> In re: complexity of Rust vs. C: The measure of complexity of a system isn't the ergonomics of the tooling, it's the time/effort for a newbie to achieve competence, eh?
I’d really seriously question whether it’s correct to assume that it’s easier to learn C plus 50 years of add-on libraries to get close to Rust-level functionality and internalizing all of the patterns people use to work around the unsafe and/or unfixable bits. That Rust newcomer will almost certainly have multithreaded code working safely while their C counterpart is acquiring some deep debugging experience. The higher level structures are a huge win and the frictional cost of not having core language support for basic tasks like text processing mean a lot of frictional costs go from being easily missed runtime mistakes or hard to debug crashes to IDE warnings or compile time errors.
> That Rust newcomer will almost certainly have multithreaded code working safely while their C counterpart is acquiring some deep debugging experience.
Yep. Which one will be better at debugging when things inevitably go wrong?
The happy path is not the measure of complexity.
Let me put it another way: Which would be simpler to implement from scratch, C or Rust?
> Yep. Which one will be better at debugging when things inevitably go wrong?
I think you're dramatically under-estimating the amount of extra work a C developer has to do, ranging from not having many data structures to not having a package manager and thus needing to write a lot more code themselves. If C forced developers to be good at debugging we'd know by now — and I'd see less printf() debugging — and being forced to cobble together more of what you get out of the box with Rust means that those skills are less portable because different programs have different combinations of conventions, macros, and libraries in use. A C developer with a lot of Windows experience is going to have a rougher time debugging a Linux program (repeat for MacOS, iOS, *BSD, etc.) than a Rust developer simply because the limited language set means even basic tasks like text processing follow project-specific conventions.
Rust is more complex than C. It's not a controversial statement.
You're arguing past that, saying that Rust is more ergonomic, or has more built-in functionality, or is more cross-platform, or has one true package manager, etc. All of that may be true but it doesn't make Rust simpler than C.
In any event, if Rust wants to take over the world but disdains "weird architectures" or "dying" hardware, well, we'll see how that plays out for them.
I hope we do get safer software one way or another, so I wish the Rust folks well. That's why I'm pointing out that this is lousy politicking. I'm not trying to hate Rust.
> All of that may be true but it doesn't make Rust simpler than C.
Note that this is not a claim I made - in part because it’d start getting into questions of how you define “simple”. The core C language is certainly smaller, although internalizing some of the undefined bits certainly takes some time, but the question at hand was “competence” which, in a thread about security software, I have been treating as the ability to write code which not just runs but is secure. Based on how routinely C programs have exploitable bugs, I would argue that the average developer using a memory-safe language goes past the point of “can write something trivial which executes” to “can write code doing something real which is not insecure” faster.
Let's say I have some new piece of hardware that is exotic enough that no high-level language is available for it yet. I think it's obvious that writing a C compiler is generally an easier task than writing a Rust compiler. As long as that's true, and I can leverage C code on my new hardware much more easily than Rust code, Rust can't replace C.
An "average developer using a memory-safe language" can't go anywhere if that language doesn't run on the machine.
Do you think average developers implement C compilers and toolchains on novel hardware frequently? That’s a pretty niche case and the vast, vast majority of C code is running on a handful of well supported architectures.
It’s also not like that’s trivial even for C - I remember how many decades it took companies employing large numbers of engineers to do so – and these days a better question is something like how long it would take to implement an LLVM backend.
I apologize in advance if it seems like I'm moving the goalposts. You're right that implementing a C compiler isn't a common or trivial task. My point is that implementing a Rust compiler is a much more complex task.
> the vast, vast majority of C code is running on a handful of well supported architectures.
Irrelevant. How much C vs Rust (vs Zig or D or ...) is running on the long tail of hardware?
FWIW, if Rust displaces C on the lion's share of machines, that's great. I'm not against Rust, or in favor of C.
> these days a better question is something like how long it would take to implement an LLVM backend.
Yes, absolutely, I agree.
Ideally you would have a program that takes as input a machine description and emits as output a correct Rust (or C or Zig or D or ...) compiler for that machine.
> The measure of complexity of a system isn't the ergonomics of the tooling, it's the time/effort for a newbie to achieve competence, eh?
Honestly it takes a very very long time to become competent in C. I do C for my day job (or rather did until recently) and I still don't call myself competent in the language. There are so many intricacies that can bite you and you're constantly learning it. I used to love C, now I hate it.
> As a political move to advance the cause of memory-safe languages, as Alex Gaynor clearly intends†, this is obviously kind of a fiasco.
On the contrary, I think this is a brilliant move; it's pulled C fans into a blatantly unreasonable position, making it clear how untenable their position is.
> As for Rust not supporting "weird architectures", are y'all serious about being the new contender or not? C isn't going to give up the title without an epic fight. Love it or hate it, to a first approximation C is programming.
Nonsense. Serious programmers (e.g. those doing it professionally) have already mostly moved on from C. Open-source is bound up with Linux and C for historical reasons, and also because the top mainstream languages were not open-source until recently, and so is disproportionately behind the times.
> Open-source is bound up with Linux and C for historical reasons, and also because the top mainstream languages were not open-source until recently, and so is disproportionately behind the times.
The top mainstream languages (C, C++, Java, JavaScript, Python, C#, etc.) have all had at least one open source implementation for at least a decade. A decade is not a long time in the life of programming languages but it’s also not “recently.”
I remembered the issue with Java; it's not really open-source because it's covered by patents that are only licensed for implementations substantially derived from OpenJDK.
I'll admit that GPLed Java is much older than I thought, but
open-source C# was certainly not first-class until 2016, and IMO not really until late last year.
I said the languages "weren't open-source". The only reasonable interpretation of whether a language "is" open-source is whether it has first-class open-source implementations and tooling. Otherwise we'd say things like "Windows is open-source" because ReactOS exists.
Putting Mono in the same category as ReactOS is disingenuous at best. Mono was such a good open source implementation that Microsoft eventually bought company behind it and canonized it (Xamarin).
My experience was that you couldn't take a random C# project and run it on Mono and expect it to work. I don't want to diminish the technical effort that went into Mono, but it would be misleading to say that open-source C# worked without further qualifications.
I don't think it is. What does it mean for a language to be open-source, if not that there are one or more open-source implementations of that language which support most or all of the extant ecosystem for that language.
Top 5 languages were Java, C, C++, PHP, Python. All five of them were open source in mainstream implementations (Open JDK, GCC, GCC, PHP mainline, Python mainline).
This is the first I've heard of the whole thing, so forgive me if I'm just bloviating.
As a political move to advance the cause of memory-safe languages, as Alex Gaynor clearly intends†, this is obviously kind of a fiasco.
The arguments about who's going to pay for safer software are uninteresting. It's like arguing over who is going to run into the burning building to save the baby. Put some liability laws in place and see what you get?
As for Rust not supporting "weird architectures", are y'all serious about being the new contender or not? C isn't going to give up the title without an epic fight. Love it or hate it, to a first approximation C is programming.
†I do not mean that in a negative way. FWIW I'm referring to https://www.usenix.org/conference/enigma2021/presentation/ga... which I just read. Personally, I'm at "Bargaining" stage, I think we can still "turd polish" C into something and Rust seems to me to be waaaaaaaay too complex (to replace C. It sure is fun though, eh?)