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

The struggle with Rust

ayende.com

Post reply on HN
Print view View original

131–140 of 301 posts

Re: The struggle with Rust

#131

Post by rntz »

rbehrends wrote: post #55
gnuvince wrote: post #11

When I first learned OCaml (knowing only Python), I swore a lot at the type checker for refusing to compile code that I knew would work at run-time (e.g., a variable having multiple types, but on strictly disjoint execution paths). It seemed insane to me that people would want to subject themselves to this kind of bondage and discipline. And yet, many years later now, I have learned and internalized how type systems…

This is a different issue. The problem that the author is observing is that Rust operates on the hypothesis that the ownership relation is mostly left-unique and acyclic and that you run into problems when this hypothesis doesn't hold. And this affects not only explicit data structures, but also the implicit structures that involve stack frames (local variables, closures, etc.). While Rust has mechanisms to deal with…

> The difference compared to a (good) static type system is that a good [1] static type system does not measurably reduce expressiveness

This is pseudo-jargon. What counts as a "measurable" reduction? Do you have any substantive evidence that "good" typesystems don't reduce it? And why are only type systems which satisfy this property "good"? You talk cogently about tradeoffs later on, but this sentence taken literally suggests only a type system which doesn't make this particular tradeoff can be "good". Why?

My go-to languages for the past few years have been Haskell and Racket. There have definitely been times I picked Racket because I knew Haskell's type system would interfere with my expressiveness. Certainly Haskell is less restrictive than Rust with regards to ownership, but all type systems restrict you. I think GP is spot-on in pointing out that you just get used to it over time as you learn to think and code in ways that avoid pushing against the type-system's weak spots.

> But where garbage collection is an option, the tradeoffs that Rust makes become much less attractive.

Yes, precisely. It's not a fundamentally different issue from getting used to other static type-systems; it's just a different tradeoff.

Re: The struggle with Rust

#132

Post by Manishearth »

drbawb wrote: post #126

>We are talking about allocating memory, in a system level language, and unless you are jumping through hops[sic], there is just no way to do that. To be fair, if you want to call malloc it is still just as accessible[1][2] as it is in C. If you search the Rust documentation for malloc `libc::malloc` is even the first result. If you were to use that on stable Rust the error message will even tell you to link your pro…

Also, most folks would use `Box` with `Box::into_raw` (also `Vec::with_capacity` for dynamically sized stuff, which works fine.

RawVec is an implementation detail; Vec exposes most of what you need for dealing with raw memory.

Re: The struggle with Rust

#133

Post by nebopolis »

ajmurmann wrote: post #108
trishume wrote: post #18

Earlier quoted context omitted.

Agreed. Rust is different from other languages in that it is HARD to learn. It took me 3 projects and thousands of lines of code before I finally felt like I'm okay at Rust. Each project involved tons of compiler fighting that I now know how to avoid or solve. The problem is that instead of a general technique for solving borrow checker issues, every issue has a different specific technique. Hash map matches (like th…

The issues and solutions you list sound super valuable. Do you know if there is a write up about those issues somewhere or did you just learn through blood and sweat?

Learning Rust With Entirely Too Many Linked Lists (http://cglab.ca/~abeinges/blah/too-many-lists/book/) is the best resource I've found for learning how to create data structures in Rust. It goes over a lot of the pain points of interacting with cyclic data structures.

Re: The struggle with Rust

#134

Post by bluejekyll »

aomix wrote: post #71
gnuvince wrote: post #11

When I first learned OCaml (knowing only Python), I swore a lot at the type checker for refusing to compile code that I knew would work at run-time (e.g., a variable having multiple types, but on strictly disjoint execution paths). It seemed insane to me that people would want to subject themselves to this kind of bondage and discipline. And yet, many years later now, I have learned and internalized how type systems…

To me it seems like Rust has an additional wrinkle with safe and unsafe code. A new Rust user needs to figure out both "How do I do this" and "Is this possible in safe code". The limits of safe code seems to be something people are figuring out at all levels. Rust projects seem to start out with a relatively high amount of unsafe code. Then as the project matures the unsafe sections are reduced or eliminated.

This really isn't that big a deal. I have written 60k lines of code in my side project, it's required zero lines of unsafe Rust code. I have needed to extend some other OSS libraries I depend on and those have required unsafe code for bindings to C, but that makes sense. Even in Java it's unsafe to write JNI to C.

Re: The struggle with Rust

#135

Post by jcranmer »

rev_null wrote: post #86
the_duke wrote: post #45

Earlier quoted context omitted.

I think the problems with Haskell are quite different than the ones with Rust. Haskell suffers more from being a research playground, bad documentation for both the language and it's libraries, confronting you with many unusual concepts (type theory, monads, laziness,...) and, as a pretty old language, a lot of legacy cruft that makes a lot of things awkward (string handling is the prime example). Rust wants to be a…

When the blub programmers look up the ladder, they see a bunch of type theory, monads, and laziness. They don't see the use for these features as they think in blub.

If you tried to teach basic arithmetic in elementary school by means of axiomatic set theory, you'd put entire generations of people off of math. It is not a virtue to require people to take the hardest path to a concept in the name of purity, and it is certainly not a virtue to be condescending in the failure of others to do so.

Take as an example call/cc. If I tried to explain that to a--as you put it--blub programmer, I would probably get glazed eyes in response. If I instead tried to explain it via means of a yield operator (à la Python), I would much more likely get someone who could think of use cases where they would want to use it in their own code. The limitations are not in the blub programmer, it's in the teacher for assuming that blub programmers are incapable of learning hard concepts.

Re: The struggle with Rust

#136

Post by tps5 »

I'm not coming from C++, but my experience with Rust has been:

* Read the book, got some of the concepts but most of it went over my head.

* Did nothing, maybe thought about it a little bit.

* Two weeks later: read the book again. It made more sense but some of it is still lost on me.

* Actually wrote some Rust. Was hard, frequently consulted the book, the "by example" book, r/Rust, and google.

* Two weeks later, it's much easier. I'm still consulting outside resources frequently, but I generally know how to fix problems as they arise and my mental model of the how the language executes is becoming more and more accurate.

I've spent on average 30 minutes a day working on a pretty simple Rust program for about a month now. The advantages of Rust so far have been: if it compiles, it works. Extremely easy to refactor: for my main data structure, I've switched between vecs and arrays back and forth probably 4 times to get a feel for the differences. This is generally really easy to do because they both implement the the iterator trait. In the other languages I use (at work), switching between one type of collection and another would be a huge time sink and involve a lot of annoying (though trivial) refactoring.

The main advantage of Rust for me (and the reason why I decided to check it out vs go) is that I don't have a lot of experience thinking about memory at a low level. The dynamic languages I work with abstract that away from the programmer. I wanted something that would force me to think about how and where memory is being allocated, and whether I want to pass by reference or value. For someone who has spent a lot of time with C/C++ or just someone with a background in CS/programming languages, this may all seem obvious to you. But there's a lot of programmers out there who learned with dynamic languages and don't have a good mental model for memory. Rust is a good instructional tool for us.

I don't really have an opinion on whether Rust is "production ready." It's being developed rapidly though, so I think it'll get there.

Re: The struggle with Rust

#137

Post by kazagistar »

gravypod wrote: post #117
lmm wrote: post #65

Earlier quoted context omitted.

Well Rust's way of ensuring you don't modify the same bytes at the same time is to ensure that any byte has precisely one "owner" in any region in which it is mutated. That's a model we know how to implement and also an easy model for humans to think about - we can see what's going on (we can see the regions in the code) and we know what to expect to work (e.g. if you have a mutable reference you expect to be able to…

From an implementation standpoint that makes sense. From a usability standpoint it does not. The use case of systems programming usually involves many mutators on a single piece of, non-copiable, data. I can see why the person writing the Rust prover would say "yea this is the best" but I can't see why anyone else would because it's filter cuts out a large portion of completely valid code that is not incorrect but in…

Lots of mutators over a single piece of data gets you data races. If you do it correctly, you protect against this somehow, using something like a mutex, or something more complex. Rust provides RefCells, Mutexes, and fancy libraries like Crossbeam for exactly this reason.

Re: The struggle with Rust

#138

Post by humanrebar »

rbehrends wrote: post #123
humanrebar wrote: post #66

Earlier quoted context omitted.

First, the expressiveness is all there. You just need to explicitly say you are responsible by using unsafe blocks. So risky pointer and allocation logic becomes the programmer's job, not the borrow checker. Second, this article only considers the costs of a stricter borrow checker, not the benefits. It will be more work for the coder to have to think about how allocation and ownership is communicates. But I've been…

> First, the expressiveness is all there. You just need to explicitly say you are responsible by using unsafe blocks. So risky pointer and allocation logic becomes the programmer's job, not the borrow checker. No, unsafe would be overkill and if you needed unsafe, it would put Rust at a massive disadvantage vis-à-vis garbage-collected languages. Simply put, Rust doesn't handle multiple ownership well. It results in s…

> No, unsafe would be overkill

I don't see an issue with 'unsafe' if it's an implementation detail and well-tested. Obviously it would be better to avoid it if possible. 'unsafe' is overkill sometimes and worth it other times.

Re: The struggle with Rust

#139

Post by eximius »

If you just want to allocate a chunk of memory for random use like you would in C, it can't be guaranteed to be safe. So I would hope you need to jump through hoops.

Re: The struggle with Rust

#140

Post by readittwice »

maffydub wrote: post #111
aomix wrote: post #71

Earlier quoted context omitted.

To me it seems like Rust has an additional wrinkle with safe and unsafe code. A new Rust user needs to figure out both "How do I do this" and "Is this possible in safe code". The limits of safe code seems to be something people are figuring out at all levels. Rust projects seem to start out with a relatively high amount of unsafe code. Then as the project matures the unsafe sections are reduced or eliminated.

I think whether you feel you need unsafe when you first come to Rust depends on the angle from which you're coming. Coming from C/C++, I know that there are structs in memory and can visualize what they look like - surely I can just go and tweak them? (No I can't because either it wasn't safe to do that anyway, or I need to explain to the Rust compiler why it is safe, and that can be quite difficult.) Coming from som…

I am not so sure about this, at least for Java for one simple reason: it is so easy to have back-pointers/cycles in your object graphs. In Java you don't even have to think about that. This was quite hard for me to figure out when starting with Rust.
Post reply on HN