I haven't seen this from Rust. Obviously lots of us think that Rust is the way forward for us but I think the problem you're talking about is that nobody offered any alternatives you liked better and that's not on Rust.
If Bob is ordering pizza for everybody who wants one, it is not the case that "Pizza is necessarily the way forward", and it's not Bob's fault that you can't have sliders, I think if you want sliders you're going to need to order them yourself and "Pizza is the way forward" is merely the default when you don't and people are hungry.
Dave Abraham's Hylo is an example of somebody offering to order sushi in this analogy. It's not yet clear whether Dave knows a Sushi place that delivers here, or how much Sushi would be but that's what having another way forward could look like.
In C++ they've got profiles, which is, generously, "Concepts of a plan" for a way forward and in C... I mean, it's not your focus, but nobody is looking at this right? Maybe Fil-C is your future? I note that Fil-C doesn't work on these obsolete targets either.
Nobody is being forced out of the community, you can fork and not adopt the changes if you want. Thats the real point of free software, that you have the freedom to make that choice. The whole point of free software was never that the direction of the software should be free from corporate control in some way, the maintainers of a project have always had the authority to make decisions about their own project, whether individual or corporate or a mix.
What are some concrete cases you can point to where a decision was made with full consensus? Literally everyone agreed? All the users?
I'm not sure many projects have ever been run that way. I'm sure we've all heard of the Benevolent Dictator for Life (BDfL). I'm sure Linus has made an executive decision once in a while.
Requiring full consensus for decisions is a great way to make no decisions.
You describe it that way, but that's not how the world in general works in practice. You do things based on majority.
False claims don't really make the claims about the evils of Rust more believable.
This assumes there wasn't agreement.
And if so, what would 'eventually adopted by the majority' mean. Is this announcement not that?
This hasn’t changed.
Well, what's the alternative? The memory safety problem is real, I don't think there is any doubt about that.
C/C++ is a dead end: the community has thoroughly rejected technical solutions like the Circle compiler, and "profiles" are nothing more than a mirage. They are yet again trying to make a magical compiler which rejects all the bad code and accepts all the good code without making any code changes, which of course isn't going to happen.
Garbage collection is a huge dealbreaker for the people still on C/C++. This immediately rules out the vast majority of memory-safe languages. What is left is pretty much only Zig and Rust. Both have their pros and cons, but Rust seems to be more mature and has better community adoption.
The way I see it, the pro-memory-safety crowd is saying "There's a giant hole in our ship, let's use Rust to patch it", and the anti-Rust crowd yells back "I don't like the color of it, we shouldn't repair the hole until someone invents the perfect solution". Meanwhile, the ship is sinking. Do we let the few vocal Rust haters sink the ship, or do we tell them to shut up or show up with a better alternative?
> Garbage collection is a huge dealbreaker for the people still on C/C++.
The problem is not so much GC itself, but more like pervasive garbage collection as the only memory management strategy throughout the program. Tracing GC is a legit memory management strategy for some programs or parts of a program.
The reason memory safety is interesting in the first place (for practical, not theoretical reasons) is that it is a common cause of security vulnerabilities. But spatial memory safety is a bigger problem than temporal memory safety, and Zig does offer spatial memory safety. So if Rust's memory safety is interesting, then so is the memory safety Zig offers.
I'm a rabid software correctness advocate, and I think that people should acknowledge that correctness, safety (and the reasons behind it) are much more complex than the binary question of what behaviours are soundly disallowed by a language (or ATS advocates would say that from that their vantage point, Rust is just about as unsafe as C, and so is completely uninteresting from that perspective).
The complexity doesn't end with spatial vs temporal safety. For example, code review has been found to be one of the most effective correctness measures, so if a language made code reviews easier, it would be very interesting from a correctness/security perspective.
I’ve written a good chunk of low level/bare metal rust—unsafe was everywhere and extremely unergonomic. The safety guarantees of Rust are also much weaker in such situations so that’s why I find Zig very interesting.
No oob access, no wacky type coercion, no nullptrs solves such a huge portion of my issues with C. All I have to do is prove my code doesn’t have UAF (or not if the program isn’t critical) and I’m basically on par with Rust with much less complexity.
No it is not. We have a lot of amazing and rock solid software written in C and C++. Stuff mostly works great.
Sure, things could be better but there is no reason why we need to act right now. This is a long term decisions that doesn't need to be rushed.
> What is left is pretty much only Zig and Rust.
We had Ada long before Rust and it is a pretty amazing language. Turns out security isn't that important for many people and C++ is good enough for many projects apparently.
There is also D, Nim, Odin and so on.
> Garbage collection is a huge dealbreaker
It isn't. We had Lisp Machines in the 80s and automatic garbage collection has vastly improved these days. So I wouldn't rule those out either.
In short, no the ship is not sinking. There are many options to improve things. The problems is once you depend on rust it will be hard to remove so it is better to think things through because rushing to adopt it.
> The Debian infrastructure currently has problems with rebuilding packages of types that systematically use static linking. With the growth of the Go and Rust ecosystems it means that these packages will be covered by limited security support until the infrastructure is improved to deal with them maintainably.
My first thought is that it is kind of like talking about gradually improving manual memory allocation in Java. C and C++ are fundamentally memory unsafe; it's part of their design, to offer complete control over memory in a straightforward, direct way.
Really? As opposed to e.g. C or C++ (as the most important languages which Rust is competing with)? Sure, taste plays into everything, but I think a lot of people work with Rust since it's genuinely a better tool.
I hear you on free software being controlled by corporate interests, but that's imo a separate discussion from how good Rust is as a language.
It seems like Ada more or less has to have memory safety bolted on -- that is what SPARK does -- and it's not clear that Ada's bias towards OO is better than Rust's bias towards functional programming.
Are you talking about features like type inference (so the Rust code could be less clear, since types are not always written out)?
you see, GP did not speak in relative terms, but absolutely: They believe Rust has problems. They did not suggest that problems with programming languages are basically all fungible, that we should sum up all problems, compare different languages, and see which ones come out on top.
Of course most people aren't smart enough for the language so they have to use inferior algol languages like rust.
I'll wait.
