6 ms·

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.

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?
- brobdingnagians 8y ago
  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.
  - fhrow4484 8y ago
    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!
    - pjmlp 8y ago
      > 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.
  - stochastic_monk 8y ago
    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.
- ori_b 8y ago
  >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.
saagarjha 8y ago
> rust is not that fast I thought Rust was pretty competitive with C++ in this respect?
- fhrow4484 8y ago
  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 https://news.ycombinator.com/item?id=18949036
- gameswithgo 8y ago
  it always was, but at the time the article was written simd instrinics were missing.
- htfy96 8y ago
  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.
gameswithgo 8y ago
3 is better now with RLS 4 isn't true anymore

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?

brobdingnagians 8y ago
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.
- fhrow4484 8y ago
  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!
  - pjmlp 8y ago
    > 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.
- stochastic_monk 8y ago
  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.
ori_b 8y ago
>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.

saagarjha 8y ago

> rust is not that fast I thought Rust was pretty competitive with C++ in this respect?

fhrow4484 8y ago
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 https://news.ycombinator.com/item?id=18949036
gameswithgo 8y ago
it always was, but at the time the article was written simd instrinics were missing.
htfy96 8y ago
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.

gameswithgo 8y ago

3 is better now with RLS 4 isn't true anymore