4 ms·

> because there is a place for a language that is safer to use than C++, yet performs at similar speeds and doesn't handhold you like C#/Java do. And sometimes

> because there is a place for a language that is safer to use than C++, yet performs at similar speeds and doesn't handhold you like C#/Java do. And sometimes some people (like me) would argue that C++ (11&14) is actually that language. A subset of C++ is actually very perfomant and safe for most of the uses.

Sean1708 11y ago
Which is absolutely fine, but competition is never a bad thing.
UK-AL 11y ago
People want C++ without the overwhelming choice it gives you.
Manishearth 11y ago
Note that it isn't 100% memory safe, it doesn't protect against iterator invalidation (which is a pretty common way in which memory unsafety springs up). But it can be close enough.
- pjmlp 11y ago
  Still I have come to like it quite much. Yes we cannot get rid of the C underpinnings, but there are enough features to write safe C++. At least when using it alone or in small teams that value safety. I have been using it in anger on my side projects for mobile s. Why use it in spite of my rants about safety? Tooling. Using C++ across Android and Windows Phone is already an extra layer of pain (thanks NDK) with first class support from the platform owners. Using Go, Swift, Rust would increase that pain level quite higher given the actual lack of comparable tooling. Meaning build scripts, IDE, debugging tools, packaging and APIs. C# doesn't suffer as much from it thanks to Xamarin, but I would only use it in commercial projects. I really would wish that one of those languages would eventually be adopted across mobile OS SDKs as C and C++ currently are. Already had a look at Rust for Windows Phone, but COM support is not yet there to the level expected by WinRT as C++/CX allows. Assuming I was looking at the right place.
  - Cshelton 11y ago
    Actually, I haven't done much with it, just messing around, so don't take this as absolute or anything but; Using Rust cross platform, across IOS and andriod, wasn't really that difficult to do...sure, the tooling isn't fully there yet. But I don't think it's any harder than c++, if anything, easier. Cargo is amazing and what makes Rust really nice to use. The community will create better IDE's and an ecosystem of tooling for cross platform, both mobile and desktop OS's. I believe Go also has some fairly popular mobile cross platform libraries as well that are probably much further along than Rusts'. I can't say for Windows phone as I have never done anything for it and I think it's dead...
    - pjmlp 11y ago
      > But I don't think it's any harder than c++ For the time being it surely is. With C++ I just download XCode or NDK/Android Studio/Visual Studio. I don't need to bother with FFI on iOS and Windows. On Android I just need to bother with JNI FFI, not additionally how to call JNI from the respective language. The IDEs show visual representation of data structures when debugging and two way editing between C++ and the respective platform language. With Rust or Go AFAIK I need to use Mac OS X or GNU/Linux for cross-compilation. Need to compile that toolchain myself and write my own wrappers to OS APIs. Also not enjoying the same IDE experience isn't that much fun. > I can't say for Windows phone as I have never done anything for it and I think it's dead... Except the APIs are the same as Windows and XBox are moving to, even if WP10 is at the end of the road now with the last update misfortune. So if Rust or Go want a place in Windows Store for desktop and XBox apps, they need to get along with WinRT APIs. Yes, those languages will surely improve but if I have 1 hour to work on a side project, I rather spend that hour coding and not fixing toolchain issues. If I had more time, I would surely like to help to improve the situation, but sadly time is limited.
      - Tyr42 11y ago
        I just got Rust compiling for a linux kernel module. It wasn't too bad, though an inability to read C header files is kinda a pain. And for any target you are going to want to wrap things up in a "Rusty" api, as dealing with cstrings is kinda a pain. Still, it'd be a pain to go from C strings to C++ strings, and hook new/delete up to kmalloc/kfree.
pcwalton 11y ago
> And sometimes some people (like me) would argue that C++ (11&14) is actually that language. The memory safety track records of large-scale software written in modern C++ disagree with you. I don't think this is a tenable argument. C++11 and C++14 don't really add any memory safety features over C++03 plus user-defined reference counted smart pointers. In fact, I think there's a reasonable argument to be made that C++11 is less safe in practice than this use of C++03. If you use rvalue references and move semantics a lot (since "use-after-move" is now a very real problem), or if you use lambdas a lot (since it's so easy to make dangling upvar references).

Sean1708 11y ago

Which is absolutely fine, but competition is never a bad thing.

UK-AL 11y ago

People want C++ without the overwhelming choice it gives you.

Manishearth 11y ago

Note that it isn't 100% memory safe, it doesn't protect against iterator invalidation (which is a pretty common way in which memory unsafety springs up). But it can be close enough.

pjmlp 11y ago
Still I have come to like it quite much. Yes we cannot get rid of the C underpinnings, but there are enough features to write safe C++. At least when using it alone or in small teams that value safety. I have been using it in anger on my side projects for mobile s. Why use it in spite of my rants about safety? Tooling. Using C++ across Android and Windows Phone is already an extra layer of pain (thanks NDK) with first class support from the platform owners. Using Go, Swift, Rust would increase that pain level quite higher given the actual lack of comparable tooling. Meaning build scripts, IDE, debugging tools, packaging and APIs. C# doesn't suffer as much from it thanks to Xamarin, but I would only use it in commercial projects. I really would wish that one of those languages would eventually be adopted across mobile OS SDKs as C and C++ currently are. Already had a look at Rust for Windows Phone, but COM support is not yet there to the level expected by WinRT as C++/CX allows. Assuming I was looking at the right place.
- Cshelton 11y ago
  Actually, I haven't done much with it, just messing around, so don't take this as absolute or anything but; Using Rust cross platform, across IOS and andriod, wasn't really that difficult to do...sure, the tooling isn't fully there yet. But I don't think it's any harder than c++, if anything, easier. Cargo is amazing and what makes Rust really nice to use. The community will create better IDE's and an ecosystem of tooling for cross platform, both mobile and desktop OS's. I believe Go also has some fairly popular mobile cross platform libraries as well that are probably much further along than Rusts'. I can't say for Windows phone as I have never done anything for it and I think it's dead...
  - pjmlp 11y ago
    > But I don't think it's any harder than c++ For the time being it surely is. With C++ I just download XCode or NDK/Android Studio/Visual Studio. I don't need to bother with FFI on iOS and Windows. On Android I just need to bother with JNI FFI, not additionally how to call JNI from the respective language. The IDEs show visual representation of data structures when debugging and two way editing between C++ and the respective platform language. With Rust or Go AFAIK I need to use Mac OS X or GNU/Linux for cross-compilation. Need to compile that toolchain myself and write my own wrappers to OS APIs. Also not enjoying the same IDE experience isn't that much fun. > I can't say for Windows phone as I have never done anything for it and I think it's dead... Except the APIs are the same as Windows and XBox are moving to, even if WP10 is at the end of the road now with the last update misfortune. So if Rust or Go want a place in Windows Store for desktop and XBox apps, they need to get along with WinRT APIs. Yes, those languages will surely improve but if I have 1 hour to work on a side project, I rather spend that hour coding and not fixing toolchain issues. If I had more time, I would surely like to help to improve the situation, but sadly time is limited.
    - Tyr42 11y ago
      I just got Rust compiling for a linux kernel module. It wasn't too bad, though an inability to read C header files is kinda a pain. And for any target you are going to want to wrap things up in a "Rusty" api, as dealing with cstrings is kinda a pain. Still, it'd be a pain to go from C strings to C++ strings, and hook new/delete up to kmalloc/kfree.

pcwalton 11y ago

> And sometimes some people (like me) would argue that C++ (11&14) is actually that language. The memory safety track records of large-scale software written in modern C++ disagree with you. I don't think this is a tenable argument. C++11 and C++14 don't really add any memory safety features over C++03 plus user-defined reference counted smart pointers. In fact, I think there's a reasonable argument to be made that C++11 is less safe in practice than this use of C++03. If you use rvalue references and move semantics a lot (since "use-after-move" is now a very real problem), or if you use lambdas a lot (since it's so easy to make dangling upvar references).