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

261–270 of 929 posts

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

#261

Post by Ar-Curunir »

noobermin wrote: post #213
ReactiveJelly wrote: post #76

Someone else downthread: "young developers can pick up Rust quite fast, and that makes it vastly easier than trying to find talented C/C++ developers." I hope so. I have a hypothesis that the big-O for language success is "How easily can new programmers learn it?" Nothing else matter. JavaScript was slow, but everyone learned it, so it got fast. Python still had bad tooling, but everyone learned it, so it got better.…

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…

No Rust Evangelist is out there thinking, "Hm, how do I put C/C++ developers out of business today"

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

#262

Post by humanrebar »

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.

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

#263

Post by Ar-Curunir »

bitL wrote: post #109
ReactiveJelly wrote: post #76

Someone else downthread: "young developers can pick up Rust quite fast, and that makes it vastly easier than trying to find talented C/C++ developers." I hope so. I have a hypothesis that the big-O for language success is "How easily can new programmers learn it?" Nothing else matter. JavaScript was slow, but everyone learned it, so it got fast. Python still had bad tooling, but everyone learned it, so it got better.…

Dunno. Young devs can pick basic Rust constructs fast but when it comes to complicated stuff where performance is critical... There must be raw talent and lot of grind. IMO it's easier to write super complex stuff in C++ than in Rust as there are just too many cognitive things to keep in mind in Rust to even compile. C++ for talented folks makes life easier there. Like JavaScript, yet another language written for bad…

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.

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

#264

Post by Ar-Curunir »

tdeck wrote: post #148
ReactiveJelly wrote: post #76

Someone else downthread: "young developers can pick up Rust quite fast, and that makes it vastly easier than trying to find talented C/C++ developers." I hope so. I have a hypothesis that the big-O for language success is "How easily can new programmers learn it?" Nothing else matter. JavaScript was slow, but everyone learned it, so it got fast. Python still had bad tooling, but everyone learned it, so it got better.…

Are new devs less likely to screw things up in Rust? Probably. Is a modern Rust codebase easier to onboard with than a 40 year old monstrosity of a Microsoft C++ codebase? You bet! Are more people excited about learning Rust? Probably. Is rust much faster to learn than C++? Call me a skeptic. I've written Rust professionally and would rather write Rust than C++. That said, almost every concept you need to understand…

Unlike C++, the Rust compiler actually helps you when you encounter those complex concepts, first by refusing to compile in tricky situations, and then by providing helpful suggestions.

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

#265

Post by Ar-Curunir »

gavinhoward wrote: post #257
synergy20 wrote: post #189

Earlier quoted context omitted.

"Oh, and it's possible to make C as good as Rust", do you have some concrete advice documented somewhere? Thanks!

I hate to admit this, but it took me a long time to do, mostly because I was not experienced when I started writing code, and the code has been rewritten several times over to get it right. First off is the code in [1]. It's technically under several licenses, but I can give it to you under the public domain because bounds checking in C is important enough that I'll give it away. The `y_ARRAY_TYPE()` macro generates…

Let's be honest, `y_i(array, 10)` is much less readable than `array[10]`. Sure, you can program with bounds checking, but it's less readable, and less newbie-friendly.

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

#266

Post by stjohnswarts »

noobermin wrote: post #255
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…

Random question, doesn't this then defeat the whole purpose of using rust? Memory errors, that is, pointer issues are the primary source of errors that ownership in rust claims to fix. If the only way you can make nontrivial data structures is use "a ton of unsafe blocks," then you'll still likely get the memory errors, only now it's in an unsafe block...so, now everyone can just blame the unsafe block? This reminds…

Not really, rust has an excellent build system (better than any c++ build system I've used), great community accepted libraries for just about everything integrated well into the build system, catches a lot more "move semantic" and ownership type errors that are easy to mess up in c++. There are other things, but for me it's the excellently maintained and integrated libraries and build system that are kind of a joy to use coming from c/c++ land.

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

#267

Post by Ar-Curunir »

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.

What? You can totally compile Rust for compatibility with python libraries or Ruby libraries or whatever you want. Rust can offer the same API that C/C++ offer, so it can be a drop-in replacement.

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

#268

Post by wahern »

Kranar wrote: post #179
wahern wrote: post #151

Earlier quoted context omitted.

> That's a fairly recent thing that some people do as a kind of virtue signaling. If by recent you mean well over 20 years ago. When I began learning C circa 2000, I used to hang out on comp.lang.c, and "C/C++" was very much frowned upon. And for good reason--people felt entitled to ask C++ questions in a C newsgroup, which was and remains a poor idea. Even if they were asking questions relevant to both, e.g. regardi…

Not seeing evidence of your claim. A simple search on comp.lang.c for C/C++ turns up plenty of results and no one, not a single person, is calling it out. Infact there's plenty of discussion on an almost daily basis discussing the two languages almost seamlessly. Looks like there's even a alt.comp.lang.learn.c-c++ newsgroup as well. For reference I also did a search from 1998 to 2002... once again no one cares or is…

Using 'group:comp.lang.c "C/C++"', here's one of the first hits[1] I get, from May 17, 2000 and starting off,

> I'm just curious, but why is it that people in this group tend to reply with "the language C/C++ does not exist" or "C/C++ is 2, what do you mean?"

https://groups.google.com/g/comp.lang.c/c/bVBTSJ3KRrg/m/uv98... [2]

followed by 14 responses in that thread, most of which explain why that is, none defending the usage. One of the respondents is active on HN, I believe: kazinator (Kaz Kylheku).

I have a local copy of the UTZOO archives, with posts from the 1980s. Out of ~30,000 posts in comp.lang.c and comp.std.c only 284 use the phrase "C/C++". Many of those are discussing specific compilers, e.g., "Zortech C/C++" (this is especially true in other newsgroups). In a quick survey I couldn't find one where people corrected the usage, but if you read those threads most people are careful to provide answers specific to C and don't often repeat "C/C++". Presumably after C and then C++ became standardized people became more vocal about treating them as distinct.

[1] Results weren't sorted by date, and the first page of results spans 30 years.

[2] I wish I could also include a reference ID from the headers, but Google Groups apparently no longer makes them accessible even when logged in. Google Groups Usenet support is horrible, even when searching. It's a real shame. I think Google Groups has even blacklisted comp.lang.c for spam, though almost all the spam in comp.lang.c comes from Google Groups. I've filtered out Google Groups posts from my feed for the past 10 years or so.

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

#269

Post by lenkite »

jnwatson wrote: post #161
tdeck wrote: post #148

Earlier quoted context omitted.

Are new devs less likely to screw things up in Rust? Probably. Is a modern Rust codebase easier to onboard with than a 40 year old monstrosity of a Microsoft C++ codebase? You bet! Are more people excited about learning Rust? Probably. Is rust much faster to learn than C++? Call me a skeptic. I've written Rust professionally and would rather write Rust than C++. That said, almost every concept you need to understand…

You don’t have to know about exception safety, move semantics, meta-template higgery jiggery, or the 30 years of cruft that C++ has accumulated. Good riddance.

You don't need to know about about 6 different string types, arcane borrow checker workarounds, RefCell complexity, massive async cruft - acquired by Rust in just 2 years.

C++ will still be used heavily when Rust is buried 6 feet under and HN moves to the next hype language.

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

#270

Post by croes »

ekianjo wrote: post #192
woodruffw wrote: post #11

Calling him the Azure CTO is strictly accurate, but HN readers probably know Mark Russinovich better as one of the primary developers of sysinternals[1]. I bring that up to highlight the weight of his opinion: Russinovich is legendary in terms of his systems programming contributions. [1]: https://en.wikipedia.org/wiki/Sysinternals

Appeal to authority?

How about experience?
Post reply on HN