Live data from Hacker News

Ask HN: Rust or C or C++ in 2023?

news.ycombinator.com

41–50 of 56 posts

Re: Ask HN: Rust or C or C++ in 2023?

#41
As a newcomer to systems programming, I hopped on the Rust hype train and enjoyed the ride for quite a while.

But in recent months, I've been more drawn to Zig. Simplicity, vision and governance of the language (among many other things) are very much to my liking.

As a bonus, I can use Zig to interact with C (even compile C, Zig is also a toolchain), so I feel I'm bound to learn more about C on this journey, too.

In your position, I'd also check out Zig, just to see if it's more your cup of tea or not. Here's a good intro talk: https://youtu.be/YXrb-DqsBNU

Re: Ask HN: Rust or C or C++ in 2023?

#42
post #28

Earlier quoted context omitted.

I'd go so far as to say it's unlikely the average C programmer has ever written a program with defined behaviour.

So my 5k lines of C code project from back in college is all... undefined?

Almost certainly. Of course the only way you'll find out is when you upgrade GCC and it suddenly leaks the contents of your memory to the whole world.

Re: Ask HN: Rust or C or C++ in 2023?

#43
I'd be interested to hear if anyone has learned Rust without first understanding memory addressing and pointers.

Although I think Rust is a better way to write safe code and the industry is right to adopt it, it seems like a heavy lift to learn about heaps, stacks and pointers whilst also learning about ownership and lifetimes.

I don't really think that C++ is worth learning unless you have to work on an existing C++ codebase.

Re: Ask HN: Rust or C or C++ in 2023?

#45
post #4

Earlier quoted context omitted.

Agree that C is easier to explore the concepts in, but knowing enough C to know why e.g. [0] gets the behavior it does is IMO not useful if the goal is to learn the _concepts_ before switching to a language that doesn't do this kind of thing. So, IMO worth jumping to Rust as soon as you feel confident with the stack vs the heap, use-after-frees, etc. [0]: https://godbolt.org/z/x7bf4edo9

You lost me here with p += (&ys[2] - &xs[0]); I mean, why would I expect the parenthesised subtraction to do anything I can rely on? Or did you mean (&ys[2] - &ys[0]) ?

Because if memory is a big array of bytes and pointers are indices into that big array, that should be numerically valid. And indeed, if instead of making xs and ys separate arrays, one writes:

    int zs[20] = {0};
    int *xs = &zs[0], *ys = &zs[10];
then no perplexing behavior is observed.

Of course, any veteran C programmer will point at that being UB, but the big-array-of-bytes (with holes) model is what one sees in userspace assembly, and what I assume most systems programmers think about most of the time, rather than the C memory model.

I wouldn't recommend that someone trying to learn systems programming (as opposed to C or C++ as languages) spend, like, any time whatsoever memorizing the list of C UBs (and then learning about pointer provenance, exposed addresses, etc., I suppose?). Assembly, Forth, safe Go, and safe Rust don't have the same kind of UB, and (Linux) kernel C has a different set of UBs than userspace/spec-compliant C.

Re: Ask HN: Rust or C or C++ in 2023?

#46
post #4

Earlier quoted context omitted.

Agree that C is easier to explore the concepts in, but knowing enough C to know why e.g. [0] gets the behavior it does is IMO not useful if the goal is to learn the _concepts_ before switching to a language that doesn't do this kind of thing. So, IMO worth jumping to Rust as soon as you feel confident with the stack vs the heap, use-after-frees, etc. [0]: https://godbolt.org/z/x7bf4edo9

You lost me here with p += (&ys[2] - &xs[0]); I mean, why would I expect the parenthesised subtraction to do anything I can rely on? Or did you mean (&ys[2] - &ys[0]) ?

Same here. Embedded programmer, primary language being C. I sat here staring at that line for a solid 30 seconds trying to understand the intent - it’s nonsensical. I read your comment and see the intent you’re guessing at but… you would not generally write C like this. Pointer arithmetic is to be avoided, and this case is contrived. I don’t think a compiler warning would be thrown here though - maybe that is the point, that the language and compiler would not catch this issue and that typos or novice learners can make compilable mistakes too easily?

Re: Ask HN: Rust or C or C++ in 2023?

#47

Earlier quoted context omitted.

You lost me here with p += (&ys[2] - &xs[0]); I mean, why would I expect the parenthesised subtraction to do anything I can rely on? Or did you mean (&ys[2] - &ys[0]) ?

Same here. Embedded programmer, primary language being C. I sat here staring at that line for a solid 30 seconds trying to understand the intent - it’s nonsensical. I read your comment and see the intent you’re guessing at but… you would not generally write C like this. Pointer arithmetic is to be avoided, and this case is contrived. I don’t think a compiler warning would be thrown here though - maybe that is the poi…

I mean, this surely wouldn't be written as obviously as this in real code. It'd be somewhere in a data structure that packs to be able to fit better in a cacheline, and has something like:

    struct edge {
        struct node* src;
        int dst_offset;
        int label;
    };
Knowing about integer overflow, the original programmer carefully wrote overflow checks where dst_offset gets computed, and the code was correct. Nodes were allocated into one contiguous array, and edges were allocated into another.

Later, someone else changed how nodes were allocated, so adding a new node would never trigger a realloc of the whole graph. Instead, a linked list of node arrays is allocated. Suddenly now, computing dst_offset is UB, and yet, the observed behavior of the resulting program is the same.

Even later, someone updated GCC on the CI machine, and now the inliner is more aggressive. Suddenly, mutations to node labels are unreliable, and edges are found to not refer to any node in the graph, except when debug logging logs the address they actually refer to.

This is the kinda thing that requires an understanding of UB that has nothing to do with the actual hardware to diagnose and fix, which I think is really unnecessary for a beginner.

Re: Ask HN: Rust or C or C++ in 2023?

#48

We have three conference podcasts talking about systems programming in depth: - The Race to Replace C & C++ (2020) [0] - The Race to Replace C & C++, Episode 2 (2021) [1] - Memory Strategies: The Merits of (Un)safe (2022) [2] They feature prominent guests including the creators of Zig and Odin, as well as people making a living using Rust. Hope this helps! [0] https://handmade.network/podcast/ep/fe1a2a6a-3ac6-4ce5-b8…

Thank you!

Re: Ask HN: Rust or C or C++ in 2023?

#49
post #45

Earlier quoted context omitted.

You lost me here with p += (&ys[2] - &xs[0]); I mean, why would I expect the parenthesised subtraction to do anything I can rely on? Or did you mean (&ys[2] - &ys[0]) ?

Because if memory is a big array of bytes and pointers are indices into that big array, that should be numerically valid. And indeed, if instead of making xs and ys separate arrays, one writes: int zs[20] = {0}; int *xs = &zs[0], *ys = &zs[10]; then no perplexing behavior is observed. Of course, any veteran C programmer will point at that being UB, but the big-array-of-bytes (with holes) model is what one sees in use…

Why always give the most contort examples? Jeez...

OP is asking about a language to learn. Let them fail, to learn and understand.

And after all, C was and actually is moving the world forward, and thanks to C you have the possibility to write and run programs in Rust. Rust can't do anything if not by calling C APIs. Removing C code from any system is removing the legs from the crab.

So why not choosing C? Seems wise to me. Think about the thousands of lines of C code executing across the world so you can just download a crate. It seems to me that your first interest, as a Rust user, is to have C programmers around so you can run your Rust code.

I'll contribute by telling my personal experience after 20 years of embedded and system C: the fear spread by Rustaceans (regarding UB) is uber-exaggerated, specially at learning stages.

Before you bring exploits up, not every C application is connected to internet or has a user interface or runs as root. Just a portion.

Re: Ask HN: Rust or C or C++ in 2023?

#50
I think learning for the sake of learning is highly overrated in programming. Would a woodworker advice anyone to learn wood working from a book?

Find a project that you think is important and work on it. Doesn’t matter which language. You can always switch. Knowing C++ will make you a better Rust programmer and vice versa.

Post reply on HN