71–80 of 89 posts
> As an aside, remember that the only difference to C/c++ is that if you write a “basic linked list” in them, all of your code will be unsafe. I stopped reading here.
Instead, please post comments that add information. If something is wrong, teach us how.
> As an aside, remember that the only difference to C/c++ is that if you write a “basic linked list” in them, all of your code will be unsafe. I stopped reading here.
Please don't use this internet trope on HN. It's a variant of the snarky dismissal, which we're hoping to avoid. Instead, please post comments that add information. If something is wrong, teach us how.
Earlier quoted context omitted.
Doesn't Option() on a Rust pointer optimize down to a zero pointer value anyway? Much of the unsafe Rust code I come across looks like either premature optimization or trying to write C in Rust.
> Doesn't Option() on a Rust pointer optimize down to a zero pointer value anyway? There aren't pointers here though. But yes, you could use NonZero to mark the hash value as never-zero so that the option gets optimized. You'd still need unsafe code to construct the nonzero, but that's okay. At least for the Hashmap I don't think the code is premature optimization; it seems to be pretty "idiomatic" unsafe Rust, with…
The number of excuses associated with unsafe code in Rust is excessive.
Earlier quoted context omitted.
He clearly states that code which depends on a linked list implementation is "unsafe" for that very reason. To me that's not convincing argumentation. If code depends on a broken "unsafe" linked list implementation, that's bad no matter what language the code is. What you say is true under some interpretation of "unsafe", but it doesn't relate with a broken "unsafe" linked list implementation. Btw. since I'm not a Ru…
The point the OP was trying to convey (and the OP could have been clearer) is that Rust will allow you to button up an unsafe core behind a completely safe interface. That is, no use of the safe interface could ever possibly lead to memory unsafety, and this is checked by the compiler. A core value proposition of Rust is not necessarily that you will never need to utter `unsafe`, but rather, you can build safe abstra…
Writing unsafe code in Rust is harder than doing it in C/C++, because Rust introduces a whole new class of undefined behaviours that is just absent from C/C++. See [0], [1] or [2] in general for examples.
[0] http://smallcultfollowing.com/babysteps/blog/2017/02/01/unsa...
[1] http://smallcultfollowing.com/babysteps/blog/2016/05/27/the-...
Earlier quoted context omitted.
> Doesn't Option() on a Rust pointer optimize down to a zero pointer value anyway? There aren't pointers here though. But yes, you could use NonZero to mark the hash value as never-zero so that the option gets optimized. You'd still need unsafe code to construct the nonzero, but that's okay. At least for the Hashmap I don't think the code is premature optimization; it seems to be pretty "idiomatic" unsafe Rust, with…
t seems to be pretty "idiomatic" unsafe Rust, with unsafe used exactly where needed. I haven't really looked at the btreemap in a while. The number of excuses associated with unsafe code in Rust is excessive.
In my programming experience, there are two kinds of code: 1. Code where my objects form a tree. Rust's ownership model is great for this. 95% of my code looks this way naturally, and maybe another 3% can be rewritten to look like this. 2. Code where my objects form a complex graph. At this point, I need to make a choice between manual pointer management (C++, unsafe Rust) and a garbage collector (lots of languages).…
That might not work if the situation is very uncontrolled and objects live and die very quickly. But in most cases you can just let die a few objects, and every once in a while do "garbage collection" manually by renumbering the still-alive objects to be consecutively indexed.
Usually the result is very clean, performant and modular code.
It's clean and modular for all the reasons that E.F. Codd preached all his life.
It's performant because the tables approach is not micro-managing allocations - each table is only one allocation. You will be hard pressed to detect a difference of (single array + relative index) to raw pointers (= absolute index). There's even machine level support for relative addressing.
You also write most of your code to operate on slices (tables or contiguous subsets of tables) instead of only one row per function call. Mike Acton rightfully says "where there's one, there's many". This approach is obviously great for performance because it avoids function-call overhead and because it's cache-friendly.
By the way, what's Rust's story to avoid referencing dead items in these tables?
Earlier quoted context omitted.
The point the OP was trying to convey (and the OP could have been clearer) is that Rust will allow you to button up an unsafe core behind a completely safe interface. That is, no use of the safe interface could ever possibly lead to memory unsafety, and this is checked by the compiler. A core value proposition of Rust is not necessarily that you will never need to utter `unsafe`, but rather, you can build safe abstra…
While hiding unsafe parts of code behind safe interface works great in Rust, especially that ownership / borrowing rules expresses much more than is possible in other mainstream languages (in Java you wouldn't know if you are the owner of collection returned collection, or maybe it just a view, etc.), there is one thing that I never seen addressed in this kind of arguments: Writing unsafe code in Rust is harder than…
I don't know how much harder it is than C/C++ though. Seems hard to quantify. But the `unsafe` markers should help quite a bit.
I think this misses the problem. Should you write your own data-structures? Not unless absolutely necessary. But mostly everyone knows that. So why are people complaining about data-structures? For me, writing the data-structures is the canary in the mine. It's the next step from hello world when trying to pick up a new language. Most importantly, trying to write a few simple data-structures hints at the difficulty t…
Creating complex object graphs is also not trivial in Haskell, yet that language seems to do fine with real-world problems.
What's a complex real-world program written in Haskell? It seems to be good for trees (compilers like GHC, although it is kind of slow). Is there a non-toy graphics or graph-ical application that is both performant and written in Haskell?
Not denying that it's possible to write C-style in it, of course... only it's not fun.
Earlier quoted context omitted.
All the other datastructures in the stdlib would still need unsafe. Why?
How would you implement the robin hood Hash{Set,Map} with this? Or BTreeMap? Maybe I misunderstood your proposal, at first it seemed like dependent types (which makes vectors awesome but really doesn't address other things), but your Pascal thing makes it sound more like complete formal verification, which is what Rustbelt is doing. I don't expect that to become part of the language (maybe? would be cool), but it wou…
Earlier quoted context omitted.
t seems to be pretty "idiomatic" unsafe Rust, with unsafe used exactly where needed. I haven't really looked at the btreemap in a while. The number of excuses associated with unsafe code in Rust is excessive.
It's not an excuse, I just don't think that your statement that the hashmap code uses unsafe superfluously is correct.
I'm fine with the use of `unsafe` here. A hash table can be implemented using safe Rust, but you can squeeze a few percent more performance out of it by using a small amount of unsafe code, in a way that would be very difficult to make safe, without a super fancy dependent type system like ATS plus a ton of annotation overhead. The unsafe code can be vetted relatively thoroughly and is safe from the outside. That kind of practical compromise seems very much in the spirit of Rust...