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

381–390 of 929 posts

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

#381

Post by kazinator »

Kranar wrote: post #179
wahern wrote: post #151

Earlier quoted context omitted.

> That's a fairly recent thing that some people do as a kind of virtue signaling. If by recent you mean well over 20 years ago. When I began learning C circa 2000, I used to hang out on comp.lang.c, and "C/C++" was very much frowned upon. And for good reason--people felt entitled to ask C++ questions in a C newsgroup, which was and remains a poor idea. Even if they were asking questions relevant to both, e.g. regardi…

Not seeing evidence of your claim. A simple search on comp.lang.c for C/C++ turns up plenty of results and no one, not a single person, is calling it out. Infact there's plenty of discussion on an almost daily basis discussing the two languages almost seamlessly. Looks like there's even a alt.comp.lang.learn.c-c++ newsgroup as well. For reference I also did a search from 1998 to 2002... once again no one cares or is…

Here is a thread starting on April 15, 2000:

https://www.usenetarchives.com/view.php?id=comp.lang.c&mid=P...

started by someone advertising a C/C++ tutorial.

Here, down in the replies, we can find the remark:

In the first place, there is no such language as "C/C++",

Another one:

BTW, what in the world is the C/C++ language

And:

First problem: is comp.lang.c/c++ a legal name for a Usenet forum ?

And:

  Jones
  16/04/2000 17:40:46 UTC

  mike burrell wrote:

  > x*....@m*-****a.com wrote:

  > > I'm beginning a new C/C++ tutorial over at

  >

  > sweet. it's the c/c++ thread all over again.

  Not from me! I'm keeping my mouth shut this time ;)

  Indi
Look, just believe the people who were there. I was; my name appears in that thread.

Another thread, same year, "NEED C/C++ PROGRAMMER", started by "ITJOBS":

https://www.usenetarchives.com/view.php?id=comp.lang.c&mid=P...

Remarks:

"No such language as C/C++."

"Presumably ITJOBS thinks "Well, I've heard of C and I've heard of C++, but I don't know anything about either. They should be about the same."

"I see this a lot and just want to add that a slash ("/") does not imply a mixture of the two, it just means "and/or", so it would read "C and/or C++".

"All the left-brained, analytical people on comp.lang.c hate "C/C++". The right-brained, "creative" people don't mind it. End of story."

"C/C++ is 1 unless C is 0 in which case the result is undefined (I couldn't resist)"

"Um, no. It's always undefined."

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

#382

Post by LtWorf »

FullyFunctional wrote: post #311
jupp0r wrote: post #291

Earlier quoted context omitted.

> the standard library needs to avoid breaking changes at nearly all costs IIRC in Rust this is a little bit looser than elsewhere (let's say in C++) as the ABI is not stable. This allows improvements that change the internal structure of structs but not the API. As a counter example, in C++11 there was a breaking change that introduced a size field to std::list, making size() O(1) instead of O(n), breaking linkage b…

Yes but everything is versioned so it's not like this will break any existing applications unless the user/owner explicitly upgrades (but then they should be ready for breakages). The absence of versioning hell with Rust is one of the many things I love about Rust.

On the other hand it means you don't automatically get security fixes and have to manually set up CVE monitoring and rebuild your application every time a CVE appears.

Of course if it appears in an old version the author won't bother to backport the fix so you will have to bump the dependency to the latest, doing all the API changes that you didn't want to do.

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

#383

Post by stouset »

ghoward wrote: post #335
drivebycomment wrote: post #319

Earlier quoted context omitted.

> In other words, it's possible to put C and C++ on the same footing as Rust when it comes to memory bugs; No. This is only true if you don't care about occasional bugs. e.g. hobby projects. But if you're talking about mission-critical or security-critical software, there is a gap - or a canyon - between C vs C++ vs Rust. And no amount of extra "efforts" by the programmer's part can bridge those gaps completely.

The true test of what I said is "show me the code." The code is my `bc`. [1] Find a memory bug, any memory bug, in my `bc` after 1.0. Rust has occasional memory bugs too; I mentioned that specifically. It still happens. So if you really are correct, break my `bc`. [1]: https://git.yzena.com/gavin/bc

Yes, let’s ignore the quite literally millions of examples of prior art for memory bugs in C/C++ programs because you believe you’ve managed to build a single-threaded CLI calculator that doesn’t have any.

I know how to call `strcpy` safely. Are we clear to put that back into the Linux kernel then?

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

#384

Post by resonious »

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…

Calling C code from Rust directly is not too hard. Yes, you will have to write some unsafe code, but it's better than 100% of your codebase being unsafe (assuming you buy into the idea that Rust's safety features help).

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

#385

Post by worik »

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…

> I had trouble expressing cyclic data structures

You cannot do cyclic data structures in Rust because every thing must have one owner, so no cycles.

You can do cyclic data structures in Rust with unsafe code or doing your own memory management (e.g. an arena data structure).

> The borrow checker worked fine when all I needed to do was pass data up and down the callstack, but anything beyond that was difficult or impossible to express

That is not true. It is true at the start of the learning curve, but you get used to it. Cyclic data structures are very far from simple.

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

#386

Post by Arnavion »

ghoward wrote: post #335
drivebycomment wrote: post #319

Earlier quoted context omitted.

> In other words, it's possible to put C and C++ on the same footing as Rust when it comes to memory bugs; No. This is only true if you don't care about occasional bugs. e.g. hobby projects. But if you're talking about mission-critical or security-critical software, there is a gap - or a canyon - between C vs C++ vs Rust. And no amount of extra "efforts" by the programmer's part can bridge those gaps completely.

The true test of what I said is "show me the code." The code is my `bc`. [1] Find a memory bug, any memory bug, in my `bc` after 1.0. Rust has occasional memory bugs too; I mentioned that specifically. It still happens. So if you really are correct, break my `bc`. [1]: https://git.yzena.com/gavin/bc

>Find a memory bug, any memory bug, in my `bc` after 1.0.

I'm surprised by this confidence given one of the commits on the first page is "Fix a double-free when using expressions and sending SIGINT". And going through the commit history quickly reveals "Fix memory bugs in bcl" (a value not being initialized) and "Fix memory leaks in bcl" (missing dealloc), all within the last two months and all which are trivially not a problem in Rust.

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

#387

Post by vasama »

Ygg2 wrote: post #292
ajross wrote: post #223

Earlier quoted context omitted.

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…

> Even a doubly-linked list is impossible to get through the borrow checker. https://github.com/rust-lang/rust/blob/master/library/alloc/... It's part of standard lib. And you don't get more idiomatic than that.

That looks like an allocating container. Probably the most useful property of linked lists and other node based data structures is the ability to make them intrusive and to avoid dynamic allocation. In some domains you just don't have a runtime allocator available to you, so this library would be useless.

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

#388

Post by kazinator »

Kranar wrote: post #179
wahern wrote: post #151

Earlier quoted context omitted.

> That's a fairly recent thing that some people do as a kind of virtue signaling. If by recent you mean well over 20 years ago. When I began learning C circa 2000, I used to hang out on comp.lang.c, and "C/C++" was very much frowned upon. And for good reason--people felt entitled to ask C++ questions in a C newsgroup, which was and remains a poor idea. Even if they were asking questions relevant to both, e.g. regardi…

Not seeing evidence of your claim. A simple search on comp.lang.c for C/C++ turns up plenty of results and no one, not a single person, is calling it out. Infact there's plenty of discussion on an almost daily basis discussing the two languages almost seamlessly. Looks like there's even a alt.comp.lang.learn.c-c++ newsgroup as well. For reference I also did a search from 1998 to 2002... once again no one cares or is…

> A simple search on comp.lang.c

I'd love to know where such a thing is possible today.

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

#389

Post by baq »

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?

what's the alternative? invent and validate everything yourself?
Post reply on HN