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

301–310 of 929 posts

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

#301

Post by ghoward »

Ar-Curunir wrote: post #265
gavinhoward wrote: post #257

Earlier quoted context omitted.

I hate to admit this, but it took me a long time to do, mostly because I was not experienced when I started writing code, and the code has been rewritten several times over to get it right. First off is the code in [1]. It's technically under several licenses, but I can give it to you under the public domain because bounds checking in C is important enough that I'll give it away. The `y_ARRAY_TYPE()` macro generates…

Let's be honest, `y_i(array, 10)` is much less readable than `array[10]`. Sure, you can program with bounds checking, but it's less readable, and less newbie-friendly.

I agree, but you get used to it. With enough familiarity, it's just as readable.

The fact that I have built all of this is part of why I don't accept contributions. [1] I don't expect people to be able to read my code.

[1]: https://git.yzena.com/Yzena/Yc#open-source-not-open-contribu...

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

#303

Post by pitaj »

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 universe depends still assumes that everything is x86, and one of five operating systems" issues as recently as late 2021.

I am curious. Could you give some more context?

> Get a build system that's easily workable without an Internet connection and recent TLS support.

Cargo supports vendoring dependencies and local dependencies.

> Make it easy for beginners to build out Rust infrastructure for OpenVMS on Itanium, Solaris on SPARC, z/OS, MorphOS, GNU/Hurd, and a 20-year-old budget PDA running a custom OS on an SH4 CPU.

When has it even been easy for beginners to build out systems infrastructure?

Progress is being made on allowing Rust to target more platforms, including `rustc_codegen_gcc` and `gcc-rs`.

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

#304

Post by pitaj »

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

Random question, doesn't this then defeat the whole purpose of using rust? Memory errors, that is, pointer issues are the primary source of errors that ownership in rust claims to fix. If the only way you can make nontrivial data structures is use "a ton of unsafe blocks," then you'll still likely get the memory errors, only now it's in an unsafe block...so, now everyone can just blame the unsafe block? This reminds…

It's much easier to audit a ton of unsafe blocks beneath a safe abstraction layer than an entire codebase. And Rust provides very powerful tools like Miri which can catch pretty much any soundness issue if you have good enough test coverage.

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

#306

Post by jandrewrogers »

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…

In fairness, using integer handles instead of pointers is pretty idiomatic in high-performance C++ too. I've never found it to be onerous or complicated.

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

#307

Post by ghoward »

pitaj wrote: post #293
gavinhoward wrote: post #257

Earlier quoted context omitted.

I hate to admit this, but it took me a long time to do, mostly because I was not experienced when I started writing code, and the code has been rewritten several times over to get it right. First off is the code in [1]. It's technically under several licenses, but I can give it to you under the public domain because bounds checking in C is important enough that I'll give it away. The `y_ARRAY_TYPE()` macro generates…

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 NULL pointers was not a problem for me personally; it's just one of the mistakes I tend to not make. So that's why I don't have a macro for it.

For use-after-free, I use scopes. My stack allocator has a function that will mark the start of a scope, and I call it when entering a new scope. Then the pointers that are allocated during that scope will all be freed when I call the function to free every item in the scope, but those pointers will also go out of scope, which means the compiler won't let me access them.

It looks like this:

    void
    func(size_t s)
    {
        y_stackallocator* p = y_strucon_stackallocator();
        // Random code.
        // Open a new scope. Notice that the scope is a bare scope.
        // But it could also be an if statement or a loop.
        {
            size_t* sp = y_stackallocator_malloc(p, sizeof(size_t) * s, NULL);
            // Random code.
            // This frees everything in the scope, including sp.
            y_stackallocator_scopeExit(p);
        }
        // Scope has exited; sp is not accessible, no use-after-free.
    }
This is less rigorous than Rust, but I use the principles in Joel's "Making Wrong Code Look Wrong" [1] here. If I have scopes that don't look like the above, they are wrong.

[1]: https://www.joelonsoftware.com/2005/05/11/making-wrong-code-...

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

#308

Post by snovv_crash »

ReactiveJelly wrote: post #203
foomatic wrote: post #184

Earlier quoted context omitted.

Why not just hire good people and ask them to learn C++. I mean how the heck did anyone actually pass this magic barrier of becoming a "C++ dev" in order to get hired as a C++ dev?

Cause those person-hours have to come from somewhere. Am I spending 2x of the new hire's time making them learn a harder language? Am I spending 2x of a senior's time teaching the new hire? What's the payoff in sticking with C++? Better libraries? Better tools? IDEs? That stuff will all shift as time goes on, if popularity is against it.

What's the equivalent in Rust to Eigen, Ceres Solver, OpenCV, JNI and Qt UI bindings?

This is my standard stack for C++ and last time I checked Rust couldn't do any of them. This is also my standard stack for building new open source computer vision libraries, growing the available libraries and making my field more locked into C++, increasing the moat Rust would need to cross.

Next step, can I compile and deploy for Windows, macOS, Linux, Android and iOS? All of these are critical business requirements. This is whether I can adopt Rust in my employer's codebase.

Finally, can I easily find and hire engineers who can read and write Rust who aren't asking FAANG compensation levels? This is the blocker for Rust in startups.

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

#309

Post by DoingIsLearning »

Kranar wrote: post #31
MathMonkeyMan wrote: post #15

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

That's a fairly recent thing that some people do as a kind of virtue signaling. The "C/C++ Users Journal" was a very popular publication and no one took issue with its name. Nor do people take issue with Dr. Dobbs which has a "C/C++" section with articles from highly influential members of the C/C++ community. C++ is a complex language, so people invent ways to show how dedicated they are to it, and nowadays that mea…

The distinction actually makes perfect sense during the hiring process.

If a recruiter approaches me with a C/C++ gig then I will immediately assume that either the hiring manager doesn't know what they want or the hiring manager didn't actually write the job specs, none of those scenarios sends a positive signal.

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

#310

Post by petre »

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…

> But the space between "Need to stay away from C++" and "Should probably just have written it in Go" seems to be getting smaller and not larger.

We also have D which can use C/C++ libraries seamlessly.

Post reply on HN