5 ms·

I will tell you what works for me. Dont try to make one language to fit all cases, but try to use the best tech for each scenario. In the past you had to learn

I will tell you what works for me. Dont try to make one language to fit all cases, but try to use the best tech for each scenario. In the past you had to learn a lot of languages and platforms and you still need it in some cases. But for my particular needs, i've managed to narrow down mostly to 2 languages: C++ and Swift. But thats for me, for others it will be different things. But dont try to find the perfect language.. dont be a hostage to any tech suffering with stockholm syndrome with a given piece of tech. This weird trend of one tech-fits-all started back in the nineties with Java, with things comming out straight from the religions like 'evangelism', and calling people infidels for trying different things. Maybe whats work for me will work for you too. I bet you can narrow down to 2 langs to do almost anything you want. About C++ vs. Rust; Fear not. Modern C++ can basically 'anotate lifetime' in methods contracts by using smart pointers and move when you need. I prefer the C++ approach, have no problems with leaking, lifetime or whatsoever and deal with very large codebases programmed by large teams. But of course, if i were to create a program to control a nuclear reactor or a submarine i would consider using Rust or Ada. But particularly i find Rust programming more stressful than C++ without (almost) nothing to gain. And on the language design aspect where Rust is superior to C++, i prefer to use Swift if i can, which i consider 'a better Rust'. By the way in a lot of cases you might consider using Rust or C++, you can use the joyful Swift. Using a powerful language with less of a burden. TLDR; Where some people will try to use Rust for everything, i prefer to use a Swift/C++ combo, and given you can mix both without much problem in a single program, i hardly need or miss anything else.

creatornator 8y ago
I don't think any embedded systems engineers are programming in Rust for nuclear reactors or subs, and I don't think they are considering it either. No amount of safety constraints in Rust make up for the fact that the Rust team is sometimes willing to forgo backwards compatibility to keep the language clean. Not to mention those are usually legacy codebases from before Rust even existed, and no one is convincing the DoD or the DoE to "rewrite in Rust".
- steveklabnik 8y ago
  > the fact that the Rust team is sometimes willing to forgo backwards compatibility to keep the language clean What cases are you thinking of here?
  - creatornator 8y ago
    Well I suppose backwards compat might have been the wrong phrase here. I'm thinking more that it's a language whose v1.0 release was only 3 years ago before which it was "difficult to maintain projects written in Rust, since the language and standard library were constantly changing" [0]. That's not to say that it isn't a stable language now (and I actually quite like it) but with only 3 years of stability to show, "nuclear reactors" and "submarines" are strange things to list as applications for the language. [0] (https://blog.rust-lang.org/2015/05/15/Rust-1.0.html https://blog.rust-lang.org/2015/05/15/Rust-1.0.html)
bmer 8y ago
> About C++ vs. Rust; Fear not. Modern C++ can basically 'anotate lifetime' in methods contracts by using smart pointers and move when you need. I prefer the C++ approach, have no problems with leaking, lifetime or whatsoever and deal with very large codebases programmed by large teams. Is there a book (or other type of resource) that approaches C++ from the "modern" direction, i.e. with a focus on correctness?

creatornator 8y ago

I don't think any embedded systems engineers are programming in Rust for nuclear reactors or subs, and I don't think they are considering it either. No amount of safety constraints in Rust make up for the fact that the Rust team is sometimes willing to forgo backwards compatibility to keep the language clean. Not to mention those are usually legacy codebases from before Rust even existed, and no one is convincing the DoD or the DoE to "rewrite in Rust".

steveklabnik 8y ago
> the fact that the Rust team is sometimes willing to forgo backwards compatibility to keep the language clean What cases are you thinking of here?
- creatornator 8y ago
  Well I suppose backwards compat might have been the wrong phrase here. I'm thinking more that it's a language whose v1.0 release was only 3 years ago before which it was "difficult to maintain projects written in Rust, since the language and standard library were constantly changing" [0]. That's not to say that it isn't a stable language now (and I actually quite like it) but with only 3 years of stability to show, "nuclear reactors" and "submarines" are strange things to list as applications for the language. [0] (https://blog.rust-lang.org/2015/05/15/Rust-1.0.html https://blog.rust-lang.org/2015/05/15/Rust-1.0.html)

bmer 8y ago

> About C++ vs. Rust; Fear not. Modern C++ can basically 'anotate lifetime' in methods contracts by using smart pointers and move when you need. I prefer the C++ approach, have no problems with leaking, lifetime or whatsoever and deal with very large codebases programmed by large teams. Is there a book (or other type of resource) that approaches C++ from the "modern" direction, i.e. with a focus on correctness?