Hacker News new | ask | show | jobs
by eldenring 1204 days ago
> Writing basic data structures isn't a niche, esoteric edge case

Maybe it isn't an edge case (although it should be) it also isn't `easy` in a non GC'd language, and a huge source of memory bugs.

I wouldn't say it makes the 'easy stuff hard' as much as the 'hard stuff appropriately difficult'.

2 comments

why should writing a basic data structure be an edge case? …what?
All of the "basic" data structures are already provided by either the standard library or crate ecosystem, so you'll rarely (if ever) need to write your own linked list or hash map from scratch.

I say "basic" in quotes because once you factor in the concurrency, ownership and memory safety concerns that are optional in other languages, but mandatory in Rust, there really isn't a simple implementation of these structures that is provably correct anymore.

Rust is supposed to be a systems programming language. If writing basic data structures was an edge case in it, the language would be broken. Luckily, in my experience it isn’t (at least not in this way).
I'm glad you posted this, I was confused as to whether "basic data structure" meant something different to Rustfolk than it did to the rest of us.
Writing data structures is trivial in C/C++.
As long as you don't care about UB or edge cases. Every time Rust makes something hard, it's forcing you to handle an edge case up front.
It's blowing my mind how many commenters here don't understand this.

Rust isn't hard just for fun. It's hard because the code you've been writing for so long is actually bad and you've not been thinking it through appropriately. This is why we keep finding serious bugs in code that is decades-old, despite the belief that code so old must be well-tested by now.

> we keep finding serious bugs in code that is decades-old

I'm sure of one thing: we will find many and different bugs in decades old rust code one day, too. The problem with software is that it has code in it ;-)

Difference of course being that zero of these bugs will be due to buffer overflows or use after free or other memory bugs in safe rust, which is a huge source of bugs in C[1].

I don't understand why this argument keeps coming up. Not all bugs are the same and when you make entire classes of bugs unrepresentable, that's a massive win, especially when they happen to be the class containing >60% of the highest severity bugs in C.

https://www.chromium.org/Home/chromium-security/memory-safet...

> zero of these bugs will be due to buffer overflows or use after free or other memory bugs in safe rust

buffer overflows [0] [1], use after frees [2] [3], and other memory bugs [4] [5] [6] can appear in safe rust from unsound unsafe internals.

[0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-2887...

[1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000...

[2] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3116...

[3] https://github.com/rustsec/advisory-db/blob/main/crates/cros...

[4] https://github.com/rustsec/advisory-db/blob/main/crates/toki...

[5] https://github.com/rustsec/advisory-db/tree/main/crates/

[6] https://github.com/Qwaz/rust-cve

It’s not that simple. Rust is used in the system’s programming space and as a result it will be used in many places where unsafe ends up required to solve problems. There won’t be memory safety bugs in safe Rust, but there will be in the interop/unsafe layers.

I think there is a strong argument to be made that if you need a lot of unsafe, Zig is going to be the safer language.

> I don't understand why this argument keeps coming up.

Not comment should be read as argument or part of a debate for or against using Rust or any other memory safe language. I made the comment because I've seen tool after tool come about to end the scourge of bugs in software... and so far my unconscious, untrained ability to find new and spectacular ways to create bugs has exceeded the ability of the makers of bug prevention tools to stop me.

While I do like Rust, let’s not forget that it indeed “forbids” to a degree many code/lifetime structures that are extremely common in basically every other language.

I believe the tradeoff for this in Rust’s niche is absolutely acceptable, but it is still a tradeoff and might not be the correct choice in certain cases.

It's in part hard because the borrow checker isn't omniscient and accepts only a subset of safe programs. There are also some concepts it's difficult to explain to the borrow checker. Both of these are things that make writing programs harder in Rust that do not add any safety value, and it's ok to acknowledge that.
That would be true if Rust was a perfect language, but it isn't (no language is).

Sometimes Rust makes things hard because the invariants you want to express cannot be cleanly mapped onto Rust's type system. I described one such case here: https://blog.reverberate.org/2021/12/19/arenas-and-rust.html

Not strictly true. Rust makes things hard by making you design within the limitations of the borrow checker, and some of those are accidental, not a necessary edge case.
Writing correct ones is not.