Live data from Hacker News

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

twitter.com

211–220 of 929 posts

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

#211
I tried Rust about five years ago and I had trouble expressing cyclic data structures because there is no clear "owner" in a cyclic data structure. The "safe" solution recommended by the rustaceans was to use integers as references to the data in a vec or hashmap. I was rather put off by this: Instead of juggling pointers I was juggling integers. It made the code harder to debug and find logic errors. At least when I was troubleshooting C I could rely on the debugger to break on a bad pointer, but finding where an integer became "bad" was more time consuming.

The borrow checker worked fine when all I needed to do was pass data up and down the callstack, but anything beyond that was difficult or impossible to express. Has the borrow checker become smarter since then? At the time I was very put off.

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

#212

Earlier quoted context omitted.

Hm? I'm not a particular fan of Microsoft, but his stated opinion here is reflective of a broader trend in software design, one that's coming from both companies and the open source community. I don't see the brainwashing.

His "opinion" is not only reflective, but amplifying, and that's the scary part. The companies are the ones pushing this "security" stuff, because they want to stop us from doing things like jailbreaking --- and eventually running any software they don't approve of. See https://news.ycombinator.com/item?id=32905587 He used to write very useful utilities which did things that Microsoft didn't officially support or oth…

I don't think Microsoft's interest in Rust boils down to preventing jailbreaking. It'd be far, far cheaper to lobby the US government to ban it.

(Jailbreaking has always been an arms race, and memory corruption exploits may eventually reach their natural end. But that'll probably be because of things like PAC, not Rust. When that happens, I expect jailbreakers to move onto the next low hanging fruit.)

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

#213

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

Ok, so I hate to be too direct but the rust enthusiasm always struck me as annoying like the meme about arch users telling everyone they use arch and so should you, but on that token, I always felt it strange given it's literally over something as mundane as a programming language choice. BUT, this as a reason seems to explain a lot more for why evangelists, particularly those in management type positions in large IT companies are pushing rust so much. Wanting to weaken the economic position of a certain type of developer makes a lot more sense.

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

#214
post #109

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…

> in Rust as there are just too many cognitive things to keep in mind in Rust to even compile.

That hasn’t been my experience. Rust (the language) doesn’t seem to get any more complex as programs get bigger. Lifetimes, while complex in isolation, tend to compose really well.

Most of the pain of learning rust seems to be experienced up front. (Well, other than async but I don’t consider that ready yet).

In comparison, my experience of C++ was that it has way more “spooky action at a distance”. A bug in one part of the code will cause problems in another totally unrelated part of the code. I’ve had memory bugs in C++ which took weeks to track down. Maybe C++ has gotten better - I haven’t touched it in over a decade. I haven’t wanted to. And I can’t see many reasons I’d pick it up now that I know rust.

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

#215

Earlier quoted context omitted.

Why not just hire good people and ask them to learn C++. I mean how the heck did anyone actually pass this magic barrier of becoming a "C++ dev" in order to get hired as a C++ dev?

Because, little by little, C++ became "unlearnable". Long ago C++ made C a little bit more complex. Because there were already lots of C programmers that wasn't a big deal. But then it didn't stop. Little by little C++ grew into a monstrosity. A lot of people went along. I gave up. For new programmers to climb in 2-3 years a mountain that seasoned programmers took 15-20 years to climb is asking too much.

Just cus they add a feature to a language doesnt mean u have to use it. Though it does seem very few programmers are smart enough to stick to the most basic features whenever possible.

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

#216

Earlier quoted context omitted.

Why not just hire good people and ask them to learn C++. I mean how the heck did anyone actually pass this magic barrier of becoming a "C++ dev" in order to get hired as a C++ dev?

Cause those person-hours have to come from somewhere. Am I spending 2x of the new hire's time making them learn a harder language? Am I spending 2x of a senior's time teaching the new hire? What's the payoff in sticking with C++? Better libraries? Better tools? IDEs? That stuff will all shift as time goes on, if popularity is against it.

My point was a good coder / CS person is going learn either twice as fast as average one, bad one not at all.

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

#217
post #211

I tried Rust about five years ago and I had trouble expressing cyclic data structures because there is no clear "owner" in a cyclic data structure. The "safe" solution recommended by the rustaceans was to use integers as references to the data in a vec or hashmap. I was rather put off by this: Instead of juggling pointers I was juggling integers. It made the code harder to debug and find logic errors. At least when I…

Juggling (raw) pointers is still an option in Rust, just not the most idiomatic one. But you're right that expressing cyclic data structures is very challenging to do idiomatically in Rust.

Using integer handles as pointer replacements does have some universal benefits though outside of Rust. You can make them more compact, they serialize more easily, etc.

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

#218
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…

Really interesting take, I've had the opposite experience. I've also seen very talented c++ devs screw things up in prod that rust doesn't even allow for. Really recommend taking it more seriously, it's fun once you get a handle on it. Also the tooling is really good now.

C++ has grown several language tools to let you write reliable, safe code.

... But it can't shed the old stuff without breaking backwards compatibility, and that's what bites you. The fact that smart pointers exist now doesn't stop a developer from passing around non -const char* with no size specifier and calling that a "buffer," and because the language is so old and accreted most of its safety features later, the shortest way to express an idea tends to be the likeliest way to be subtly wrong.

This is really just a problem that other languages don't have because they didn't have the same starting point.

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

#219

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

Ok, so I hate to be too direct but the rust enthusiasm always struck me as annoying like the meme about arch users telling everyone they use arch and so should you, but on that token, I always felt it strange given it's literally over something as mundane as a programming language choice. BUT, this as a reason seems to explain a lot more for why evangelists, particularly those in management type positions in large IT…

> Wanting to weaken the economic position of a certain type of developer makes a lot more sense.

Just more anecdata, but this isn't true for my company. We're hiring for Rust because we're seeing more and more clients take memory safety seriously (and ask specifically about it as a design consideration).

These things have a way of balancing themselves out: developers like Rust, so there will probably be an eventual "glut" of Rust programmers like there was for C++ programmers in the 1990s. But it's a multiparadigm language, so I don't expect there to be consistent wage deflation based on that (and especially not in systems, where finding competent engineers is a perennial problem).

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

#220

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

Very very rarely in my life do I feel affectionate towards Windows (and I've been virtually exclusively Linux/other-unix for a long time.) Sometimes it happened when I was writing dumb VBA in some Excel project, which I find fun for some reason. It happens when I play Windows 95/XP era Minesweeper. It also happens when I touch or have to use any part of Sysinternals. I even like reading the docs for Sysinternals, eve…

I feel the same way about Sysinternals tools. They give me a warm fuzzy feeling, I think acquiring+maintaining Sysinternals is one of the best things Microsoft's ever done.

The way they expose OS internals in a powerful-but-user-friendly way is delightful and empowering. I still remember the first time I used procmon; it felt like a veil was removed from my eyes, suddenly I could trivially see everything processes were doing!

Sysinternals represents an idealized Windows to me: an OS for power users with a GUI-first culture that differentiates it from Unix. Windows itself might not live up to that dream anymore, but at least we have Sysinternals.

Post reply on HN