It's time to halt starting any new projects in C/C++ • Hacker News Board

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

#371

Post by howinteresting » Tue, Sep 20, 2022, 6:31 AM UTC

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…

Rust also solves many classes of logical issues through ADTs and pattern matching. And many classes of thread safety issues. Memory safety is an important part of Rust but not all of it.

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

#372

Post by spoiler » Tue, Sep 20, 2022, 6:32 AM UTC

snovv_crash wrote: post #339

lmm wrote: post #285

Earlier quoted context omitted.

> You don't need to know about about 6 different string types If you're working on a substantial C++ codebase you probably do, actually.

There are no 20 year old Rust codebase to compare with. C++ has gotten easier and cleaner on the last 20 years, whereas Rust has gotten more complicated. If we want to plot future trajectories...

What are you basing this on? I've found Rust has gotten simpler, and the correct things to do has become more ergonomic, if anything.

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

#373

Post by imron » Tue, Sep 20, 2022, 6:33 AM UTC

ghoward wrote: post #336

imron wrote: post #323

Earlier quoted context omitted.

After looking at this, honestly, you should just use C++.

Well, you're not wrong, but I hate C++. With a passion.

I get where you're coming from - there are plenty of parts of C++ that I dislike also, but this kind of 'clean up on scope exit' has always been one of C++'s strengths - even before modern c++, and is significantly less error-prone than the solution you present above.

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

#374

Post by prabhu-yu » Tue, Sep 20, 2022, 6:33 AM UTC

In C++, there is Move semantic. If we use "Move semantic" in C++ code, could it match the memory safety of the Rust?

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

#375

Post by phantom_of_cato » Tue, Sep 20, 2022, 6:34 AM UTC

This is a stupid "hot take", no matter the stature of the person who said it. They may have a point, but they aren't making much of an argument with a single tweet.

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

#376

Post by pharmakom » Tue, Sep 20, 2022, 6:35 AM UTC

Gigachad wrote: post #279

hardwaregeek wrote: post #210

Earlier quoted context omitted.

Because “just hire good people” is on par with “just hire good pilots”. Easier said than done.

It's also expensive. Every industry has focused on changing the environment so average people can do good work rather than fight over the top 5% of talent.

I guess Java would be the counter example to this.

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

#377

Post by selfmodruntime » Tue, Sep 20, 2022, 6:38 AM UTC

ajross wrote: post #223

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…

That's my take too. Idiomatic Rust is "safe" in the sense that... it disallows most nontrivial data structures. Even a doubly-linked list is impossible to get through the borrow checker. That's... not really that fatal. There's a lot of very useful code that can be written using only runtime-provided[1] containers and straightforward ownership trees. But obviously the big problem is that for applications that do need…

Both doubly linked lists and cyclic graphs can be written in a way that satisfies the borrow checker. If not already existing in the STL, there is a crate for it 99% of the time.

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

#378

Post by JCWasmx86 » Tue, Sep 20, 2022, 6:39 AM UTC

user8501 wrote: post #271

Seems like kind of a crazy thing to say. The first thing to note, is that we should obviously be free to write software like games and other utilities in whatever language we want, especially if they’re not connected to the internet. Second, why exactly are we demonizing people now? Suddenly declaring a language deprecated not only doesn’t actually make any sense, but also seems like a great way to influence people’s…

Agreed. And while rust has fantastic ideas, those are frankly often badly executed:

- Static linking of everything

- Big dependency trees that somehow remind me of npm

- Slow compilation, it should reach at least the average speed of C compilation

- Big binaries because of static linking

Before this is solved, I frankly wouldn't even consider touching rust again for personal projects, did it once, and it was an awful experience with too long compile times, as my style of development depends on fast compile-run-test cycles and having to wait around a minute to recompile for a small program is just too much.

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

#379

Post by spoiler » Tue, Sep 20, 2022, 6:39 AM UTC

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…

> 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 is x86

Anecdotally, I had the same issue recently with a C++ tool I wanted to tun on arm linux (forgot what it was; but it was a WASM tool. I ended up using a Rust alternative that was less mature, but did all I needed anyway)

Lastly, the issue you're describing is more of a DevOps one. C++ has a longer history, and one would hope it has accumulated more DevOps wisdom over that period of time.

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

#380

Post by imagine99 » Tue, Sep 20, 2022, 6:39 AM UTC

kramerger wrote: post #332

virgulino wrote: post #251

You could say that Mark Russinovich is a hacker's hacker, the foremost Windows hacker, and a reverse engineering wizard. It was he who discovered and blew the whistle on the Sony rootkit scandal, for example, after finding and reverse engineering it on his machine. https://en.wikipedia.org/wiki/Sony_BMG_copy_protection_rootk... He extensively reverse engineered and documented "Windows Internals" details before joinin…

Well... He is also written some horrible fiction novels, so the guys is not perfect.

Why would you say that? They are all rated 4+ stars on Amazon (at first glance), so the general consensus is that they are probably not that "horrible".

Personally, I enjoyed them a lot and I am actually a bit bummed that he stopped publishing new ones...

Granted, I probably would not have read them had I not recognised his name on the cover (there is too much cookie-cutter stuff out there). But I did not regret buying them and I remember being impressed by the fact that this guy wrote Syinternals AND engaging fiction...