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

881–890 of 929 posts

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

#881

Post by fxtentacle »

unnouinceput wrote: post #493
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...

I feel like this is very much outside the scope of "Rust is more safe than C++". I was talking about shielding from accidental bugs in an otherwise well-designed server where Rust would reduce the severity of one error class (out of many).

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

#883

Post by nspattak »

dxuh wrote: post #411

When people use "C/C++" as a single language I usually know right away don't know much about C++. The distance between C and modern idiomatic C++ is many times larger than the distance between C++ and Rust. C++ looks like an ancient juvenile dialect of Rust compared to C and C++ looking almost nothing alike. You can write shit C++ that looks like C and breaks like C or you can write good C++ instead and end up with l…

The problem with "c/c++" is not that the people using this notation are ignorant of their difference. the problem is that there is nothing preventing someone writing c in a cpp file. what is more, it is up to every one/every project to choose the cpp subset to use.

That is why i think the criticism is very very valid

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

#884

Post by roca »

scoutt wrote: post #459
roca wrote: post #313

Earlier quoted context omitted.

> the big problem is that for applications that do need to do non-trivial reference semantics, Rust doesn't really offer much. For those applications you can almost always encapsulate the unsafe code in a data structure library with a safe interface, such that the library is a tiny fraction of the application code. And in many cases someone else already wrote that library. For graphs, for example, there is petgraph.…

> For those applications you can almost always encapsulate the unsafe code in a data structure library with a safe interface, such that the library is a tiny fraction of the application code. This is something I never understood. Given that a Rust application is running on top of an OS making OS calls... or uses a huge library like FFMPEG... The only safe portion is like the 1% of code being executed. "such that the…

It's true that writing code in safe Rust does not make other non-Rust code safe.

Nevertheless, the more code we write in Rust, the safer we will be. Especially because popular kernels and system libraries are often very well tested these days, whereas application code newly written by developers of varying skill levels likely won't be.

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

#885

Post by sophacles »

ncmncm wrote: post #871
sophacles wrote: post #786

Earlier quoted context omitted.

> Obviously nobody will "lay off all the C++ folks" just because Rust promoters would really like that, and as much as say so 1. If it was so obvious, why did you claim it to be true, and then double down? 2. I have yet to see anyone say or even strongly imply it. The closest I've seen is this thread wherein you take a lot of leaps in reasoning and a very specific path through a large possibility space to divine the…

It is one thing for people to advocate a thing, such as "you should fire all your C++ staff and hire us", and another thing for my employer to obey. But that difference does not make advocating it less bad, unless they are obviously speaking facetiously and expect it to have no effect. It is very clear people saying it mean it and want that to happen. Azure CTO's announcement is a success for that advocacy.

I think you are delusional. No one is advocating for your firing. "NEW projects" is not "all projects ever existing". Just like cobol is still there and running decades after it was first considered a dead language. Even after new projects were all being written in java, the cobol programmers were there. They switched languages, or kept working in cobol. There are still new cobol programmers in 2022.

Even if every C++ codebase wanted to rewrite itself in rust that effort would take decades and in the mean time we'd still need C++ devs.

The only people advocating for firing C++ all devs are the imaginary ones in your head.

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

#886

Post by sophacles »

ncmncm wrote: post #870
cercatrova wrote: post #845

Earlier quoted context omitted.

Have you even used Rust? Based on your other comments, it just seems like you have an axe to grind against anyone who uses Rust, coming up with accusations of "Rust devs trying to take 'er jerbs"

I like Rust fine. But Rust is not suitable for my work, where C++ is. So, anyone saying "no programs should be written in C++" is saying, exactly, that I should not be able to do my work, and that I should not have employment. That my current employer will not necessarily obey such an instruction does not make the attempt any the less offensive.

It's finally clear - You don't actually think that people are advocating for you to be fired[1]. You are just taking an absurd extreme position because after a career of not having to think too much about other languages something comes along that can actually threaten the C++ crown. Now you are worried that you'll be relegated to the niches along with your language, like assembler and cobol. Don't worry - there'll be room for you there even as C++ fades away: you can stay in the niches, or you can maintain the mountains of existing C++ code, or you can evolve and move forward with the rest of us.

You are a great case study in why the rest of us shouldn't comingle our identities with the identities of our tools.

[1] I did note that you changed it from "no new projects" to "no programs" a dirty trick that I'm only going to address by pointing it out.

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

#887

Post by JonChesterfield »

ghoward wrote: post #788
JonChesterfield wrote: post #774

Earlier quoted context omitted.

What calls scope exit if there's a break / return / goto between the allocation and the scopeExit invocation?

I have macros for that that I use instead of the keywords. If the keywords appear in code that uses scopes like that, it's a bug. I still have a lot of technical debt with that, but I haven't gotten to it. However, when I do change it, I'll be able to find all instances automatically with grep.

There's a compiler extension to tag variables with a function called on scope exit. Attribute cleanup. For dubious portability reasons I'm unwilling to rely on it for correctness but it's really useful in a debug build for types where you can detect they haven't been cleaned up.

Change MyType to RAIIMyType or similar in the function to get the checking when using GCC/clang with asserts enabled. In practice sometimes types should drop out of scope without deallocation - return from functions etc. Thinking about it now I should probably apply it by default and use (MyType) to avoid the macro expansion selectively.

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

#888

Post by KptMarchewa »

galangalalgol wrote: post #562
KptMarchewa wrote: post #556

Earlier quoted context omitted.

>the way modern code is supposed to be written Many experts disagree with the way modern C++ evolves. To say that modern code is supposed to use all the C++11-forward features or else it's obsolete is a massive bias on your part.

C with classes originally meant non oo c++. It was a common crticism from a time when not being oo was considered a defect rather than a design decision on which paradigm fit your problem space. It would be like a haskell zealot saying someone's clojure was "java with lambdas" to imply it was imperative. Implying imperative code was always inferior. All that said, some parts of moder c++ like move semantics do really…

The "classes" part explicitly means OO.

It meant not using stuff like templates, operator overloading, RTTI, exceptions, STL.

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

#889

Post by sophacles »

snovv_crash wrote: post #874
sophacles wrote: post #601

Earlier quoted context omitted.

This is a really good point. Just like the Great and Powerful oz telling us not to look behind the curtain or you'll see a goofy old man - C++ is quite mighty if you don't look over there at the other stuff.

Rust only released 1.0 in 2015. If you want to complain about pre-C++11 features, I would like to complain about Rust's garbage collector.

Did rust have a GC at some point pre-1.0? Interesting.

Not sure how limiting the discussion of a language to just the features included in the 3rd standard and forward makes sense. Particularly when the old stuff is still present and valid in the later standards.

Just because you want to use some convention curtain off some area of the language doesn't mean it's not there.

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

#890

Post by ncmncm »

sophacles wrote: post #885
ncmncm wrote: post #871

Earlier quoted context omitted.

It is one thing for people to advocate a thing, such as "you should fire all your C++ staff and hire us", and another thing for my employer to obey. But that difference does not make advocating it less bad, unless they are obviously speaking facetiously and expect it to have no effect. It is very clear people saying it mean it and want that to happen. Azure CTO's announcement is a success for that advocacy.

I think you are delusional. No one is advocating for your firing. "NEW projects" is not "all projects ever existing". Just like cobol is still there and running decades after it was first considered a dead language. Even after new projects were all being written in java, the cobol programmers were there. They switched languages, or kept working in cobol. There are still new cobol programmers in 2022. Even if every C+…

Calling people delusional means you have no argument.

If my employer announced no new C++ projects, that would mean, at best, a sharp demotion. I would be relegated to maintenance of legacy products. The kind of systems I make would no longer be written, because Rust is not up to the job.

You reveal that what you are doing is fully as nasty as it seems. You reveal that you believe there wil be no room for your language without first tearing down another.

Post reply on HN