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

761–770 of 929 posts

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

#761

Post by stouset »

gavinhoward wrote: post #749
stouset wrote: post #486

Earlier quoted context omitted.

"Find a memory bug in this repo. No, not those bugs. No, the ones in that part of the program are off limits. The ones I pushed but caught just before tagging don't count either because I noticed them just in time. Okay there was this one time where it happened when my complicated sanitizer setup broke without me realizing but that was a total fluke. And that other one also doesn't count because it definitely wouldn'…

Seriously? Just try it. Break my `bc` in a release. I dare you. Until any of you do, you're just trolls or the RESF.

To what end? You’ve already stated elsewhere that your only point is that you can, under an increasingly strict set of conditions, write code that is (almost always) free of memory bugs. Great!

Nobody is hiding around the corner waiting to take `gcc` or `clang` away from you if you want to keep using them. Nobody's threatening to take away your software engineering license if we catch you writing a memory bug.

This whole thread is ridiculous. “The safety improvements in modern cars are substantial. If you're buying a new car these days, you should probably buy one made after 2018.” “Well I'm still driving my 1969 Malibu. Plus I’ve never been in an accident so I don’t need those safety features.” “Okay but… what are those dents in your car?” “I said no accidents on public roads. Prove me wrong or STFU.”

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

#762

Post by est31 »

petmon wrote: post #344
est31 wrote: post #229

Earlier quoted context omitted.

> That said, almost every concept you need to understand C++ is also needed to understand Rust I agree that many basic C++ concepts are also present in Rust, but C++ is more than just its basic concepts: it's a huge set of features on top of those that interact with each other in complicated ways. Like how constructors aren't functions but something very special. If you just want to be a beginner C++ dev who works al…

Rust's "feature surface area" reaches or exceeds that of C++ through procedural macros, which surfaces the entire Rust AST to the developer. Major Rust crates like serde use this feature, and when it goes wrong the errors are actively misleading. I've personaly been bitten by this, it's incredibly frustrating to debug. https://serde.rs/derive.html#troubleshooting

proc macros are their own walled off thing with well defined input of tokens, and well defined output (also of tokens). You have tooling to inspect their output (cargo expand). Compare this to the average C++ feature which is usually implicit and not visible in syntax and interacts with other C++ features in interesting ways that you have to keep in mind.

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

#764

Post by dan_mctree »

metaltyphoon wrote: post #665
dan_mctree wrote: post #526

Earlier quoted context omitted.

>I agree. It's like when MS tell everyone just to "upgrade to dotnet 6" or 7 or whatever! The amount of global manhours MS is throwing down the drain by constantly ending support for their versions must be absolutely staggering. Updates are often far from trivial, and they expect everyone to keep up with their fast upgrades and tiny support windows? Long term support is only 3 years, are you kidding me?

> Updates are often far from trivial No, they are actually trivial starting from 3.1/5/6 exactly because of the work they have put in.

That's great for those already there. For those of us still partially stuck on .Net Framework it is anything but trivial.

And sure, upgrading from .Net 5 to 6 was trivial, but do you really anticipate it will now finally remain stable for eternity? Give it two or three minor versions and they'll have come up with something else to break 90% of your dependencies.

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

#766

Post by jokoon »

I highly doubt that it's easy to hire rust developers.

Maybe it's possible to hire c++ dev and make them work on a rust project?

Anyhow, is there a qt equivalent for rust? Can rust really compete with c++?

I've read rust code and I'm sorry but it seems like the steep learning curve is just not worth it, even if the benefits are big.

I still believe rust fills the same niche of ada, meaning tight requirements. Most c++ projects don't care that much. It's cheaper to test things or rewrite than betting on a new difficult language.

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

#767

Post by 29athrowaway »

sudosysgen wrote: post #641
29athrowaway wrote: post #337

Earlier quoted context omitted.

There is C++ code that 99.999% of people that list C++ in their resume are unable to explain. You can get comfortable with some idioms of C++, that's fine. Can you understand what any valid C++ code means? No. Such person does not exist, not even Bjarne.

You can say the same of any language. Deobfuscation is a hard problem. Only code meant to be reasonably understood is a valid comparison.

I don't mean obfuscation, I mean features of the language and their interactions.

C++ is a mine field. You need to learn where all the mines are and spend your day carefully walking around them.

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

#768

Post by generichuman »

dleslie wrote: post #746
generichuman wrote: post #731

Earlier quoted context omitted.

As far as I can tell this only improves things on the Unity side. What I have in mind is just making a game that can run on PS5/Xbox/Switch without using anything other than C# itself (and the platform API). No engines. I vaguely remember proof-of-concepts/experiments on Nintendo Switch that made it possible to deploy NET Core AOT builds, but it was in some gitter chatroom so sadly I can't find it again. Anyway, we s…

If you're not using an engine, with a good editor, then you're already firmly among a niche few. The asset pipeline has been the dominating concern in game development for decades now, folks who willingly toss all that aside to write a game from scratch are among the fringe.

> If you're not using an engine, with a good editor, then you're already firmly among a niche few.

Not really. SDL, SFML, Monogame and FNA (and more) do not have editors, but a lot of popular indie titles are shipped with them.

> folks who willingly toss all that aside to write a game from scratch are among the fringe

Check out Dear Imgui. Indie shops such as exok (makers of Celeste) and AAA companies such as Rockstar Games (GTA) use it to create editors for their games.

You don't really need an engine. You probably need a framework if you're going cross-platform. If you're exclusive, you don't even need that.

If we start depending on proprietary engines instead of platform APIs, we're shooting ourselves in the foot in the long-term.

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

#769

Post by bobbylarrybobby »

worik wrote: post #385
hgs3 wrote: 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…

> I had trouble expressing cyclic data structures You cannot do cyclic data structures in Rust because every thing must have one owner, so no cycles. You can do cyclic data structures in Rust with unsafe code or doing your own memory management (e.g. an arena data structure). > 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 imp…

The data held by an Rc doesn't have one owner. It would probably be pretty painstaking to do cyclic data structures with them correctly, differentiating between strong and weak Rc as appropriate, but probably doable. If you don't care about leaking memory, or if the graph is static, you don't even need to worry about that.

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

#770

Post by _gabe_ »

slashdev wrote: post #722
_gabe_ wrote: post #602

Earlier quoted context omitted.

> Programmers currently using Rust are superior to programmers using C++ > People learn C++ in college. People learn Rust because they love their craft Wow... and rust programmers wonder why rust has a stigma? So I guess John Carmack is inferior and is not an ultimate craftsman.

I think I hit a nerve with this one. If you put out a job ad for any mainstream language (Java, JavaScript, C++, among others) you're inundated by applicants who have no business even working in this industry. If you put an esoteric language like Elixir or Rust, you get a smaller but much higher quality pool of applicants. That's my personal experience, I don't have hard data to back it up. Paul Graham once wrote abo…

> I think I hit a nerve with this one.

It does tend to grate on people when you have developers from a certain community going and calling anybody that doesn't agree with their "One True Way" inferior and not loving their craft. This is literally the No True Scotsman fallacy to a tee. You're essentially saying, "Only a true programmer that loves their craft would use Rust. Clearly if you're not using Rust, you're not a true programmer". Yeah, sure.

I'll say this for the millionth time, I've seen great code in C++, I've seen terrible code in C++. I've seen great code in Python, I've seen terrible code in Python. I've seen great code in Typescript, I've seen terrible code in Typescript. I personally don't look at Rust code, but I'm willing to bet that there's great Rust code, and terrible Rust code. It turns out, the language is not the variable in this equation, it's the developer.

> That's my personal experience, I don't have hard data to back it up.

So, statistically speaking, you're making this up out of thin air.

> That you can find an exception doesn't disprove the rule. You still have to treat people as individuals, and not as a population. That should go without saying.

Exactly, which is why saying something like:

>> People learn C++ in college. People learn Rust because they love their craft.

Is such a radical statement. I don't see people from other programming language communities talk like this. It's amazing to me that people from the Rust community think saying things like, "If you don't learn Rust, it must be because you don't love your craft" is a verifiable fact.

I know it's a crazy thought to have, but maybe, just maybe, people can like different things...?

Post reply on HN