rustc 1.32.0 as-of Sat, 19 Jan 2019
Here are the points:
1 - there's a ton of existing c++ programs
2 - other have tried replacing c++ and failed (D for instance)
3 - no one will use Rust until it has cool IDE stuff and production ready libraries: a chicken and egg problem that Go was able to solve with Google support.
4 - rust is not that fast
5 - c++ has all these static and dynamic sanitizers which makes rust not that safer compared to c++
6 - if 90%/10% rule true, you could write most of your code in Go/Java and the hot parts in C, instead of most code in Rust and hot parts in unsafe Rust.
7 - premature optimization "rant"?
8 - language verbosity complains around pointers (Box Rc, Arc)
9 - a few more reasons in conclusion, including issues with cargo pulling out code from git repos
The first 2 points are really bad arguments in my opinion, it's easy to see by imagining people saying this at the peak year of Fortran: "there's a ton of existing Fortran programs, other have tried to replace Fortran and failed" edit: (forgot to finish sentence) therefore, this new C language will never succeed
3 - I agree that community backing is very important, but in this case: Mozilla use of rust, and Google writing an entire OS in rust seems to prove that rust has a chance.
4 - this one chart used as evidence isn't very conclusive
5 - a language with that safety built-in the compiler itself is better in my opinion. I've read mixed reviews on the effectiveness of the c++ analysers.
6 - first I didn't think that unsafe Rust was there for that hypothetical 90%/10% rule, but more for interacting with unsafe libraries in C/C++?
Second, even if that was true a mix of 2 languages completely ignores the marshalling needed between the two languages?
7 - ?? Not sure what the point was here
8 - one could complain similarly about verbosity in c++ templates. It would be sure nice to have some tooling support to refactor code if in such a situation of using the wrong pointers, but: do people really end up in a situation of 'Vec<Rc<RefCell<Box<Trait>>>>' ?
Also, how's it different from making mistakes with "const" keywords in c++ and having to change the const qualifiers everywhere. Programmers mistakes will happen in any language, the more strongly typed , the less forgiving the compiler will be.
9 - cargo concerns could be valid, but c++ doesn't even have a cargo equivalent yet?
And they'd be right: At work, even our Android app written this year contains a huge amount of Fortran via scientific libraries.
For instance the amount of Fortran code and libraries in 1979 was probably order of magnitude bigger than the amount of C code. Was there more general purpose language that C was competing with back in the time?
I guess picking C as the old language and C++ as the new would have make the example clearer :)
But yeah I agree, and believe Fortran is still being used heavily in scientific computing!
Plenty of Algol and PL/I variants.
C had an almost free OS with source code going for it, had UNIX been a commercial offering right from the start with a price tag similar to systems like OS/360 or VMS, and the outcome would have been completely different.
Although personally I don't think being a better C++ is the direction D should be going for (I'd rather see it going in the direction of lower level Java/C#).
While being merged into GCC mainline is an huge success for any programming language, D is still kind of looking for its space and competition is getting stiffer.
I thought Rust was pretty competitive with C++ in this respect?
The article questioned whether Rust's design made sense. It looks like it's holding up. Major pieces of software have shipped. Projects analyzing language's soundness have found some bugs in libstd, but not any fatal flaws yet.
The article complained about Rust's speed. In the benchmarks game it used to be on par with Go, now (as far as the game goes) it's clearly faster than Go, Java, Fortran, Ada and Swift.
The article questioned whether anyone sane would write web servers in Rust. There are some nice web frameworks now. AWS officially supports Rust in Lambda. Futures-based ecosystem for async programming is growing. It's getting there.
The predicted huge mess of crates.io hasn't happened yet. crates.io is lucky to have npm a few steps ahead of it, so it can proactively prepare for growing pains that are coming.
The 2018 edition has shipped a new borrow checker that's easier to work with, more powerful and properly namespaced macros.
Of course C/C++ isn't going anywhere, but it looks like Rust is here to stay, too.
> Rewriting it is way, way too expensive, risky, and, honestly, doesn't seem to make sense except in the heads of the most frantic Rust fans.
I've met hundreds of rust developers at this point and at no point in conversation has anyone ever expressed that we should be working to rewrite every C++ project in Rust.
> for example Vala, Cyclone, Limbo, BitC. How many of you have even heard of these languages?
I'm aware of Cyclone and Vala, not the other two. Vala isn't even a little memory safe, so not sure why it's mentioned. Cyclone was a research project from my understanding, and that's it.
> By the way, most of the critics have never seen C++ code in production.
> Rust is safe indeed but, unfortunately, far from fast. By the moment of writing this article, it is comparable to Java, Go, and Haskell regarding performance:
Old benchmarks, no discussion of why those benchmarks are the way they are. Benchmarks without analysis are just meaningless charts. Old benchmarks are even worse.
Here's the up to date benchmarks.
> or if it is automatically doomed to be twice slower than C/C++ because of the constant checks for array overruns, safe wraps of bindings to C-libraries, and other stuff like that.
There are a lot of really interesting reasons why Rust is slower in some benchmarks, like lack of constexpr or int generics, which at least one C++ benchmark uses heavily.
> But these are actually two dialects of one language, which doesn't look much different from the "Java + C" or "Go + C" combos.
Practically, there is a world of difference, given the lack of 0-cost FFI in eithe rof the mentioned languages.
The rest of the article is just disconnected conjecture, I stopped reading. If anyone thinks there's value to finish it though, let me know, I'll circle back.
edit: It occurs to me that I'm not reading "The next in a series" but actually an extremely dated article that wasn't accurate in 2015 and isn't accurate now.
So the reason Rust is slow is because C++ has features that allow programmers to write faster implementations of the same algorithms? I think that's the point he is making.
His point was that fundamentally Rust will have overhead by being safe, and that it's necessary to drop into unsafe to match the performance of C++.
He takes this further, stating that if you're going to drop into unsafe for hot code, why not just use Java/Go and FFI into C++.
This is misleading or incorrect for a few reasons.
* Rust isn't considerably slower than C++ (again, the benchmarks are total nonsense and way out of date)
* The performance differences are not a matter of safety features (such as bounds checking array accesses), but separate features like constexpr, int generics, and SIMD.
* His statement on Go/Java ignores that Go and Java will pay a significant cost for calling out to C/C++ for the "hot code"
As an aside, Rust now has explicit SIMD, and there's progress being made on `const fn` (the contexpr equivalent) and int generics.
Embedded, unfortunately, is not a good canary. I still program all of my devices with C and not C++. C++ simply brings nothing to the table for the end user of an embedded device (<1M flash; <256K RAM). Development productivity on those platforms is gated by way more factors than choice of programming language.
Actually game developers tend to only switch when forced to do so via the SDKs of the platforms they have to target for their business.
It was so during all the transitions that already took place.
Assembly -> C/Pascal/AMOS, C/Pascal/AMOS -> C/C++, C/C++ -> C++/C#/Blueprints/Swift/Objective-C/Java
So there is already an ongoing slow movement regarding D, C#, Rust and eventually Jai, but there needs to be a catalyst from a few well known names in the industry for it to take place, like all those before.
Chucklefish’s new game is in rust.
EA: SEED has been using it.
Some people left SEED and started a new AAA studio (Embark) that’s all Rust.
Ready At Dawn has moved all development over and has even been releasing some open source. Their CTO has said some really nice stuff on Twitter, repeatedly.
Other rumblings and rumors.
We’ll see! Exciting times.
Or rather, many game developers already switched to C#. Most every major engine has C# bindings to some degree.
There are a few well known former developers from Insomniac Games working on the project.
When Rust approaches and gets an IDE like Segger/Rowley, KEIL, IAR, etc then I’ll beleive it’s happening. But currently supporting a few old chips and the cargo package system having some ambiguous entries for other chips tells me it’s not close yet.
It's a myth that garbage collection is slow, and it's furthermore a myth that manual memory management is easy. So C (and, to a lesser extent, C++) will continue to lose ground for new projects to languages that take the requirement to manage memory off the programmer.
Furthermore, while C and C++ require low-level attention to detail in managing memory, they prohibit many low-level manipulations that you might want to use them for, if you're implementing e.g. an operating system kernel or a language runtime, by assigning them 'undefined behavior'. The C or C++ abstract machine, according to the actual language standard enforced by the compilers, is not noticeably closer to even the PDP-11 abstract machine than, say, Haskell's. (Haskell also has raw pointers, it also allows arithmetic on them, it also allows them to be converted to and from integers, and, in practice, any portable, defined-behavior low-level C code is going to end up using operations remarkably similar to what Haskell allows.)
So C (in particular) is too low-level for application code, but too high-level for system code; there is no realm where C is advisable for a new project. That leaves maintaining existing programs.
The problem here is that C and C++ long (10 years or more) ago abandoned the original X3J11 mandate to 'keep most existing programs working', in favor of aggressively using undefined behavior for optimizations. You can't keep breaking your existing programs without convincing some of their maintainers that re-writing in a new language is a better option, and without new programs that means that C and C++ will, inevitably, die, when the last program written in them is either abandoned or re-written after the compilers (yet again) break them with a new 'optimization'.
Aren't most systems written in C?
Multicore vector based CPUs with branch prediction, GPGPU, NUMA architectures....
Some of those features are exposed as compiler intrinsics or C dialects for GPGPUs (e.g. OpenCL).
However none of those features exist in the abstract hardware model of ISO C.
It's like gasoline and oil. Both will always be the dominant energy paradigm because of ubiquity and because of habit.
Also if you look at the C code, the multi-threaded optimizations are quite hard to write in C, while Rust has Rayon (which is not yet used in the Benchmarks game examples).
Yes it is!
Since or before May 11th, 2017 —
I guess the fanboys will complain for me calling Rust unsafe. You can write "safer" programs in Rust just like you can in C++. They are however not as fast as those using unsafe parts of the language. You will never get the same kind of total safety as you get in, say, Python because Rust doesn't do overflow checking. It does in debug mode, but you are strongly encouraged to distribute binaries in release mode since the speedup is substantial.
Offering safety and programming ergonomics for performance is a crappy trade.
I'd say more people have had to jump into "unsafe" Python than have had to jump into "unsafe" Rust.
As for overflow checking, that won't lead to unsafety on its own, just panics (it's defined to wrap in release).
Your post conflates all sorts of issues and lacks nuance.
A wrap around on its own can not cause unsafety in rust, only panics.
As in, maybe you try to use the wrapped integer as an array index, that's still safe even if it wraps (because Rust bounds checks).
It would only case memory safety when used alongside code in an unsafe block.
> The author says that it is very hard not easy to exploit C libraries loaded by Python.
I drew a different conclusion from that section
You are either misinformed or do not know what safety means. Integer types in Rust in release mode wraps around and that can lead to consequences much worse than crashing. Programs doing the exact opposite of what they were intended to.
Now I see that you are talking about MEMORY safety which I'm not. Writing safe programs includes so much more than just memory safety.
> I drew a different conclusion from that section
I have not seen a single CVE about the issue.
Yes, what rust claims is memory safety, not safety from all forms of bugs. If you don't want wrapping integers, you can compile with a flag to panic on overflow, or use types in std that will have the behavior you want.
> I have not seen a single CVE about the issue.
That's part of the point of the article. CVEs are rarely filed for memory safety issues in the underlying C libraries that make up the Python ecosystem.
Which was the point! High level languages have many more safety features than Rust have, such as non-wrapping integers. Trading those features for performance is foolish.
Claiming Rust or any other low-level language is on an "equal footing" with Python or any other high-level language because you have this and that feature is facetious. In C you can write your own types with bounds checking and even your own garbage collector to make your programs memory safe. Using dumb arguments like these we can claim C is as safe as Python. But the arguments are dumb because that is not how programs are written in the real world.
In the same way, claiming Rust is as safe as Python because it has a flag (that no one uses because it makes your programs twice as slow!) to perform wrap around checking and types in the standard library with correct behavior is dumb. It is what happens IN PRACTICE that matters.
Funny you should say that, because when you compile Rust programs in debug mode (e.g., how most tests are run), then overflow results in a panic. This isn't foolproof, but that's what "in practice" means. For me, overflow bugs tend to be caught in tests.
You're getting too hung up on one specific point (integer wrapping) and being too bombastic about it. Consider other facets of safety such as exception safety, data races and ownership.
Someone needs to write the unsafe code so that the safe code can execute on top of it.
And the first hypertext based software was developed at Xerox PARC, which also did not use any Bell Labs languages.
For Python and Ruby, it is a matter of someone actually taking the effort of doing it, which no one does because it would only be proving a point that anyone with major in compiler design already knows it is possible, just with lots of hard work.
I don't care about Ruby or Python, both toy languages.