6 ms·

Modern C++ is certainly good compared to old C++, or compared to C. But this article completely glosses over why the author chose not to go with Rust. From just

by eridius 11y ago

Modern C++ is certainly good compared to old C++, or compared to C. But this article completely glosses over why the author chose not to go with Rust. From just the article alone, my impression is basically that the author just decided to lump Rust in with all the other "shiny" languages and didn't really look into it much. And that's a real shame, because unlike any of the other languages that are listed, Rust is basically a better alternative to C++ for almost any usage of C++ that doesn't require interoperating with existing C++ libraries (or vending new C++-specific APIs).

santaclaus 11y ago
> Rust is basically a better alternative to C++ for almost any usage of C++ that doesn't require interoperating with existing C++ libraries What often isn't mentioned is that C++ has a much more diverse ecosystem than Rust. C++ has four major compilers, three major standard library implementations, and 30 years of associated tooling and library development. Occasional serious issues in GCC and libstdc++ (or Clang and libc++, or in Microsoft, ...) do crop up, and the ability to cross reference alternative toolchains is quite valuable. If Rust can hit enough critical mass the ecosystem will develop, but it isn't there, yet.
- forrestthewoods 11y ago
  Can I easily use and debug Rust on Windows, Mac, Linux, iOS, Android, Playstation, and Xbox? Then it's not a viable option.
  - tomjakubowski 11y ago
    > Can I easily use and debug Rust on Windows, Mac, Linux, iOS, Android Yes. > Playstation With a little effort, probably; the toolchains both use LLVM, and writing a custom target for Rust is possible. Someone managed to do it back in the dark times when Rust still depended on libuv [1]. I think that was before the "flexible target specification" [2] was a thing, too. Whether Sony would allow you to distribute a game written in Rust is another question ;-) > Xbox Nope. [1]: https://twitter.com/wickerwaka/status/479842553831776257 https://twitter.com/wickerwaka/status/479842553831776257 [2]: https://github.com/rust-lang/rfcs/blob/master/text/0131-target-specification.md https://github.com/rust-lang/rfcs/blob/master/text/0131-targ...
    - pjmlp 11y ago
      > Can I easily use and debug Rust on Windows, Mac, Linux, iOS, Android > Yes. Easily means using something like Visual Studio debuggers, with its graphical visualizers. Command line gdb is something I use when there isn't any other option available.
      - dkersten 11y ago
        As someone who used to write a ton of C++ and only occasionally fired up gdb (and never anything fancier), I feel like maybe "easily" means different things to different people. Going by what was said above and how I developed in C++, it sounds like "easily" to me.
        pjmlp 11y ago
        Yeah, I always been an IDE guy since Turbo Pascal 5.5 and only reluctantly used vi and Emacs as poor man's IDE replacement.
      - steveklabnik 11y ago
        I haven't used it yet, but https://github.com/pistondevelopers/visualrust https://github.com/pistondevelopers/visualrust claims to have started MIEngine integration.
        pjmlp 11y ago
        Thanks for the heads up.
      - forrestthewoods 11y ago
        Easy means: * breakpoint debugging * ability to step debugger line by line * high quality watch window GDB does not qualify as easy. Ability to printf debug, while 100% mandatory, is also not easy.
      - pcwalton 11y ago
        Rust debugging works beautifully with Xcode. I would assume it works with Linux graphical debugging tools as well. Visual Studio support is mostly gated on LLVM support for PDB. We do have support for using the MSVC toolchain as of a couple of releases ago, so I'm not actually sure what if anything is left to get that working.
- dikaiosune 11y ago
  But those same features make it very bewildering and difficult for newcomers. Four different compiler behaviors to read about in any area not defined by the standard, tooling that can require a long and complex setup from an expert, and 30 years of differing opinions about good development practices crufting up learning resources.
  - fsloth 11y ago
    "But those same features make it very bewildering and difficult for newcomers" Yes, that is very true. "tooling that can require a long and complex setup from an expert" If one is on windows, one can 1. install visual studio community edition and 2. click "new project". Sure, it's nowhere close to npm or Rusts's crates or go's dependency management but that's bit hyperbolic way to express it. I can waste hours trying to get Rusts' dependencies working if I'm using something bleeding edge.
    - dikaiosune 11y ago
      Not having used C++ on Windows, I have to take that at face value. But getting autotools or cmake set up as a new C++ developer...not super fun. Also, spending lots of time setting up bleeding edge features is different than trying to get a single working build with a couple of fairly standard dependencies.
      - pjmlp 11y ago
        Having started with C++ IDEs on MS-DOS, OS/2 and Windows, UNIX development was never appealing to me. I have spent a big part of my time trying to find that IDE developer experience back. Nowadays Qt and KDevelop do a good job, but it wasn't always like that, specially in the mid-90's when we were already enjoying C++ Builder and Delphi on Windows.
      - fsloth 11y ago
        "But getting autotools or cmake set up as a new C++ developer...not super fun." Yes, this is the main reason I prefer visual studio :). I know my way around unixes but since I don't use them for my daily work I forget most of the things I would need to remember to be productive.
- pcwalton 11y ago
  You could say the same thing about any new language that has come up in the past 20 years. Yet new languages do appear and become popular all the time.
  - AnimalMuppet 11y ago
    They don't become as popular as C++ very often, though...
- deleted 11y ago
  [deleted]
wuch 11y ago
I have been playing with Rust for a few weeks now, so I can give a few reasons not to use it. What I will write may sound overly negative, but keep in mind that those are only reasons not to use it, in general I found a lot to like in Rust. Unsurprisingly most of issues described below, boil down to Rust not being mature yet, and are perfectly fixable. However, fixing some of those will break backward compatibility one way or other and require effort that would be unnecessary otherwise. Language is underspecified. In what order are subexpression evaluated in Rust? Unspecified yet, in fact it is even worse than that, it differs between borrow checkers (which I think uses the most useful one given Rust syntax: right to left behaviour), while code generation assumes left to right order. https://github.com/rust-lang/rust/issues/28160 https://github.com/rust-lang/rust/issues/28160 What can you do with pointers in unsafe parts of code so that everything is still well-defined. There does not seem to be real answer to this question yet: https://github.com/rust-lang/rfcs/issues/1447 https://github.com/rust-lang/rfcs/issues/1447 What does Rust guarantee with respect to lifetimes? In fact it guarantees much less than what would you expect. Take for example a drain method of a Vec. Drain gives you an iterator that moves elements out of a Vec. Naive implementation would leave Vec in a inconsistent state while drain iterator is still alive (because some of elements are already moved from), but restore Vec to a valid state in destructor of drain iterator. It appears to work because no one can touch Vec while drain iterators still holds mutable reference to it. Except it wouldn't work, because Rust does not guarantee that drain destructor will be executed, in fact in perfectly safe code it may not be executed at all. Surprisingly a borrow of a mutable reference may outlive the lifetime of a referent. At least it seems that Rust guarantees that those references would be inaccessible. https://internals.rust-lang.org/t/are-memory-leaks-considered-to-violate-memory-safety/1674/2 https://internals.rust-lang.org/t/are-memory-leaks-considere... There are quite a few language issues like this, and in general I found it very hard to find what exactly Rust semantics is. Rust sends mixed signals about panic. On one hand it try to tells you that code that panics is probably badly broken, and may have left data structures in an inconsistent state, so you should not even try to access them. And Rust tries to ensure this to some degree by putting roadblocks on your way if you think otherwise (see Mutex poisoning, and strange things like AssertRecoverSafe you have to use when recovering from panics). Except in reality, all your desctructors already do access all those data structures. It seems that all those roadblocks are quite pointless. Running out of memory aborts program. This is I think quite a bad decision (it seems that this may be a temporary one) for a language that have exceptions in form of panic. Not many programs need to handle out of memory situations, but handling those in programming language with exceptions and RAII is quite easy, and mostly boils down to: don't perform dynamic memory allocation in destructors. This is a step backwards from C++. Bugs, bugs and more bugs. Rust not calling your desctructor for variables in the same scope after panic, still there after more than a year: https://github.com/rust-lang/rust/issues/14875 https://github.com/rust-lang/rust/issues/14875 Borrow checker is interesting, certainly prevents you from writing buggy code, but also prevents you from writing code which is perfectly fine. In certainly does not play nice with ideas which are very common in C++ world, any STL algorithm + container would be a good example. I am still not sure if it is worth the effort, it seems to prevent problems that I don't commit in C++ anyway. Immature state of ecosystem, libraries, documentation, ... . In general you probably will not be as productive in Rust now as you would be in other languages. If you are interested in developing those libraries that are currently lacking, having some impact in how Rust language may look in a future, then Rust community is certainly great. But a lot of people have different priorities.
thinkpad20 11y ago
I got this impression as well. It seems like Rust would have been a great fit for what he/she is looking for. For example, calling into Rust from Python is dead simple because of its C-compatible ABI.
- Ygg2 11y ago
  Rust doesn't have stable ABI. I think what you meant is that Rust exposes C API.
  - thinkpad20 11y ago
    Hmm, I guess I'm not familiar enough with the terms to be confident that I'm using the correct terminology, but in any case it's very easy to call Rust code from C, or from Python, etc. Anything that can call C code can call Rust code (with a few compiler directives around the desired functions to prevent name mangling etc). This might not be the exact same thing as having the same ABI (although I had been under the impression that that is what it meant). Examples: http://blog.rust-lang.org/2015/04/24/Rust-Once-Run-Everywhere.html http://blog.rust-lang.org/2015/04/24/Rust-Once-Run-Everywher... https://gist.github.com/seanjensengrey/f5d73bbdf22cfa1ad463 https://gist.github.com/seanjensengrey/f5d73bbdf22cfa1ad463
    - tatterdemalion 11y ago
      "Rust's ABI" is the representation of functions without `extern` declarations. `extern` causes functions to use a different ABI, by default `extern "C"`. https://doc.rust-lang.org/reference.html#extern-functions https://doc.rust-lang.org/reference.html#extern-functions
  - eridius 11y ago
    It's not that Rust has a C API, it's that Rust has a simple means by which you can mark a function as using the C calling convention, and export this function as a symbol from your library, which lets anything else that speaks the C calling convention (e.g. C, or plenty of other languages) invoke that function.

by eridius 11y ago

santaclaus 11y ago

> Rust is basically a better alternative to C++ for almost any usage of C++ that doesn't require interoperating with existing C++ libraries What often isn't mentioned is that C++ has a much more diverse ecosystem than Rust. C++ has four major compilers, three major standard library implementations, and 30 years of associated tooling and library development. Occasional serious issues in GCC and libstdc++ (or Clang and libc++, or in Microsoft, ...) do crop up, and the ability to cross reference alternative toolchains is quite valuable. If Rust can hit enough critical mass the ecosystem will develop, but it isn't there, yet.

forrestthewoods 11y ago
Can I easily use and debug Rust on Windows, Mac, Linux, iOS, Android, Playstation, and Xbox? Then it's not a viable option.
- tomjakubowski 11y ago
  > Can I easily use and debug Rust on Windows, Mac, Linux, iOS, Android Yes. > Playstation With a little effort, probably; the toolchains both use LLVM, and writing a custom target for Rust is possible. Someone managed to do it back in the dark times when Rust still depended on libuv [1]. I think that was before the "flexible target specification" [2] was a thing, too. Whether Sony would allow you to distribute a game written in Rust is another question ;-) > Xbox Nope. [1]: https://twitter.com/wickerwaka/status/479842553831776257 https://twitter.com/wickerwaka/status/479842553831776257 [2]: https://github.com/rust-lang/rfcs/blob/master/text/0131-target-specification.md https://github.com/rust-lang/rfcs/blob/master/text/0131-targ...
  - pjmlp 11y ago
    > Can I easily use and debug Rust on Windows, Mac, Linux, iOS, Android > Yes. Easily means using something like Visual Studio debuggers, with its graphical visualizers. Command line gdb is something I use when there isn't any other option available.
    - dkersten 11y ago
      As someone who used to write a ton of C++ and only occasionally fired up gdb (and never anything fancier), I feel like maybe "easily" means different things to different people. Going by what was said above and how I developed in C++, it sounds like "easily" to me.
      - pjmlp 11y ago
        Yeah, I always been an IDE guy since Turbo Pascal 5.5 and only reluctantly used vi and Emacs as poor man's IDE replacement.
    - steveklabnik 11y ago
      I haven't used it yet, but https://github.com/pistondevelopers/visualrust https://github.com/pistondevelopers/visualrust claims to have started MIEngine integration.
      - pjmlp 11y ago
        Thanks for the heads up.
    - forrestthewoods 11y ago
      Easy means: * breakpoint debugging * ability to step debugger line by line * high quality watch window GDB does not qualify as easy. Ability to printf debug, while 100% mandatory, is also not easy.
    - pcwalton 11y ago
      Rust debugging works beautifully with Xcode. I would assume it works with Linux graphical debugging tools as well. Visual Studio support is mostly gated on LLVM support for PDB. We do have support for using the MSVC toolchain as of a couple of releases ago, so I'm not actually sure what if anything is left to get that working.
dikaiosune 11y ago
But those same features make it very bewildering and difficult for newcomers. Four different compiler behaviors to read about in any area not defined by the standard, tooling that can require a long and complex setup from an expert, and 30 years of differing opinions about good development practices crufting up learning resources.
- fsloth 11y ago
  "But those same features make it very bewildering and difficult for newcomers" Yes, that is very true. "tooling that can require a long and complex setup from an expert" If one is on windows, one can 1. install visual studio community edition and 2. click "new project". Sure, it's nowhere close to npm or Rusts's crates or go's dependency management but that's bit hyperbolic way to express it. I can waste hours trying to get Rusts' dependencies working if I'm using something bleeding edge.
  - dikaiosune 11y ago
    Not having used C++ on Windows, I have to take that at face value. But getting autotools or cmake set up as a new C++ developer...not super fun. Also, spending lots of time setting up bleeding edge features is different than trying to get a single working build with a couple of fairly standard dependencies.
    - pjmlp 11y ago
      Having started with C++ IDEs on MS-DOS, OS/2 and Windows, UNIX development was never appealing to me. I have spent a big part of my time trying to find that IDE developer experience back. Nowadays Qt and KDevelop do a good job, but it wasn't always like that, specially in the mid-90's when we were already enjoying C++ Builder and Delphi on Windows.
    - fsloth 11y ago
      "But getting autotools or cmake set up as a new C++ developer...not super fun." Yes, this is the main reason I prefer visual studio :). I know my way around unixes but since I don't use them for my daily work I forget most of the things I would need to remember to be productive.
pcwalton 11y ago
You could say the same thing about any new language that has come up in the past 20 years. Yet new languages do appear and become popular all the time.
- AnimalMuppet 11y ago
  They don't become as popular as C++ very often, though...
deleted 11y ago
[deleted]

wuch 11y ago

I have been playing with Rust for a few weeks now, so I can give a few reasons not to use it. What I will write may sound overly negative, but keep in mind that those are only reasons not to use it, in general I found a lot to like in Rust. Unsurprisingly most of issues described below, boil down to Rust not being mature yet, and are perfectly fixable. However, fixing some of those will break backward compatibility one way or other and require effort that would be unnecessary otherwise. Language is underspecified. In what order are subexpression evaluated in Rust? Unspecified yet, in fact it is even worse than that, it differs between borrow checkers (which I think uses the most useful one given Rust syntax: right to left behaviour), while code generation assumes left to right order. https://github.com/rust-lang/rust/issues/28160 https://github.com/rust-lang/rust/issues/28160 What can you do with pointers in unsafe parts of code so that everything is still well-defined. There does not seem to be real answer to this question yet: https://github.com/rust-lang/rfcs/issues/1447 https://github.com/rust-lang/rfcs/issues/1447 What does Rust guarantee with respect to lifetimes? In fact it guarantees much less than what would you expect. Take for example a drain method of a Vec. Drain gives you an iterator that moves elements out of a Vec. Naive implementation would leave Vec in a inconsistent state while drain iterator is still alive (because some of elements are already moved from), but restore Vec to a valid state in destructor of drain iterator. It appears to work because no one can touch Vec while drain iterators still holds mutable reference to it. Except it wouldn't work, because Rust does not guarantee that drain destructor will be executed, in fact in perfectly safe code it may not be executed at all. Surprisingly a borrow of a mutable reference may outlive the lifetime of a referent. At least it seems that Rust guarantees that those references would be inaccessible. https://internals.rust-lang.org/t/are-memory-leaks-considered-to-violate-memory-safety/1674/2 https://internals.rust-lang.org/t/are-memory-leaks-considere... There are quite a few language issues like this, and in general I found it very hard to find what exactly Rust semantics is. Rust sends mixed signals about panic. On one hand it try to tells you that code that panics is probably badly broken, and may have left data structures in an inconsistent state, so you should not even try to access them. And Rust tries to ensure this to some degree by putting roadblocks on your way if you think otherwise (see Mutex poisoning, and strange things like AssertRecoverSafe you have to use when recovering from panics). Except in reality, all your desctructors already do access all those data structures. It seems that all those roadblocks are quite pointless. Running out of memory aborts program. This is I think quite a bad decision (it seems that this may be a temporary one) for a language that have exceptions in form of panic. Not many programs need to handle out of memory situations, but handling those in programming language with exceptions and RAII is quite easy, and mostly boils down to: don't perform dynamic memory allocation in destructors. This is a step backwards from C++. Bugs, bugs and more bugs. Rust not calling your desctructor for variables in the same scope after panic, still there after more than a year: https://github.com/rust-lang/rust/issues/14875 https://github.com/rust-lang/rust/issues/14875 Borrow checker is interesting, certainly prevents you from writing buggy code, but also prevents you from writing code which is perfectly fine. In certainly does not play nice with ideas which are very common in C++ world, any STL algorithm + container would be a good example. I am still not sure if it is worth the effort, it seems to prevent problems that I don't commit in C++ anyway. Immature state of ecosystem, libraries, documentation, ... . In general you probably will not be as productive in Rust now as you would be in other languages. If you are interested in developing those libraries that are currently lacking, having some impact in how Rust language may look in a future, then Rust community is certainly great. But a lot of people have different priorities.

thinkpad20 11y ago

I got this impression as well. It seems like Rust would have been a great fit for what he/she is looking for. For example, calling into Rust from Python is dead simple because of its C-compatible ABI.

Ygg2 11y ago
Rust doesn't have stable ABI. I think what you meant is that Rust exposes C API.
- thinkpad20 11y ago
  Hmm, I guess I'm not familiar enough with the terms to be confident that I'm using the correct terminology, but in any case it's very easy to call Rust code from C, or from Python, etc. Anything that can call C code can call Rust code (with a few compiler directives around the desired functions to prevent name mangling etc). This might not be the exact same thing as having the same ABI (although I had been under the impression that that is what it meant). Examples: http://blog.rust-lang.org/2015/04/24/Rust-Once-Run-Everywhere.html http://blog.rust-lang.org/2015/04/24/Rust-Once-Run-Everywher... https://gist.github.com/seanjensengrey/f5d73bbdf22cfa1ad463 https://gist.github.com/seanjensengrey/f5d73bbdf22cfa1ad463
  - tatterdemalion 11y ago
    "Rust's ABI" is the representation of functions without `extern` declarations. `extern` causes functions to use a different ABI, by default `extern "C"`. https://doc.rust-lang.org/reference.html#extern-functions https://doc.rust-lang.org/reference.html#extern-functions
- eridius 11y ago
  It's not that Rust has a C API, it's that Rust has a simple means by which you can mark a function as using the C calling convention, and export this function as a symbol from your library, which lets anything else that speaks the C calling convention (e.g. C, or plenty of other languages) invoke that function.