Live data from Hacker News

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

twitter.com

51–60 of 929 posts

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

#51

Earlier quoted context omitted.

Zig is production ready? I must have missed the 1.0 release announcement

It's not. But to be fair it feels more ready than rust did at 1.0

Not to say I'm not excited for Zig, but there are still bugs, miscompilations, and many breaking changes planned. Communicate realistic expectations, lest you become the next language evangelism strike force.

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

#52

The C/C++ people hate it when you call it C/C++.

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?

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

#53

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.

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

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

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

#55
post #45
post #31

Earlier quoted context omitted.

That's a fairly recent thing that some people do as a kind of virtue signaling. The "C/C++ Users Journal" was a very popular publication and no one took issue with its name. Nor do people take issue with Dr. Dobbs which has a "C/C++" section with articles from highly influential members of the C/C++ community. C++ is a complex language, so people invent ways to show how dedicated they are to it, and nowadays that mea…

I think it's also that idiomatic C++ is evolving further and further away from anything resembling C. So it's turning from C with extra features into a completely separate language that happens to interoperate well with C.

This is true. It's also true that, in terms of abstract machine semantics, C++ is the closest language to C. Similarly, in terms of optimizing compiler implementations, they're the two "core" languages implemented by most frontends. The grouping of "C/C++" makes sense in both of these contexts, at the minimum.

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

#56
post #52

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?

Not necessarily -- I've interviewed plenty of people where "C/C++" meant "experienced in both, but most work was in C with a small smattering of C++" (or vice versa).

In my experience, it breaks roughly between half that and half recent graduates who took one C course and one C++ course.

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

#57

I'm waiting for Rust to support both static and dynamical link equally well. static link produces binaries too large for my embedded boards when stdlib is needed. dynamic link looks like a second class citizen to me in Rust. Is there some hope?

you can use no_std when available. not sure how dynamic linking would help when your boards don’t have enough (flash ?) space… the linked library still needs to go somewhere? how small of a flash medium are you using?

Maybe multiple entrypoints?

The busybox style of packing everything into subcommands of one big exe is admittedly a hack, but... if it works for Busybox, and it works for Go, and it works for Git, and it works for Docker, then it works for me.

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

#58

> 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

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

#59

> 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 sort), especially for less experienced C++ engineers. Some kinds of corruption (like double frees) have become even more common as beginner mistakes, in my experience, thanks to the complex mental model required for move construction (compared to Rust, where moves are statically checked).

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

#60

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.

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"?
Post reply on HN