[bayindirh]

Many of the Rust "evangelists" thinks/behaves like Rust's guarantees are absolute and leads to absolutely unbreakable software by default, and advocate that the language is the silver bullet combining abilities of C, C++ (depending on application) without any of their downsides.

When you hit a limitation you really need to implement in Rust, they say "Hey, there's unsafe{}, use that". Also, they advocate that unsafe{} is equal to C/C++ in programming freedom, which is again not.

When they're reminded that reality is not like that, they get upset and defensive. This comment is a nice flag to remind this reality.

I congratulate Rust for being what it is, but it's not a silver bullet and it's not the next C or C++. It's just a very nice programming language for various applications.

Being all shiny-eyed doesn't work in CS or programming in general, and also hardware doesn't work like that (a deterministic, perfectly good behaving, spec-obeying magic box with some included smoke for higher performance).

[pizza234]

> Many of the Rust "evangelists" thinks/behaves like Rust's guarantees are absolute and leads to absolutely unbreakable software by default

Can you point to (high-profile) evangelists that actually push this view? I think the people you refer to are a loud minority of developers who possibly don't even write professionally in Rust. I've never read or heard this position from experts.

[bayindirh]

While the people I talk with are not high profile evangelists, all of them are using Rust in their professional life for work.

Maybe the messaging should be clear, and hype should be better controlled from top to bottom, because I never talked with anyone who doesn't casts stones to C & C++ and badmouths it while saying that Rust is the one, and only, and the last savior we need.

BTW, I'm not against Rust, but I don't use LLVM. I'm waiting gccrs to dive into the language.

[pjmlp]

> I never talked with anyone who doesn't casts stones to C & C++ and badmouths it while saying that Rust is the one, and only, and the last savior we need.

So here is one, Ada was already that saviour in 1983, and in every use case where using a GC is an option, there are already plenty of options besides Rust.

Also until Rust compilers get fully botstraped, knowing C++ is a requirement to contribute to the compiler's backend.

[c-cube]

Ada is cool, but as far as I understand it doesn't give you memory safety in the presence of dynamic allocations? Unless you use recent improvements to spark? It's hardly a superset of the safety features rust has.

[pjmlp]

It surely does, RAII exists since Ada 95.

https://www.adaic.org/resources/add_content/docs/95style/htm...

You are not supposed to call Ada.Unchecked_Deallocation() directly, rather from Ada's version of "Drop".

Then SPARK allows for formal proofs that one actually does the right thing, integrated into the language as of Ada 2012.

The cherry on top of the cake is that the language is also getting affine types on top of the already battle tested features in 40 years of production deployment into high integrity systems.

[c-cube]

Who said anything about RAII? Having RAII doesn't make C++ memory safe. If you can take a reference or pointer to some RAII-created vector, and access it after the vector is gone… then you're not memory safe?

Yes, SPARK exists, and is very cool. I think there's work on a similar system for rust (or ferrocene, anyway, which is being co-developed by AdaCore: https://blog.adacore.com/adacore-and-ferrous-systems-joining...). It also seems that SPARK now has memory ownership and aliasing support, but only since ~2019 (https://blog.adacore.com/using-pointers-in-spark), and with clear inspiration from rust. It seems to me that this addition to SPARK was felt necessary by the AdaCore people, meaning that rust had something Ada did not support (or did not support well).

[howinteresting]

Has Ada ever been the most loved language on the Stack Overflow developer survey for seven years in a row?

There are plenty of options besides Rust, but none that have & and &mut which eliminates many classes of bugs in both multithreaded and single-threaded code.

[pjmlp]

Stack Overflow did not exist during the first decade of Ada's existence, nor there was a free beer compiler for it.

[pizza234]

> because I never talked with anyone who doesn't casts stones to C & C++ and badmouths it while saying that Rust is the one, and only, and the last savior we need.

I do definitely cast stones on C/++, especially considering that a C project I've rewritten in Rust uncovered several memory safety issues from the very first run. Another C project I've approached also showed C-specific issues from the very beginning.

On the other hand, I don't define Rust and the savior and so on; to be specific, memory safety is a very serious issue, but not the only one, and memory safe languages solve a very serious issue, but not all the issues. Additionally, I think Rust is a niche language; other memory safe languages may be more productive for the majority of the use cases ("webcrap", like a famous software engineer described :)).

Now you know one!

[howinteresting]

I mean I'd personally rate the opinion of people who actually use Rust higher than people who don't.

Rust isn't a silver bullet but it does shift the balance materially.

[falkaer]

I'm curious, why not use LLVM?

[bayindirh]

I'm a big GPL advocate, and publish I everything I can publish under GPLv3. Also, I want the code I publish to be able to be built with openly available tools. In other words, I want my software to be free and can be easily reproduced/built. This is the first aspect.

Second aspect is I don't like the behavior of LLVM ecosystem which is trying to subtly EEE gcc toolchain.

Lastly, I don't desire to be able to build a project I developed, or cloned to be only can be built with "clang/llvm/20201024+somecompanyClosedGitBuild20210514+bp1" which is available in binary form for a single distribution for a specific architecture. I have experienced SDKs and other software like that, and I don't want to go through again, or put anyone through that hoops.

[dralley]

> Second aspect is I don't like the behavior of LLVM ecosystem which is trying to subtly EEE gcc toolchain.

As opposed to GCC, which not-very-subtlety added extensions onto C which hurt portability?

GCC really shot themselves in the foot by making their architecture so difficult to use as a library, even from GPL code.

[sebzim4500]

>Many of the Rust "evangelists" thinks/behaves like Rust's guarantees are absolute and leads to absolutely unbreakable software by default, and advocate that the language is the silver bullet combining abilities of C, C++ (depending on application) without any of their downsides.

Where are these people? I'm not doubting that they exist, but I've never come across one and I've been in the rust community for several years now.

[howinteresting]

This is misunderstanding the point of unsafe.

All memory-safe languages in existence have safe abstractions built around unsafe code. For example, most JavaScript runtimes are written in C++. The point of unsafe Rust is to be able to use the same language to write both safe and unsafe code.

On the flip side, almost all C and C++ is unsafe code. The point of unsafe Rust is to be able to reserve brainpower for small subsets of code while having a relaxed posture towards most of it.

[ladyanita22]

> When you hit a limitation you really need to implement in Rust, they say "Hey, there's unsafe{}, use that". Also, they advocate that unsafe{} is equal to C/C++ in programming freedom, which is again not.

I'm interested. How does rust unsafe give you less freedom than let's say c or cpp?

[steveklabnik]

Rust's unsafe still needs to uphold the rules of safe Rust. It's not a license to just do whatever you want.

There are often ways to do whatever you want, but it's not as simple as "I have a raw pointer now let's goooooo."

I'd describe it as different, not "less", but I wasn't the one who said it originally.