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

491–500 of 929 posts

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

#491

Post by lbriner »

ekianjo wrote: post #192
woodruffw wrote: post #11

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

Appeal to authority?

Appeal to authority is when you claim something is true just because an "authority" said so.

MR is clearly expressing an opinion and reasons for it and it is up to you to decide whether his experience qualifies him to make such bold claims, whether there are edge cases for exceptions and whether or not you agree or care.

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

#492

Post by lbriner »

physicsguy wrote: post #312

Blanket statements like this just show that people don’t understand why people stuck with a language. I worked in C/C++ for a long time, though it’s been a while now. I just went to look at whether Rust had any bindings for MPI. It does - rsmpi. But they’re not fully implemented, and only support a restricted subset of MPI implementations which are pretty much the latest versions. Some others might work, but it is no…

I agree. It's like when MS tell everyone just to "upgrade to dotnet 6" or 7 or whatever!

Most of us don't have the funding, skills, time, priority to rewrite all of our old web forms apps even if we wanted to. Who is going to pay to rewrite the app that only earns us $10K a year?

Even if we did decide that Rust is great, do we immediately expect our C++ senior devs to produce the same quality code in a language they have only just learned? Are we going to recruit some confident youngsters who possibly know Rust but haven't been burned enough times to be pragmatic when implementing it in the wild. Do we want to rely on a new language that ticks lots of boxes but also lacks the understanding/support and battle-testedness of C++?

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

#493

Post by unnouinceput »

fxtentacle wrote: post #349

I get that it makes sense at his level, but my impression is that mistakes in the business logic are both more common and more financially painful for the company than the memory safety issues that Rust solves when compared to C++. Unsafe binary? Run it in docker. Crashes? Run two and monit. RAM leak? Restart with cron. Now I'm not saying that these are good solutions, but they are good enough so that plenty of compa…

If you think that an unsafe binary is safe if you run it in docker then I challenge you to run, on your personal computer, this program in docker:

https://arstechnica.com/information-technology/2022/09/new-l...

use this picture in a hexeditor:

https://cdn.arstechnica.net/wp-content/uploads/2022/09/shiki...

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

#494

Post by Xcelerate »

I’ll controversially go a step further and say we need to even begin requiring this via regulation for certain applications, at least for those that involve the personal or financial data of customers. From working with security at a large tech company, it’s abundantly clear that C/C++ should not ever be used for processing sensitive information (it’s fine to keep around for high performance computing or processing non-sensitive data). There are just too many people involved in making codebase changes and too many potential errors to be made. Not every company has the resources to devote to an in-house static analysis team.

We have all sorts of regulation in other industries to protect consumers, and with so much of our economic infrastructure dependent on the security and integrity of information processing, it’s bizarre to me that we’re still using programming languages with severe deficiencies for these purposes.

Will there be performance hits, cost hits, and inefficiencies introduced by requiring safer languages? Of course. But I see that as vastly preferable to the dangerous state of cybersecurity at almost all companies.

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

#495

Post by lbriner »

foomatic wrote: post #184
ReactiveJelly wrote: post #76

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

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?

This is a common fallacy imho that if I am a good dev, I can easily cross-train.

I have been writing C# almost exclusively for around 20 years and I am still learning tricks/tips/gotchas and not just for new language features. That is why my experience is important. Even in something like Java which looks very similar to C#, it takes a long time to work out what works differently, good patterns and idioms, the correct libraries that everyone uses for stuff etc. even when I know what I am looking for.

When I looked at Rust, I got some of it because I have previously written C and C++ and didn't have a problem with the concept of pointers or references but it still took me several weeks to get a basic example working and I had to ask on a forum in the end.

So yeah, not easy!

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

#496

Post by pizza234 »

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…

> The "safe" solution recommended by the rustaceans was to use integers as references to the data in a vec or hashmap

This is not correct advice; not sure why you've been given this answer.

There are a couple of solutions.

1. you use a data structure (library) that returns you a handler, which can be an int, but it's not an int as in "position inside a vec" (index), but a symbolic reference, whose management is deferred to the library.

You can't use an index directly because if a position is freed, then taken, you will hold an invalid reference (int).

This is a handy solution, convenient to work with; if you do something wrong, you'll get an error from the library.

2. the manual solution is to use strong/weak references, which are quite ugly to use :)

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

#497

Post by classified »

stouset wrote: post #467
ghoward wrote: post #438

Earlier quoted context omitted.

Notice that in my first post, I said to use Rust where practical. I never said that everyone should use C. I'm only claiming that I personally can do just as well in C as I could do in Rust, and that I prefer to work in C, so I might as well. Break my `bc`.

I honestly don't understand the point of your post then. Are you looking for a pat on the back?

No post body was provided.

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

#498

Post by bscphil »

hda2 wrote: post #316
lenkite wrote: post #260

Earlier quoted context omitted.

Stuff like Slotmap should be part of the standard library instead of some github project with open issues that isn't updated for over a year.

This is my main gripe with Rust. Things that should be part of the standard library are relegated to third parties, thus requiring developers to audit yet another dependency (and it's dependencies, and sub-dependencies, and sub-sub-dependencies, ...). Realistically, this just means I can't use most third-party crates, greatly limiting what I can do with Rust. It's been a long time since I've been able to write anythi…

> gcc-rs splitting the Rust ecosystem into two; the current npm-style crates.io ecosystem and a more destro-centric properly vetted package ecosystem

Has there been discussion about this here on HN or an article about it you can point me to? I'm very much interested in exactly the same thing.

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

#499

Post by heeen2 »

physicsguy wrote: post #312

Blanket statements like this just show that people don’t understand why people stuck with a language. I worked in C/C++ for a long time, though it’s been a while now. I just went to look at whether Rust had any bindings for MPI. It does - rsmpi. But they’re not fully implemented, and only support a restricted subset of MPI implementations which are pretty much the latest versions. Some others might work, but it is no…

https://www.areweguiyet.com/

Until rust catches up with some meaningful feature set that Qt provides starting a GUI project in rust is probably going to be painful.

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

#500

Post by pie_flavor »

ninefathom wrote: post #242

There are new programs being written daily in COBOL and Fortran, and I'm fairly certain that I see new PL/I floating around occasionally. C and C++ aren't going anywhere anytime soon. Love them, hate them, want to burn them with fire, they're here for a long, long time. Leaving that aside, I was still hitting Rust "oh look the developer of this crate on which the entire universe depends still assumes that everything…

It's not like it's any different for C. Rust gives you a choice of five operating systems? A given C library gives you a choice of one, on a good day. And if you've got your favorite C library already then binding to it is a breeze. I don't understand the mindset that because Rust and its entire ecosystem is less than perfect it should be junked for C which never even cracked a quarter of the distance.
Post reply on HN