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

531–540 of 929 posts

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

#531

Post by archi42 »

stouset wrote: post #224
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.

Not a rust dev, but shouldn't this be solvable using generics? At least I'm pretty sure I could construct a double linked list with a sane API using only references in C++ with templates.

I would have used inheritance to create a "ListBaseType" with a "ListElementType" specialization (with all the data required to wrap some element) and an empty "ListNullType" to use as begin/end elements. A quick Google search results in a implementation using "None" instead: https://gist.github.com/matey-jack/3e19b6370c6f7036a9119b79a... (I don't vouch for it!)

In the end the correctness boils down to correctly handling the beginning/end. It does matter little if that's a NULL, None, nullptr or ListNullType.

The real difficulty would be adding thread safety with minimal performance loss.

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

#532

Post by cinntaile »

kramerger wrote: post #485
Ygg2 wrote: post #448

Earlier quoted context omitted.

Why are fiction novels relevant to field of computer languages? This seems like ad hominem.

The books are about computer security. My impression from the first book was that the author has a very back and white view of the world. That could very well also affect his day job

You're really using a fictional story that he wrote to conclude that he has a very black and white view of the world? That's not proof of anything...

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

#533

Post by throwaway2037 »

stouset wrote: post #224
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.

Yes, I felt the same when I read the grandparent post! I am not a Rust nut (nor expert!), but the improvements offered seem very impressive. After reading your post, I immediately went to Google this phrase: "doubly-linked list in safe Rust". Plenty of good and interesting results!

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

#534

Post by palata »

dale_glass wrote: post #520
aspyct wrote: post #517

Earlier quoted context omitted.

What's wrong with .cpp extension?

The implication is that he's mostly writing C despite the file extension suggesting they contain C++. C++ changed a lot over time, and the way modern code is supposed to be written is very distinct from "C with classes", but you still can do that if you want.

Wut? Makes no sense to me.

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

#535

Post by sqrt_1 »

jiggawatts wrote: post #504
abareplace wrote: post #446

Earlier quoted context omitted.

No, they don't. We typically use the UTF-16 functions (with the W suffix).

More specifically, the 8-bit 'A'-suffixed functions could be used as UTF8, but only on some versions of Windows if, and only if, the system code page is set to use UTF8 instead of the Latin1 (or whatever).

I don't think the system code page needs to be set? https://learn.microsoft.com/en-us/windows/apps/design/global...

https://learn.microsoft.com/en-us/cpp/c-runtime-library/refe...

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

#536

Post by pornel »

humanrebar wrote: post #262
ninefathom wrote: post #242

There are new programs being written daily in COBOL and Fortran, and I'm fairly certain that I see new PL/I floating around occasionally. C and C++ aren't going anywhere anytime soon. Love them, hate them, want to burn them with fire, they're here for a long, long time. Leaving that aside, I was still hitting Rust "oh look the developer of this crate on which the entire universe depends still assumes that everything…

The fact that Rust has a whole other ecosystem is the main thing that gives me pause. For all their faults, C and C++ targets the ecosystem you have: gems, pip, Conan, Nix, ...doesn't matter. They don't expect you to port to a new ecosystem. They can contort to meet your needs. Herb Sutter's latest proposal and, to a slightly lesser degree, Carbon are more interesting in that respect.

C/C++ target a fragmented mess that's different on every platform and inconsistent across projects. Technically you can invoke rustc the same way you invoke cc, and craft makefiles and handle all your dependencies the old way, but it's so tedious and fragile compared to Cargo that nobody wants to.

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

#538

Post by survirtual »

ajross wrote: post #223
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…

The thing is, once you get it right in Rust it just works very, very well — and it generally works multithreaded with little additional effort.

The language causes you to rethink datastructures that were largely created in a single-core context. You can think up equivalent functionality that satisfies the Rust borrow checker but then also lets you trivially parallelize via something like Rayon.

Rc or Arc work for a double LL if you insist on pointers, or a wrapped owned vector with integer based references if you don’t want the overhead of reference counting. But to say “Rust doesn’t offer X” is just not true; you can build anything but it just takes more work and thought, and it is always worth it given the performance and bug classes automatically eliminated by that extra effort. And with unsafe code, you get bare metal access without the rules.

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

#539

Post by nindalf »

ninefathom wrote: post #406
humanrebar wrote: post #320

Earlier quoted context omitted.

...as long as you're fine shelling out to cargo, right? What if that's not appropriate or ergonomic? There's a world where Rust is as easy to use as C, C++, Fortran, etc. outside of cargo, but it's not an interesting use case for the Rust community to support right now for whatever reason. That's basically my point. And it's common enough to have linked programs in which python calls C that calls C++ that calls Fortr…

"There's a world where Rust is as easy to use as C, C++, Fortran, etc. outside of cargo, but it's not an interesting use case for the Rust community to support right now for whatever reason. That's basically my point." Yep. The Rust ecosystem is very much a product of the always-connected, move-fast-and-break-things, DevOps-CI/CD-SCRUM-Agile, horizontal scaling world... which is fine right up until the point where it…

What a strange comment.

It’s true that building Rust projects is easy with cargo and hard without. But how did you go from that to “move-fast-and-break-things”? Could you give an example of a broken thing?

Is the Linux kernel “DevOps-CI/CD”? Does Linus Torvalds manage the project in a “SCRUM-Agile” way? Let’s find out if “all hell breaks loose” when we get Linux 6.1.

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

#540

Post by pornel »

prabhu-yu wrote: post #374

In C++, there is Move semantic. If we use "Move semantic" in C++ code, could it match the memory safety of the Rust?

Rust has move semantics too (it's automatic and there are no moved-from leftover objects), but it adds borrow checking on top of that, which C++ doesn't have.
Post reply on HN