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

571–580 of 929 posts

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

#571

Post by jstanley »

twic wrote: post #566
jstanley wrote: post #560

Earlier quoted context omitted.

That's good! That's what you want. Out-of-bounds array accesses causing segfaults is the happy case! The sad case is security vulnerabilities.

If dereferencing an invalid pointer reliably caused a segfault, this would be true. But it's undefined behaviour, so it can segfault, corrupt data, leak data, etc. Given that the possible behaviour is a superset of what can go wrong using an integer index, i would say it's worse. I would agree that using naive integer indices, and running the risk of accessing the wrong data, is also completely unacceptable, though.

I'm agreeing with you. I'm saying that a bounds checker is better than a segfault because it always works.

(You're right that it actually doesn't always work because sometimes your stale index will still be inside the array but refer to a different thing, but at least it can't be abused to write into other arrays).

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

#572

Post by pizza234 »

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.

There are convenient libraries for working with such data structures. Unsafe should be relegated for highly specific us cases.

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

#573

Post by mkl »

twelve40 wrote: post #207
cutierust wrote: post #32

Earlier quoted context omitted.

I don't want to sound too girle or fanboyish but there is no other way to say it so I'll say it (hopefully he won't read this)- Mark Russinovich transcends titles and if he's said something about technology, it's probably 99.999% true. Also, RITF, I love Rust but remember zig exists so chill I also want to say one thing-- sometimes it's not so easy to just decide to write a project and say okay let me write this in R…

RITF? Research Institute of Tropical Forestry? Rat Intestinal Trefoil Factor?

I think they mean either Rust Evangelism Strike Force [1] or Rust Evangelism Task Force.

[1] e.g. https://news.ycombinator.com/item?id=30396282

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

#574

Post by ModernMech »

ajross wrote: post #230
Fiahil wrote: post #221

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

> a pretty tall order for a language that claims to be high performance.

Doing this in Rust is still going to be orders of magnitude faster than many other languages. Maybe not C/C++, but then again if you’re chasing pointers in a list maybe squeezing every ounce of performance you can isn’t the #1 priority for the given application. The industry consensus is shifting to the idea that being #1 in security at the expense of being #2 or #3 in performance is a fine trade off.

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

#575

Post by pizza234 »

ptato wrote: post #484
alpaca128 wrote: post #473

Earlier quoted context omitted.

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.

Using integers as allocation strategy (as in the referenced use case) will fail when slots are reused.

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

#576

Post by tmtvl »

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…

As a fan of S-expressions, yes I prefer certain languages over others simply because of syntax.

After all, isn't that why all the "safety over all" people are switching to Rust now rather than Ada 20 years ago?

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

#577

Post by pjmlp »

ithkuil wrote: post #564
dale_glass wrote: post #543

Earlier quoted context omitted.

Here's an example of C++ code written intentionally with all the latest C++ features: https://gist.github.com/caiorss/c7db87df674326793431a14006aa... It looks pretty much nothing like a C program doing the same job. A lot of those features were made to make C++ a safer language to use. Eg, with a construction like: for(const auto& it : ast){ You can't accidentally walk past the end of the array by going one item too…

Why some functions are declared like: void foo() { .. } And others auto foo() -> void { .. }

Fashion.

The second syntax was introduced for lambdas and decltype() usage for return types that depend on the parameters (due to look up rules), and some C++ subcultures now use it everywhere.

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

#578

Post by krona »

slashdev wrote: post #549

I'm just a programmer who's been doing this for 20 years. I don't have the credentials of Mark, who is a legend. But I fully agree with him. There will be specific exceptions, but if you have the choice between Rust and C++ you would be making a big mistake to not choose Rust. The language is simpler, cleaner, safer, and more enjoyable to work with. The build tools are far more pleasant. The IDE experience is compara…

> The language is simpler, cleaner, safer, and more enjoyable to work with.

I was a Rust v1 contributor. I have great hopes for the language as a replacement for c in systems engineering. However, I much prefer C++ 20 for the kind of work I do (scientific computing). Rust isn't a competitor to C++ in that arena, in my humble opinion.

> Programmers currently using Rust are superior to programmers using C++, statistically speaking

The phrase 'statistically speaking' suggests the collection of empirical data. Could you elaborate?

> People learn Rust because they love their craft.

If Rust becomes popular enough, this will no longer be any truer than for people who learn c++.

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

#579

Post by prabhu-yu »

pornel wrote: post #540
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.

Thank you, I will study more.
Post reply on HN