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

141–150 of 929 posts

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

#141

Post by idontpost »

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…

> Like JavaScript, yet another language written for bad to average developers to keep them from shooting themselves in the foot.

I can't imagine anyone ever describing vanilla JavaScript this way.

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

#142

Post by customkitchen »

ghoward wrote: post #135

Unless he means that Rust should be used on projects where the Rust compiler is available for all relevant platforms and C and C++ can be used otherwise, I disagree. In fact, until LLVM is replaced, C++ will probably be the language of choice for new languages. Even `rustc` requires a C++ bootstrap for that purpose. There are also other important C++ and C libraries that will continue to mean C and C++ may be better…

If we are offering absolutist opinions, I would like to offer a counterpoint.

>I've got macros to do automatic bounds checking. I've got RAII and stack traces. I've got structured concurrency, which will give the same capabilities as the Rust borrow checker if you adjust your coding style. And all this in portable C11.

You can do this all in C but it is an absolute nightmare. Every large C program grows some strange bespoke and incompatible versions of all that stuff at some point. And they're all a pain to use because none of it is idiomatic to the language. It's seriously awful. Things like the Linux kernel are the worst offenders. I will be happy when the C language finally reaches the end of its miserable, slow, agonizing death.

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

#144

Post by ghoward »

customkitchen wrote: post #142
ghoward wrote: post #135

Unless he means that Rust should be used on projects where the Rust compiler is available for all relevant platforms and C and C++ can be used otherwise, I disagree. In fact, until LLVM is replaced, C++ will probably be the language of choice for new languages. Even `rustc` requires a C++ bootstrap for that purpose. There are also other important C++ and C libraries that will continue to mean C and C++ may be better…

If we are offering absolutist opinions, I would like to offer a counterpoint. >I've got macros to do automatic bounds checking. I've got RAII and stack traces. I've got structured concurrency, which will give the same capabilities as the Rust borrow checker if you adjust your coding style. And all this in portable C11. You can do this all in C but it is an absolute nightmare. Every large C program grows some strange…

I understand you think it's awful, but I do like it. Everyone has their preference.

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

#145

Post by kllrnohj »

throwaway2037 wrote: post #67
woodruffw wrote: post #59

Earlier quoted context omitted.

The primary defining quality of Rust (in a security context) is spatial and temporal memory safety: if you're an ordinary user of Rust, you cannot write code that produces memory corruption. Modern C++ is really nice (I write mostly C++17 and later for work), and does a great job of obsoleting bug-prone patterns from earlier versions of the language. But it's still very easy to introduce memory corruption (of either…

I would call myself an average C++ programmer. Starting with move semantics in C++11 (very cool!), I found myself frequently making bugs by re-using an "already moved" container (like a vector). I couldn't find any simple way to avoid that mistake. And, from my tooling, it was a hard problem to debug, as are double frees. Do you have any advice to avoid re-using "already moved" containers?

It's well defined safe to use a vector after a move:

    Move constructor. Constructs the container with the contents of other using move semantics. Allocator is obtained by move-construction from the allocator belonging to other. After the move, other is guaranteed to be empty().
https://en.cppreference.com/w/cpp/container/vector/vector

Which can be a useful property at times, but also means tooling won't help you here since it's not an obvious bug.

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

#146

Post by bcrosby95 »

jimbob45 wrote: post #50

I don’t feel that his opinion is all-encompassing. If Rust is being used in the name of security and reliability, then C/C++ should remain king of game development, where those two aren’t as important.

I've always wondered, why isn't it important here? Are security researchers just not looking?

Especially for networked games.

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

#147

Post by BenFrantzDale »

pengaru wrote: post #52
woodruffw wrote: post #38

Earlier quoted context omitted.

I certainly don't. Although I also write Rust now, so I suspect someone will accuse me of having split loyalties or something equally ridiculous. The only context in which I care about "C/C++" is on resumes, where it's a sign that I need to ask a little more about the person's background.

> The only context in which I care about "C/C++" is on resumes, where it's a sign that I need to ask a little more about the person's background. Is that because you'd expect anyone actually experienced in either to know better than to lump them together so casually?

For me, I see “C/C++” as a sign they see C++ (which I’m looking for experience in) as interchangeable with C. I want people who grok C++’s ability to build powerful abstractions, not people messing around with it as C with polymorphic classes.

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

#148

Post by tdeck »

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 C++ is also needed to understand Rust, but then Rust adds additional complex semantics that aren't going to be intuitive to novices and don't trivially map to either other common high-level languages or obvious low-level concepts.

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

#150

Post by Klonoar »

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…

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

Surely you can describe this with more than a throwaway sentence, given that more and more people are seeming to experience the opposite.

>Like JavaScript, yet another language written for bad to average developers to keep them from shooting themselves in the foot.

Nobody would describe JS this way - the entire existence of that language is filled with projects attempting to make it better for "bad to average developers" because it is certainly not what you're describing.

Edit: minor formatting of quotes.

Post reply on HN