Live data from Hacker News

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

twitter.com

651–660 of 929 posts

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

#651

Earlier quoted context omitted.

The argument you are missing: Your position is bespoke and incompatible. You don't use idioms in your C code. You use idiolect. Thus, you exist in your own universe and are a party of one. And the clue was something you might not expect... I programmed C++ for five years, and C for over ten years before that. I don't know rust, but I followed this discussion with great interest. One of the topics that came up several…

It's not lost on me at all. I prefer to finish software. [1] I get it to where it needs to be and put it in maintenance mode. I don't accept outside contributions. [2] I prefer to work alone to keep the scope of my software manageable and to reduce communication overhead. And to avoid working with people. People are too complicated. I obsessively document my software. [3] I comment all of my code. I wrote design docu…

I was going to start this reply by saying "I am not necessarily defending / supporting ghoward's position", but after I read his whole reply, I realize I am.

I enjoy writing C (more than C++); I do not find it awful. If you cannot accept that, then there is nothing I can say to change your mind. What I don't understand is this atavistic obsession that "everyone must migrate to rust now", and "C is so dangerous in can explode in your hands while you are sleeping".

Please, go forth and multiply, and use rust to your heart's content. But be more open minded to the fact that there are people who like, enjoy or even love using C. As for me, I admit I have gone from interested in rust, to neutral, to an active dislike, because this narrow-mindedness some of its proponents show.

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

#652
post #514
post #400

Earlier quoted context omitted.

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

What issue is there for the C++ developers to transition? Rust is a simpler language, with better characteristics. Memory safety is the a big selling point for the business people, but there is also a better module system, dependency management, better generics, no hidden memory allocation, etc. etc.

> What issue is there for the C++ developers to transition?

rust is lacking a ton of libraries.

And personally I prefer using a big thing like Qt which has classes for everything, rather than rust where I have to find a non-terrible library for every little thing.

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

#653

Earlier quoted context omitted.

In what world is C++ harder to learn than Rust?

Cargo is the number one feature of Rust that makes it easier for a newbie to use. New users of C++ struggle the most with building and linking projects together. Cargo makes that newbie proof. Source: I teach C++ and Rust to new programmers, and they almost universally get further, faster with Rust than C++.

Meson has improved the build situation in C++ significantly.

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

#654
post #534

Earlier quoted context omitted.

Wut? Makes no sense to me.

Here's an example of C++ code written intentionally with all the latest C++ features: https://gist.github.com/caiorss/c7db87df674326793431a14006aa... It looks pretty much nothing like a C program doing the same job. A lot of those features were made to make C++ a safer language to use. Eg, with a construction like: for(const auto& it : ast){ You can't accidentally walk past the end of the array by going one item too…

Why are spaces randomly omitted for language constructs like if and for, and reference type &s left aligned?!

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

#655

Earlier quoted context omitted.

This means that you have array accesses that cause index out of bounds fatal errors instead of invalid pointer dereferencing that causes fatal segmentation failure errors. Detecting this kind of bugs reliably is a very good thing, but preventing such errors (and optimizing away bounds checking if possible) would be better.

That's good! That's what you want. Out-of-bounds array accesses causing segfaults is the happy case! The sad case is security vulnerabilities.

The alternative in Rust would be using `.get()` in those situations, which returns an optional result. That still doesn't account for valid but outdated array indices, though.

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

#656

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…

Agree 100%. The C++ language and ecosystem shouldn't feel dynamic, given its age and the installed base, and yet it really does. I remember when c++11 came out and all the crazy typedefs I had to type out just disappeared overnight, and I was able to write statements like "using Elem = uint64_t; using Node = MyClass::Node;" which were so much more straightforward. Function pointers disappeared too and were replaced by lambdas so I could write my own "each_node" functions and actually have them be really useful.

Then we had concurrency primitives, and now apparently there's a module system in c++20 which should be interesting. C++ clearly has no plans to bow out gracefully or otherwise go quietly into the night, which is fine by me since I still think it's the language which gives me, as a developer, the most freedom and control over the system.

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

#657
post #228

Earlier quoted context omitted.

The borrow checker has become smarter, but not at handling cyclic data structures. The problem you're describing still exists, though I'd say the advice isn't quite right. Generally the better advice is to use a graph library, or something like slotmap [1] if you're rolling your own, than to use a Vec or HashMap. That's superior to a vec/hashmap for a few reasons. It handles keeping indicies stable/writing your own i…

Stuff like Slotmap should be part of the standard library instead of some github project with open issues that isn't updated for over a year.

Yeah. FFS, they don't even have a JSON parser in the standard library...

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

#658
post #649

Earlier quoted context omitted.

There are plenty of things that ASan won’t catch, like misuse between contiguous allocations. But that’s sort of tangential: the goal is to write software that’s correct to begin with, not poke holes in it with the testsuite after the fact. With Rust, I can pick third-party dependencies that I can be (vanishingly) confident don’t have memory safety issues; when I start a greenfield C++ project, any dependencies I bri…

Do you vet all of your dependencies' code for unsoundness when using unsafe?

One of the guarantees that Unsafe Rust makes is that well-formed unsafe code cannot trigger unsoundness in safe code.

In other words: I very rarely write unsafe code myself. When I bring in others’ unsafe code, I use cargo-geiger and siderophile (which I help maintain) to quantify it.

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

#659

I'm just a programmer who's been doing this for 20 years. I don't have the credentials of Mark, who is a legend. But I fully agree with him. There will be specific exceptions, but if you have the choice between Rust and C++ you would be making a big mistake to not choose Rust. The language is simpler, cleaner, safer, and more enjoyable to work with. The build tools are far more pleasant. The IDE experience is compara…

Why do you think Rust isn't used more widely?

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

#660

I'm just a programmer who's been doing this for 20 years. I don't have the credentials of Mark, who is a legend. But I fully agree with him. There will be specific exceptions, but if you have the choice between Rust and C++ you would be making a big mistake to not choose Rust. The language is simpler, cleaner, safer, and more enjoyable to work with. The build tools are far more pleasant. The IDE experience is compara…

>> The hiring market is way better for Rust because it's not mainstream. The ratio of C++/rust jobs where I am (EU country) is 5564/54. And these 54 jobs are mostly in cryptocurrencies.

I mean the argument is made that Rust is not mainstream, but if you were to pull in e.g. Java or Javascript apps in that comparison I'm confident it would make C++ look like a non-mainstream language too.

edit: numbers say I'm wrong, C++ is more mainstream than C#, C is more mainstream than Java: https://www.tiobe.com/tiobe-index/. I mean I doubt this source (it seems to indicate objective-C, which is all but superseded by swift, is on the rise) but it's at least one datapoint.

Post reply on HN