Live data from Hacker News

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

twitter.com

161–170 of 929 posts

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

#161
post #148

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…

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.

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

#162

Is he actually doing it? Making a plan and a policy to replace the bone marrow of MS with Rust? Or is this just a pie in the sky tweet? I don't know what Mark is like as a CTO, so I really don't know what to expect here.

Which part of "new projects" did you miss?

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

#163
post #109

Earlier quoted context omitted.

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.

Yeah, made me reread the whole message with my sarcasm checker turned up. I can’t recall another widely used language of the era with as many foot-guns or one that went so long without a decent debugging experience.

It really draws into question the claim that “it's easier to write super complex stuff in C++ than in Rust” when so clearly incorrect about JS. Especially when we have _decades_ of evidence from world-stopping vulnerabilities in the C/C++ ecosystem.

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

#164
It's also time to have a spec & alternative free implementation for Rust. Multiple compilers and standard library implementations for C is the reason why it's so ubiquitous in the embedded space and where Rust can do a lot of positive impact.

As of now, Rust does not have a spec: https://users.rust-lang.org/t/where-is-the-rust-language-spe...

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

#165

> 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++?

I'd pick Rust over "modern" C++ just because I don't have to deal with 15 compilers, 15 IDEs, 15 build systems, decades of language experiments, kind of compiler-flags driven development

Give rust a few decades and it will get there.

Remember when python was simple? And you just had setuptools? Popularity breeds complexity and fragmentation.

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

#166
post #134

Earlier quoted context omitted.

Of all the people to nitpick on that (and it is indeed a ridiculous nitpick), this is not one of them.

Maybe he thinks Azure should standardize on one of Go/Rust, Java/C#, or Haskell/OCaml for managing its hosting service. He is apparently in a position to enforce his opinion on the division. It is hard to know how anybody outside will be able to tell which he has chosen without his announcing it: "Azure has designated Haskell/Ocaml as its preferred language for hosting management utilities." Microsoft is no stranger…

What does this have to do with your grandparent comment?

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

#168

> 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++?

I'd pick Rust over "modern" C++ just because I don't have to deal with 15 compilers, 15 IDEs, 15 build systems, decades of language experiments, kind of compiler-flags driven development

I ran into those issues when trying to build some old modding software for a game that was written in C++ (Corsix Mod Studio if anyone is wondering).

I was not able to figure out how to get it to build, maybe someday I'll fire up a VM running XP and whatever version of Visual Studio was popular in 2006 and try again.

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

#169

Is he actually doing it? Making a plan and a policy to replace the bone marrow of MS with Rust? Or is this just a pie in the sky tweet? I don't know what Mark is like as a CTO, so I really don't know what to expect here.

Which part of "new projects" did you miss?

He stopped reading after Microsoft with his head racing hard to somehow bring them down

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

#170
post #20

Earlier quoted context omitted.

Eh, the main thing that can be done in python is calling all the libraries that have been written for python. Can't do that from JS.

The big stuff is mostly done in C/C++ (because Python is slow) and bound to, so you could end up with basically the same bindings for JS/TS.

The incredibly long time it took to port very popular libraries from Python 2, to Python 3, demonstrates how unrealistic this thought is.
Post reply on HN