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

61–70 of 929 posts

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

#61

Post by ncmncm »

qbasic_forever wrote: post #17
ncmncm wrote: post #13

Quoted post unavailable.

Lol if you don't know who Mark is and his real world experience particularly developing critical and low level windows tools. I think it's safe to say his opinion on the language and its use with Microsoft/Windows is very relevant.

As he appears to have been wholly concerned with details of Microsoft's walled garden, I would not have heard of him. It seems like his opinions today involve only Microsoft's internal management of its hosting products, which nobody outside Microsoft can know much about.

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

#62

Post by jcelerier »

woodruffw wrote: post #44
NonNefarious wrote: post #41

Earlier quoted context omitted.

ABI shenanigans are what killed the whole "off-the-shelf components" promise of C++ and object orientation. They really made the same mistake again?

I don't know how you arrived at that. C++ has the exact opposite ABI problems: it has a far-too-stable ABI that leaks thanks to poor abstractions (header files and template expansion in first-party code). Institutional C++ users have far too many implicit ABI dependencies to ever sign off on breakages, so C++ stdlib maintainers are unable to optimize much of the `std` namespace. This in contrast to Rust, which actual…

C++ has Schrödinger's ABI: some will say that it has a too stable ABI and others will say that its ABI is not stable at all. Which one is it ?

https://stackoverflow.com/questions/67839008/please-explain-...

Can one link two rust static libraries communicating with actual rust symbols (not just C ones), one built with gcc-rs (assuming that this is possible yet), the other built with rustc with its default x86_64-pc-windows-msvc abi ? if not, it's at the exact same state ABI-wise than C++

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

#63

Post by monocasa »

ReactiveJelly wrote: post #60
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…

Wouldn't pip install and import be equivalent to "cargo new; cargo add; cargo check"?

I think what they're saying is that there isn't always an acceptable third party crate for what they need, but the python ecosystem is more likely to have that front covered.

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

#64

Post by woodruffw »

jcelerier wrote: post #62
woodruffw wrote: post #44

Earlier quoted context omitted.

I don't know how you arrived at that. C++ has the exact opposite ABI problems: it has a far-too-stable ABI that leaks thanks to poor abstractions (header files and template expansion in first-party code). Institutional C++ users have far too many implicit ABI dependencies to ever sign off on breakages, so C++ stdlib maintainers are unable to optimize much of the `std` namespace. This in contrast to Rust, which actual…

C++ has Schrödinger's ABI: some will say that it has a too stable ABI and others will say that its ABI is not stable at all. Which one is it ? https://stackoverflow.com/questions/67839008/please-explain-... Can one link two rust static libraries communicating with actual rust symbols (not just C ones), one built with gcc-rs (assuming that this is possible yet), the other built with rustc with its default x86_64-pc-wi…

Well, it's a multiparadigm language, so both :-)

I'm being facetious, but it really is both: it's too unstable in ways that are bad, and also too stable in other ways that are bad.

Edit: since you updated your comment: Rust is not in the same position as C++. C++ has an unstable ABI that it cannot break; Rust has an unstable ABI that it can (and regularly does break). Rust works around this with developer tooling; C++ largely ignores the problem and requires developers to learn the secret rules through blood and tears.

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

#67

Post by throwaway2037 »

woodruffw wrote: post #59
tejohnso wrote: post #54

> For the sake of security and reliability. I just read a few C++ vs Rust comparisons online yesterday and didn't see anything about a significant difference in security or reliability. Mind you the articles weren't very technical. How is Rust so much more secure and reliable than *modern* C++?

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?

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

#68

Post by mustache_kimono »

Mountain_Skies wrote: post #53
Grim-444 wrote: post #49

Imagine how much impact we could have if we used all the effort gong to develop Rust and port everything over to Rust to instead just improve the wrinkles that exist in C++.

If we did that, the Rust folks wouldn't be able to claim credit for the colossal amount of very important code written in C and C++ that gets ported over to Rust. I've never seen a language where feathers in the cap are more important than they are to the Rust community.

Gosh, every Rust post feels like Thanksgiving dinner. Let's settle down.

> ... if we used all the effort gong (sic) to develop Rust and port everything over to Rust to instead just improve the wrinkles that exist in C++.

If you read the tweet, you might notice Mr. Russinovich isn't actually advocating porting everything to Rust. If you'd care to explain how one might iron out the little wrinkles in C++, you have a captive audience.

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

#69

Post by jpgvm »

paranoidrobot wrote: post #6

I think this title could be misinterpreted. There is a difference between Mark Russinovich saying this, as a personal opinion, and Mark Russinovich, Azure CTO, saying this as a company policy/directive. This tweet does not indicate that it's from him in his official capacity as Azure CTO.

Personally, given this is Russinovich - his personal opinion would carry more weight with me than whatever he has to say in his official capacity as Azure CTO.

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

#70

Post by kevin_thibedeau »

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.

They had a C compiler for kernel drivers.
Post reply on HN