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

741–750 of 929 posts

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

#741

Post by pwpw »

eloff wrote: post #729
pwpw wrote: post #700

Earlier quoted context omitted.

As someone that is looking to learn one or the other (and hopefully be able to utilize it to land a job too), is the recommendation to skip learning C++ at this point and learn Rust instead? I was going to learn how to write a game boy emulator, which could be written in either, but I’d also like the language to help me in the professional world as someone getting ready to enter the field.

You'll have a harder time finding work, as there aren't a lot of Rust jobs. That's why it's a signal that a person loves their craft - there's little financial incentive in learning it. When it comes to finding work, pick a mainstream language. This will change over time as Rust becomes mainstream, which I think is likely.

Thanks. My plan will be to follow along https://www.learncpp.com/ and then check out the Rust book later on then. I've found previous success in learning an older language that a newer one can replace (JavaScript to TypeScript) as it helps me understand why devs might prefer the newer language and what it aims to solve. It's a lot of learning, but perhaps that is a necessary evil to grow into a strong developer.

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

#742

Post by woodruffw »

LtWorf wrote: post #733
woodruffw wrote: post #658

Earlier quoted context omitted.

One of the guarantees that Unsafe Rust makes is that well-formed unsafe code cannot trigger unsoundness in safe code. In other words: I very rarely write unsafe code myself. When I bring in others’ unsafe code, I use cargo-geiger and siderophile (which I help maintain) to quantify it.

It's not a guaranteed guarantee as far as I can understand. Or such bugreports would make no sense: https://github.com/denoland/deno/issues/15020

The bug report says exactly what I said: if you don't write well-formed Unsafe Rust, then Rust will not make any guarantees about invariant preservation in Safe Rust.

This is exactly the same as in C++, except stronger: in C++, any piece of well-formed code can violate safe invariants. In Rust, only unsafe code can violate safe invariants, and can only do so if it isn't itself well-formed.

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

#745

Post by sophacles »

ncmncm wrote: post #703
sophacles wrote: post #597

Earlier quoted context omitted.

"Hey C++ developer, you should use rust instead" is very different than "Hey C++ developer, I don't want you to have a job". Do you not see the difference?

I do. "New programs should not be in C++" means, exactly, "You should be laid off so they can hire me instead". If you had something that could do what I need, I would be using it already. It cannot. But you want to bypass me and fool managers, instead, with FUD about memory faults I don't code and have not in years. I have spent strictly more time in the past five years filing compiler bug reports than chasing memor…

> "New programs should not be in C++" means, exactly, "You should be laid off so they can hire me instead".

That strikes me as wrong in many ways. I think it means, exactly - "new programs should use a different language than C++".

I someone writing that might have been implying "hire me instead", but given the specific author is CTO of azure, i doubt they are angling for your job, or really any dev job.

Managers hearing this advice from the CTO of could possibly interpret it as "lay off our C++ folks, we're hiring for rust". Or they could interpret it as:

* We should switch to the new language, have the team train up.

* We should have the team start evaluating new languages (or rust specifically).

* We hire some rust folks for the next project to evaluate how it goes.

Any half-way decent management will know that the institutional knowledge in their existing dev team is worth a lot, and getting the new hires up to speed is rather expensive.

Sure crap management exists, but I've never had, nor known any who has had management so bad that they would lay off thier whole dev team over a tweet. I really doubt "lay off all the C++ folks" would be a particularly common response.

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

#746

Post by dleslie »

generichuman wrote: post #731
metaltyphoon wrote: post #688

Earlier quoted context omitted.

Well say no more then https://blog.unity.com/technology/unity-and-net-whats-next

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.

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

#747

Post by ugh123 »

dynamite-ready wrote: post #418

I think this is a silly idea. There are still loads of questions surrounding Rust. Especially about it's practicality... There are articles denigrating the likes of the trait and async systems on HN almost every day. And even ignoring that argument, any language is viable, so long as it can be used to build what you want to build.

I think you're forgetting the security issues surrounding C. Also, I could build a lot of stuff in PHP. But in 2022, is that wise?

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

#748

Post by acdha »

mkl wrote: post #551
nindalf wrote: post #544

Earlier quoted context omitted.

They’re claiming the CTO of Azure doesn’t know enough about modern C++ to make the statement that we’re discussing. Bold claim.

I find it hard to imagine the CTO of Azure has done enough C++ programming in the last few years to be fluent in C++20. Maybe as a hobby I suppose; it doesn't match my understanding of what a CTO of a big organisation does otherwise.

No, but a good CTO would have people they trust telling them how it’s working. At Microsoft’s scale they could have an entire team auditing internal project stats looking at error rates, adoption of newer features, etc. - they spend more on toilet paper than that would cost!

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

#749

Post by gavinhoward »

stouset wrote: post #486
gavinhoward wrote: post #435

Earlier quoted context omitted.

Notice that I said to find a memory bug in a release, not just any commit. Yes, there will be memory bugs during development, but I usually find them before release. There will definitely be commits fixing memory bugs during development. The bcl library is an exceptional case, where my test suite did not have sanitizers and Valgrind properly hooked up, and that one was because it went from a global (guaranteed to be…

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

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

#750

Post by ghoward »

Arnavion wrote: post #477
gavinhoward wrote: post #435

Earlier quoted context omitted.

Notice that I said to find a memory bug in a release, not just any commit. Yes, there will be memory bugs during development, but I usually find them before release. There will definitely be commits fixing memory bugs during development. The bcl library is an exceptional case, where my test suite did not have sanitizers and Valgrind properly hooked up, and that one was because it went from a global (guaranteed to be…

>Notice that I said to find a memory bug in a release, not just any commit. You did not say anything of the sort. >But I also said to find one in the program, not the library. You did not say anything of the sort. You said: >>The code is my `bc`. [1] >>Find a memory bug, any memory bug, in my `bc` after 1.0. >>[1]: https://git.yzena.com/gavin/bc But okay, let's acknowledge the moved goalposts. >I issue that challenge…

Okay, so I didn't say a release at first, but I meant to. That's only fair.

Anything built without the -a option to configure.sh is "the program." That's the vast majority. You can try the library too, but there is that one mistake you already know about. I don't think there are any others though.

And again, even with the things you all have found that are in random commits, it doesn't really matter; Rust isn't completely memory safe either. It's close, but not quite.

Post reply on HN