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

481–490 of 929 posts

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

#481

Post by stouset »

chongli wrote: post #401
stouset wrote: post #224

Earlier quoted context omitted.

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.

Sorry to stretch the analogy beyond recognition but a lot of people who would prefer C over Rust want to build a bathtub for the baby without dragging the rest of the greater metro area into the picture.

Yeah, and a ton of people still complain about having to put their seat belt on in the car too.

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

#482

Post by ptato »

Dangsuckslol wrote: post #472
hda2 wrote: post #316

Earlier quoted context omitted.

This is my main gripe with Rust. Things that should be part of the standard library are relegated to third parties, thus requiring developers to audit yet another dependency (and it's dependencies, and sub-dependencies, and sub-sub-dependencies, ...). Realistically, this just means I can't use most third-party crates, greatly limiting what I can do with Rust. It's been a long time since I've been able to write anythi…

Quoted post unavailable.

> "standard library" does not exist as a concept.

What?

"The Rust Standard Library": https://doc.rust-lang.org/std/

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

#484

Post by ptato »

alpaca128 wrote: post #473
laserbeam wrote: post #288

Earlier quoted context omitted.

Using integers instead of pointers is a cool optimization outside of Rust as well. It lets you serialize data easier (indices are the same when you load data on a different machine, pointers will change) and can use less memory (common choices: 8, 16 or 32 bits per int; 32 or 64 bits per pointer). This is, however, an optimization. I rarely write my code like that on the first pass. It's something I always have in mi…

While that is true, using integers as pointers in Rust just makes them invisible to the borrow checker. It's a useful trick but one should be aware this is basically unmarked unsafe code. Though in Rust it has another advantage over pointers: it doesn't force you to suddenly annotate every single type that touches your data structure in any way.

There's nothing unsafe about integer indices because access to the array they index will incur bounds checks.

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

#485

Post by kramerger »

Ygg2 wrote: post #448
kramerger wrote: post #332

Earlier quoted context omitted.

Well... He is also written some horrible fiction novels, so the guys is not perfect.

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

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

#486

Post by stouset »

gavinhoward wrote: post #435
Arnavion wrote: post #386

Earlier quoted context omitted.

>Find a memory bug, any memory bug, in my `bc` after 1.0. I'm surprised by this confidence given one of the commits on the first page is "Fix a double-free when using expressions and sending SIGINT". And going through the commit history quickly reveals "Fix memory bugs in bcl" (a value not being initialized) and "Fix memory leaks in bcl" (missing dealloc), all within the last two months and all which are trivially no…

Notice that I said to find a memory bug in a release, not just any commit. Yes, there will be memory bugs during development, but I usually find them before release. There will definitely be commits fixing memory bugs during development. The bcl library is an exceptional case, where my test suite did not have sanitizers and Valgrind properly hooked up, and that one was because it went from a global (guaranteed to be…

"Find a memory bug in this repo. No, not those bugs. No, the ones in that part of the program are off limits. The ones I pushed but caught just before tagging don't count either because I noticed them just in time. Okay there was this one time where it happened when my complicated sanitizer setup broke without me realizing but that was a total fluke. And that other one also doesn't count because it definitely wouldn't have been stopped by Rust[1]."

I'm almost tempted to believe this entire exchange was an elaborate setup to convince people to use memory-safe languages.

[1] except I'm… pretty sure it would have been

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

#487

Post by scoutt »

hansjorg wrote: post #478
scoutt wrote: post #459

Earlier quoted context omitted.

> For those applications you can almost always encapsulate the unsafe code in a data structure library with a safe interface, such that the library is a tiny fraction of the application code. This is something I never understood. Given that a Rust application is running on top of an OS making OS calls... or uses a huge library like FFMPEG... The only safe portion is like the 1% of code being executed. "such that the…

Not all Rust programs are thin layers around libraries like FFMPEG. Why would you assume that? Also, "if it can't be 100% safe right now all at once, then why even bother?" isn't very pragmatic.

> Why would you assume that?

It might not be using FFMPEG, but gdi32.dll, winsock2.dll, libc, etc. Correct?

Unless you run on 100% bare-metal, the "safe" code is still a tiny fraction.

What if my linked C library returns an invalid pointer? Rust will still make the assumption it might be valid and play along.

(that might be the reason why Rust likes to compile libraries/dependencies from source)

> Also, "if it can't be 100% safe right now all at once, then why even bother?" isn't very pragmatic.

Never said that. I only say that people thinks "unsafe" is just for a "tiny wrapper around a library" or as parent said "that the library is a tiny fraction of the application code."

At the end, it's not. If you consider the rest of the code that makes a Rust program run, then "library is a tiny fraction" is, in fact, the other 99% of your executing code, and that this code is unsafe (unless you run on 100% bare-metal).

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

#488

Post by dncornholio »

lenkite wrote: post #260
gpm wrote: post #228

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

A github with open issues that hasn't been updated for over a year doesn't say anything about the code or quality.

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

#489

Post by stouset »

Arnavion wrote: post #477
gavinhoward wrote: post #435

Earlier quoted context omitted.

Notice that I said to find a memory bug in a release, not just any commit. Yes, there will be memory bugs during development, but I usually find them before release. There will definitely be commits fixing memory bugs during development. The bcl library is an exceptional case, where my test suite did not have sanitizers and Valgrind properly hooked up, and that one was because it went from a global (guaranteed to be…

>Notice that I said to find a memory bug in a release, not just any commit. You did not say anything of the sort. >But I also said to find one in the program, not the library. You did not say anything of the sort. You said: >>The code is my `bc`. [1] >>Find a memory bug, any memory bug, in my `bc` after 1.0. >>[1]: https://git.yzena.com/gavin/bc But okay, let's acknowledge the moved goalposts. >I issue that challenge…

> Tell me what subset of the repo named "bc" you consider to be "the program"

Clearly, the parts where you aren't able to find memory bugs.

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

#490

Post by nickdothutton »

He is probably right but then that doesn’t mean it will happen. Having worked in Ada 25 years ago, and made the argument (which largely fell on deaf ears for reasons that most of us this old understand), I think his statement is less controvesial than you might imagine. These changes take a long time, but I’m already encouraged by what I’m seeing, especially with companies like Cloudflare adopting a rust proxy in place of nginx.
Post reply on HN