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

321–330 of 929 posts

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

#321

Post by Shorel »

snickerbockers wrote: post #241
woodruffw wrote: post #233

Earlier quoted context omitted.

We do indeed listen to what authorities on subjects have to say, yes. Mark Russinovich is an authority on systems programming, and his thoughts carry weight because of his track record.

yeah, but he's not an authority on everything written in C/C++. He's entitled to his own opinions, but this scope exceeds whatever experience he has doing sysinternals or whatever it was (idk, i'm a unix guy not a windows guy). He definitely can be criticized and disagreed with. Where does it end? If he says mint chocolate chip is the worst ice cream flavor, am I obliged to agree with him because he made sysinternals…

Neither thing.

It means he has a very informed opinion. That doesn't mean we are forced to agree (I do not), but that we must answer with another informed opinion ourselves.

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

#322

Post by einpoklum »

lmm wrote: post #280
ajross wrote: post #223

Earlier quoted context omitted.

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…

> 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. If you're perfectly attentive…

> If you're perfectly attentive and constantly vigilant, maybe

That used to be the case 10 or 15 years ago. Today it is much easier to "follow the rules", because:

1. You used to need to tread carefully to both follow them and do what you needed to; now you can do more complex things more easily. Example: In the past, you couldn't avoid new and free being strewn around your code. These days, you can avoid them entirely when not implementing a complex data structure of your own.

2. A decent version of "the rules" is basically explicit: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines

3. The standard library and other FOSS libraries do a lot of the rule-following for you

(4. Compilers are more attentive and do more static checking.)

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

#323

Post by imron »

ghoward wrote: post #307
pitaj wrote: post #293

Earlier quoted context omitted.

Okay and what about preventing use-after-free and dereferencing null pointers?

Dereferencing NULL pointers: my code is structured such that every function parameter that can be NULL is marked so. And I check those possibly-NULL pointers. This could also be done with a macro: #define y_d(p) ((p) == NULL ? abort(), *p : *p) Otherwise, the compiler (clang, usually) warns me when a NULL pointer is passed in and I have asserts to catch them. Even before I had all of this infrastructure, deferencing…

After looking at this, honestly, you should just use C++.

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

#324

Post by sai_c »

lenkite wrote: post #281
stackbutterflow wrote: post #237

Earlier quoted context omitted.

Sure. In the meantime that's a few decades of better developer experience.

More like a few decades of extreme churn. Hey dude are you using Crate #43? No, thats dead on github. Try Crate #999. No dude that uses a diff async runtime. Try Crate #888. No dude, that has protest-ware on it and the boss complained. Try Crate #888. No dude, that has incompatible dependencies. Try Crate #456. No dude, that lib causes "fearless concurrency" deadlocks with async. Try crate #999. No dude, that has a g…

Have an upvote for making my day :-).

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

#326

Post by snovv_crash »

woodruffw wrote: post #219
noobermin wrote: post #213

Earlier quoted context omitted.

Ok, so I hate to be too direct but the rust enthusiasm always struck me as annoying like the meme about arch users telling everyone they use arch and so should you, but on that token, I always felt it strange given it's literally over something as mundane as a programming language choice. BUT, this as a reason seems to explain a lot more for why evangelists, particularly those in management type positions in large IT…

> Wanting to weaken the economic position of a certain type of developer makes a lot more sense. Just more anecdata, but this isn't true for my company. We're hiring for Rust because we're seeing more and more clients take memory safety seriously (and ask specifically about it as a design consideration). These things have a way of balancing themselves out: developers like Rust, so there will probably be an eventual "…

> we're seeing more and more clients take memory safety seriously

Running your test suite with asan, msan, tsan isn't sufficient? From my experience you need to start doing really nasty things (which shouldn't pass code review) before the sanitizers won't find your issues.

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

#327

Post by fsloth »

croes wrote: post #270
ekianjo wrote: post #192

Earlier quoted context omitted.

Appeal to authority?

How about experience?

This. Experts respect experts not due to political status but experience and demonstrated capability. Status and authority within a technical community are then products of actual results. Nobody is claiming infallibility, but generally when a person voices opinions in a subject within a domain they have previously demonstrated excellence generally people listen.

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

#328

Post by fsloth »

physicsguy wrote: post #312

Blanket statements like this just show that people don’t understand why people stuck with a language. I worked in C/C++ for a long time, though it’s been a while now. I just went to look at whether Rust had any bindings for MPI. It does - rsmpi. But they’re not fully implemented, and only support a restricted subset of MPI implementations which are pretty much the latest versions. Some others might work, but it is no…

Generally - yes. But in this case, if you happen to be the CTO of Azure I imagine funds would be available to implement the missing components in Rust ecosystem for projects you lobby to be critical.

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

#330

Post by pmontra »

atomicnumber3 wrote: post #247
everyone wrote: post #215

Earlier quoted context omitted.

Just cus they add a feature to a language doesnt mean u have to use it. Though it does seem very few programmers are smart enough to stick to the most basic features whenever possible.

One problem here is that everyone ends up with their own little niches of the language that they like, and nobody's code looks like anyone else's, and suddenly to read a codebase you do need to know huge swathes of the sprawling language. At lastjob, we did a lot of C++, and I could tell whose code I was reading without checking blame because I knew who liked what idioms and features.

This is so true. Two examples.

1. I got a couple of downvotes a few days ago because I commented that I don't like the &s of Elixir (kind of shortcuts for 'fn x ->') and I prefer to write the full form as it's easier to read for everyone no matter how proficient in the language (zero to expert.) I also don't like and almost don't use the & shortcuts in Ruby (positional arguments.)

2. I got a customer recently with the lead developer fond of each_with_object. I never saw that in 17 years of Ruby and I had to check the reference. It's probably faster than the naive implementation (more time inside the C implementation doing real work vs inside the C parser?) but the naive one is immediately readable by anyone.

Post reply on HN