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

431–440 of 929 posts

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

#431

Post by ncmncm »

Kranar wrote: post #193
unglaublich wrote: post #140

Earlier quoted context omitted.

C/C++ is as naïve as ASM/C or Ape/Human. You come up with examples that are over 30 years old.

Yes my examples are old because the entire point I'm making is that this outrage over "C/C++" is a relatively recent phenomenon. People 10-20 years ago didn't really care or take issue with that term.

I was there and yes we did.

You wish it was recent and something you could pretend about. But anytime you write it, you are telling a lie. Being seen lying tells the reader more about you than you probably intend.

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

#432

Post by c0mptonFP »

CameronNemo wrote: post #358
deadbeeves wrote: post #259

Earlier quoted context omitted.

People who use permissive licenses usually don't care about the license-inclusion clause, so most people just don't bother with it until someone comes asking. At the end of the day, fixing that problem is just a matter of including a new text file in the next release. It's nowhere near as big of a deal as when someone complains that you're not complying with the GPL. By the way, whether you're linking statically or d…

I disagree with both paragraphs. By choosing a license that requires attribution, developers are communicating a preference. MIT0 and 0BSD exist. If someone does not care about attribution, they would use one of those licenses. Dynamically linking to a MIT lib is not the same as distributing an MIT lib, so yeah static linking to the lib is completely different, according to the terms of the license. If you are workin…

That's one of the thing that riles me up. The vast majority of programmers, especially in the open source community, don't take licensing seriously.

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

#433

Post by IshKebab »

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 don't think anyone's saying there aren't specific areas where you might need to use another language. You pretty much have to use Python if you want to use ML, or Typescript if you want to do web stuff.

But if you do have the freedom to choose, then I don't see why anyone would really pick C++ over Rust at this point.

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

#434

Post by ncmncm »

woodruffw wrote: post #38
MathMonkeyMan wrote: post #15

The C/C++ people hate it when you call it C/C++.

I certainly don't. Although I also write Rust now, so I suspect someone will accuse me of having split loyalties or something equally ridiculous. The only context in which I care about "C/C++" is on resumes, where it's a sign that I need to ask a little more about the person's background.

It's a sign of a liar, and you can round-file it without reading any more.

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

#435

Post by gavinhoward »

Arnavion wrote: post #386
ghoward wrote: post #335

Earlier quoted context omitted.

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

Notice that I said to find a memory bug in a release, not just any commit.

Yes, there will be memory bugs during development, but I usually find them before release. There will definitely be commits fixing memory bugs during development.

The bcl library is an exceptional case, where my test suite did not have sanitizers and Valgrind properly hooked up, and that one was because it went from a global (guaranteed to be zeroed) to allocated.

But I also said to find one in the program, not the library.

I issue that challenge again: find a memory bug in the `bc` or `dc` program in a release after 1.0.

Oh, and the double-free with `SIGINT`? Rust isn't going to help you much there. Signals are not part of Rust's model.

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

#436

Post by ncmncm »

BenFrantzDale wrote: post #147
pengaru wrote: post #52

Earlier quoted context omitted.

> The only context in which I care about "C/C++" is on resumes, where it's a sign that I need to ask a little more about the person's background. Is that because you'd expect anyone actually experienced in either to know better than to lump them together so casually?

For me, I see “C/C++” as a sign they see C++ (which I’m looking for experience in) as interchangeable with C. I want people who grok C++’s ability to build powerful abstractions, not people messing around with it as C with polymorphic classes.

Yes. "C/C++" on a résumé is a red flag.

"Next!"

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

#437

Post by pjmlp »

einpoklum wrote: post #342
AtlasBarfed wrote: post #240

Earlier quoted context omitted.

C++ the "language culture" unfortunately has a lot of gatekeeping as well. The fact that the gatekeeping generally revolves around "replace feature from n-5 years with the newer feature in the latest 0x00x release" is a bit tiresome. Yes, I'm exaggerating, a bit. As for the Microsoft whomever-he-is: I agree in theory, I disagree in practice. If there are a lot of C++ devs writing important code, then let them continu…

> "replace feature from n-5 years with the newer feature in the latest 0x00x release" Let me put a more pro-C++ spin on that sentiment. C++ is a language that's under long-term development. It might sound weird, but only with C++20 Bjarne Stroustrup felt that his vision for the language was now mostly-realized - and he had worked on it since the 1980s. With other languages, there's a lot of clearing-of-the-desk and s…

A vision that ironically is only fulfilled by Visual C++, and who knows when GCC and clang will manage to reach it, specially in what concerns modules.

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

#438

Post by ghoward »

stouset wrote: post #383
ghoward wrote: post #335

Earlier quoted context omitted.

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?

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

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

#439

Post by IshKebab »

noobermin wrote: post #213
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.…

Ok, so I hate to be too direct but the rust enthusiasm always struck me as annoying like the meme about arch users telling everyone they use arch and so should you, but on that token, I always felt it strange given it's literally over something as mundane as a programming language choice. BUT, this as a reason seems to explain a lot more for why evangelists, particularly those in management type positions in large IT…

I love that you can't accept the possibility that Rust is good so much that you had to come up with a genuine conspiracy theory to explain its popularity.

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

#440

Post by jeff-davis »

As much as I like rust, I feel the statement is a bit premature.

Rust has only one real compiler and no independent language standard.

Rust is also the only alternative that is really being discussed most places. For an idea as major as "deprecate C/C++" you really want a couple solid alternatives. Rust is not perfect for everything, and so its easy to pick on the weaknesses and say "that's why we're sticking with C/C++".

I guess Ada or D are viable alternatives, too, and maybe need more attention. But the tweet only mentions rust.

Post reply on HN