9 ms·

I'm not sure why anyone today would start a greenfield project in C++ instead of D, rust or Nim. Maybe in niches where C++ is deeply rooted, like games.

by auxym 8y ago

21 8y ago
For one thing, there are many more C++ programmers out thare than D or Rust. And nobody heard of Nim.
throwawaymath 8y ago
I've never heard of Nim. Is this it: https://nim-lang.org https://nim-lang.org? Why would you choose Nim over C++?
shaklee3 8y ago
In many ways, it's about being the first to do something. I write a lot of code around DPDK for packet processing. It's a pure C library. I know rust has good C bindings, but I heard Go did as well. I started a project in go using cgo for the dpdk parts. What a nightmare. I spent more time figuring out the idiosyncrasies of cgo than actually writing useful code. And in many cases, cgo couldn't actually do what I needed to do. I had to write some functions and see inside of the .go file. I'm sure rust would have been easier to call C with since the languages bare inherently more compatible, but I don't want to go down that path again right now.
- nickpsecurity 8y ago
  The Go language has weak, C interoperability. The parents are strong in it. You wouldnt be going down same path. More like the opposite one that is closer to your actual goals. I recommend Rust or D for your next try since compiler quality is best for those. D will be easiest to learn. You can always use unsafe in either if memory management gets in way.
FartyMcFarter 8y ago
Because C++ is a stable, reliable and well supported (read: production-ready) language that works on many platforms. Last I heard D was definitely not all of those (it doesn't even have a straight story on garbage collection, as its creator said himself! [1]), and I'm not sure about Rust or Nim. [1] https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why/answer/Andrei-Alexandrescu https://www.quora.com/Which-language-has-the-brightest-futur...
- steveklabnik 8y ago
  Rust is used in production by hundreds of companies, from ones as large as Facebook, Amazon, and Microsoft, down to tiny new startups.
  - snovv_crash 8y ago
    What is the state of UI bindings?
    - steveklabnik 8y ago
      GTK is coming along really well. There’s two different native-to-Rust ones in progress I’m excited about. It’s not my area of specialty though.
  - gumby 8y ago
    As is C++ at all of those companies.
    - steveklabnik 8y ago
      Sure. The question was if Rust was production ready, it has nothing directy to do with C++. Everyone knows C++ is production ready.
  - int_19h 8y ago
    The visual tooling is still very meh though. Just compare the kind of code completion you get for C++ (even something as gnarly as Boost) in modern IDEs, to what RLS can do in VSCode.
    - steveklabnik 8y ago
      IntelliJ is heavily investing, and it’s already showing. We are too: https://ferrous-systems.com/blog/rust-analyzer-2019/ https://ferrous-systems.com/blog/rust-analyzer-2019/ But yeah, if that matters to you, it’s less mature. We’ll get there!
jjuhl 8y ago
Because "it's the language you know best" is a perfectly valid reason. Another valid reason is that, if used properly, C++ performance blows other languages out of the water.
- auxym 8y ago
  Based on what I've seen, rust really can be just as fast. D and Nim are a bit more iffy since they have built in GC. It can be turned off, but at that point you lose a major selling point over C++, memory safety.
snovv_crash 8y ago
What about cross platform with UI and requiring high performance? Eg anything for consumers with image processing. Hard to beat C++ and Qt in this case, IMO.
- pedrocr 8y ago
  For the UI rust has bindings for a lot of stuff and it's easy to generate more. There are also more and more native options. It's also very good for that use case because it makes certain high-performance things much easier/safer. Threading is a joy for example. I've worked on an image processing project in C for a while and am now doing one in rust and would never want to go back. The code is much cleaner and easy to maintain. The zero-cost abstractions really pay off, and the safety guarantees means you don't spend so much of your time chasing heisenbugs from subtle threading and locking issues.
  - danieldk 8y ago
    For the UI rust has bindings for a lot of stuff and it's easy to generate more. I use Rust as my main language, but as far as I have seen gtk-rs is the only somewhat mature binding for an existing UI toolkit. This is not coincidental, since Gtk+ is a C (with objects) toolkit, it is much easier to bind than toolkits in other languages. Unfortunately, outside Linux, Gtk+ also looks pretty out of place. AFAIK, there isn't any binding for e.g. Qt or Cocoa that has wide API coverage and is mature. Definitely not for production-level work. I think currently the only viable solution is to write a core in C++, expose C functions and write the UI in C++, Swift, etc.
    - pedrocr 8y ago
      I searched and saw some Qt bindings as well, but didn't check if they're complete. I've decided to just do 100% rust so I use conrod instead of bindings. But the cases where I've tried the GObject stuff it did indeed seem pretty well done, at least in the Gstreamer case. I'd expect that over time even this gets fixed and Qt bindings become first class as well. > I think currently the only viable solution is to write a core in C++, expose C functions and write the UI in C++, Swift, etc. This is the worst case and is not that bad. It does force you to write in two languages but on the other hand it enforces a cleaner UI vs backend split and that's not a bad habit to have.
AlexMax 8y ago
I like Nim but its ffi, while really good, is not effortless. You have to wrap every function you call, which in large C libraries can be an incredible pain in the neck. There are tools to help you out, like c2nim, but in my experience the output it produces requires fixing to get it working, and of course when the upstream library changes or adds to its API those sorts of things have to be taken into account as well.
JulianMorrison 8y ago
Real world answer: no code is greenfield. You work in the established ecosystem.
floatboth 8y ago
C++ is ubiquitous. Pretty much any modern unix on any CPU architecture — it's there. And it likes shared libraries.
int_19h 8y ago
C++ is going to be around in 20 years. Maybe as legacy (although I doubt that), but there will be support for it even so. It's not a given for Rust, and especially not a given for D or Nim (since they don't have any large companies behind them).

I'm not sure why anyone today would start a greenfield project in C++ instead of D, rust or Nim. Maybe in niches where C++ is deeply rooted, like games.

by auxym 8y ago

I'm not sure why anyone today would start a greenfield project in C++ instead of D, rust or Nim. Maybe in niches where C++ is deeply rooted, like games.

21 8y ago

For one thing, there are many more C++ programmers out thare than D or Rust. And nobody heard of Nim.

throwawaymath 8y ago

I've never heard of Nim. Is this it: https://nim-lang.org https://nim-lang.org? Why would you choose Nim over C++?

shaklee3 8y ago

In many ways, it's about being the first to do something. I write a lot of code around DPDK for packet processing. It's a pure C library. I know rust has good C bindings, but I heard Go did as well. I started a project in go using cgo for the dpdk parts. What a nightmare. I spent more time figuring out the idiosyncrasies of cgo than actually writing useful code. And in many cases, cgo couldn't actually do what I needed to do. I had to write some functions and see inside of the .go file. I'm sure rust would have been easier to call C with since the languages bare inherently more compatible, but I don't want to go down that path again right now.

nickpsecurity 8y ago
The Go language has weak, C interoperability. The parents are strong in it. You wouldnt be going down same path. More like the opposite one that is closer to your actual goals. I recommend Rust or D for your next try since compiler quality is best for those. D will be easiest to learn. You can always use unsafe in either if memory management gets in way.

FartyMcFarter 8y ago

Because C++ is a stable, reliable and well supported (read: production-ready) language that works on many platforms. Last I heard D was definitely not all of those (it doesn't even have a straight story on garbage collection, as its creator said himself! [1]), and I'm not sure about Rust or Nim. [1] https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why/answer/Andrei-Alexandrescu https://www.quora.com/Which-language-has-the-brightest-futur...

steveklabnik 8y ago
Rust is used in production by hundreds of companies, from ones as large as Facebook, Amazon, and Microsoft, down to tiny new startups.
- snovv_crash 8y ago
  What is the state of UI bindings?
  - steveklabnik 8y ago
    GTK is coming along really well. There’s two different native-to-Rust ones in progress I’m excited about. It’s not my area of specialty though.
- gumby 8y ago
  As is C++ at all of those companies.
  - steveklabnik 8y ago
    Sure. The question was if Rust was production ready, it has nothing directy to do with C++. Everyone knows C++ is production ready.
- int_19h 8y ago
  The visual tooling is still very meh though. Just compare the kind of code completion you get for C++ (even something as gnarly as Boost) in modern IDEs, to what RLS can do in VSCode.
  - steveklabnik 8y ago
    IntelliJ is heavily investing, and it’s already showing. We are too: https://ferrous-systems.com/blog/rust-analyzer-2019/ https://ferrous-systems.com/blog/rust-analyzer-2019/ But yeah, if that matters to you, it’s less mature. We’ll get there!

jjuhl 8y ago

Because "it's the language you know best" is a perfectly valid reason. Another valid reason is that, if used properly, C++ performance blows other languages out of the water.

auxym 8y ago
Based on what I've seen, rust really can be just as fast. D and Nim are a bit more iffy since they have built in GC. It can be turned off, but at that point you lose a major selling point over C++, memory safety.

snovv_crash 8y ago

What about cross platform with UI and requiring high performance? Eg anything for consumers with image processing. Hard to beat C++ and Qt in this case, IMO.

pedrocr 8y ago
For the UI rust has bindings for a lot of stuff and it's easy to generate more. There are also more and more native options. It's also very good for that use case because it makes certain high-performance things much easier/safer. Threading is a joy for example. I've worked on an image processing project in C for a while and am now doing one in rust and would never want to go back. The code is much cleaner and easy to maintain. The zero-cost abstractions really pay off, and the safety guarantees means you don't spend so much of your time chasing heisenbugs from subtle threading and locking issues.
- danieldk 8y ago
  For the UI rust has bindings for a lot of stuff and it's easy to generate more. I use Rust as my main language, but as far as I have seen gtk-rs is the only somewhat mature binding for an existing UI toolkit. This is not coincidental, since Gtk+ is a C (with objects) toolkit, it is much easier to bind than toolkits in other languages. Unfortunately, outside Linux, Gtk+ also looks pretty out of place. AFAIK, there isn't any binding for e.g. Qt or Cocoa that has wide API coverage and is mature. Definitely not for production-level work. I think currently the only viable solution is to write a core in C++, expose C functions and write the UI in C++, Swift, etc.
  - pedrocr 8y ago
    I searched and saw some Qt bindings as well, but didn't check if they're complete. I've decided to just do 100% rust so I use conrod instead of bindings. But the cases where I've tried the GObject stuff it did indeed seem pretty well done, at least in the Gstreamer case. I'd expect that over time even this gets fixed and Qt bindings become first class as well. > I think currently the only viable solution is to write a core in C++, expose C functions and write the UI in C++, Swift, etc. This is the worst case and is not that bad. It does force you to write in two languages but on the other hand it enforces a cleaner UI vs backend split and that's not a bad habit to have.

AlexMax 8y ago

I like Nim but its ffi, while really good, is not effortless. You have to wrap every function you call, which in large C libraries can be an incredible pain in the neck. There are tools to help you out, like c2nim, but in my experience the output it produces requires fixing to get it working, and of course when the upstream library changes or adds to its API those sorts of things have to be taken into account as well.

JulianMorrison 8y ago

Real world answer: no code is greenfield. You work in the established ecosystem.

floatboth 8y ago

C++ is ubiquitous. Pretty much any modern unix on any CPU architecture — it's there. And it likes shared libraries.

int_19h 8y ago

C++ is going to be around in 20 years. Maybe as legacy (although I doubt that), but there will be support for it even so. It's not a given for Rust, and especially not a given for D or Nim (since they don't have any large companies behind them).