5 ms·

And yet another "C++ sucks, Rust is better" thread. Why are these C++ bashing threads practically always about Rust? I have nothing against the language but I

by janoc 6y ago

And yet another "C++ sucks, Rust is better" thread. Why are these C++ bashing threads practically always about Rust? I have nothing against the language but I do feel the Rust devs have some sort of inferiority complex and a compulsive need to convince everyone about the superiority of their tool. Guys, these endless pissing contests are not really productive.

sfkdjf9j3j 6y ago
It's an article about Rust, why wouldn't people be talking about Rust in the comments?
- saagarjha 6y ago
  I'm sure the implicit question was "why are these articles always about Rust".
  - the_only_law 6y ago
    Because alternatives are either not mature or too old and not C-like enough to be cool ig
    - blub 6y ago
      Another plausible explanation is that Rust job numbers continue to be rather thin, which gives Rust fans on average more free time to write blog posts and open-source libraries. :)
FpUser 6y ago
>"What happens if the file has been deleted between the directory listing and the open?" Did author even know that one can check stream state or have it throw exception. It is a very poor attempt at pissing contest.
spiffytech 6y ago
I think it's because Rust was started by a high-profile, respected company specifically because they felt C++ was inadequate for their use case, and they had the expertise to be authoritative about that inadequacy. That means Rust is a technologically natural counterpoint to C++ because it was literally designed to be a C++ replacement, and coming from a high-profile company means its entire target audience found out about it very quickly, so any discussion relevant to Rust can find plenty of participants. The rest is just due to all the usual reasons programmers bicker about things, and we've seen this language bickering again and again before, it's just a different language's turn in the spotlight. I'd love to see these discussions include a more coherent analysis of when a language is appropriate, instead of assuming everyone should always make the same choice. If I'm starting greenfield, when should I pick C++ over Rust? If I'm looking at C++ alternatives, how would I choose between Rust and Golang? Is D ever a better choice? When? Why do we act like you can only pick one, when IPC and FFI and microservices mean you can split the difference if a language is only best for a portion of your project?
- danhor 6y ago
  (Have [mostly embedded] rust experience, only dabbled in go) > Is D ever a better choice? When? Probably not, very small community, few resources, etc. … > Why do we act like you can only pick one, when IPC and FFI and microservices mean you can split the difference if a language is only best for a portion of your project? FFI is a huge pain and pretty slow in golang if not already done for you. IPC & microservices do have a lot of overhead, so you probably don't want use it for e.g. your text parser. It also makes it harder to use established knowledge in another language. > If I'm starting greenfield, when should I pick C++ over Rust? - Do you have experienced C++ developers/are you one? - Is your environment geared for C/C++ code, e.g. kernel modules or RTOSes, maybe game development? - Do you have dependencies that strongly expect you to use a certain language, e.g. QT or (less so) GTK? Might be a pain to use with Rust > If I'm looking at C++ alternatives, how would I choose between Rust and Golang? - Rust is more speed/correctness focused while Go feels a bit like a faster scripting language. So something that might have started in python is probably a better match for go (a webserver, something script-like) - Go really isn't meant for constrained environments (although there do exist solutions) like small linux IOT devices or even bare-metal stuff, I feel like Go & Rust are pretty good complements and while you can do a lot of things with both, they are clearly very different. For some examples, with what I'd recommend, not necessarily what I'd use, since I do have a huge fondness for Rust, not so much for go - Normal web backend: Go - High performance web server: Rust - DB: Rust - App server: Go - Crypto (the non-money kind) stuff: Rust - WASM (it's pretty embedded-like): Rust
skocznymroczny 6y ago
Don't worry, it's not always about Rust. Sometimes it's about D :)
steveklabnik 6y ago
The first person to write a response post to the original post used Go, with an even more aggressive title than this (IMHO) http://jmoiron.net/blog/cpp-deserves-its-bad-reputation/ http://jmoiron.net/blog/cpp-deserves-its-bad-reputation/ A bunch of people have been doing it in a bunch of languages. It’s kind of the natural way to explore the topic.

by janoc 6y ago

sfkdjf9j3j 6y ago

It's an article about Rust, why wouldn't people be talking about Rust in the comments?

saagarjha 6y ago
I'm sure the implicit question was "why are these articles always about Rust".
- the_only_law 6y ago
  Because alternatives are either not mature or too old and not C-like enough to be cool ig
  - blub 6y ago
    Another plausible explanation is that Rust job numbers continue to be rather thin, which gives Rust fans on average more free time to write blog posts and open-source libraries. :)

FpUser 6y ago

>"What happens if the file has been deleted between the directory listing and the open?" Did author even know that one can check stream state or have it throw exception. It is a very poor attempt at pissing contest.

spiffytech 6y ago

I think it's because Rust was started by a high-profile, respected company specifically because they felt C++ was inadequate for their use case, and they had the expertise to be authoritative about that inadequacy. That means Rust is a technologically natural counterpoint to C++ because it was literally designed to be a C++ replacement, and coming from a high-profile company means its entire target audience found out about it very quickly, so any discussion relevant to Rust can find plenty of participants. The rest is just due to all the usual reasons programmers bicker about things, and we've seen this language bickering again and again before, it's just a different language's turn in the spotlight. I'd love to see these discussions include a more coherent analysis of when a language is appropriate, instead of assuming everyone should always make the same choice. If I'm starting greenfield, when should I pick C++ over Rust? If I'm looking at C++ alternatives, how would I choose between Rust and Golang? Is D ever a better choice? When? Why do we act like you can only pick one, when IPC and FFI and microservices mean you can split the difference if a language is only best for a portion of your project?

danhor 6y ago
(Have [mostly embedded] rust experience, only dabbled in go) > Is D ever a better choice? When? Probably not, very small community, few resources, etc. … > Why do we act like you can only pick one, when IPC and FFI and microservices mean you can split the difference if a language is only best for a portion of your project? FFI is a huge pain and pretty slow in golang if not already done for you. IPC & microservices do have a lot of overhead, so you probably don't want use it for e.g. your text parser. It also makes it harder to use established knowledge in another language. > If I'm starting greenfield, when should I pick C++ over Rust? - Do you have experienced C++ developers/are you one? - Is your environment geared for C/C++ code, e.g. kernel modules or RTOSes, maybe game development? - Do you have dependencies that strongly expect you to use a certain language, e.g. QT or (less so) GTK? Might be a pain to use with Rust > If I'm looking at C++ alternatives, how would I choose between Rust and Golang? - Rust is more speed/correctness focused while Go feels a bit like a faster scripting language. So something that might have started in python is probably a better match for go (a webserver, something script-like) - Go really isn't meant for constrained environments (although there do exist solutions) like small linux IOT devices or even bare-metal stuff, I feel like Go & Rust are pretty good complements and while you can do a lot of things with both, they are clearly very different. For some examples, with what I'd recommend, not necessarily what I'd use, since I do have a huge fondness for Rust, not so much for go - Normal web backend: Go - High performance web server: Rust - DB: Rust - App server: Go - Crypto (the non-money kind) stuff: Rust - WASM (it's pretty embedded-like): Rust

skocznymroczny 6y ago

Don't worry, it's not always about Rust. Sometimes it's about D :)

steveklabnik 6y ago

The first person to write a response post to the original post used Go, with an even more aggressive title than this (IMHO) http://jmoiron.net/blog/cpp-deserves-its-bad-reputation/ http://jmoiron.net/blog/cpp-deserves-its-bad-reputation/ A bunch of people have been doing it in a bunch of languages. It’s kind of the natural way to explore the topic.