4 ms·

As someone who was following Rust since its inception, i got pretty fond of the first Graydon Hoare's vision to it. It looked a lot like Swift is now, but with

As someone who was following Rust since its inception, i got pretty fond of the first Graydon Hoare's vision to it. It looked a lot like Swift is now, but with a different syntax and more FP dialects. As a im a (mostly) C++ programmer, despite the fact that i liked the language, i feel that the balance between what the language was giving me, and the productivity, was not worth it when compared to C++. I feel much more productive in C++, the language is still faster, with a low memory footprint in the majority of cases, and with modern C++, smart pointers, move, a correct understanding of the ownership model .. the bad sides of it, the ones Rust did a better job shelving us from, from my point of view are not worth paying for the lack of productivity i felt in Rust as compared to C++. I know this is an unpopular opinion here in HN, but I decided to take a different approach .. instead of "one language to rule them all" i tend to use C++ for what's good at, and Swift for more application centered goals , because its nicer than C++ and Rust (in my opinion), release you from the burden of managing memory all around while being very fast at the same time. Swift for me is "the better Java" we were looking for, Rust does not seem appealing in this arena (and the same goes for C++ here), while you pay for what you use in Rust in terms of productivity, even compared to C++. The other thing that makes C++ a better option in my opinion, is the ammount of libraries and codebase you have access to, not only in C++, but in C. Very important codebases are either C or C++, even the newer ones like Tensorflow or V8, Chrome, LLVM, etc ... I understand the importance of what Rust provides, I like its goal, but your comment sounded like the OP was either stupid or lazy / incompetent by using your anedoctical evidence. (While in the same anedoctical example you are the hidden figure who are sensitive about security while still using C++, as the 'lazy guy', enabling -Wall, using Valgrind, etc) When I entered in the comments section here, I was just expecting the sort of comments in the spirit of "how could you even do that?" PS: Im not the kind of guy who tends to disable -Wall -Werror to have more productivity and i would not favor C ++ in exchange for Rust, if i feel the balance were better among what i pay in terms of productivity were fair in exchange for more safety as compared to what I have now with C++.

pjmlp 8y ago
I have a similar approach, just different languages. Java and .NET platforms, with C++ only when really required. So for me, and the people I work with, whatever alternative comes to replace C++, needs to fit into the same workflow and IDE mixed language development tooling that others are already comfortable using. And I do advocate both ways, managed languages getting features that reduce the need to reach for C++, safer C++ replacements that might eventually succeed long term (C++ took 25 years to reach where it is now), and exactly because C++, or even C, isn't going away tomorrow, ways to improve existing code quality. Because the ultimate goal is to improve our IT stack, and not celebrate yet another Morris Worm birthday.
skohan 8y ago
I have taken a similar approach, although I tend to rely more on C than C++. I think Swift has somewhat similar advantages to Rust in terms of safety, but accomplishes it while being a largely permissive language rather than by putting the developer in a safety "jail" where it's almost impossible to make a mistake. I know this comes at the cost of performance when compared to Rust when compared to memory management, but the value proposition in terms of productivity is huge. And recently I've done some experimentation with optimizing Swift for performance, and Swift can actually do surprisingly well there too if you stick to certain patters. I think Rust has its place, and for things like kernel development, firmware, or software for a mars rover where you absolutely want the strongest compile-time checking of your code with respect to safety with a minimal cost to performance, it is a natural choice. I'm not convinced it's categorically better for all use-cases.
Const-me 8y ago
Same here, only C# instead of Swift. Native interop through C API adds some friction, but despite that, I also find it easier to use two distinct languages. C++ excels at interop. As you mentioned there’re many libraries that only support of C or C++ but for me their set is different, most often I need to consume native OS APIs and GPU APIs. Also, C++ is good at number crunching, when performance matters, e.g. because first party SIMD intrinsics support. For everything else I use C#.

pjmlp 8y ago

I have a similar approach, just different languages. Java and .NET platforms, with C++ only when really required. So for me, and the people I work with, whatever alternative comes to replace C++, needs to fit into the same workflow and IDE mixed language development tooling that others are already comfortable using. And I do advocate both ways, managed languages getting features that reduce the need to reach for C++, safer C++ replacements that might eventually succeed long term (C++ took 25 years to reach where it is now), and exactly because C++, or even C, isn't going away tomorrow, ways to improve existing code quality. Because the ultimate goal is to improve our IT stack, and not celebrate yet another Morris Worm birthday.

skohan 8y ago

I have taken a similar approach, although I tend to rely more on C than C++. I think Swift has somewhat similar advantages to Rust in terms of safety, but accomplishes it while being a largely permissive language rather than by putting the developer in a safety "jail" where it's almost impossible to make a mistake. I know this comes at the cost of performance when compared to Rust when compared to memory management, but the value proposition in terms of productivity is huge. And recently I've done some experimentation with optimizing Swift for performance, and Swift can actually do surprisingly well there too if you stick to certain patters. I think Rust has its place, and for things like kernel development, firmware, or software for a mars rover where you absolutely want the strongest compile-time checking of your code with respect to safety with a minimal cost to performance, it is a natural choice. I'm not convinced it's categorically better for all use-cases.

Const-me 8y ago

Same here, only C# instead of Swift. Native interop through C API adds some friction, but despite that, I also find it easier to use two distinct languages. C++ excels at interop. As you mentioned there’re many libraries that only support of C or C++ but for me their set is different, most often I need to consume native OS APIs and GPU APIs. Also, C++ is good at number crunching, when performance matters, e.g. because first party SIMD intrinsics support. For everything else I use C#.