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

471–480 of 929 posts

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

#471

Post by Noe2097 »

jupp0r wrote: post #287
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…

It's intentionally limiting. If you need an owner, create one (call it a graph struct that holds all you nodes for example). Make lifetime management an explicit and separate concern and unit test it independently. If this is too slow for your performance needs use a library that probably uses unsafe Rust to optimize the parts that matter and that offers safe abstractions for you to interact with. If there's none, ro…

Was about to write this exactly. Keep the lifecycle management in a dedicated component. Unsafe seems vastly overkill for dealing with this use case.

I'm even having a hard time seeing how this could be slower than any other alternative. Yes, in the places where creating / deleting is necessary, the "root" structure will have to be passed around, but in the worst case that has the cost of adding one argument to a function (which has the nice side effect of making the lifecycle _visible_).

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

#472

Post by Dangsuckslol »

hda2 wrote: post #316
lenkite wrote: post #260

Earlier quoted context omitted.

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.

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…

No post body was provided.

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

#473

Post by alpaca128 »

laserbeam wrote: post #288
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…

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.

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

#474

Post by Ygg2 »

ncmncm wrote: post #410
Ar-Curunir wrote: post #263

Earlier quoted context omitted.

It's not easier to write "super complex stuff" in C++ than in Rust, precisely because C++ has much more cruft that the compiler can't check for you. And so what if Rust is lowering the bar for entry to systems programming? I'd much rather fresh ideas and fresh blood enter the field, than it slowly dying as the only people with arcane C/C++ knowledge slowly retire/die.

There is still quite a lot that you can only ever express in C++. So, no. And plenty of that, you will never be able to express in Rust.

That's a bold claim (since both languages are Turing complete). I presume you meant safe Rust? But that's kinda the point. If something is memory tricky it is supposed to go into unsafe so you can make a safe abstraction around it.

Unless you meant actually all of Rust. In that case, please share what's inexpressible in Rust.

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

#475

Post by cvccvroomvroom »

virgulino wrote: post #251

You could say that Mark Russinovich is a hacker's hacker, the foremost Windows hacker, and a reverse engineering wizard. It was he who discovered and blew the whistle on the Sony rootkit scandal, for example, after finding and reverse engineering it on his machine. https://en.wikipedia.org/wiki/Sony_BMG_copy_protection_rootk... He extensively reverse engineered and documented "Windows Internals" details before joinin…

Almost 15-20 yrs ago, before I deleted my LI profile, he was kind enough to have a look at some random malware at (big name) caught in the wild (because the org dragged its heels into any measurable security) doing actually weird and clever things to hide itself from all manner of scanning tools, including that 4 letter acronym collection package MSFT gave to customers to grab forensics. Back then, they also taught MSFT NT kernel devs for a time how their own stuff worked.

Satya Narayana and company out of Azure are a tribe of forward thinkers who rescued MSFT in the long-term by adapting and embracing without as much extinguishing.

PS: Unnamed yours truly is now around the corner from where Winternals was. Small world.

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

#476

Post by baq »

petmon wrote: post #422
baq wrote: post #402

Earlier quoted context omitted.

> 6 different string types have fun living your life pretending all strings are of the same type. spoiler alert: it's the wrong kind of fun. it's a bit easier if you're from a native English speaking country, but only until you get blown up by utf-8 (if you're lucky) in production.

It's common in other programming languages for string literals to have type string. It's weird and confusing that they do not in both Rust and in C++.

It might be acceptable in higher level languages where some things will simply break in corner cases, at which point the developer will just say 'don't do that' and all is fine. If you're aiming at a true low-level bare-metal-capable syscall-winapi-native-speaker language, this is not an option.

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

#477

Post by Arnavion »

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…

>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 again: find a memory bug in the `bc` or `dc` program in a release after 1.0.

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

>Oh, and the double-free with `SIGINT`? Rust isn't going to help you much there. Signals are not part of Rust's model.

Crates like tokio::signal allow a signal to be converted to a stream of events, which can be handled along with any other events in the program, instead of interrupting the current fn in the middle and necessitating longjmp shenanigans. Since the existing stack is not interrupted in any special way, dtors fire as they're supposed to.

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

#478

Post by hansjorg »

scoutt wrote: post #459
roca wrote: post #313

Earlier quoted context omitted.

> the big problem is that for applications that do need to do non-trivial reference semantics, Rust doesn't really offer much. 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. And in many cases someone else already wrote that library. For graphs, for example, there is petgraph.…

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

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

#479

Post by spacechild1 »

howinteresting wrote: post #371
fxtentacle wrote: post #349

I get that it makes sense at his level, but my impression is that mistakes in the business logic are both more common and more financially painful for the company than the memory safety issues that Rust solves when compared to C++. Unsafe binary? Run it in docker. Crashes? Run two and monit. RAM leak? Restart with cron. Now I'm not saying that these are good solutions, but they are good enough so that plenty of compa…

Rust also solves many classes of logical issues through ADTs and pattern matching. And many classes of thread safety issues. Memory safety is an important part of Rust but not all of it.

I don't know much about ADTs, but I'm skeptical they would help me for my own programs since most of my logic errors boil down to wrong math...

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

#480

Post by spacechild1 »

mappu wrote: post #66
MathMonkeyMan wrote: post #15

The C/C++ people hate it when you call it C/C++.

You see it a lot more often from the Microsoft world since MSVC only supported "C/C++" as a combined language, there was no separate C compiler.

Well, technically it is one compiler, but it can operate in different modes, depending on the file input. So I don't this distinction is all too relevant.
Post reply on HN