The main problem with Rust is that it is thread safe, and that makes code and libraries very hard to write. Thread safety is a lot stricter than memory safety, and since it is easy to write single threaded memory safe modern C++ it gets hard to shift to Rust.

But if you want thread safety or mostly do data processing scripts then Rust is far superior, just that for many applications enforced thread safety is an anti feature since it makes your code way too hard to work with. If they could make ergonomic thread safe libraries for everything then great, but I really doubt it will ever happen as it is very hard to do.

> Programs written in Rust are empirically safer than programs written in C or C++.

But Rust defines safety as being safe from the kinds of errors that the Rust compiler is capable of making one safe from (buffer overflows, race conditions, undefined behaviour, etc).

If one if distracted by trying to satisfy the borrow checker, they might overlook a logical error. People have limited concentration, patience and perseverance and usually have to work to deadlines.

Rust is great for writing high-performance code, or code that needs to be parallelised within a single process. However if performance is not a concern then a statically typed language with a GC is usually a better choice.

The safety is limited to data races, not concurrency or parallelism problems.

True.

> Rust is no exception.

Also true.

> Nobody should derive any confidence from the language a product is written in.

This, on the other hand, is a non-sequitur, or at least it's too strong, because Rust can do things that C can't do: safe deterministic memory management and safe concurrency without data races. These things are not just available, they are the defaults in Rust. You have to go out of your way to get these things wrong. So, I wouldn't derive absolute confidence from an application being written in Rust. But I'd be willing to bet a whole lot that it has fewer memory bugs than an equivalent application written in C.

Dynamically-typed language with a GC, executing scripts via an interpreter will always be slower against a compiled, statically-typed language with no GC.

Unfortunately, this comparison is sort of unfair and is frankly "optimization" by using another language.

Well, here's the kicker. Nothing about rust forces you to use concurrency. Saying "Concurrency is bad, therefore rust is bad" makes no sense. There is nothing that forces you to spin off new threads in rust, just as there is nothing that forces you to spin off new threads in C.

In fact, it is pretty rich complaining about Rust's concurrency story while praising Go. A HUGE selling point to go was/is goroutines! The language was even given keywords for making concurrent actions!

At the limit, I think the performance benefits of rust are pretty clear. The performance ceiling of rust seems to be pretty unambiguously higher than that of Go, Python, C#, javascript, etc. But yeah - no contest on rust being way harder to learn and use. I’ve been programming rust for years now, but I still reach for typescript when prototyping because I still find it much faster when making prototypes. Especially when async is involved.

> This might simply be an indication that you were using the wrong tools in the first language. Most native languages (D, C++ etc...) have facilities to avoid unsafe behavior. Use them.

Can you give some examples of those tools? The “first language” I mentioned above was C. What equivalent does C have to rust’s memory safety? Or C++ for that matter? Are smart pointers in C++ that ubiquitous and good that memory corruption is a thing of the past?

I'm not sure that's a fair assessment.

Even if you didn't gain anything in terms of raw performance, the gains in performance predictability would probably still be enough for many applications.

Even if you didn't gain anything in terms of performance at all, the ownership semantics also give you good safety characteristics around concurrency, which would still probably be worthwhile for at least some applications.

That is one problem and i don't want to attack you. This is something Rust needs to work on! Rust is indeed a relatively hard language to learn and understand and it is not really clear from the beginning nor in the intermediate level if its worth the effort. I can only speak from an empirical standpoint. Time showed – to me and maybe i am the only one – that i have fewer bugs in general, especially in the late stage of development. Rust tends to feel a little viscid in the beginning but it catches up later where you don't try to find a race condition in a 100k cloc Program. Rust has a good way to reason about your program especially in a multi threaded environment. And this is where Rust is fundamentally different of what we – as programmers – have experienced in the wild. Yes there are many efforts in academia and research languages but non of them are used outside.

Rust does nothing new or has concepts that are not strongly researched in academia. Rust is trying to bring those findings into the wild.

In Rust practically nothing can throw null pointer exceptions or class cast exceptions. Rust don't let you express ill-defined semantics with multi threaded code – you can't have data races.

And this implies – of course – that the set of programs that you can write in safe Rust is smaller than in C/C++/Java/C# ... you can't possibly write programs with data races or dangling pointers / null pointers. Thus making like 60% of all CVE's (i pulled this number out my ____) impossible to write.

Rust can't prevent you from making logical errors but it can help you preventing various categories of bugs we see in the wild exactly now.

Rust has many problems of its own kind, but none of the ones you listed above. immaturity in its ecosystem due to its short lifetime, steep learning curve and many more. But it can deliver very well in certain disciplines today.

The same can be said in reverse. There are many, many C and C++ codebases that make design compromises and copy data unnecessarily so as not to be utterly hellish to maintain. People meme about "fearless concurrency" but it's true, with Rust you don't need KGB levels of paranoia and attentiveness to write parallel or reference-heavy code. I can write code in Rust I would never be comfortable writing in C/C++ because the language gives me the confidence to not compromise in those areas.

Maybe, there are better options out there these days for parallel and concurrent programs. Parallel programming in C and C++ is very fraught for the very reasons the parent brings up. There are so many footguns, starting from the fact that the favorite debugging method of C programmers, printf(), is not even thread safe.

It’s so bad that Rust markets as a feature “fearless concurrency”, capitalizing on the recognition that the prevailing emotional state of a C or C++ devs writing concurrent or parallel programs is one of fear.

And the very thing that makes Rust concurrency fearless over C and C++ is that borrowing and mutability are explicitly tracked. As we enter a world where over a dozen CPU cores are the norm, we are learning what works and what doesn’t in writing programs for these machines, and integrating those learnings into new languages.

It’s really not. That is a fringe benefit; there are a dozen other reasons to use Rust over, say, C++. The syntax is cleaner, there are async await semantics, locking is way better, destructors aren’t a dumpster fire, macros aren’t the wild west, there just isn’t as much cruft... and et cetera.

1. Rust doesn't force you to do manual memory management. Rust memory management is automatic by default and only if you really, really want to, you can do it manually.

2. Memory is not the only resource. The GCs in languages you listed only solve the memory management problem, but regarding the other types of resources, their ergonomics are often worse than C - you have to remember to close the resources manually and you get virtually no help from the compiler.

3. None of the listed languages address problems related to concurrency, e.g. data races. Ok, Haskell kinda avoids the problem by imposing other restrictions - by not allowing mutation / side effects ;)

4. Rust offers way better tools for building high level abstractions than Go, Python and Java. It has set a very high bar with algebraic data types, pattern matching, traits/generics and macros.

I think that's it in a nutshell.

I want to write a program in a language that allows modern programming construction... Cool: Python, Ruby, JavaScript (ES 6+), Haskell, Elixir

The language must be fast... OK, so maybe Java or C#?

I need to control the response times and can't have GC pauses. It needs to be really fast... Assembly!

Stop... OK, OK, you're kind of stuck with C or C++.

Sigh. I want a modern language that compiles to bare metal, doggone it. What should I do?

This is what Rust is. Memory safety without GC, and a modern language without an interpreter or runtime. Plus all the package management/build tool/library ecosystems that all those 1990s languages have. (Would you believe that Java, Ruby, and Python are all more than 20 years old and that Java is the youngest of the three?!?)

I would say that the biggest win of Rust, once you get past the data race freedom, is that Rust's overall design puts the CSP model front and center like Erlang and Go do, while C++ is built on mutexes, locks, and futures. The way to get started with concurrent programming in Rust is thread::spawn, Sender, and Receiver, which will take you far. But C++ doesn't even have channels in the standard library; it encourages you to dive headfirst into shared memory, which makes simple concurrency needlessly difficult.

Rust doesn't restrict you from using shared memory when you need to (and verifies that it's safe when you do). But Rust's libraries and ecosystem encourage you to design your apps in shared-nothing fashion first, and only to introduce memory sharing when you need it for performance. That's a much friendlier way to deal with concurrency than mutexes, locks, and futures.

I don’t think that it would be the point of rust — otherwise why not write Java, or a litany of GCd languages instead?

Rust is a low-level/systems programming language where you have more control over the program’s execution (e.g. no fat runtime), which is a necessity in some rare, niche, but important use cases.

Ironic because safe Rust can't express many valid programs, like those with cyclic data structures.

> Some parts of Rust are starting to remind me of the horror I ran from with C++.

Rust is most certainly designed for C++ programmers. C is all about minimalism and simplicity. I think there is a niche for a C like language with memory safety that retains the simplicity of C. Rust isn't it.

Yes, but that's the main allure of Rust. As for the rest (e.g. resource releasing, avoiding concurency issues, avoding not-exhastive mathces, injection, etc.), other languages have their own ways as well, including Java.

If those are your main concerns (and not also top-speed) I don't think Rust is worth the extra cost (learning slope, slow compilation times, single implementation, fewer libs and developer tools, etc).

Strictly speaking, no. But there are many ways that the quality of life of writing code is so much higher in Rust than C. A non-exhaustive stuff of just the things I've done in my most recent project:

* String handling. C's idiomatic string interface (i.e., null-terminated strings) is a dumpster fire of an interface that makes security vulnerabilities far more likely. And the set of string functions in the C standard library are a joke.

* For that matter, memory management. Sure, I can write malloc and free manually, and have to manually remember whenever I get a pointer whether or not I'm responsible for freeing it, or if the pointer is only valid until the next function call, or stuff like that. But scale that to 100KLOC, and the ability of programmers to remember all of those details turns out to shockingly poor. Meanwhile, in Rust, it's a compiler error if you get it wrong, rather than being a crash or worse.

* Asynchronous programming. Rust has built-in coroutine support; C does not.

* Better idiomatic error handling. Handling an error in Rust is very often just a single ? character. No more chance of gotofail!

* Newtypes, which are a godsend if you want to implement a parse-don't-validate strategy.

* Better threading support. Rust has a much richer standard library for writing multithreaded applications, and it provides much better compiler support for it (Send and Sync traits are absolute godsends for annotating what can and can't be used from multiple threads). And if you go out into common crates... rayon is a better way to do embarrassingly parallel code than OpenMP is, especially if you want to do fancy stuff like non-trivial reductions. (Side note: the first successful attempt at a multithreaded HTML rendering engine was written in Rust, and that's not for a lack of trying with C++ code. That is how much of a godsend Rust ends up being.)

I am by no means a member of the Rewrite-it-in-Rust brigade; I'm pretty sober about the costs of rewrites and the benefits you'd get from such a thing. However, I will say that Rust is generally a superior option than C/C++ if you're doing parsing code (which means you're dealing with untrusted input that you really want to be sure isn't going to go haywire on unexpected input). And for email protocols, where you deal with a lot of mixed binary and text in the same stream, Rust's string handling support is in a sweet spot, especially compared to most other safe VM languages which have different types for binary strings and text strings.

Also, knowing enough of the Thunderbird internals to know what code already does need to be rewritten, I'm fairly confident of where I can sensibly propose that things ought to be written in Rust in lieu of C++ or JS.