Seems like kind of a crazy thing to say. The first thing to note, is that we should obviously be free to write software like games and other utilities in whatever language we want, especially if they’re not connected to the internet. Second, why exactly are we demonizing people now? Suddenly declaring a language deprecated not only doesn’t actually make any sense, but also seems like a great way to influence people’s personal opinions about others. I can tell you from experience that sentiments like this breed hostility in the workplace. And finally, this is pretty short-sighted, considering the supply chain attack is clearly the attack of the coming age.
It's time to halt starting any new projects in C/C++
271–280 of 929 posts
Re: It's time to halt starting any new projects in C/C++
#272Earlier quoted context omitted.
> The "safe" solution recommended by the rustaceans was to use integers as references to the data in a vec or hashmap. What ? Box, Arc (and weak) are exactly made for this.
Box doesn't solve the problem of cyclic references. And telling people they need to eat the overhead of a per-object reference count and/or weak pointer double-dereference just to write a list that can delete items in place is a pretty tall order for a language that claims to be high performance. No, this is genuinely a big hole in the expressive space of the language. Not a lot of apps really need to do a ton of man…
As other pointed out, if Arc is not an option, then a well encapsulated raw pointer might just be what's needed.
I've implemented several of such data structures, there is not that many tradeoffs available : safe and easy, or unsafe and fast.
The unsafe parts are still much better than raw C. I don't agree that the language and ecosystem is missing a "big piece". Everything is already there.
Re: It's time to halt starting any new projects in C/C++
#273Earlier quoted context omitted.
> IMO it's easier to write super complex stuff in C++ than in Rust as there are just too many cognitive things to keep in mind in Rust to even compile. It keeps you from compiling (many of) the bugs you'll happily write and deploy in C++. I don't think there's really much practical difference in "cognitive load" between modern C++ (which is painfully complex in ways that are largely not even useful) and rust. C++ jus…
Sure, but don't forget the inherent trade-off - Rust allows you to write safer code at the cost of getting in the way. It simplifies some things and makes other things very complex. It empowers average devs that can suddenly write certain types of system services easily and be reasonably sure they work as intended, but it gets in the way of advanced devs writing core systems.
This sounds an awful lot like how everyone thinks they're an exceptional driver and everyone else is bad. Reality is no one's actually that great at piloting a ton of metal at speeds their brains can't keep up with in an uncontrolled environment.
Anyways, unsafe exists so that if rust is genuinely in your way you can still do what you need to do.
Re: It's time to halt starting any new projects in C/C++
#274Would Rust be able to replace C++ in HFT?
Re: It's time to halt starting any new projects in C/C++
#275Earlier quoted context omitted.
Because, little by little, C++ became "unlearnable". Long ago C++ made C a little bit more complex. Because there were already lots of C programmers that wasn't a big deal. But then it didn't stop. Little by little C++ grew into a monstrosity. A lot of people went along. I gave up. For new programmers to climb in 2-3 years a mountain that seasoned programmers took 15-20 years to climb is asking too much.
Just cus they add a feature to a language doesnt mean u have to use it. Though it does seem very few programmers are smart enough to stick to the most basic features whenever possible.
> Just cus they add a feature to a language doesnt mean u have to use it
While I absolutely agree with this in general, in practice with C++ if you're trying to use it safely you do in fact need to use those new features. But the old features are all still around too. It's a very, very large language in terms of mental space required these days.
Re: It's time to halt starting any new projects in C/C++
#276Earlier quoted context omitted.
Just cus they add a feature to a language doesnt mean u have to use it. Though it does seem very few programmers are smart enough to stick to the most basic features whenever possible.
One problem here is that everyone ends up with their own little niches of the language that they like, and nobody's code looks like anyone else's, and suddenly to read a codebase you do need to know huge swathes of the sprawling language. At lastjob, we did a lot of C++, and I could tell whose code I was reading without checking blame because I knew who liked what idioms and features.
> One problem here is that everyone ends up with their own little niches of the language that they like
Amusingly, this was always the criticism I've seen leveled at Lisps over the years. It's just as true in C++ for sure.
Re: It's time to halt starting any new projects in C/C++
#277Earlier quoted context omitted.
> Like JavaScript, yet another language written for bad to average developers to keep them from shooting themselves in the foot. I can't imagine anyone ever describing vanilla JavaScript this way.
Yeah, made me reread the whole message with my sarcasm checker turned up. I can’t recall another widely used language of the era with as many foot-guns or one that went so long without a decent debugging experience. It really draws into question the claim that “it's easier to write super complex stuff in C++ than in Rust” when so clearly incorrect about JS. Especially when we have _decades_ of evidence from world-sto…
> I can’t recall another widely used language of the era with as many foot-guns or one that went so long without a decent debugging experience.
As someone who was writing both in the 2000s: PHP fits this "nicely" haha
Re: It's time to halt starting any new projects in C/C++
#278Earlier quoted context omitted.
The borrow checker has become smarter, but not at handling cyclic data structures. The problem you're describing still exists, though I'd say the advice isn't quite right. Generally the better advice is to use a graph library, or something like slotmap [1] if you're rolling your own, than to use a Vec or HashMap. That's superior to a vec/hashmap for a few reasons. It handles keeping indicies stable/writing your own i…
Stuff like Slotmap should be part of the standard library instead of some github project with open issues that isn't updated for over a year.
I just glanced through the small number of open issues, and none seem like actual issues so much as potential improvements. The maintainer seems to still be around, and I've never found that a standard library is faster at merging improvements than third party libraries, rather the exact opposite (for good reason, the standard library needs to avoid breaking changes at nearly all costs).
While I think there are valid arguments in both directions for putting more things like this in std, I don't think "non-bug issues have been open for over a year" is one of them. The exact same is true of std.
Re: It's time to halt starting any new projects in C/C++
#279Earlier quoted context omitted.
Why not just hire good people and ask them to learn C++. I mean how the heck did anyone actually pass this magic barrier of becoming a "C++ dev" in order to get hired as a C++ dev?
Because “just hire good people” is on par with “just hire good pilots”. Easier said than done.
It's also expensive. Every industry has focused on changing the environment so average people can do good work rather than fight over the top 5% of talent.
Re: It's time to halt starting any new projects in C/C++
#280I tried Rust about five years ago and I had trouble expressing cyclic data structures because there is no clear "owner" in a cyclic data structure. The "safe" solution recommended by the rustaceans was to use integers as references to the data in a vec or hashmap. I was rather put off by this: Instead of juggling pointers I was juggling integers. It made the code harder to debug and find logic errors. At least when I…
That's my take too. Idiomatic Rust is "safe" in the sense that... it disallows most nontrivial data structures. Even a doubly-linked list is impossible to get through the borrow checker. That's... not really that fatal. There's a lot of very useful code that can be written using only runtime-provided[1] containers and straightforward ownership trees. But obviously the big problem is that for applications that do need…
> And the somewhat more cynical point is: for applications that can easily fit within standard containers and standard allocation paradigms, C++ actually works really well already. Use your smart pointers. Use your containers. Follow the rules everyone tells you about not using bare new/malloc. And... it's basically just as safe, because anything beyond that would be unsafe in Rust too.
If you're perfectly attentive and constantly vigilant, maybe. In practice everyone thinks they're following the rules and everyone messes it up.