Rust Language, and Why C/C++ Will Never Die (2015)(viva64.com)
viva64.com
Rust Language, and Why C/C++ Will Never Die (2015)
https://www.viva64.com/en/b/0324/
65 comments
Per HN guidelines, this article should have its publication year of 2015 in the title (the article itself seems to not include a date, but one can find the various submissions on Reddit where this was originally discussed). In fact, it's old enough that it even predates the Rust 1.0 release. I haven't gone ahead and read it in full again this time, since the irony of a company selling C++ static analysis software denouncing the utility of Rust is not lost on me, but it would be interesting to see someone with time on their hands go through and see how things have changed in the past four years. In my skimming I noticed it criticizing Rust's results on the benchmarks game, which indeed have improved to C++ levels since then.
benchmars game is great, but sadly not well maintained anymore. Rust has it's flaws, but it's not runtime speed (much more compilation speed, IDE support, distributed compilation support).
> benchmars game is great, but sadly not well maintained anymore.
?
rustc 1.32.0 as-of Sat, 19 Jan 2019
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
?
rustc 1.32.0 as-of Sat, 19 Jan 2019
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Wow that's a long article, I tried summarizing the main points. I think some of them have merit, but for the "technical reasons", I don't think I agree on most.
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.
Technical reasons:
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
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.
Technical reasons:
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
My biggest disagreement would be:
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?
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?
Not disagreeing, more curious, but isn't Fortran still in relatively common use in Scientific computing? I haven't gotten into that domain, but I guess it is probably far below where it was at it's peak. Maybe it is just that we are getting lots of languages good for certain niches, instead of one general purpose language dominating multiple niches.
It sure is. My colleagues in Mech E and atmospheric science all write fortran. I imagine this is common for technically proficient fields which aren’t computer science or engineering but still need efficient solutions, making starting from scratch in a more modern language prohibitively expensive.
Yeah, I'm not expert on Fortran use back in those time, it's just more used as an example of a language that at one point in time was much more popular than another.
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!
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!
> Was there more general purpose language that C was competing with back in the time?
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.
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.
>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"
And they'd be right: At work, even our Android app written this year contains a huge amount of Fortran via scientific libraries.
And they'd be right: At work, even our Android app written this year contains a huge amount of Fortran via scientific libraries.
D hasn't failed.
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#).
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#).
However due to market pressure from very important customers, Java and C# are getting better at low level programming, while enjoying the tooling and libraries.
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.
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.
> rust is not that fast
I thought Rust was pretty competitive with C++ in this respect?
I thought Rust was pretty competitive with C++ in this respect?
Yeah, that's one of my biggest disagreement with the author, there's more discussion about it in this comment thread from staticassertion: https://news.ycombinator.com/item?id=18949036
it always was, but at the time the article was written simd instrinics were missing.
I have to say that most "Rust is fast" articles I read stop at comparing microbenchmarks written with not much care on performance. I really want to see some comparisons in highly-optimized cases like linear algebra library (Eigen) or game engines with things like stack-local allocators or even using alloca() built upon EA STL/Folly.
3 is better now with RLS
4 isn't true anymore
Since 2015 Rust has grown and matured:
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.
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.
I'm reluctant to comment because the first iteration of this 'series' was fraught with blatant errors, from what I recall.
> 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.
Not true.
> 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.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
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.
> 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.
Not true.
> 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.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
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.
> 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.
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.
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.
Not really, no.
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.
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.
Rust has const fn, which are very similar to constexpr (although the limitations aren’t quite the same).
[deleted]
The question about C++ vs Rust boils down, to me, when the game developers finally decide to switch. Game developers are not wedded to languages, if something is 25% more productive they WILL use it. If game developers flip, Rust is going to displace C++.
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.
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.
> Game developers are not wedded to languages, if something is 25% more productive they WILL use it. If game developers flip, Rust is going to displace C++.
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.
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.
We have some small amount of this happening:
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.
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.
Game development isn't what it was ten years ago; better tools have basically reshaped how games are made. C# is a serious contender for most-used language in game development, because the gains in productivity thanks to related tools easily make the performance impact worthwhile. Besides, hot points can always be rewritten in something faster.
Or rather, many game developers already switched to C#. Most every major engine has C# bindings to some degree.
Or rather, many game developers already switched to C#. Most every major engine has C# bindings to some degree.
The latest news out of Unity is really interesting in this regard; they switched from C++ to a restricted subset of C# for their hot loops, in my understanding.
Yes, it's much like asm.js -- the code works as plain C# but can also be fed through their "burst compiler" to produce optimized native binaries: https://unity3d.com/learn/tutorials/topics/scripting/using-b...
Indeed, it is called HPC# and from what I understood during the interview with Miguel at Unite, Unity developers also contributed to the design of low level programming features from C# 7.x, and the ongoing ones for C# 8.0.
There are a few well known former developers from Insomniac Games working on the project.
There are a few well known former developers from Insomniac Games working on the project.
Well, it seems to me that a lot of developers that don’t really have a great in house engine aren’t super interested in starting one from scratch anymore unless they’re super constrained by what the current offerings are (UE4 or Unity or bitsquid or some open source alternatives). Almost all of those are going to box you into c++ with “scripting” coming from c#/lua/python/ or more c++. It seems hard to see how Rust makes a dent there significantly.
Embedded. That’s when I’ll beleive Rust has made it as Rust is a direct competitor to ubiquitous C in this area.
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.
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.
C (and, to a lesser extent, C++) absolutely will die. The way the languages are managed guarantees this.
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'.
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'.
> C is too high-level for system code
Aren't most systems written in C?
Aren't most systems written in C?
Modern computers aren't PDP-11 like anymore.
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.
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.
I think a more important question is whether Rust will supplant C++ for new development at some point. Obviously, no one is going to rewrite the existing C++ code base from scratch.
So basically C/C++ will never die because of ubiquity.
It's like gasoline and oil. Both will always be the dominant energy paradigm because of ubiquity and because of habit.
It's like gasoline and oil. Both will always be the dominant energy paradigm because of ubiquity and because of habit.
"Never" and "always" are dangerous words. Things sometimes change very quickly.
[deleted]
I do not like Rust, but the argument about the lack of a big corporation to back the new language does not seem to hold water.
The Rust - C++ speed comparison is sadly quite bad. On a modern machine, some of the benchmarks from the benchmarks game ran faster in Rust than in C++. It usually depends on the explicit / implicit vectorisation support, and a lot of it is taken care of by LLVM.
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).
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).
> Rust has Rayon (which is not yet used in the Benchmarks game examples)
Yes it is!
Since or before May 11th, 2017 —
https://web.archive.org/web/20170511062152/http://benchmarks...
Yes it is!
Since or before May 11th, 2017 —
https://web.archive.org/web/20170511062152/http://benchmarks...
(2015)
I really wish people would just forget about unsafe ("unsafe" as in Ruby is much safer) languages completely and embrace languages with safe run times. Rust, C, C++, Go and many more languages all need to "die" and be replaced with high-level languages; Lisp, Python, Ruby, Javascript, etc.
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 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.
Alternatively, Python could easily be argued as being radically unsafe compared to Rust, given the many, many libraries that call out to C and the ease of exploiting C libraries loaded by CPython.
https://hackernoon.com/python-sandbox-escape-via-a-memory-co...
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.
https://hackernoon.com/python-sandbox-escape-via-a-memory-co...
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.
Saying that wrap around doesn't lead to unsafety because "it is defined that way" is wrong. Wrap around is one of the leading causes of security issues in all software. Scroll down to the Quantifying the risk in the blog post. The author says that it is very hard not easy to exploit C libraries loaded by Python.
> Wrap around is one of the leading causes of security issues in all software.
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
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
> A wrap around on its own can not cause unsafety in rust, only panics.
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.
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.
> 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.
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.
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.
> 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.
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.
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.
> 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.
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.
> I really wish people would just forget about unsafe ("unsafe" as in Ruby is much safer) languages completely and embrace languages with safe run times. Rust, C, C++, Go and many more languages all need to "die" and be replaced with high-level languages; Lisp, Python, Ruby, Javascript, etc.
Someone needs to write the unsafe code so that the safe code can execute on top of it.
Someone needs to write the unsafe code so that the safe code can execute on top of it.
Indeed, however it is a big difference to write unsafe code in a code block that makes it explicitly to everyone, and having every line of code being a possible victim of 200+ UB possibilities, every string or array operation a possible memory corruption.
Is it possible to write an operating system or a browser if we forget about the languages you want us to forget about?
Not only it is possible, it has been done multiple times, the first OS written in a high level language was developed in 1961, about 8 years before any line of UNIX was written in Assembly.
And the first hypertext based software was developed at Xerox PARC, which also did not use any Bell Labs languages.
And the first hypertext based software was developed at Xerox PARC, which also did not use any Bell Labs languages.
And how, might I ask, are you going to write your runtime for all these safe languages?
Won't work for any of the languages mentioned. Somewhere underneath it all you need a runtime witten in a bare metal language
Source of your claim? Lisp compilers have been written in Lisp for the last 30 years or so.
I don't care about Ruby or Python, both toy languages.
I don't care about Ruby or Python, both toy languages.
Rust, Go, Lisp do have certainly bootstraped compilers, with the runtime also written with them.
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.
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.