Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust Sucks If I Fail to Write X

llogiq.github.io

Post reply on HN
Print view View original

81–89 of 89 posts

Re: Rust Sucks If I Fail to Write X

#81

Post by comex »

Animats wrote: post #66
Manishearth wrote: post #56

Earlier quoted context omitted.

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…

Rustbelt is a research project, and they're using Coq, which is interactive and requires a lot of user effort. What I'm talking about is doing it within the language and automatically. Looking at BTreeMap, the extensive use of unwrap_unchecked seems to be unnecessary. That looks like premature optimization - omitting the check saves maybe two instruction on the main path. The other unsafe code there seems to mostly i…

To me, Rust is very much about doing "premature optimization", in the sense that small overheads add up and should be avoided where possible.

BTW, I do think the language ought to have an answer to backpointers. In fact, there is an interesting crate named 'rental' that tries to make a subset of cases safe; but to do it properly requires more concepts in the type system, especially immovable types.

It's tricky, though. The problem with backpointers is that they destroy uniqueness. You can't have 'node: &mut Node' if Node is the target of backpointers, because you could do 'let node2 = &node.left.parent'; you could then take a reference to some field of node2 and mutate it via the original, leading to use-after-free, etc. But without uniqueness, how do you mutate? One option is to use `Cell`, a.k.a. allowing mutation via shared references - but then if you have a reference to a node, you can't take a reference to its child without worrying it could be freed from under you. So you need reference counting. Another option is to use `RefCell`, dynamically tracking whether a value is borrowed, but that has its own overhead (especially if the code is multithreaded, then you need a mutex!) and generally makes it pretty easy to write code that crashes (safely, but still a crash from a user's perspective).

I'm sure there are constructs that can solve this problem in many instances, but as far as I know, it's hard to make general without a very complex proof system.

Re: Rust Sucks If I Fail to Write X

#82

Post by pka »

jstimpfle wrote: post #78
adrianN wrote: post #42

Earlier quoted context omitted.

Creating complex object graphs is also not trivial in Haskell, yet that language seems to do fine with real-world problems.

Is it doing fine? There's lots of "cool" stuff, but in my perception it's still a long shot to "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…

At my previous company we used Haskell for a very complex, edge-case ridden, algorithm heavy path finding and pricing backend.

For other uses, [0].

[0] https://wiki.haskell.org/Haskell_in_industry

Re: Rust Sucks If I Fail to Write X

#83

Post by adrianN »

sjolsen wrote: post #47
adrianN wrote: post #42

Earlier quoted context omitted.

Creating complex object graphs is also not trivial in Haskell, yet that language seems to do fine with real-world problems.

Haskell is also garbage-collected, and lazily evaluated to boot. It's not really an apples-to-apples comparison.

Of course not. Haskell is a purely functional language and Rust is an imperative systems language. It can hardly be more Apples to Oranges.

Re: Rust Sucks If I Fail to Write X

#84

Post by jstimpfle »

pka wrote: post #82
jstimpfle wrote: post #78

Earlier quoted context omitted.

Is it doing fine? There's lots of "cool" stuff, but in my perception it's still a long shot to "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…

At my previous company we used Haskell for a very complex, edge-case ridden, algorithm heavy path finding and pricing backend. For other uses, [0]. [0] https://wiki.haskell.org/Haskell_in_industry

Of course it would be nice to have examples that we can actually look at. Also that webpage is known to mostly not point to easy to find information.

Re: Rust Sucks If I Fail to Write X

#85

Post by Manishearth »

comex wrote: post #81
Animats wrote: post #66

Earlier quoted context omitted.

Rustbelt is a research project, and they're using Coq, which is interactive and requires a lot of user effort. What I'm talking about is doing it within the language and automatically. Looking at BTreeMap, the extensive use of unwrap_unchecked seems to be unnecessary. That looks like premature optimization - omitting the check saves maybe two instruction on the main path. The other unsafe code there seems to mostly i…

To me, Rust is very much about doing "premature optimization", in the sense that small overheads add up and should be avoided where possible. BTW, I do think the language ought to have an answer to backpointers. In fact, there is an interesting crate named 'rental' that tries to make a subset of cases safe; but to do it properly requires more concepts in the type system, especially immovable types. It's tricky, thoug…

I think you can solve the backpointer problem in a relatively straightforward way if Rust had true linear types. Possibly not as simple as it seems, though.

Re: Rust Sucks If I Fail to Write X

#86

Post by fanf2 »

charles-salvia wrote: post #36
vvanders wrote: post #26

Earlier quoted context omitted.

How often do you really need those interesting structures(and the memory fragmentation that comes with them)? I've seen countless times where a developer reached for std::hash_map/linked_list when there will never be more than 10 values in their dataset. In that case an array would be at least as fast and much easier on your data layout. Also if you're trying to implement lockfree data structures then safe/unsafe poi…

When you need them you really need them. A Patricia Trie for example, which includes back pointers to ancestor nodes, is simply an ideal structure for prefix search.

Check out qp tries http://dotat.at/prog/qp for something rather more compact than Patricia tries

Re: Rust Sucks If I Fail to Write X

#87

Post by notriddle »

jstimpfle wrote: post #76
ekidd wrote: post #7

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

A common approach to 2) is the database approach ("data-oriented design") where you basically have tables and replace pointers by offsets into these tables. 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 consecut…

> By the way, what's Rust's story to avoid referencing dead items in these tables?

One option is Option.

Re: Rust Sucks If I Fail to Write X

#88

Post by notriddle »

wuch wrote: post #74
burntsushi wrote: post #64

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…

There are a bunch of things that are UB in C and C++ that are well-defined in Rust.

* Signed integer overflow * Aliased pointers to different types (-fno-strict-alias) * Probably more, but the formalised memory model is still up in the air. The ones I just listed are just the ones that are already decided...

Re: Rust Sucks If I Fail to Write X

#89

Post by wuch »

notriddle wrote: post #88
wuch wrote: post #74

Earlier quoted context omitted.

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…

There are a bunch of things that are UB in C and C++ that are well-defined in Rust. * Signed integer overflow * Aliased pointers to different types (-fno-strict-alias) * Probably more, but the formalised memory model is still up in the air. The ones I just listed are just the ones that are already decided...

True, in fact undefined-behaviour-wise I don't think there is any mainstream language that comes close in this respect to C/C++. Alas, this is well-known and addressed in various publications.

Converse, things that could be eventually decided to be UB in Rust, but are not UB in C/C++, is rarely mentioned at all. It is quite interesting what is cost (in terms of UB behaviour) of making various optimization that are claimed to be possible in Rust but not yet realized. Reading through some of Niko proposals it would seems that this cost is quite nontrivial.

Post reply on HN