8 ms·

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

41 points by federicoponzi 10y ago

sickbeard 10y ago
I always chalked it up to the "I'm old" sentiment. There hasn't been a language that has actually caused us to think of writing a different kind of software. Sure we write nicer easier code but the software remains the same in the end, buggy, full of problems and not maintainable. These are the problems we should be solving.. the result of what WE code, not how pretty it looks in the ide.
lmm 10y ago
> Note: Further in this text, I am presuming that Rust is a conscious attempt to create a fast and safe language. After all, it was initially conceived by the guys from Mozilla as a tool to develop a browser engine. But if it proves to be yet another just safe language, then I just don't get the whole thing. There is plenty of very different safe languages to choose from to any taste, and if Rust is not meant to replace C++, then (1) why does it need to include an unsafe subset?; and (2) why did the authors throw away lightweight processes from Rust? They are convenient, after all, aren't they? In other words, if I'm wrong in my assumption, then the whole affair just doesn't seem to make any sense at all. > I sincerely hope that programmers will find a way to speed it up in time, but until then, it's going to be of hardly more interest than Scala or Go from the viewpoint of the safety/speed compromise. The question is still open if it is possible at all to make a language both fast and safe 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. If it ends up being a factor of 2 slower than C I really don't think that matters. The point isn't to be faster than Ada/Go/Scala/Java/Haskell/OCaml, it's to be as safe as those without GC - primarily for the sake of using it in a Javascript runtime and not having to run two GCs. > Anyway, in any serious project, you use a continuous integration system and run tons of tests when compiling builds. If you don't, then your troubles are much worse than the language's lack of safety because static typing doesn't guarantee correct execution logic! Guarantees are absolutely possible. Most practical programs don't guarantee everything in the type system, but test suites don't guarantee everything either. For a practical program where you have a certain acceptable defect rate, it's not at all clear that a large test suite will be a cheaper way to achieve that than a type system, and my experience is in fact the opposite. > Following its logic, we could rewrite 90% of WebKit or VirtualBox or GCC into Java and get the same result. But it is obviously wrong. Not at all obvious - I suspect not in fact wrong at all. > Well, it depends on the project scale. For Google, even a few percent may help save millions of dollars (see Section 5, "Utilization", in the paper). Or imagine that with a next update, JVM will suddenly start requiring 10% more resources! So maybe C++ is worth using at Google. Most of us aren't Google. > But if we want to follow it word for word, why not use bubble sort instead of quicksort in all of the code? Go ahead. See if I care. See if you care. 99% of the time, bubblesort really isn't a problem. (Not using library functions is a problem, so in practice this would never come up, but it really isn't a performance problem if you do end up using bubblesort) > After all, who will dare to argue that finding a hot spot, rewriting the code (perhaps tons of it) and proving it has become really faster is an easier job than think about performance in advance? What are you talking about? That is absolutely a lot easier. Needing to rewrite tons is extremely rare, at least in a well- or even moderately-structured program. > So, to sum it up, personally I will be investing my time into studying C/C++ rather than Rust in the next 5 or so years. C++ is an industrial standard. Programmers have been using it to solve a huge variety of tasks for over 30 years now. As for Rust and stuff like that - they are just odd toys with vague future. People have been predicting C++'s soon death since the 2000-s, but C/C++ hasn't become less used and demanded for since then. Quite on the contrary, in fact. It is evolving (C ++11, C++14), new tools are released (take CLion and Clang, for example), and the number of vacancies is just huge. If you believe the future looks like the past then sure. Personally I think the Internet will become both more vital and more hostile: the security requirements of a web browser are a canary for things that will become requirements for every program in 5 or 10 years' time. Mozilla started Rust because they couldn't write a safe enough browser in C++. That should be a warning to anyone who wants to continue using the language.
- gsnedders 10y ago
  > it's to be as safe as those without GC - primarily for the sake of using it in a Javascript runtime and not having to run two GCs That's not actually the reason why Rust doesn't have a GC, nor it the reason why Servo doesn't have a GC. (It's worthwhile remembering that Rust predates Servo, and it has always been a goal to not require a GC.) The reason why there's such a big desire to avoid GC is to have predictable memory layout and to avoid the overhead of the GC. In a browser, having predictable memory layout is important to be able to control memory usage, as well as for performance. > Personally I think the Internet will become both more vital and more hostile: the security requirements of a web browser are a canary for things that will become requirements for every program in 5 or 10 years' time. Mozilla started Rust because they couldn't write a safe enough browser in C++. That should be a warning to anyone who wants to continue using the language. With the proviso that Rust predated Mozilla's involvement and any attempt to write a browser in it, I totally agree. The fact that no browser vendor has managed to write a secure piece of software is pretty damning—these aren't small applications written by small teams, these are big applications written by very well funded development organisations which absolutely have the budget to do plenty of work to ensure their products are secure.
nickpsecurity 10y ago
I'm not upvoting this toward the front page because, although the writer makes some smart observations, the piece largely doesn't apply to Rust due to key misconception: "You know, it's like the "Chicken or the Egg" dilemma. On very rare occasions, this problem does get resolved (relatively representative examples are Go and Scala) - mostly thanks to investments of time and money from some large company (Google, Typesafe) who for some reason finds it worthy to popularize a new language." Which is exactly what happened with Rust. A large company put significant resources into language, compiler, libraries, and community. Already meant his write-up didn't apply to Rust if that was a precondition of its truth. It then of exploded in usage and available code. It was also deployed at Dropbox for mission-critical apps. So, many things he says it will need to prove something are already there. Amazing thing is the article from 2015 was disproven by Rust ecosystem by 2016.
- kartD 10y ago
  If anyone would like to see some Rust deployment, take a look at this page. https://www.rust-lang.org/en-US/friends.html https://www.rust-lang.org/en-US/friends.html
- edko 10y ago
  Scala was already popular before Lightbend (Typesafe). Its backing was academic (EPFL).
- vvanders 10y ago
  Agreed. I think the freetype alternative that made the front page of HN the other day puts the performance argument pretty well to bed. The rest seems to be things that the author doesn't agree with(exceptions) or "You're just not using it right"(to paraphrase the last bullet point at the end). So far I've been using Rust in every side-project where I'd use C++ and you know what I don't miss? Crashes/stack corruptions/etc because of an off-by-one error. 90% of the C++ code you write is not the inner loop, that said if I want to use modern C++ stuff I'd still be hitting the heap for std::vector. Rust's iterators are an awesome way to keep everything stack based in a nice ergonomic way. Most recently I wrote a packet library over an AX.25 radio link in Rust. With about 1:1 code:unit test radio most stuff just worked. I've almost never seen that in a production C++ library. C++ isn't going away but for me Rust is here to stay.
greydius 10y ago
C and C++ will eventually die in the same way that COBOL has died. That is, they'll never go away, but there will be fewer and fewer people able and willing to use them.
- tkinom 10y ago
  I prefer data on evaluating a programming language's potential: Search indeed.com for C++ : 4287 jobs. golang : 71 jobs Java : 6817 jobs Rust : 7 jobs
  - dcu 10y ago
    The go results are inaccurate because "go" is not searchable and most people write "go" instead of golang. Try searching for "backend go" in indeed.com and you'll see what I mean.
  - jolux 10y ago
    Rust hit 1.0 18 months ago while everything else on that list is between 5-33 years old. Give it time.
  - echelon 10y ago
    Rust is beginning to be evaluated by large tech companies for production use (I can attest). When companies start using it and blogging about it, other companies will catch on and do the same. My money is on this number rising. Rust is something truly special, and I'd be shocked for it not to gain widespread usage.
  - PopsiclePete 10y ago
    Trust me. You would not enjoy roughly the 92% of Java jobs out of that number. My Java work was easily the most corporatish "enteprise" soul-sucking nightmare that I'm glad to be out of forever. I bet the majority of the Golang jobs are fun, in small teams though. I know which one I'd rather work on.
    - AnimalMuppet 10y ago
naasking 10y ago
It's interesting that his own points argue against his own conclusion. For instance, "I can't but remind you for one more time that the source of troubles is usually in humans, not technology", doesn't jive with the conclusion that C/C++ are here to stay, nor does it agree with his point that he was annoyed with the restrictions Rust placed on him. If humans are the problem, then a language that restricts these problematic human urges in a way that maximizes safety and extensibility is an important solution. C/C++ does only one of these, and not very well either. Any solution that strikes a better balance will replace C/C++ eventually, and I think Rust is on the right track.
- rkangel 10y ago
  I was going to make that exact point. Language design philosophy has shifted. It used to be a question of giving programmers all the tools and trusting them to do it right. History (the list of CVEs if nothing else) has shown that even the best and most well-intentioned programmers will shoot themselves in the foot on occasion if handed a gun. Modern language design has shifted to prioritise preventing such footguns, while retaining as much programmer power as possible. Humans are the source of troubles, and so we give them tools that help them not make mistakes. That's what will actually get Rust adopted (if that actually happens): companies will weigh off the extra productivity (fewer bugs) against the cost of switching.
  - saosebastiao 10y ago
    I totally agree, simply because all tools have learning curves. It is one thing to learn a language, but it is another entirely to learn a language + debugger + profiler + static analyzer + IDE + build system + package manager + test framework + test runner, etc.. (Just typing this is giving me Node/javascript anxiety...) Rust has done an amazing job packing almost all of that into rustc + cargo, and while there is a learning curve it is nothing like the learning curve necessary to produce code of similar quality in C/C++.
rkangel 10y ago
This title needs editing with a [2015] tag. The original was written in April last year and some of the things it talks about are out of date.
- ben0x539 10y ago
  Previous discussion: https://news.ycombinator.com/item?id=9531822 https://news.ycombinator.com/item?id=9531822
GreaterFool 10y ago
What is dead may never die! (sorry, couldn't help myself :P)
- dllthomas 10y ago
  That is not dead which can eternal lie. And with strange aeons even death may die.
zaphar 10y ago
He considers Racer to be insignificant. And while It's true that it doesn't yet do everything an IDE usually does it's also true that Racer is exactly the path that Languages should be taking in the future. Locking all of that logic up in an IDE in ways that it can't be factored back out makes automated refactoring and analysis tools harder to build. It locks people into editors they may prefer not to use and just generally splits your user base up in ways that are unnecessary. Providing a build your own IDE api is a superior approach that more and more languages are moving over to.
- kibwen 10y ago
  Going forward there are indeed plans to continue to develop suitable interfaces for IDEs/tooling in the Rust compiler itself, to further facilitate easy integration (for example, the ability to typecheck incomplete fragments of code). Mozilla has a vested interest in making the programming experience as pleasant as possible, since it intends to have more and more employees using the language as time goes on. :)
jbb555 10y ago
Rust isn't a proper systems language, it restricts how you can access the machine in the name is spurious "safety". A small number of people are making a lot of noise about it, but it's not going anywhere.
- steveklabnik 10y ago
  > it restricts how you can access the machine in the name is spurious "safety". Yet, you can also get around any of these things at any time.
- adrusi 10y ago
  Maybe it doesn't line up with your definition of a systems language, whatever that is. But in practice it's works in places where you would otherwise need a systems language, like writing device drivers. Don't get too worked up over semantics.
- Jtsummers 10y ago
  That makes it a wonderful systems language. Systems need to be stable and correct, not just fast. Rust has good performance, so it's got fast down. The restrictions that it introduces increase stability and correctness at the added cost (high to start, should drop as time goes on) of increased developer effort to get it correct (compared to C, one of the best footguns ever invented). And the ability to create "unsafe" blocks allows you to minimize the amount of bullets that end up in your feet.
Cshelton 10y ago
It's hard to follow this author's arguments because so many of them are simply wrong and off base. I've used Rust since 1.0 stable release, I have yet to write a piece of unsafe code. Almost all of my code has run at speeds similar to C/C++. If something in Rust is slow, then it is a bug. Of which the Rust contributors are very good at getting rid of. The new MIR stuff will change a lot. This guy also makes many blunt assumptions on what other programmers will do. He says no sane programmer will write a webserver/service in Rust. Uhhh.. yes they will and do. When they need to benefits that the Rust lang comes with, they will/do already. This guy clearly doesn't like Rust, which is fine. Most programmers have a language they really dislike that is popular. Nothing wrong with that. As for "replacing" C/C++, no, in the near future it won't It may never. But the fact of the matter is old programmers will....grow older, retire and be gone. Young programmers just getting started in their career/education will look at the ecosystem of tools available to them and make their own choices on what to use. Which in turn has the potential to make C/C++ go the way of COBAL. Rust isn't the only language either. Many new languages will arise in the next few decades that will completely displace some of the most popular languages now. That's how it is. I frankly do no see C++ being used for new programs 20 years from now. Unless it is a new subset of C++ that does not resemble anything like C++ today...which for that matter...is a new language. Sure, C/C++ programs will be around for at least a few decades. But will anyone new program in them? Highly doubtful. Rust is just one of the first displacing languages. And this is not a bad thing. We SHOULD rewrite many of the things that we heavily rely on. They have to evolve and not be tied down to something written decades past. System kernels will be re-written. Linux itself, eventually, will effectively be re-written. (Yes...it will take a while, may be something else, not called Linux...Redox perhaps?) If it were up to this author, all language developers would only be working to make C++/C faster/safer.(The author calling C++ "safe" is laughable, he even counters his own argument elsewhere in the article about humans being the weak point. ) No. We have to reject that. Just as Henry Ford said, "If I asked people what they wanted, they would say 'faster horses'".
- rkangel 10y ago
  > I've used Rust since 1.0 stable release, I have yet to write a piece of unsafe code Yes, he conflates 'unsafe' with 'fast'. Speed doesn't necessarily require unsafety. Very occasionally it does, but Rusts approach to checking everything at compile means that mostly it doesn't.
dcu 10y ago
So Rust has started to receive criticism which means it's becoming popular. As the creator of c++ says: "There are only two kinds of languages: the ones people complain about and the ones nobody uses."
- Cshelton 10y ago
  This is an old article [2015] by a guy who is paid to attack Rust by a company that makes static analysis tools for C/C++. But yeah, if you don't have haters, you're doing something wrong.
- falcolas 10y ago
  How about "the ones that are evangelized to the point of annoying everyone else"?
  - AnimalMuppet 10y ago
    They're in the second category - the ones nobody uses. Once people start using them, they'll move into the first category. (Note well: This does not mean that no improvement is possible, or that all languages are equally bad. It merely means that the perfect language has never been written, and likely never will be. If people are using it, they will run into limitations, problems, and areas of frustration. Then - hello, human nature - they will complain.)
wyldfire 10y ago
> take, for instance, the inevitable "stop the world" issue during garbage collection. ... 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 ...and then he goes on to show a boxplot graph of (likely) CPU-bound benchmarks. C++ pays a penalty (~1.7x?) and so does Rust (~2.5x). Well, who cares about CPU?! Yes, okay, lots of you. But if you really care, you rewrite that inner loop of your C++ system in C. And if you really, really, care, you rewrite that inner loop in assembly (or corresponding intrinsics). So, hey, here's what I care about: latency! Many systems designed in C/C++ are thus because until recently it was just about the only game in town for predictable low latencies (refer to the "stop the world GC" paragraph above). Also, there's no other language out there offering both memory safety and the ability to do things like I/O and system control with memory-mapped registers. Linking your rust code against C libraries and executables is not-super-painful. So phase-in of rust code is easier than other languages described. > On the one hand, it's not bad to make programmers ponder if their variables are stored in the stack or heap and if they can or cannot be handled by several threads at a time. Indeed! All the C/C++ static checkers in the world can only hint "Hey this might not be safe, but WTF I have no idea..." only to be declared [FALSE_POSITIVE, IGNORE]. BTW authors of static checkers (like the translators at PVS-Studio) have a vested interest in unsafe languages like C/C++.
- deleted 10y ago
  [deleted]
- bvinc 10y ago
  The benchmarks are from The Computer Language Benchmarks Game. I used to think this was a good way to compare programming language performance. But if you look into the results in detail, it's really not that simple. If you look at rust vs C, you'll see many cases where rust is on par with C, or beats C. When you start comparing WHY some rust version of a program is twice as slow as the C version, usually what you'll find is that someone has not spent the same amount of effort optimizing that program. Or in some cases, you'll see the C program using SIMD instructions, which you could do in rust, but it isn't stabilized yet. What you won't find, is some intrinsic reason that the safety of rust is causing it to be slower than C. To just look at the benchmark totals and make that assumption would be wrong, and that's exactly what the author did.
kibwen 10y ago
As I remarked when this article originally came out last year, there's a certain delicious irony in a hit piece on Rust coming from a company that makes its money writing static analysis tools to try and plug the safety holes in C++. :P
- dman 10y ago
  There is irony all around including in the rust communities own positions - relying on jemalloc and llvm while claiming that reliable software cannot be written in C/C++.
  - dead10ck 10y ago
    Show me where anyone involved in Rust in an official capacity has claimed that "reliable software cannot be written in C/C++"
legulere 10y ago
> Wikipedia tells us that there were a lot of other attempts besides D to kill C++ - for example Vala, Cyclone, Limbo, BitC. Vala pretty much is a DSL for writing GTK+ programs. Cyclone is a safe dialect of C. Both don't really have anything to do with C++.

41 points by federicoponzi 10y ago

I always chalked it up to the "I'm old" sentiment. There hasn't been a language that has actually caused us to think of writing a different kind of software. Sure we write nicer easier code but the software remains the same in the end, buggy, full of problems and not maintainable. These are the problems we should be solving.. the result of what WE code, not how pretty it looks in the ide.

lmm 10y ago

> Note: Further in this text, I am presuming that Rust is a conscious attempt to create a fast and safe language. After all, it was initially conceived by the guys from Mozilla as a tool to develop a browser engine. But if it proves to be yet another just safe language, then I just don't get the whole thing. There is plenty of very different safe languages to choose from to any taste, and if Rust is not meant to replace C++, then (1) why does it need to include an unsafe subset?; and (2) why did the authors throw away lightweight processes from Rust? They are convenient, after all, aren't they? In other words, if I'm wrong in my assumption, then the whole affair just doesn't seem to make any sense at all. > I sincerely hope that programmers will find a way to speed it up in time, but until then, it's going to be of hardly more interest than Scala or Go from the viewpoint of the safety/speed compromise. The question is still open if it is possible at all to make a language both fast and safe 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. If it ends up being a factor of 2 slower than C I really don't think that matters. The point isn't to be faster than Ada/Go/Scala/Java/Haskell/OCaml, it's to be as safe as those without GC - primarily for the sake of using it in a Javascript runtime and not having to run two GCs. > Anyway, in any serious project, you use a continuous integration system and run tons of tests when compiling builds. If you don't, then your troubles are much worse than the language's lack of safety because static typing doesn't guarantee correct execution logic! Guarantees are absolutely possible. Most practical programs don't guarantee everything in the type system, but test suites don't guarantee everything either. For a practical program where you have a certain acceptable defect rate, it's not at all clear that a large test suite will be a cheaper way to achieve that than a type system, and my experience is in fact the opposite. > Following its logic, we could rewrite 90% of WebKit or VirtualBox or GCC into Java and get the same result. But it is obviously wrong. Not at all obvious - I suspect not in fact wrong at all. > Well, it depends on the project scale. For Google, even a few percent may help save millions of dollars (see Section 5, "Utilization", in the paper). Or imagine that with a next update, JVM will suddenly start requiring 10% more resources! So maybe C++ is worth using at Google. Most of us aren't Google. > But if we want to follow it word for word, why not use bubble sort instead of quicksort in all of the code? Go ahead. See if I care. See if you care. 99% of the time, bubblesort really isn't a problem. (Not using library functions is a problem, so in practice this would never come up, but it really isn't a performance problem if you do end up using bubblesort) > After all, who will dare to argue that finding a hot spot, rewriting the code (perhaps tons of it) and proving it has become really faster is an easier job than think about performance in advance? What are you talking about? That is absolutely a lot easier. Needing to rewrite tons is extremely rare, at least in a well- or even moderately-structured program. > So, to sum it up, personally I will be investing my time into studying C/C++ rather than Rust in the next 5 or so years. C++ is an industrial standard. Programmers have been using it to solve a huge variety of tasks for over 30 years now. As for Rust and stuff like that - they are just odd toys with vague future. People have been predicting C++'s soon death since the 2000-s, but C/C++ hasn't become less used and demanded for since then. Quite on the contrary, in fact. It is evolving (C ++11, C++14), new tools are released (take CLion and Clang, for example), and the number of vacancies is just huge. If you believe the future looks like the past then sure. Personally I think the Internet will become both more vital and more hostile: the security requirements of a web browser are a canary for things that will become requirements for every program in 5 or 10 years' time. Mozilla started Rust because they couldn't write a safe enough browser in C++. That should be a warning to anyone who wants to continue using the language.

gsnedders 10y ago
> it's to be as safe as those without GC - primarily for the sake of using it in a Javascript runtime and not having to run two GCs That's not actually the reason why Rust doesn't have a GC, nor it the reason why Servo doesn't have a GC. (It's worthwhile remembering that Rust predates Servo, and it has always been a goal to not require a GC.) The reason why there's such a big desire to avoid GC is to have predictable memory layout and to avoid the overhead of the GC. In a browser, having predictable memory layout is important to be able to control memory usage, as well as for performance. > Personally I think the Internet will become both more vital and more hostile: the security requirements of a web browser are a canary for things that will become requirements for every program in 5 or 10 years' time. Mozilla started Rust because they couldn't write a safe enough browser in C++. That should be a warning to anyone who wants to continue using the language. With the proviso that Rust predated Mozilla's involvement and any attempt to write a browser in it, I totally agree. The fact that no browser vendor has managed to write a secure piece of software is pretty damning—these aren't small applications written by small teams, these are big applications written by very well funded development organisations which absolutely have the budget to do plenty of work to ensure their products are secure.

nickpsecurity 10y ago

I'm not upvoting this toward the front page because, although the writer makes some smart observations, the piece largely doesn't apply to Rust due to key misconception: "You know, it's like the "Chicken or the Egg" dilemma. On very rare occasions, this problem does get resolved (relatively representative examples are Go and Scala) - mostly thanks to investments of time and money from some large company (Google, Typesafe) who for some reason finds it worthy to popularize a new language." Which is exactly what happened with Rust. A large company put significant resources into language, compiler, libraries, and community. Already meant his write-up didn't apply to Rust if that was a precondition of its truth. It then of exploded in usage and available code. It was also deployed at Dropbox for mission-critical apps. So, many things he says it will need to prove something are already there. Amazing thing is the article from 2015 was disproven by Rust ecosystem by 2016.

kartD 10y ago
If anyone would like to see some Rust deployment, take a look at this page. https://www.rust-lang.org/en-US/friends.html https://www.rust-lang.org/en-US/friends.html
edko 10y ago
Scala was already popular before Lightbend (Typesafe). Its backing was academic (EPFL).
vvanders 10y ago
Agreed. I think the freetype alternative that made the front page of HN the other day puts the performance argument pretty well to bed. The rest seems to be things that the author doesn't agree with(exceptions) or "You're just not using it right"(to paraphrase the last bullet point at the end). So far I've been using Rust in every side-project where I'd use C++ and you know what I don't miss? Crashes/stack corruptions/etc because of an off-by-one error. 90% of the C++ code you write is not the inner loop, that said if I want to use modern C++ stuff I'd still be hitting the heap for std::vector. Rust's iterators are an awesome way to keep everything stack based in a nice ergonomic way. Most recently I wrote a packet library over an AX.25 radio link in Rust. With about 1:1 code:unit test radio most stuff just worked. I've almost never seen that in a production C++ library. C++ isn't going away but for me Rust is here to stay.

greydius 10y ago

C and C++ will eventually die in the same way that COBOL has died. That is, they'll never go away, but there will be fewer and fewer people able and willing to use them.

tkinom 10y ago
I prefer data on evaluating a programming language's potential: Search indeed.com for C++ : 4287 jobs. golang : 71 jobs Java : 6817 jobs Rust : 7 jobs
- dcu 10y ago
  The go results are inaccurate because "go" is not searchable and most people write "go" instead of golang. Try searching for "backend go" in indeed.com and you'll see what I mean.
- jolux 10y ago
  Rust hit 1.0 18 months ago while everything else on that list is between 5-33 years old. Give it time.
- echelon 10y ago
  Rust is beginning to be evaluated by large tech companies for production use (I can attest). When companies start using it and blogging about it, other companies will catch on and do the same. My money is on this number rising. Rust is something truly special, and I'd be shocked for it not to gain widespread usage.
- PopsiclePete 10y ago
  Trust me. You would not enjoy roughly the 92% of Java jobs out of that number. My Java work was easily the most corporatish "enteprise" soul-sucking nightmare that I'm glad to be out of forever. I bet the majority of the Golang jobs are fun, in small teams though. I know which one I'd rather work on.
  - AnimalMuppet 10y ago

naasking 10y ago

It's interesting that his own points argue against his own conclusion. For instance, "I can't but remind you for one more time that the source of troubles is usually in humans, not technology", doesn't jive with the conclusion that C/C++ are here to stay, nor does it agree with his point that he was annoyed with the restrictions Rust placed on him. If humans are the problem, then a language that restricts these problematic human urges in a way that maximizes safety and extensibility is an important solution. C/C++ does only one of these, and not very well either. Any solution that strikes a better balance will replace C/C++ eventually, and I think Rust is on the right track.

rkangel 10y ago
I was going to make that exact point. Language design philosophy has shifted. It used to be a question of giving programmers all the tools and trusting them to do it right. History (the list of CVEs if nothing else) has shown that even the best and most well-intentioned programmers will shoot themselves in the foot on occasion if handed a gun. Modern language design has shifted to prioritise preventing such footguns, while retaining as much programmer power as possible. Humans are the source of troubles, and so we give them tools that help them not make mistakes. That's what will actually get Rust adopted (if that actually happens): companies will weigh off the extra productivity (fewer bugs) against the cost of switching.
- saosebastiao 10y ago
  I totally agree, simply because all tools have learning curves. It is one thing to learn a language, but it is another entirely to learn a language + debugger + profiler + static analyzer + IDE + build system + package manager + test framework + test runner, etc.. (Just typing this is giving me Node/javascript anxiety...) Rust has done an amazing job packing almost all of that into rustc + cargo, and while there is a learning curve it is nothing like the learning curve necessary to produce code of similar quality in C/C++.

rkangel 10y ago

This title needs editing with a [2015] tag. The original was written in April last year and some of the things it talks about are out of date.

ben0x539 10y ago
Previous discussion: https://news.ycombinator.com/item?id=9531822 https://news.ycombinator.com/item?id=9531822

GreaterFool 10y ago

What is dead may never die! (sorry, couldn't help myself :P)

dllthomas 10y ago
That is not dead which can eternal lie. And with strange aeons even death may die.

zaphar 10y ago

He considers Racer to be insignificant. And while It's true that it doesn't yet do everything an IDE usually does it's also true that Racer is exactly the path that Languages should be taking in the future. Locking all of that logic up in an IDE in ways that it can't be factored back out makes automated refactoring and analysis tools harder to build. It locks people into editors they may prefer not to use and just generally splits your user base up in ways that are unnecessary. Providing a build your own IDE api is a superior approach that more and more languages are moving over to.

kibwen 10y ago
Going forward there are indeed plans to continue to develop suitable interfaces for IDEs/tooling in the Rust compiler itself, to further facilitate easy integration (for example, the ability to typecheck incomplete fragments of code). Mozilla has a vested interest in making the programming experience as pleasant as possible, since it intends to have more and more employees using the language as time goes on. :)

jbb555 10y ago

Rust isn't a proper systems language, it restricts how you can access the machine in the name is spurious "safety". A small number of people are making a lot of noise about it, but it's not going anywhere.

steveklabnik 10y ago
> it restricts how you can access the machine in the name is spurious "safety". Yet, you can also get around any of these things at any time.
adrusi 10y ago
Maybe it doesn't line up with your definition of a systems language, whatever that is. But in practice it's works in places where you would otherwise need a systems language, like writing device drivers. Don't get too worked up over semantics.
Jtsummers 10y ago
That makes it a wonderful systems language. Systems need to be stable and correct, not just fast. Rust has good performance, so it's got fast down. The restrictions that it introduces increase stability and correctness at the added cost (high to start, should drop as time goes on) of increased developer effort to get it correct (compared to C, one of the best footguns ever invented). And the ability to create "unsafe" blocks allows you to minimize the amount of bullets that end up in your feet.

Cshelton 10y ago

It's hard to follow this author's arguments because so many of them are simply wrong and off base. I've used Rust since 1.0 stable release, I have yet to write a piece of unsafe code. Almost all of my code has run at speeds similar to C/C++. If something in Rust is slow, then it is a bug. Of which the Rust contributors are very good at getting rid of. The new MIR stuff will change a lot. This guy also makes many blunt assumptions on what other programmers will do. He says no sane programmer will write a webserver/service in Rust. Uhhh.. yes they will and do. When they need to benefits that the Rust lang comes with, they will/do already. This guy clearly doesn't like Rust, which is fine. Most programmers have a language they really dislike that is popular. Nothing wrong with that. As for "replacing" C/C++, no, in the near future it won't It may never. But the fact of the matter is old programmers will....grow older, retire and be gone. Young programmers just getting started in their career/education will look at the ecosystem of tools available to them and make their own choices on what to use. Which in turn has the potential to make C/C++ go the way of COBAL. Rust isn't the only language either. Many new languages will arise in the next few decades that will completely displace some of the most popular languages now. That's how it is. I frankly do no see C++ being used for new programs 20 years from now. Unless it is a new subset of C++ that does not resemble anything like C++ today...which for that matter...is a new language. Sure, C/C++ programs will be around for at least a few decades. But will anyone new program in them? Highly doubtful. Rust is just one of the first displacing languages. And this is not a bad thing. We SHOULD rewrite many of the things that we heavily rely on. They have to evolve and not be tied down to something written decades past. System kernels will be re-written. Linux itself, eventually, will effectively be re-written. (Yes...it will take a while, may be something else, not called Linux...Redox perhaps?) If it were up to this author, all language developers would only be working to make C++/C faster/safer.(The author calling C++ "safe" is laughable, he even counters his own argument elsewhere in the article about humans being the weak point. ) No. We have to reject that. Just as Henry Ford said, "If I asked people what they wanted, they would say 'faster horses'".

rkangel 10y ago
> I've used Rust since 1.0 stable release, I have yet to write a piece of unsafe code Yes, he conflates 'unsafe' with 'fast'. Speed doesn't necessarily require unsafety. Very occasionally it does, but Rusts approach to checking everything at compile means that mostly it doesn't.

dcu 10y ago

So Rust has started to receive criticism which means it's becoming popular. As the creator of c++ says: "There are only two kinds of languages: the ones people complain about and the ones nobody uses."

Cshelton 10y ago
This is an old article [2015] by a guy who is paid to attack Rust by a company that makes static analysis tools for C/C++. But yeah, if you don't have haters, you're doing something wrong.
falcolas 10y ago
How about "the ones that are evangelized to the point of annoying everyone else"?
- AnimalMuppet 10y ago
  They're in the second category - the ones nobody uses. Once people start using them, they'll move into the first category. (Note well: This does not mean that no improvement is possible, or that all languages are equally bad. It merely means that the perfect language has never been written, and likely never will be. If people are using it, they will run into limitations, problems, and areas of frustration. Then - hello, human nature - they will complain.)

wyldfire 10y ago

> take, for instance, the inevitable "stop the world" issue during garbage collection. ... 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 ...and then he goes on to show a boxplot graph of (likely) CPU-bound benchmarks. C++ pays a penalty (~1.7x?) and so does Rust (~2.5x). Well, who cares about CPU?! Yes, okay, lots of you. But if you really care, you rewrite that inner loop of your C++ system in C. And if you really, really, care, you rewrite that inner loop in assembly (or corresponding intrinsics). So, hey, here's what I care about: latency! Many systems designed in C/C++ are thus because until recently it was just about the only game in town for predictable low latencies (refer to the "stop the world GC" paragraph above). Also, there's no other language out there offering both memory safety and the ability to do things like I/O and system control with memory-mapped registers. Linking your rust code against C libraries and executables is not-super-painful. So phase-in of rust code is easier than other languages described. > On the one hand, it's not bad to make programmers ponder if their variables are stored in the stack or heap and if they can or cannot be handled by several threads at a time. Indeed! All the C/C++ static checkers in the world can only hint "Hey this might not be safe, but WTF I have no idea..." only to be declared [FALSE_POSITIVE, IGNORE]. BTW authors of static checkers (like the translators at PVS-Studio) have a vested interest in unsafe languages like C/C++.

deleted 10y ago
[deleted]
bvinc 10y ago
The benchmarks are from The Computer Language Benchmarks Game. I used to think this was a good way to compare programming language performance. But if you look into the results in detail, it's really not that simple. If you look at rust vs C, you'll see many cases where rust is on par with C, or beats C. When you start comparing WHY some rust version of a program is twice as slow as the C version, usually what you'll find is that someone has not spent the same amount of effort optimizing that program. Or in some cases, you'll see the C program using SIMD instructions, which you could do in rust, but it isn't stabilized yet. What you won't find, is some intrinsic reason that the safety of rust is causing it to be slower than C. To just look at the benchmark totals and make that assumption would be wrong, and that's exactly what the author did.

kibwen 10y ago

As I remarked when this article originally came out last year, there's a certain delicious irony in a hit piece on Rust coming from a company that makes its money writing static analysis tools to try and plug the safety holes in C++. :P

dman 10y ago
There is irony all around including in the rust communities own positions - relying on jemalloc and llvm while claiming that reliable software cannot be written in C/C++.
- dead10ck 10y ago
  Show me where anyone involved in Rust in an official capacity has claimed that "reliable software cannot be written in C/C++"

legulere 10y ago

> Wikipedia tells us that there were a lot of other attempts besides D to kill C++ - for example Vala, Cyclone, Limbo, BitC. Vala pretty much is a DSL for writing GTK+ programs. Cyclone is a safe dialect of C. Both don't really have anything to do with C++.