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++.

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.

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.

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#.

The issue is that code that the borrow checker flags is not code that is unsafe, but code that the borrow checker cannot prove safe. There is a difference.

Until, you natively start thinking and writing code with idioms that the borrow checker is tuned for, there will be friction.

I complain about C's safety all the time, but it isn't as if Dennis and others weren't aware of its shortcomings in that regard.

> Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions.

-- https://www.bell-labs.com/usr/dmr/www/chist.html

C static analysis tools, being ignored since 1979, because "nobody has got time for that."

Perhaps it's more of a case of there being 2 issues:

  domain specific knowledge (e.g. 3d math, usability)

  correct program writing

And you do them in sequence rather than in parallel (and then of course your boss declares phase 2 doesn't get any of your time).

Lots of software engineers really emphasize the second part. But this is like insisting on correct shoelace tying in a shoe factory ... it's nice, but without making a shoe in the first place there is no shoe and no need for shoelaces. And when it comes to choosing between no shoe or badly tied shoelaces ... the choice is clear.

This is why the neverending complaint of software engineers that no-one cares about correctness. Entirely true. You can do without correctness (if there's anything Microsoft taught us), but you cannot do without domain knowledge.

And it's a bit self-serving: guess which one is most often missing in software engineers ?

Actually, coming from a country where Informatics Engineering is an actual professional title, I think adoption of such practices around the world, instead of allowing somone to name themselves engineer after a six weeks bootcamp would already help a lot regarding the quality of work output.

Any good certified engineers degree takes care that students have a concern for acquiring domain specific knowledge and adopt best practices.

Another thing would be liability, people just need to sue more often IT companies, so that security is actually taken up seriously.

Too many CVEs in the last couple of months? The servers get grounded, product recalls are required from state.

I'm not saying correct software has no advantages. Quite the opposite: I state and acknowledge the advantages. But it's an amplifier: without something to amplify (which boils down to domain knowledge) it's like owning a billion dollars buried on the moon : interesting, even cool but fundamentally useless.

Software quality has advantages for companies that are very strongly in the "milking their 100% understood market where they have an overwhelming competitive advantage" phase. Large companies. And is between neutral and a disadvantage for nearly everyone else.

That doesn't mean you can't take pride in good software. Or that it isn't an accomplishment. But you want to write quality software for money ? Get a job at Google/Facebook. Better yet, get one at Bank of America, Exxon Mobil or Boeing. Or research it at university.

Depending on the situation a write unsafe fast fix later maybe the more economic approach. Especially if the code is more exploratory, changes a lot and large parts will be finally discarded.

It seems to me that letting yourself work under the assumption something may be easy to fix later when you add the safety constraints back is just asking for major pains when it isn't easy. A wrong assumption at that level can render your entire algorithm unworkable if your plan was to make it safe in the end, since some patters just don't lend themselves to easy expression in rust. Then you're stuck with the choice, leave it unsafe and worry about it from them on, or rewrite it safely using an altered or entirely different algorithm. That doesn't seem like a gamble that's worth it to me.

Even for exploratory code. Unless it's such a performance critical portion of the project that I'm willing to write it in a different language for speed, why bait myself so?

If one of my goals for a project is to write somewhat functionally, I wouldn't start off with an exploratory approach using procedural techniques. I think we can all see what I'd probably end up with in the end, and it might work, but it probably wouldn't have some of the attributes I was hoping for.

I've found that more often, it should be reworded as "unsafe fast, painfully maintain without the resources to ever fix later".

The number of TODO's that litter code in general, or issues file to "cleanup" are generally significant. You're making a great point that accruing technical debt at the cost of safety, is quite possibly technical debt, like all other, that will never be paid down over the life of the software.

I completely agree.

What is this "fix later" you speak of?

Usually the "later" part never comes, specially in consulting, where there is only one shot to implement each module.

Unabashedly, I think leaving in it pure C would have been better. Well, if that was of their main reasons. Although, it sounds like they wanted more "infrastructure".

There is a lot of C infrastructure, almost anything can work with C too...

One-sided changes to build configuration sounds like an issue with code reviews though. It shouldn't be possible to merge something like that without others agreeing.

>very productive co-worker

He-he