Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It's time to halt starting any new projects in C/C++

twitter.com

Post reply on HN
Print view View original

221–230 of 929 posts

Re: It's time to halt starting any new projects in C/C++

#221

Post by Fiahil »

hgs3 wrote: post #211

I 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…

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

Re: It's time to halt starting any new projects in C/C++

#222

Post by woodruffw »

hgs3 wrote: post #211

I 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…

If the last time you tried it was 5 years ago, then you probably didn't experience Rust with non-lexical lifetimes. That was added in around 2018 (IIRC), and radically increased the number of programs that the borrow checker accepted.

That being said, you still can't do "naive" cyclical data structures without some additional assistance. But the ecosystem has matured around that: crates like ouroboros[1] provide safe interfaces for creating self-referential structures and datatypes.

Edit: NLL was indeed added in the 2018 Edition[2].

[1]: https://docs.rs/ouroboros/latest/ouroboros/

[2]: https://blog.rust-lang.org/2018/12/06/Rust-1.31-and-rust-201...

Re: It's time to halt starting any new projects in C/C++

#223

Post by ajross »

hgs3 wrote: post #211

I 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 to do non-trivial reference semantics, Rust doesn't really offer much. Applications with nonstandard allocator paradigms or weak-referenced caches or that need to do complicated graph management are mostly on their own in the world of unsafe.

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.

I don't dislike Rust, really. But the space between "Need to stay away from C++" and "Should probably just have written it in Go" seems to be getting smaller and not larger.

[1] Which in Rust, means "written using a ton of unsafe blocks".

Re: It's time to halt starting any new projects in C/C++

#224

Post by stouset »

hgs3 wrote: post #211

I 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…

Seriously, just use unsafe.

“Welp, can’t write a doubly-linked list in safe Rust so I might as well use C” is throwing the baby, the bathtub, and the rest of the greater metro area out with the bathwater.

Re: It's time to halt starting any new projects in C/C++

#225

Post by shadowgovt »

andrewmcwatters wrote: post #182

I wish technical people would stop pretending that choice of programming language isn't just largely very much a personal choice and then occasionally based on whatever else the ecosystem has to offer. Yeah, most people doing scientific computing might use Python, but then you have whole groups of people who are used to something else and would plainly prefer not to use a language for completely personal reasons. Lik…

I find that practically speaking, 80 to 90% of the decision-making and what language to use boils down to what one is trying to do and what examples one can find of somebody doing something similar. For medium to large scale software, ecosystem matters most because when you get stuck you don't want to be reinventing wheels that other people have already solved.

I have definitely, for example, used Java in a project where I would rather walk on hot coals than add more Java to the world... Except the project was to write a second webserver that included all the accreted wisdom the company had built up over the years and we already had a first one written in Java.

The pain of adding more Java was offset by avoiding the pain of having to explain to a vice president how the company got hacked a second time in the exact same way we got hacked 5 years ago...

Re: It's time to halt starting any new projects in C/C++

#226

Post by dtornabene »

ekianjo wrote: post #192
woodruffw wrote: post #11

Calling him the Azure CTO is strictly accurate, but HN readers probably know Mark Russinovich better as one of the primary developers of sysinternals[1]. I bring that up to highlight the weight of his opinion: Russinovich is legendary in terms of his systems programming contributions. [1]: https://en.wikipedia.org/wiki/Sysinternals

Appeal to authority?

multiple people, myself included, logged in to comment precisely because the idea that MR is mostly aptly described as "Azure CTO" is a bit much. Glad the op commented the way they did, it also obviated this exact argument by simply establishing who exactly he is and not exhaustive foot stomping recitation of all his work.

Re: It's time to halt starting any new projects in C/C++

#227

Post by philosopher1234 »

ekianjo wrote: post #192
woodruffw wrote: post #11

Calling him the Azure CTO is strictly accurate, but HN readers probably know Mark Russinovich better as one of the primary developers of sysinternals[1]. I bring that up to highlight the weight of his opinion: Russinovich is legendary in terms of his systems programming contributions. [1]: https://en.wikipedia.org/wiki/Sysinternals

Appeal to authority?

Appeals to authority are useful and good. They’re shorthands for doing PhD theses on every topic you encounter. They aren’t bulletproof, though.

Re: It's time to halt starting any new projects in C/C++

#228

Post by gpm »

hgs3 wrote: post #211

I 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…

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 index allocator. It also makes it possible with a feature flag to detect all use after frees at low-ish cost (instead of only detecting them if no-one is re-using the slot). It makes it convenient to use typed keys instead of integers. The underlying datastructure is basically the same though.

You can also use Rc/Weak for cyclic data, for ref counting "GC", it's an approach I have less experience with so I can't speak towards it as well.

In the end not that much data is cyclic (especially in idiomatic rust), and this is trading off a small amount of debugging convenience on cyclic data, for guarantees of memory handling correctness in the rest of your code, and for guarantees about the amount of damage that mistakes can do in the code that does need to handle cyclic data (which in turn is a debugging win on cyclic data, so...).

I agree it's a bit of a rough edge, but it's a case where rust solved the easy 95% of the problem with only slightly questionable tradeoffs on the remaining 5%, and that's a win in my book.

[1] https://crates.io/crates/slotmap

Re: It's time to halt starting any new projects in C/C++

#229

Post by est31 »

tdeck wrote: post #148
ReactiveJelly wrote: post #76

Someone else downthread: "young developers can pick up Rust quite fast, and that makes it vastly easier than trying to find talented C/C++ developers." I hope so. I have a hypothesis that the big-O for language success is "How easily can new programmers learn it?" Nothing else matter. JavaScript was slow, but everyone learned it, so it got fast. Python still had bad tooling, but everyone learned it, so it got better.…

Are new devs less likely to screw things up in Rust? Probably. Is a modern Rust codebase easier to onboard with than a 40 year old monstrosity of a Microsoft C++ codebase? You bet! Are more people excited about learning Rust? Probably. Is rust much faster to learn than C++? Call me a skeptic. I've written Rust professionally and would rather write Rust than C++. That said, almost every concept you need to understand…

> That said, almost every concept you need to understand C++ is also needed to understand Rust

I agree that many basic C++ concepts are also present in Rust, but C++ is more than just its basic concepts: it's a huge set of features on top of those that interact with each other in complicated ways. Like how constructors aren't functions but something very special. If you just want to be a beginner C++ dev who works alone on their piece of software that doesn't have any dependencies, you can be fine, you just use the subset you are familiar with. But if you want to maintain other people's code, you need to fully understand what it is doing, the C++ features it's using. Rust's whole feature surface is absolutely smaller than that of C++, and the features that exist integrate way better than the C++ features.

Plus, if there is a gap or misconception in your knowledge, in Rust you would get a compiler error, often very well explained. In C++ you would get a segfault, often not a really nice one.

Re: It's time to halt starting any new projects in C/C++

#230

Post by ajross »

Fiahil wrote: post #221
hgs3 wrote: post #211

I 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…

> 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 manual pointer work implementing non-trivial data structures, but some do, and it kinda sucks in Rust.

Post reply on HN