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

421–430 of 929 posts

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

#421

Post by blub »

drivebycomment wrote: post #319
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…

> In other words, it's possible to put C and C++ on the same footing as Rust when it comes to memory bugs; No. This is only true if you don't care about occasional bugs. e.g. hobby projects. But if you're talking about mission-critical or security-critical software, there is a gap - or a canyon - between C vs C++ vs Rust. And no amount of extra "efforts" by the programmer's part can bridge those gaps completely.

Mission critical is almost meaningless when applied to the entire software industry. It’s whatever each company wrote their core software in. For twitter Ruby was mission critical, for Facebook it was PHP.

Security critical is also rather meaningless, because the idea that a specific language must be used to write secure software is something that the Rust community is claiming but is otherwise unproven and not particularly popular as an opinion. In fact I’ve seen many counters that nearly any GC language offers the same security guarantees as Rust.

Finally, there’s the mighty inconvenient fact that a large amount of safety-critical software (a well-defined term and domain!) is written in C and C++ with a track record of multiple decades while Rust is completely unproven.

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

#422

Post by petmon »

baq wrote: post #402
lenkite wrote: post #269

Earlier quoted context omitted.

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.

> 6 different string types have fun living your life pretending all strings are of the same type. spoiler alert: it's the wrong kind of fun. it's a bit easier if you're from a native English speaking country, but only until you get blown up by utf-8 (if you're lucky) in production.

It's common in other programming languages for string literals to have type string. It's weird and confusing that they do not in both Rust and in C++.

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

#423

Post by GolDDranks »

fulafel wrote: post #347
gpm wrote: post #228

Earlier quoted context omitted.

The borrow checker has become smarter, but not at handling cyclic data structures. The problem you're describing still exists, though I'd say the advice isn't quite right. Generally the better advice is to use a graph library, or something like slotmap [1] if you're rolling your own, than to use a Vec or HashMap. That's superior to a vec/hashmap for a few reasons. It handles keeping indicies stable/writing your own i…

What is the advantage of a slotmap style approach vs references? It seems a bit manual and error prone, and the errors risk being silent references to wrong objects that may result in security vulnerabilities or data corruption.

The advantage w.r.t references is that with Slotmap, you can express cyclical data structures, whereas with references you can't.

The advantage w.r.t plain Vec and juggling integer indices is that unlike integers, Slotmap keeps track of the "identity" of the stored object; the keys are unique to that object, and you can't accidentally refer to a wrong object with them.

> errors risk being silent references to wrong objects

Slotmap is specifically designed to prevents this. I recommend you to read its documentation; the generational indices system is quite nice!

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

#424

Post by ncmncm »

Arnavion wrote: post #386
ghoward wrote: post #335

Earlier quoted context omitted.

The true test of what I said is "show me the code." The code is my `bc`. [1] Find a memory bug, any memory bug, in my `bc` after 1.0. Rust has occasional memory bugs too; I mentioned that specifically. It still happens. So if you really are correct, break my `bc`. [1]: https://git.yzena.com/gavin/bc

>Find a memory bug, any memory bug, in my `bc` after 1.0. I'm surprised by this confidence given one of the commits on the first page is "Fix a double-free when using expressions and sending SIGINT". And going through the commit history quickly reveals "Fix memory bugs in bcl" (a value not being initialized) and "Fix memory leaks in bcl" (missing dealloc), all within the last two months and all which are trivially no…

Rust is perfectly happy to leak. But as in C++, there is no temptation to.

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

#425

Post by rob74 »

kosolam wrote: post #417

Mark is not the subject. He is speaking of Rust and memory safety. I agree with him in general, that if a project requires C/c++ kind of capabilities then better to use Rust. But, if one doesn’t require Rust then I think one must avoid it by all means, because it’s such an investment into such a huge learning curve and such deep levels of complexity and mental burden.

Well, he wrote "use Rust for those scenarios where a non-GC language is required", so I guess his opinion is similar to yours. But, judging by the "using Rust for web dev" articles that keep popping up here, there are people with other opinions too...

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

#426

Post by generichuman »

dleslie wrote: post #74
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.

C# is the new King of game development.

Only if you're using Unity / Monogame / other custom game engines that use C# as their scripting language.

Unity (IL2CPP) and Monogame (BRUTE) transpile the C# (byte)code to C++ to be able to deploy to consoles and the C# version they support lags several versions behind.

I don't think we can call C# "the new King of gamedev" until it is officially supported by console makers but it seems unrealistic for a couple of years.

Hopefully C# 7's NativeAOT fixes this (Sony & Nintendo will probably need to ship a runtime for C# for this to happen), I don't want to deal with transpiling stuff, I just want C# support out of the box.

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

#427

Post by xavxav »

ChadNauseam wrote: post #231
woodruffw wrote: post #222

Earlier quoted context omitted.

If the last time you tried it was 5 years ago, then you probably didn't experience Rust with non-lexical lifetimes. That was added in around 2018 (IIRC), and radically increased the number of programs that the borrow checker accepted. That being said, you still can't do "naive" cyclical data structures without some additional assistance. But the ecosystem has matured around that: crates like ouroboros[1] provide safe…

Ghost-cell [0] also lets you create a doubly-linked lists (without you having to use unsafe code, and with no overhead) [0]: https://crates.io/crates/ghost-cell

Yea but it’s not really useable in practice as it heavily relies on nesting allocations in closures to simulate “generative lifetimes”. It’s a research artifact, not meant for serious usage. Instead, I would recommend using something like https://crates.io/crates/qcell, which works on similar principles.

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

#428

Post by usrusr »

hda2 wrote: post #316
lenkite wrote: post #260

Earlier quoted context omitted.

Stuff like Slotmap should be part of the standard library instead of some github project with open issues that isn't updated for over a year.

This is my main gripe with Rust. Things that should be part of the standard library are relegated to third parties, thus requiring developers to audit yet another dependency (and it's dependencies, and sub-dependencies, and sub-sub-dependencies, ...). Realistically, this just means I can't use most third-party crates, greatly limiting what I can do with Rust. It's been a long time since I've been able to write anythi…

There was a time when it felt as if every piece of interesting java code out there also came in variation badge-engineered into its matching "spring-whatever". Perhaps there is some merit to that kind of business model?

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

#429

Post by jillesvangurp »

user8501 wrote: post #271

Seems like kind of a crazy thing to say. The first thing to note, is that we should obviously be free to write software like games and other utilities in whatever language we want, especially if they’re not connected to the internet. Second, why exactly are we demonizing people now? Suddenly declaring a language deprecated not only doesn’t actually make any sense, but also seems like a great way to influence people’s…

Well, he's the CTO at Azure and apparently he's telling his people to avoid using C/C++ for new projects. They no longer have that freedom there because he just told them so. What people do in their spare time is of course their own business.

I believe other big companies have similar reservations about using C/C++ on new projects. And given the cost of cleaning up the security mess that using C/C++ has caused these companies, I can see where they are coming from.

It's not about demonizing people but just a simple, rational business decision to not use C/C++ for new things anymore. We have Rust now and it's capable of delivering the same level of performance as C/C++ but without all the memory leaks, buffer overflows and other costly headaches that a CTO of Azure needs to worry about messing up his business. Not worth it anymore.

People taking things like this personally is unfortunate but more a problem these people have than anything else. I get it, it's not fun having your favorite language - and by extension you - labelled obsolete. Not a nice message to receive.

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

#430

Post by gruturo »

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

Seconding this. I saw the article before its title was changed, and I admit I dismissed it right away (I know, how improper of me).

When I see Mark's name, I stop and read the article.

Post reply on HN