10 ms·

> I don't think anyone is arguing that we should throw everything out, however for all my greenfield stuff Rust has been a welcome breath of fresh air. If you

> I don't think anyone is arguing that we should throw everything out, however for all my greenfield stuff Rust has been a welcome breath of fresh air. If you can write things from scratch in a clear room fashion, perhaps. C++ is very good, when you need to integrate a lot of 'low-level' libraries (that are alredy in C or C++) together in a meaninful way, like for instance, browsers do. Like the capacity to 'talk' with FFMPEG, levelDB, linux, etc.. in a complete native fashion basically. I think in that regard Rust is sort of late to the party, and will find a wall hard to beat down, once the adoption rate get some maturity. If you are already a experienced C++ dev, compared to modern C++, Rust has very little to offer. Of course is more modern, (maybe) more ergonomic? But little things like package manager or explicit lifetime management by itself wont cut it.. at least not for people with large codebases already in C++. When you are younger, programming languages look like that secret ingredient that will turn whatever you do into a magical tool.. But experience tells you that nothing beats hard work or that you should understand the strenght and weakness of each language, and know when and how to use it. So for the problem domains where C++ are being used, it will get hard to beat, because a lot of great software are already there, and can be integrated in a native fashion, with whatever you do on top of it. And by the way, modern C++ is already secure enough, making some selling points for Rust, a little bit of cosmetic right now. If you throw a language like Swift into the equation.. particularly i think they(C++ and Swift) form a lovely and unbeatable couple.

vvanders 9y ago
I mean this in the most non-confrontational way: have you actually used/looked at Rust? The reason I ask is just about every item you laid out I've had the opposite experience. Talking with C/C++ is trivial with bindgen and clang. Embedding in C++ is likewise straightforward. I mean Firefox is one of the larger C++ codebases out there. The package manager is great and makes dropping in things much less painful. On the security front I don't think you can compare the two, I can easily think of things like iterator invalidation that C++ just doesn't handle well. The last big project I did in Rust ran on 6 different targets(x68 win32/linux/osx, android armv7/x86, wasm) targeting 3 different rendering stacks(OpenGL, HTML Canvas, Android Views) integrated deeply with a Lua interpreter. Having done cross-platform stuff like this in the past it was a build/toolchain nightmare. With Rust everything was straightforward and pretty darn painless.
- stochastic_monk 9y ago
  The real problem is when it's not just binding: it's actually using metaprogramming, which is a huge part of why I use C++. There's no equivalent to blaze or eigen for linear algebra in Rust, and much of that heavy lifting is handled by templates. (There are some libraries with rudimental expression template-like behavior, but nothing as sophisticated.)
  - kelnos 9y ago
    This is the sort of thing that bothers me about these kinds of arguments. Sure, you're always going to be able to find certain domains where existing libraries or language features make a certain ecosystem very well suited. And that's fine. No one's saying to discard the best tool for the job for another one that might have some general advantages but won't actually get you where you need to go. But there are a ton of domains where C++ doesn't have anything special to offer and you could just as reasonably write the code in rust.
    - stochastic_monk 9y ago
      Perfect. I absolutely agree. The thing is, I use C++ because it does a lot of things specialized for what I need. I don't work on every problem, and I look forward to the chance to use Rust. That being said, for now, the problems I'm working on are domains that very much benefit from C++ and I will continue to use it. I totally agree that Rust is a great language and has wide applications. It doesn't fit my current needs, but I don't doubt it meets many people's needs. More power to them -- and it's cool to have a "The new C++ killer language" which can actually live up to its hype, unlike Java and C# and Go and D.
      - Majora320 9y ago
        What's wrong with D? I quite liked it when I used it (for a relatively small project). It's not really a C++ replacement (GC), but as a high-level language the only problem I found was lack of a large library ecosytem - the language itself was quite pleasant to work with (more so than C++ and even Rust, which I also like).
kelnos 9y ago
> C++ is very good, when you need to integrate a lot of 'low-level' libraries ... like for instance, browsers do. That's sorta funny that you use that example, since rust is a Mozilla project, and they've already moved some parts of Firefox over to rust, and plan to move more in the future. Clearly this is not an impediment; reasonable C/C++ interop was a must-have for rust's design. > If you are already a experienced C++ dev, compared to modern C++, Rust has very little to offer. That's a weird argument to make. Essentially you're arguing that you should never learn any new languages once you have proficiency in something similar? That would seem to be a bit short sighted. > ... at least not for people with large codebases already in C++. Sure. No one's saying "throw out all your C++ code and rewrite everything in rust" (and if anyone is, they can be safely ignored). But that doesn't preclude taking a look at some parts of your code that might benefit from being written in a safer language, or rewriting small tools in rust, or considering it for new projects. > When you are younger, programming languages look like that secret ingredient that will turn whatever you do into a magical tool.. But experience tells you that nothing beats hard work or that you should understand the strenght and weakness of each language, and know when and how to use it. No one's saying languages are magic, just that, by some metrics, some are objectively better. This might be an odd example, but I did Java for many years before switching to Scala a couple years ago. In the past few months I've had to go back to Java, and it's been frustrating that it's so easy to write certain classes of bugs that I just never see or write in Scala. Does that make Scala some magical tool that fixes all my problems and means I don't have to do any work? No, of course not. But it is objectively better than Java by some metrics (and sadly, worse by others). > modern C++ is already secure enough That's a pretty bold claim, and I'm certain it's not true. You might have a different idea of what "enough" is than I do, though. I'd believe that the "default" state-of-the-art C++ use is more secure than it was 10 years ago, but that doesn't mean that a language like rust can't offer superior safety guarantees. And there's something to be said about encouraging safer practices through language features and convention. If you can make certain kinds of errors in C++ programs (I don't see pointer arithmetic going away any time soon, or people always using vectors and the like and never raw arrays), then you (or someone else) will, regardless if there are safer ways that help you avoid those kinds of errors. Given a language with a huge surface area like C++, and disagreements on what are the "safe" parts to use, it's inevitable. > If you throw a language like Swift into the equation.. particularly i think they(C++ and Swift) form a lovely and unbeatable couple. Despite Swift's open source status, I really don't see it making any meaningful foothold outside macOS/iOS. I don't have a horse in this race. I abandoned C++ years ago, and I've only started learning rust a few weeks ago. I like it, but I have a lot to learn, and I've already found some rough spots that aren't so great. No tool is perfect.
pcwalton 9y ago
> And by the way, modern C++ is already secure enough, making some selling points for Rust, a little bit of cosmetic right now. There is not a single large-scale network-facing widely attacked piece of software I'm aware of in C++ that has not fallen to some memory safety problem. Memory safety issues frequently produce RCE.
- oscargrouch 9y ago
  > And by the way, modern C++ is already secure enough, making some selling points for Rust, a little bit of cosmetic right now. Sorry. In hindsight, and out of the context like this, i think i picked up harsher words than i should. I dont meant to be disrespectful to all the great and valuable work that is going on the Rust community. > There is not a single large-scale network-facing widely attacked piece of software I'm aware of in C++ that has not fallen to some memory safety problem. Memory safety issues frequently produce RCE. Sure, Rust will be better at this. No doubt. But lets not forget that a lang like C++ needed to evolve while still working, so how much of those security issues are there given the use of ancient code practices of the past? software coded in the 90's even the 80's. I guess we at least should wait for when Rust has millions of tools, and billions of line of codes running in production, to see what sort of issues might plague Rust code the most. But Rust will need to get there first. So lets not forget that its a language created in the 70's and that is responsible for great tool, and is still being used to build big project, with millions of LOC and with many devs working in groups in some very sophisticated pieces of software, and this is no small feat. What i meant to say, earlier, that maybe is not so clear, is the choice is not as unidimensional, by just cherry picking one point of view when you need to decide what kind of tech, fits the best for a given scenario. Im trying to point out that other languages like C++ or even C, still can be good bets, when you look into more vectors of influence, not only in the security aspect, or what language have more FP idioms in it. In the real life, is not as easy as some Rust evangelists imply it is. C++ its not as good as Rust in the security aspect, theres no doubt about it, but the modern C++ is fine when you sum the vectors of what language will fit the best for a given scenario. I mean, you can be explicit about ownership, and make the api clear about ownership and lifetime. Of course Rust choose to be more pedantic about it. But as a C++ dev i have no issues with lifetime or owership management just by using smart pointers, std::move, etc.. (even in a multi-threaded environment) But i dont think is as easy, as the Rust community is implying, that is to "just use Rust" for a project, where C++ may also be a good fit. Even for new, clean room projects, i think C++ may be a better fit for certain scenarios, and im glad that theres also Rust as a choice. But i think sometimes this zealot type of evangelism sometimes more based in spreading fear, than by selling Rust for its own virtues, can hurt more than it looks like. I guess by now, Rust doesnt even need to be compared to anything else, thanks to great hackers like you its already showing its own virtues. Im just trying to say that by now it probably reached a peak of users that can use the language in more low-level scenarios, and it probably should aim to get more of the Ruby, Python, PHP, NodeJS crowd, to fill its army. Because from now on it would be harsher for Rust to get more adoption, without a big ecosystem backing it up (Like Swift has with Apple, Java with Android and C and C++ has with Unix)
ernst_klim 9y ago
>modern C++ is already secure enough Why to have nullptr dereferencing? Why to have an undefined behavior on option<> dereferencing? Why to have dangling refs? Why not to check borrow possibility statically? God, we don't event have a decent and safe variant (sum) type in c++. Adding all that (unnecessary) complexity c++ has (how many whatever-values and initializations does it have?). It is unsafe as hell, and lots of stuff could be made safer trivially in a new language (say, rust or F*).
- zaarn 9y ago
  Just as a sidenote, rust has no defined behaviour when dereferencing a null pointer. What makes it worse is that a null pointer in an option<> is handled as None instead of Some, which kind of broke some of my code until I found that particularly nasty bug and worked around it (with offsets).
  - ernst_klim 9y ago
    Rust does not have nulls beyond unsafe blocks, does it? >What makes it worse is that a null pointer in an option<> is handled as None instead of Some What? How could NULL be treated as Some?
    - steveklabnik 9y ago
      It does not. I think your parent must have been doing something strange; if you have a *const T, one that's null will still be a Some. It's &T, which cannot be null by definition, that uses the null value as None, since it cannot be null.
      - zaarn 9y ago
        I was actually using mut/const and got this bug, I don't think I used &T since I was handling raw memory addresses.
        steveklabnik 9y ago

vvanders 9y ago

I mean this in the most non-confrontational way: have you actually used/looked at Rust? The reason I ask is just about every item you laid out I've had the opposite experience. Talking with C/C++ is trivial with bindgen and clang. Embedding in C++ is likewise straightforward. I mean Firefox is one of the larger C++ codebases out there. The package manager is great and makes dropping in things much less painful. On the security front I don't think you can compare the two, I can easily think of things like iterator invalidation that C++ just doesn't handle well. The last big project I did in Rust ran on 6 different targets(x68 win32/linux/osx, android armv7/x86, wasm) targeting 3 different rendering stacks(OpenGL, HTML Canvas, Android Views) integrated deeply with a Lua interpreter. Having done cross-platform stuff like this in the past it was a build/toolchain nightmare. With Rust everything was straightforward and pretty darn painless.

stochastic_monk 9y ago
The real problem is when it's not just binding: it's actually using metaprogramming, which is a huge part of why I use C++. There's no equivalent to blaze or eigen for linear algebra in Rust, and much of that heavy lifting is handled by templates. (There are some libraries with rudimental expression template-like behavior, but nothing as sophisticated.)
- kelnos 9y ago
  This is the sort of thing that bothers me about these kinds of arguments. Sure, you're always going to be able to find certain domains where existing libraries or language features make a certain ecosystem very well suited. And that's fine. No one's saying to discard the best tool for the job for another one that might have some general advantages but won't actually get you where you need to go. But there are a ton of domains where C++ doesn't have anything special to offer and you could just as reasonably write the code in rust.
  - stochastic_monk 9y ago
    Perfect. I absolutely agree. The thing is, I use C++ because it does a lot of things specialized for what I need. I don't work on every problem, and I look forward to the chance to use Rust. That being said, for now, the problems I'm working on are domains that very much benefit from C++ and I will continue to use it. I totally agree that Rust is a great language and has wide applications. It doesn't fit my current needs, but I don't doubt it meets many people's needs. More power to them -- and it's cool to have a "The new C++ killer language" which can actually live up to its hype, unlike Java and C# and Go and D.
    - Majora320 9y ago
      What's wrong with D? I quite liked it when I used it (for a relatively small project). It's not really a C++ replacement (GC), but as a high-level language the only problem I found was lack of a large library ecosytem - the language itself was quite pleasant to work with (more so than C++ and even Rust, which I also like).

kelnos 9y ago

> C++ is very good, when you need to integrate a lot of 'low-level' libraries ... like for instance, browsers do. That's sorta funny that you use that example, since rust is a Mozilla project, and they've already moved some parts of Firefox over to rust, and plan to move more in the future. Clearly this is not an impediment; reasonable C/C++ interop was a must-have for rust's design. > If you are already a experienced C++ dev, compared to modern C++, Rust has very little to offer. That's a weird argument to make. Essentially you're arguing that you should never learn any new languages once you have proficiency in something similar? That would seem to be a bit short sighted. > ... at least not for people with large codebases already in C++. Sure. No one's saying "throw out all your C++ code and rewrite everything in rust" (and if anyone is, they can be safely ignored). But that doesn't preclude taking a look at some parts of your code that might benefit from being written in a safer language, or rewriting small tools in rust, or considering it for new projects. > When you are younger, programming languages look like that secret ingredient that will turn whatever you do into a magical tool.. But experience tells you that nothing beats hard work or that you should understand the strenght and weakness of each language, and know when and how to use it. No one's saying languages are magic, just that, by some metrics, some are objectively better. This might be an odd example, but I did Java for many years before switching to Scala a couple years ago. In the past few months I've had to go back to Java, and it's been frustrating that it's so easy to write certain classes of bugs that I just never see or write in Scala. Does that make Scala some magical tool that fixes all my problems and means I don't have to do any work? No, of course not. But it is objectively better than Java by some metrics (and sadly, worse by others). > modern C++ is already secure enough That's a pretty bold claim, and I'm certain it's not true. You might have a different idea of what "enough" is than I do, though. I'd believe that the "default" state-of-the-art C++ use is more secure than it was 10 years ago, but that doesn't mean that a language like rust can't offer superior safety guarantees. And there's something to be said about encouraging safer practices through language features and convention. If you can make certain kinds of errors in C++ programs (I don't see pointer arithmetic going away any time soon, or people always using vectors and the like and never raw arrays), then you (or someone else) will, regardless if there are safer ways that help you avoid those kinds of errors. Given a language with a huge surface area like C++, and disagreements on what are the "safe" parts to use, it's inevitable. > If you throw a language like Swift into the equation.. particularly i think they(C++ and Swift) form a lovely and unbeatable couple. Despite Swift's open source status, I really don't see it making any meaningful foothold outside macOS/iOS. I don't have a horse in this race. I abandoned C++ years ago, and I've only started learning rust a few weeks ago. I like it, but I have a lot to learn, and I've already found some rough spots that aren't so great. No tool is perfect.

pcwalton 9y ago

> And by the way, modern C++ is already secure enough, making some selling points for Rust, a little bit of cosmetic right now. There is not a single large-scale network-facing widely attacked piece of software I'm aware of in C++ that has not fallen to some memory safety problem. Memory safety issues frequently produce RCE.

oscargrouch 9y ago
> And by the way, modern C++ is already secure enough, making some selling points for Rust, a little bit of cosmetic right now. Sorry. In hindsight, and out of the context like this, i think i picked up harsher words than i should. I dont meant to be disrespectful to all the great and valuable work that is going on the Rust community. > There is not a single large-scale network-facing widely attacked piece of software I'm aware of in C++ that has not fallen to some memory safety problem. Memory safety issues frequently produce RCE. Sure, Rust will be better at this. No doubt. But lets not forget that a lang like C++ needed to evolve while still working, so how much of those security issues are there given the use of ancient code practices of the past? software coded in the 90's even the 80's. I guess we at least should wait for when Rust has millions of tools, and billions of line of codes running in production, to see what sort of issues might plague Rust code the most. But Rust will need to get there first. So lets not forget that its a language created in the 70's and that is responsible for great tool, and is still being used to build big project, with millions of LOC and with many devs working in groups in some very sophisticated pieces of software, and this is no small feat. What i meant to say, earlier, that maybe is not so clear, is the choice is not as unidimensional, by just cherry picking one point of view when you need to decide what kind of tech, fits the best for a given scenario. Im trying to point out that other languages like C++ or even C, still can be good bets, when you look into more vectors of influence, not only in the security aspect, or what language have more FP idioms in it. In the real life, is not as easy as some Rust evangelists imply it is. C++ its not as good as Rust in the security aspect, theres no doubt about it, but the modern C++ is fine when you sum the vectors of what language will fit the best for a given scenario. I mean, you can be explicit about ownership, and make the api clear about ownership and lifetime. Of course Rust choose to be more pedantic about it. But as a C++ dev i have no issues with lifetime or owership management just by using smart pointers, std::move, etc.. (even in a multi-threaded environment) But i dont think is as easy, as the Rust community is implying, that is to "just use Rust" for a project, where C++ may also be a good fit. Even for new, clean room projects, i think C++ may be a better fit for certain scenarios, and im glad that theres also Rust as a choice. But i think sometimes this zealot type of evangelism sometimes more based in spreading fear, than by selling Rust for its own virtues, can hurt more than it looks like. I guess by now, Rust doesnt even need to be compared to anything else, thanks to great hackers like you its already showing its own virtues. Im just trying to say that by now it probably reached a peak of users that can use the language in more low-level scenarios, and it probably should aim to get more of the Ruby, Python, PHP, NodeJS crowd, to fill its army. Because from now on it would be harsher for Rust to get more adoption, without a big ecosystem backing it up (Like Swift has with Apple, Java with Android and C and C++ has with Unix)

ernst_klim 9y ago

>modern C++ is already secure enough Why to have nullptr dereferencing? Why to have an undefined behavior on option<> dereferencing? Why to have dangling refs? Why not to check borrow possibility statically? God, we don't event have a decent and safe variant (sum) type in c++. Adding all that (unnecessary) complexity c++ has (how many whatever-values and initializations does it have?). It is unsafe as hell, and lots of stuff could be made safer trivially in a new language (say, rust or F*).

zaarn 9y ago
Just as a sidenote, rust has no defined behaviour when dereferencing a null pointer. What makes it worse is that a null pointer in an option<> is handled as None instead of Some, which kind of broke some of my code until I found that particularly nasty bug and worked around it (with offsets).
- ernst_klim 9y ago
  Rust does not have nulls beyond unsafe blocks, does it? >What makes it worse is that a null pointer in an option<> is handled as None instead of Some What? How could NULL be treated as Some?
  - steveklabnik 9y ago
    It does not. I think your parent must have been doing something strange; if you have a *const T, one that's null will still be a Some. It's &T, which cannot be null by definition, that uses the null value as None, since it cannot be null.
    - zaarn 9y ago
      I was actually using mut/const and got this bug, I don't think I used &T since I was handling raw memory addresses.
      - steveklabnik 9y ago