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

151–160 of 301 posts

Re: The struggle with Rust

#151

Post by eternalban »

throwaway91111 wrote: post #127
eternalban wrote: post #73

Earlier quoted context omitted.

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 'datin…

Of all the things I'd accuse rust of, complex is not one of them. Could you give an example of the complexity? I've not found a single pattern in rust I wouldn't already have to think about in c++, but I have to think about it less because the compiler thinks about it for me. I just can't postpone the confidence until later.

It was an impression, but clearly it is not a 'simple' language at the syntactic or semantic levels.

(You should not read my OP as a negative critique. I'm merely pointing out that anyone expecting 'immediate gratification' with Rust is likely to be disappointed.)

> the compiler thinks about it for me.

Indeed. One valid approach to categorizing programming languages is by considering upfront vs amortized cognitive load.

Re: The struggle with Rust

#152

Post by eternalban »

gcp wrote: post #101
eternalban wrote: post #73

Earlier quoted context omitted.

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 'datin…

And imho the initial promise of addressing the out of control complexity of C++ was not met. I'm not sure. Type traits seem to be much more manageable than how the same thing is handled in C++ template code, no? Also, if we can bring in ecosystem effects such as cargo...

I guess I should have added that I last touched C++ in '96 and never (ever) have had an urge to look back. :)

Re: The struggle with Rust

#153

Post by rbehrends »

rntz wrote: post #131
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…

> 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 literal…

> This is pseudo-jargon. How do you measure expressiveness?

Actually, not jargon. I had Matthias Felleisen's characterization of expressiveness [1] in mind (incidentally, he's also one of Racket's authors).

> Do you have any substantive evidence that "good" typesystems don't reduce it?

If we want to be precise, there is a continuum from statically to dynamically typed language. A dynamically typed language is, after all, the same as a static language with just a single polymorphic type. This means that we can trivially translate a dynamically typed program into a statically typed program, though obviously we don't gain anything by that at this point (this is essentially an argument that Bob Harper has advanced before) and we pay for it in additional verbosity. However, in practice we know that we don't need all that flexibility and can constrain types more, allowing us to get better type guarantees; static types then also allow us to do things that we can't do in a dynamic language (such as compile-time overloading).

[1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.51.4...

Re: The struggle with Rust

#154

Post by allengeorge »

Bartweiss wrote: post #95
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…

> Even if Rust is much harder than alternatives instead of just different, and even if that's inherent in borrow checking, it's not clear that it's still not worth it in the long run. One obvious argument is that Rust frontloads its difficulty. It's a terrible tool for most 30 line tasks, simply because the majority of your work will go into arguing with the compiler. But that's true of a great many tools - if there'…

My observation is that that's not quite true. It's fine for smaller tasks, but that mushy middle where you're discovering the parameters and outlines of a problem can be painful. Looser (note that I explicitly don't say "better" or "worse") languages give you more leeway to play around and discover how the problem is structured.

Re: The struggle with Rust

#155

Post by spullara »

bluejekyll wrote: post #128
Bartweiss wrote: post #95

Earlier quoted context omitted.

> Even if Rust is much harder than alternatives instead of just different, and even if that's inherent in borrow checking, it's not clear that it's still not worth it in the long run. One obvious argument is that Rust frontloads its difficulty. It's a terrible tool for most 30 line tasks, simply because the majority of your work will go into arguing with the compiler. But that's true of a great many tools - if there'…

> It's a terrible tool for most 30 line tasks, simply because the majority of your work will go into arguing with the compiler. This arguing with the compiler is really only while you are learning Rust and it's nuances. For me the first two weeks were this way, then I started thinking more in Rust terms. Now I rarely deal with the borrow checker at all, but I do end up in some complex type situations. You're spot on…

I think the difference is that while you are coding Python in a C style the code is working. The front loaded nature of Rust means that you are in a constant fight to get something to run.

Re: The struggle with Rust

#156

Post by braveo »

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…

I agree, ayende is a C# person, he's well aware of statically typed languages.

I also agree about your other points, I think maybe one of these days the borrower will become more sophisticated, but these issues he's complaining about are the exact reason I put Rust down. It just felt too sophomoric, as if the language wasn't really ready.

Not all is bad, I really like the way errors are handled in Rust, but there are definitely some problems with the approach they take.

Re: The struggle with Rust

#157

Post by bluejekyll »

humanrebar wrote: post #138
rbehrends wrote: post #123

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

Instead of unsafe, as much as possible should be looking at interior mutability, Cell and RefCell allow for this, with no unsafe, and they guarantee for you at runtime that what you believe is accurate.

unsafe should be IMO, reserved for only those cases where strictly needed, e.g. FFI is the clearest example.

Re: The struggle with Rust

#158

Post by braveo »

humanrebar wrote: post #138
rbehrends wrote: post #123

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

> if it's an implementation detail and well-tested

The same can be said of C and C++, at which point, why does it matter if you use Rust?

Re: The struggle with Rust

#159

Post by braveo »

bluejekyll wrote: post #128
Bartweiss wrote: post #95

Earlier quoted context omitted.

> Even if Rust is much harder than alternatives instead of just different, and even if that's inherent in borrow checking, it's not clear that it's still not worth it in the long run. One obvious argument is that Rust frontloads its difficulty. It's a terrible tool for most 30 line tasks, simply because the majority of your work will go into arguing with the compiler. But that's true of a great many tools - if there'…

> It's a terrible tool for most 30 line tasks, simply because the majority of your work will go into arguing with the compiler. This arguing with the compiler is really only while you are learning Rust and it's nuances. For me the first two weeks were this way, then I started thinking more in Rust terms. Now I rarely deal with the borrow checker at all, but I do end up in some complex type situations. You're spot on…

> This arguing with the compiler is really only while you are learning Rust and it's nuances. For me the first two weeks were this way, then I started thinking more in Rust terms. Now I rarely deal with the borrow checker at all, but I do end up in some complex type situations.

It just means you've learned to head off problems before they occur, that does not mean the problems you're heading off should be there.

Re: The struggle with Rust

#160

Post by mtanski »

readittwice wrote: post #145
lhnz wrote: post #120

Earlier quoted context omitted.

> Cyclic data structures require an Arena or Rc >. Is there a way of creating a cyclic data structure that doesn't involve these types? I ask because I used the latter recently, after struggling to create lifetimes that were acceptable to the compiler. I only found it when I searched for 'cyclic data structures rust' on Google. It would have been much nicer if the compiler could have noticed that I was trying to crea…

You could use id/vec indices, instead of directly pointing to your e.g. sucessors: "struct Node { successors: Vec }". This has the obvious disadvantage that deleting nodes is quite hard though.

> This has the obvious disadvantage that deleting nodes is quite hard though

It's hard because now you're in charge of building a malloc(3) implementation. Depending how important this data structure is you might need to worry about 1. about fragmentation 2. free space managment 3. adjacency and cache effects

So you've traded on hard problem for another hard problem. Not something I'd call a win.

Post reply on HN