Wasn't Rust supposed to be the language that should be used to write all security-critical software? What happened? Are crates like rustls/ring still intentionally sabotaging Rust's cryptographic ecosystem with their "we will always be pre-1.0.0 and never have a stable API" philosophy?
What does "supposed" mean in this case?
There's no one dictating what language "security-critical" or other software will be written. So, if it was "supposed", it was incorrectly supposed, by people reading some enthusiast posts about Rust and thinking it's adoption is inevitable or that it applies to everybody.
In real life, some went with Rust, others chose Go, and others C++, Java, etc.
>Are crates like rustls/ring still intentionally sabotaging Rust's cryptographic ecosystem with their "we will always be pre-1.0.0 and never have a stable API" philosophy?
That could help, but whether Rust has stable crypto crates or not, wouldn't change the fact that teams and projects will use what they wanna use, which is not necessarily Rust.
Just because some enthusiasts went "Rust all the things!" doesn't mean others will follow them.
"Sooo many" compared to what? Did you scrutinize the equivalent of Java's SDK in Rust + extra crates to get the same functionality?
Do you include things like unrelated package bugs, like log4j bugs?
Java exists today because of corporateware. Outside of it, it's dead. De-ad. No one uses Java seriously for emulators, browsers, or basic software. Just ad-hoc company-graded enterprise, live VB6 back in the day.
For starters, Java is by no means used just in "corporateware", if this means some intranet stuff. It's also hugely dominant in server side development (including FAANG) and is used by tons of startups, it's big in banking, high frequency trading, and all kinds of heavy service infrastructure.
That covers the huge majority of programming work, not writing "emulators and broswers" (sic), which is why it's in the top 5 of the TIOBE index.
"GUI libraries" have little to do with, not to mention they're generally irrelevant for most modern programming use cases, which is server/backend or web-based (and where they're not, they're already provided by the host OS and its preferred SDKs).
Also "Hyperbola GNU/Linux"? That yardstick of what's secure?
I know that if you were to work in any company, Java would ve everywhere, but today the times changes. Even the Crustacean lang it's preferable againt Java on big backends. On the ligther workloads, Golang works great and it solves the multiplatform issue by crosscompiling from anywhere to anywhere.
In any case, there's some serious lack of seriousness in the above. I mean, Java "not so performant against the new iterations of C# or even PHP >7"?
Personally I’m not a fan of batteries included languages because they inevitably suffer a Python heat death if standard libraries as the ecosystem improves faster without the baggage standard libraries carry intrinsically.
Hence, IMO the fact std provides a highly common and simple layer and external crates provide opinionated ergonomic interfaces is a feature, not a flaw, of rust. The crate ecosystem in rust is exceptionally good.
Go uses garbage collection, while Rust uses manual memory management with borrow-checking to ensure safety. Both are just as safe, but garbage collection is slower while Rust's manual memory management requires a lot more effort on the part of the developer. In particular, the performance of garbage collection is less predictable, making Go unsuitable for things like audio processing or video games, where you need to reliably deliver data every few milliseconds to avoid crackling audio or weird glitches. In Rust, you can predict exactly when memory will be freed, and if part of your code must always run in a predictable amount of time, this can be done. Go doesn't give you that guarantee. This isn't very important in traditional client-server apps, CLI tools etc, so go is usually fine for those.
In addition, Go requires a runtime, which is somewhat heavy. This makes it pretty unsuitable for kernels, software that runs on bare metal, microcontrollers etc. Rust doesn't have that problem.
However, Go is usually much faster to write in, as you don't have to worry about managing memory and proving to the borrow checker that you're doing it correctly. The fact that you have Goroutines instead of OS threads also makes it easier to handle lots of concurrent activities, like in a web app that concurrently handles many requests.
I feel like you’re confusing rust with c/c++ in this discussion.
I don’t find go faster to write in at all. I feel like they’re about the same, but I find go package management to be a mess and prefer cargo. Rust however does require you to be more aware of memory lifetime and ownership, and provides generally better performance in exchange.
With a single execution context this is true. But, whereas you simply can't write data race bugs in Safe Rust† in Go you can write them and they blow up your safety guarantees. If you race something trivial Go promises (unlike C or C++) that this doesn't immediately set fire to the world, the raced trivial object (say, an integer) is ruined and you must not touch it, but if you stay away from that object your program has clearly defined behaviour. Unfortunately non-trivial objects (say, a slice) are immediately Undefined Behaviour when raced.
† This falls out of the mutability rules. A data race is when somebody else modifies something at "the same time" as you're using it, e.g. thread A changes actor to "Steve Buscemi" from "Susan Sarandon" at the same moment thread B is printing the actor out and oops, we write "Susan Sarcemin" or crash or something different happens, who knows. Rust says you can't have multiple aliases and mutability, so this never happens.
That said, I'm not sure why developers freak out over races so much. Races that result in simple display of data that's one nanosecond old is typically not a failure condition in most applications. Actual failure conditions from races are usually from read-operate-writes like increments/decrements/etc. And for these, we have tons of solutions, anywhere from atomics to transaction contexts to CRDTs, etc.
In all languages if you cause a data race you lose Sequential Consistency. Java's experience teaches us that even if you go to extraordinary lengths to ensure that everything else is still fine, programmers cannot reason about non-trivial software without Sequential Consistency and so now they can't fix it. In something like C or C++ all races are Undefined Behaviour, all bets are off. In Go as we saw some data races aren't immediately dangerous but even if you're careful you do lose Sequential Consistency and so good luck doing anything when you don't understand what your program means any more.
> And for these, we have tons of solutions
If you put the solution in place and thus prevent a data race, you don't have a data race. Now, when was the last time you wrote a program in which you got everything right first time?
I wasn't thinking specifically about Go for this example, but alas Go's strings aren't trivial objects, and so this data race would be immediate UB in Go, whereupon "Susan Sarcemin" while still very unlikely is not impossible. The text (underlying rune slices? really? I guess that would be on brand but it's a bad idea) isn't getting mutated, but your string typed value is, and that is a non-trivial object.
I don't necessarily disagree with you about C/C++ (or even Brainfuck) but some languages have the tendency to push you in the right direction and I've come to appreciate those more with time.
You can write memory unsafe code in rust, including memory management if you want - you just have to wrap it in unsafe which at least clues others in to watch this area carefully. In C++ you can put unsafe code anywhere. Sometimes unsafe is really needed, rust makes it hard enough to write unsafe code that you will only do that where you must and then jump back to safe code. In C++ you are likely to mix safe and unsafe code all over and that makes audits harder.