It's time to halt starting any new projects in C/C++ • Hacker News Board

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

#311

Post by FullyFunctional » Tue, Sep 20, 2022, 5:43 AM UTC

jupp0r wrote: post #291

gpm wrote: post #278

Earlier quoted context omitted.

I just glanced through the small number of open issues, and none seem like actual issues so much as potential improvements. The maintainer seems to still be around, and I've never found that a standard library is faster at merging improvements than third party libraries, rather the exact opposite (for good reason, the standard library needs to avoid breaking changes at nearly all costs). While I think there are valid…

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

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

#312

Post by physicsguy » Tue, Sep 20, 2022, 5:43 AM UTC

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 not explicitly tested against them. Without that, there’s a whole class of distributed applications that you’d be ill advised to write in Rust using that library, because it’s such a fundamentally core library for distributed applications, which needs to be compiled differently and with specific versions to handle the specialist interconnects on HPC systems. If you only support the latest versions, your code is not very portable to other machines.

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

#313

Post by roca » Tue, Sep 20, 2022, 5:44 AM UTC

ajross wrote: post #223

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…

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…

> 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 applications that can easily fit within standard containers and standard allocation paradigms, C++ actually works really well already

Not at all. For example it is still easy to corrupt memory using C++ references. Just the other day I discovered a nasty little bug involving absl::hash_map: someone had written "map[i] = map[j]" which is unsafe if the element at i does not already exist --- it can trigger a rehash, invalidating the reference obtained by map[j].

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

#314

Post by Shorel » Tue, Sep 20, 2022, 5:45 AM UTC

I would have complied if he said D lang.

Tried Rust, did not like it that much, compared to D.

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

#315

Post by pitaj » Tue, Sep 20, 2022, 5:45 AM UTC

ghoward wrote: post #307

pitaj wrote: post #293

Earlier quoted context omitted.

Okay and what about preventing use-after-free and dereferencing null pointers?

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…

Do you have a tool that enforces the use of all of these macros and stuff? How do you know that, for instance, you didn't forget something? Seems like one slip-up is all it would take.

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

#316

Post by hda2 » Tue, Sep 20, 2022, 5:47 AM UTC

lenkite wrote: post #260

gpm wrote: 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.

This is my main gripe with Rust. Things that should be part of the standard library are relegated to third parties, thus requiring developers to audit yet another dependency (and it's dependencies, and sub-dependencies, and sub-sub-dependencies, ...). Realistically, this just means I can't use most third-party crates, greatly limiting what I can do with Rust.

It's been a long time since I've been able to write anything in Rust despite loving the language. My last hopes for Rust are now in gcc-rs splitting the Rust ecosystem into two; the current npm-style crates.io ecosystem and a more destro-centric properly vetted package ecosystem. If this doesn't happen, I'll just continue to use other languages or limit my dependencies to those with sane package management (usually this means libraries written in C) until something better pops up.

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

#317

Post by imron » Tue, Sep 20, 2022, 5:47 AM UTC

pitaj wrote: post #303

ninefathom wrote: post #242

There are new programs being written daily in COBOL and Fortran, and I'm fairly certain that I see new PL/I floating around occasionally. C and C++ aren't going anywhere anytime soon. Love them, hate them, want to burn them with fire, they're here for a long, long time. Leaving that aside, I was still hitting Rust "oh look the developer of this crate on which the entire universe depends still assumes that everything…

> C and C++ aren't going anywhere anytime soon. Love them, hate them, want to burn them with fire, they're here for a long, long time. Nobody denies this, which is why one of Rust's main goals was supporting the C ABI, so Rust can use existing C libraries, or an application written in C can use Rust libraries. > Leaving that aside, I was still hitting Rust "oh look the developer of this crate on which the entire univ…

> I am curious. Could you give some more context?

Probably talking about this: https://github.com/pyca/cryptography/issues/5771

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

#318

Post by FullyFunctional » Tue, Sep 20, 2022, 5:48 AM UTC

ephimetheus wrote: post #295

diego_moita wrote: post #198

Earlier quoted context omitted.

Because, little by little, C++ became "unlearnable". Long ago C++ made C a little bit more complex. Because there were already lots of C programmers that wasn't a big deal. But then it didn't stop. Little by little C++ grew into a monstrosity. A lot of people went along. I gave up. For new programmers to climb in 2-3 years a mountain that seasoned programmers took 15-20 years to climb is asking too much.

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

Rust isn't actually that complicated and more importantly, most of it makes sense. I don't feel the same way about C++.

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

#319

Post by drivebycomment » Tue, Sep 20, 2022, 5:48 AM UTC

ghoward wrote: post #135

Unless he means that Rust should be used on projects where the Rust compiler is available for all relevant platforms and C and C++ can be used otherwise, I disagree. In fact, until LLVM is replaced, C++ will probably be the language of choice for new languages. Even `rustc` requires a C++ bootstrap for that purpose. There are also other important C++ and C libraries that will continue to mean C and C++ may be better…

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

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

#320

Post by humanrebar » Tue, Sep 20, 2022, 5:48 AM UTC

Ar-Curunir wrote: post #267

humanrebar wrote: post #262

Earlier quoted context omitted.

The fact that Rust has a whole other ecosystem is the main thing that gives me pause. For all their faults, C and C++ targets the ecosystem you have: gems, pip, Conan, Nix, ...doesn't matter. They don't expect you to port to a new ecosystem. They can contort to meet your needs. Herb Sutter's latest proposal and, to a slightly lesser degree, Carbon are more interesting in that respect.

What? You can totally compile Rust for compatibility with python libraries or Ruby libraries or whatever you want. Rust can offer the same API that C/C++ offer, so it can be a drop-in replacement.

...as long as you're fine shelling out to cargo, right? What if that's not appropriate or ergonomic?

There's a world where Rust is as easy to use as C, C++, Fortran, etc. outside of cargo, but it's not an interesting use case for the Rust community to support right now for whatever reason. That's basically my point.

And it's common enough to have linked programs in which python calls C that calls C++ that calls Fortran that calls C. Replacing arbitrary layers with Rust is technically possible, though Rust doesn't tend to be deployed in situations like that, at least not yet. I'll consider the Rust ecosystem more mature when you see Rust used mixed ELF situations like that.