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

71–80 of 301 posts

Re: The struggle with Rust

#71

Post by aomix »

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.

Re: The struggle with Rust

#72

Post by jackmott »

humanrebar wrote: post #66
rbehrends wrote: post #55

Earlier quoted context omitted.

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…

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…

It might be worth it over C++, but assuming the task at hand is not hindered by garbage collection, is it ever worth it over an ML style language?

It certainly takes a lot more typing to get things done.

Re: The struggle with Rust

#73

Post by eternalban »

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…

You came from interpreted Python to compiled OCaml and I suspect that your initial encounter with a compiler is the underlying issue. (For example, being new to FP but very friendly with compilers -- C, C++, Java, C# -- I found the initial OCaml encounter surprisingly pleasant. Haskell was something else though :))

I looked at Rust specs 1.0 when they were released and immediately recognized that Rust is not a 'dating' language, but rather a very serious 'marriage' till death do us part sort of deal. (I would say the same for Haskell, & Scala.) And imho the initial promise of addressing the out of control complexity of C++ was not met.

I have no doubt that Rust is a thoughtful, and powerful, language. But you have to be prepared to exchange vows at the alter.

Re: The struggle with Rust

#74

Post by GolDDranks »

radarsat1 wrote: post #43
burntsushi wrote: post #20

Earlier quoted context omitted.

There's no single solution to the problem, which is perhaps one reason why folks new to Rust might stumble over it. You can't just get two aliased mutable pointers to the same region of memory in safe code. Sometimes the borrow checker can't quite see through everything. Consider this trivial example, which will fail the borrow checker: let mut owned = vec![1, 2]; let x = &mut owned[0]; let y = &mut owned[1]; That th…

> That this fails might come as a surprise to a lot of folks because it's easy for a human to see that it's perfectly safe. So what's still unclear to me is, is this failing in the borrow checker "by design", or is it something that will be "improved"? Also, _why_ does it fail in the borrow checker? Is it correct that it fails, or is it a deficiency of the current borrow checker?

It's a limitation of the borrow checker, but it's more of a limitation of simple, orthogonal design than a hard technical limitation of the implementation.

It could have special cases for many things, such as letting the disjoint indexes pass. But that would be a special case because it can't always prove that the indexes are disjoint. So it leaves up to libraries to provide APIs that do that. This is why `split_at_mut()` demonstrated in grandparent post exists.

Re: The struggle with Rust

#75

Post by pron »

burntsushi wrote: post #61
pron wrote: post #58

Rust provides something that few if any other languages do: memory safety without GC. It is very obvious that this comes at a non-negligible cost in development effort. If you need what Rust provides -- and an important class of software certainly does -- you should be more than happy to pay that extra cost. If you don't, there are plenty of alternatives. But exchanging effort for rather unique guarantees is the very…

To be clear, I think the data supports that Rust comes with a non-negligible learning cost. Whether that cost is continually paid isn't clear yet. (I personally think the answer is "no.")

I agree that there's no data, but I would be very surprised if the answer is indeed no, as there are at least good theoretical reasons to assume extra cost. Proving anything (let alone to a compiler) comes at a computational complexity cost (think of the proof as a certificate). In principle, a large number of proofs may be "free" in the sense that no more information than the programmer normally supplies the compiler is necessary. But if this is true in every case, that is very surprising.

Re: The struggle with Rust

#76

Post by bronson »

justinlaster wrote: post #21

>So I spent a few evenings with Rust I stopped reading. There is literally nothing you could possibly say that'd be worthwhile after "a few evenings" with Rust, especially when you lack the proper background in the first place. This trend of "The problem with Rust: A naive and inexperienced perspective"-esque articles is already old.

I made it to

> I have a buffer, that I want to mutate using pointers

Turns out you were right.

Re: The struggle with Rust

#77

Post by sametmax »

jnbiche wrote: post #53
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…

> I believe that we are seeing the same kind of phenomenon in Rust: I don't know. I picked up OCaml fairly quickly, but I have consistently struggled with Rust, trying it for a while before abandoning it in frustration with lifetimes, 2 or 3 times. I can program in Rust, but it still seems like an ongoing struggle, as opposed to the smooth brain to text programming I've gotten used to in Python, JavaScript, OCaml, an…

Give it time. Rust is brand new and has changed considerably during the last year. The rust team listen closely to the community and will smooth things up. But they can't do it all at once.

Re: The struggle with Rust

#78

Post by vbezhenar »

I don't know Rust good enough, but do unsafe blocks help there? Data structures belong to library code and libraries surely can utilize unsafe blocks, because they are expected to be heavily tested.

Re: The struggle with Rust

#79

Post by the_af »

camus2 wrote: post #50
the_af wrote: post #26

Earlier quoted context omitted.

> You just need to meditate deeply on category theory and draw direction graphs to become one with types and all would be revealed to you. In order to just use Haskell you don't need to meditate about category theory at all. Some things do require months -- or even years -- of studying. Like, for example, C++, Java or whatever was your first programming language. There is absolutely no getting around that.

> or whatever was your first programming language. People who complain about how difficult rust is to learn certainly aren't learning rust as their first programming language.

That's my point. I think people complaining that Rust (or Haskell, or whichever paradigm shift) "takes too long to learn" have forgotten what it was to learn their first language. It took them long, because some things take long. Learning something different takes time, but it's easy to forget this once you have a couple of languages under your belt.

Re: The struggle with Rust

#80

Post by jnbiche »

smt88 wrote: post #67
jnbiche wrote: post #53

Earlier quoted context omitted.

> I believe that we are seeing the same kind of phenomenon in Rust: I don't know. I picked up OCaml fairly quickly, but I have consistently struggled with Rust, trying it for a while before abandoning it in frustration with lifetimes, 2 or 3 times. I can program in Rust, but it still seems like an ongoing struggle, as opposed to the smooth brain to text programming I've gotten used to in Python, JavaScript, OCaml, an…

> smooth brain to text programming This isn't a good thing, in my opinion. Brains make mistakes. I don't want smooth, uninterrupted coding. I want the compiler to tell me when I'm making the mistake, even if it makes things choppier. It's a lot less painful to write code in fits and starts than to write a million tests or spend hours debugging.

> I want the compiler to tell me when I'm making the mistake, even if it makes things choppier.

You don't think the OCaml type system would do this? OCaml gives you just as much safety as Rust does, it just doesn't also give you no GC like Rust does. And the price Rust pays for the absence of GC is the lifetime concept, which adds a very significant layer of complexity to the language. Much like OCaml, Swift and Scala also provide very safe type systems.

Again, if you can't have a GC, then Rust is an excellent option, and the only really safe GC-less language unless you use C with FramaC or similar static analysis (and FramaC also requires lots of training and time to use, just like Rust).

Post reply on HN