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