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

781–790 of 929 posts

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

#781

Post by ncmncm »

sophacles wrote: post #745
ncmncm wrote: post #703

Earlier quoted context omitted.

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

The topic in this subthread is overbearing Rust evangelists and their effects.

To the degree that management pays them any attention -- and a CTO parroting their advocacy in tweets (squawks?) certainly counts -- the threat is real. Other companies' management may be equally affected, in a degree more than just posting idle-hack tweets.

Against, the subthread topic is overbearing Rust advocates and, specifically, what harm they can do. Obviously nobody will "lay off all the C++ folks" just because Rust promoters would really like that, and as much as say so. But that is very far from saying no harm is done, or that no one is harmed by their extremist rhetoric.

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

#782

Post by diffxx »

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.

Gavin, there is no point in arguing with fanatics. (You have to know that none of them are actually going to dive into your code and possibly learn something new that didn't come from a vetted authority figure). They are incapable of listening to their own independent thoughts, assuming that they have them, and must attack anyone who counters their dogma because it risks shattering their core beliefs, which is intolerable. The funny thing is that the truth of rust is right there in its name. It is a corrosive process that ruins the iron that it touches.

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

#783

Post by ncmncm »

Qwertious wrote: post #463
ncmncm wrote: post #400

Earlier quoted context omitted.

I see you do not have much contact with Rust evangelists.

I think they're thinking "how do we get those C++ businesses to switch to Rust" rather than "how do I bankrupt them".

They're thinking "how do we get those C++ businesses to stop hiring C++ coders, and start hiring us Rust coders instead".

The original purpose of Rust was to displace C, a laudable goal. But it is failing at that, because C coders are practically defined as people who will never switch to anything. (Any who might have did already.) So now the only hope is to displace C++ instead, and the propaganda machine is trying to paint C++ as equally as unsafe as C, which it manifestly is not, lying if that is what it takes.

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

#784

Post by Ygg2 »

kramerger wrote: post #485
Ygg2 wrote: post #448

Earlier quoted context omitted.

Why are fiction novels relevant to field of computer languages? This seems like ad hominem.

The books are about computer security. My impression from the first book was that the author has a very back and white view of the world. That could very well also affect his day job

Sure, but a fiction book isn't written in a vacuum.

https://www.youtube.com/watch?v=mvaUwagX_uU

For a light-hearted take.

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

#785

Post by howinteresting »

spacechild1 wrote: post #479
howinteresting wrote: post #371

Earlier quoted context omitted.

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.

I don't know much about ADTs, but I'm skeptical they would help me for my own programs since most of my logic errors boil down to wrong math...

It is true that Rust won't catch bad math or a flipped not sign, but it catches just about everything else, which is very valuable since brainpower can be devoted to just the subset of issues it doesn't catch.

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

#786

Post by sophacles »

ncmncm wrote: post #781
sophacles wrote: post #745

Earlier quoted context omitted.

> "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 hea…

The topic in this subthread is overbearing Rust evangelists and their effects. To the degree that management pays them any attention -- and a CTO parroting their advocacy in tweets (squawks?) certainly counts -- the threat is real. Other companies' management may be equally affected, in a degree more than just posting idle-hack tweets. Against, the subthread topic is overbearing Rust advocates and, specifically, what…

> 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 true intent of a simple sentence.

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

#787

Post by stouset »

diffxx wrote: post #782
gavinhoward wrote: post #749

Earlier quoted context omitted.

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.

Gavin, there is no point in arguing with fanatics. (You have to know that none of them are actually going to dive into your code and possibly learn something new that didn't come from a vetted authority figure). They are incapable of listening to their own independent thoughts, assuming that they have them, and must attack anyone who counters their dogma because it risks shattering their core beliefs, which is intole…

I really like C. I did actually spend about an hour reading his code. It's very nice, and I genuinely believe that Gavin is probably capable of writing memory-safe C most of the time. Except when his sanitizer setup is accidentally disabled, of course.

I did find at least one case where a function in isolation is explicitly not memory-safe, but its safety depends on implicit and undocumented assumptions about how it's called. I didn't find a way to exploit it from the userland program. In `bc_parse_addNum`[1], a `char *` string is indexed into without checking the length. Callers are expected to provide strings of at least length 2. That expectation is not documented, though it is adhered to. But it is a landmine waiting to be tripped over should that assumption change.

But this is a sideshow. Experts have been insisting for decades that they can write crash-free C and yet we continue to regularly find exploitable memory issues in every large multi-author C project. It's plain as day that—for almost all of us—an increasingly indefensible amount of the time spent on C programs is in dealing with the types of bugs that languages like Rust prevent outright. Whether that's simply finding and fixing them, architecting programs to avoid them, incorporating those fixes into downstream projects, mitigating their impact in live production systems, or whatever, our industry pays an enormous ongoing cost. Even in projects that have never had a public release with a memory bug, significant engineering time is spent on them just during development iteration.

As a handy example, the Linux kernel is still trying to rid itself of `strlcpy`[2] which has been the source of multiple CVEs. This process has taken upwards of twenty years. And that's after spending god knows how much time and effort migrating to `strlcpy` from `strcpy` in the first place.

[1] https://git.yzena.com/gavin/bc/src/branch/master/src/parse.c...

[2] https://lwn.net/Articles/905777/

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

#788

Post by ghoward »

JonChesterfield wrote: post #774
ghoward wrote: post #307

Earlier quoted context omitted.

Dereferencing NULL pointers: my code is structured such that every function parameter that can be NULL is marked so. And I check those possibly-NULL pointers. This could also be done with a macro: #define y_d(p) ((p) == NULL ? abort(), *p : *p) Otherwise, the compiler (clang, usually) warns me when a NULL pointer is passed in and I have asserts to catch them. Even before I had all of this infrastructure, deferencing…

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.

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

#789

Post by ghoward »

bowlerman wrote: post #530
ghoward wrote: post #441

Earlier quoted context omitted.

Except that the tweet was pretty absolute. He could have had a reply tweet with something like "unless you have to or you're doing a hobby project." I took issue with the absolutism.

Those qualifications are going to hold for any advice about technology. You can even justify using malbolge for your hobby project with "I like it" or "It's just for fun". If your company is only going to pay you for producing malbolge code, then you write malbolge or quit. If you decide to stay, then trying to change their mind might be a good idea if you can spare the effort.

> Those qualifications are going to hold for any advice about technology.

They should hold, but the RESF can be too absolutist. The wording of the tweet encouraged that, so I was just trying to push back on it.

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

#790

Post by gavinhoward »

stouset wrote: post #761
gavinhoward wrote: post #749

Earlier quoted context omitted.

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

The RESF seems to want to take C away from me. They seem to think I am a bad person for using C. They seem to think I am a bad programmer for using C.

To refute all of that, I point people at some code that they would probably struggle to break.

Post reply on HN