7 ms·

Rust Language, and Why C/C++ Will Never Die (2015)

71 points by ghosthamlet 8y ago

winterthedeep 8y ago
(2015)
kibwen 8y ago
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.
- xiphias 8y ago
  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).
  - igouy 8y ago
    > 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/faster/rust.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
staticassertion 8y ago
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/which-programs-are-fast.html 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.
- deleted 8y ago
  [deleted]
- yholio 8y ago
  > 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.
  - staticassertion 8y ago
    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.
  - achamayou 8y ago
    Rust has const fn, which are very similar to constexpr (although the limitations aren’t quite the same).
fhrow4484 8y ago
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
- skocznymroczny 8y ago
  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#).
  - pjmlp 8y ago
    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.
- fhrow4484 8y ago
  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?
xiphias 8y ago
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).
- igouy 8y ago
  > 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://benchmarksgame.alioth.debian.org:80/u64q/program.php?test=mandelbrot&lang=rust&id=4 https://web.archive.org/web/20170511062152/http://benchmarks...
IWeldMelons 8y ago
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.
crimsonalucard 8y ago
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.
- maxxxxx 8y ago
  "Never" and "always" are dangerous words. Things sometimes change very quickly.
- deleted 8y ago
  [deleted]
bsder 8y ago
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.
- overgard 8y ago
  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.
- pjmlp 8y ago
  > 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.
- SlowRobotAhead 8y ago
  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.
brianberns 8y ago
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.
pornel 8y ago
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.
bjourne 8y ago
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.
- staticassertion 8y ago
  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-corruption-bug-19dde4d5fea5?gi=f6ad2dd2d987 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.
  - bjourne 8y ago
    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.
    - staticassertion 8y ago
      > 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
jonathanccast 8y ago
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'.
- solarkraft 8y ago
  > C is too high-level for system code Aren't most systems written in C?
  - pjmlp 8y ago
    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.
faget 8y ago
u gay

71 points by ghosthamlet 8y ago

(2015)

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.

xiphias 8y ago
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).
- igouy 8y ago
  > 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/faster/rust.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

staticassertion 8y ago

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/which-programs-are-fast.html 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.

deleted 8y ago
[deleted]
yholio 8y ago
> 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.
- staticassertion 8y ago
  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.
- achamayou 8y ago
  Rust has const fn, which are very similar to constexpr (although the limitations aren’t quite the same).

fhrow4484 8y ago

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

skocznymroczny 8y ago
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#).
- pjmlp 8y ago
  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.
fhrow4484 8y ago
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?

xiphias 8y ago

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

igouy 8y ago
> 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://benchmarksgame.alioth.debian.org:80/u64q/program.php?test=mandelbrot&lang=rust&id=4 https://web.archive.org/web/20170511062152/http://benchmarks...

IWeldMelons 8y ago

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.

crimsonalucard 8y ago

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.

maxxxxx 8y ago
"Never" and "always" are dangerous words. Things sometimes change very quickly.
deleted 8y ago
[deleted]

bsder 8y ago

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.

overgard 8y ago
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.
pjmlp 8y ago
> 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.
SlowRobotAhead 8y ago
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.

brianberns 8y ago

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.

pornel 8y ago

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.

bjourne 8y ago

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.

staticassertion 8y ago
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-corruption-bug-19dde4d5fea5?gi=f6ad2dd2d987 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.
- bjourne 8y ago
  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.
  - staticassertion 8y ago
    > 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

jonathanccast 8y ago

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

solarkraft 8y ago
> C is too high-level for system code Aren't most systems written in C?
- pjmlp 8y ago
  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.

faget 8y ago

u gay