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

61–70 of 301 posts

Re: The struggle with Rust

#61

Post by burntsushi »

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

Re: The struggle with Rust

#62

Post by JepZ »

adwhit wrote: post #5

These sorts of articles are starting to pop up a bit more frequently, presumably because Rust is starting to get a bit of traction. The theme is "I know $LOW_LEVEL_LANGUAGE therefore I should be able to program Rust. I spent a few days and couldn't. I don't like Rust." Unfortunately, things aren't that simple and Rust really is different from other languages. It takes months of steady investment (and yes, frustration…

I never wrote a single line of rust, but when a language is hard to learn, the compiler error messages are probably just bad in terms of comprehensibility and offer the user no direct solution.

Re: The struggle with Rust

#63

Post by krat0sprakhar »

tejinderss wrote: post #15
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…

Not related to the topic but how do you find ocaml as compared to python or rust? Do you think its worth learning today as opposed to rust for high level general purpose programming?

Absolutely! If you're looking for fast, GC'd, native functional language I'd say OCaml is a great option. There's actually a very comprehensive set of blog posts migrating an open-source python based project to OCaml, that I'd recommend reading if you're looking for a more thorough comparison - http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-ret...

Personally, I used OCaml while at university to write a programming language (http://jsjs-lang.org) and totally loved it. Real world OCaml is a great resource and I'd definitely recommend giving OCaml a try. My only regret is that I don't get to write OCaml as much as I want to due to the kind of projects I work on, but given that Bucklescript[0] and Reason[1] are moving ahead in full steam, that might change shortly too :)

[0]- https://bloomberg.github.io/bucklescript/

[1] - https://facebook.github.io/reason/

Re: The struggle with Rust

#64

Post by rubber_duck »

vertex-four wrote: post #40
rubber_duck wrote: post #22

Earlier quoted context omitted.

>It takes months of steady investment (and yes, frustration), but the payoffs are spectacular. This was the exact same thing I kept reading back when functional programming was becoming in vogue - people were pushing for Haskell, saying that purity and laziness were amazing, type system could almost prove correctness at compile time, etc. etc. You just need to meditate deeply on category theory and draw direction gra…

> 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. Luckily, Rust's community is much more pragmatic - but their goals are still to create something substantially different from existing languages because existing languages are not enough to guarantee what Rust guarantees.

Yea that's what I see as an issue as well, I was hoping it wouldn't be but the deeper I go in to Rust the more it shows up. On one hand a really simple solution would be to make unsafe a first class citizen when it makes sense, this would let you avoid "pushing square pegs in to round holes" solutions when the borrow checker doesn't capture your problem nicely, and it would be trivial for C++ devs to get on board.

On the other hand this defeats the goal of the language - being as safe as possible - because their domain is very sensitive to memory safety issues (browser) - promoting an ecosystem of unsafe libraries wrapped in safe facades would be against their goals.

So I guess right now, because of it's design decisions, Rust isn't simply an upgrade to C++ which I want but more of a language that took different trade-offs to solve specific problems. It remains to be seen if it's worth taking those trade-offs to be rid of C++ legacy garbage.

Re: The struggle with Rust

#65

Post by lmm »

gravypod wrote: post #37

Could the issues of rust be rectified with a better theorem proved that goes past "2 things are touching this"? I don't think I'd mind if the compiler said "your code will not work because eventually it will modify the same bytes at the same time and create an unpredictable state" but I will mind if it says "your not good because you have two mutable references.

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 use it to mutate what it refers to). If you can formalize a better model you can probably implement it in a language, but what model would that be?

Re: The struggle with Rust

#66

Post by humanrebar »

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…

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 through much bigger headaches in production code at inconvenient times (for the business plan) due to dangling pointers, multi-writer concurrency bugs, and ill-defined memory models in software designs.

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.

Re: The struggle with Rust

#67

Post by smt88 »

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…

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

Re: The struggle with Rust

#68

Post by moomin »

The joke being, this is being written by a guy who has constantly insisted on his blog that if people don't think NHibernate and IoC are a good idea for their project, it's because of their personal failings.

Me, I muck around with Haskell. No I'm not productive in it. I don't think that's Haskell's problem, though.

Re: The struggle with Rust

#69

Post by leshow »

The first few of these types of posts were OK. But now it's a bit ridiculous. You spent 2 days trying a new language and you didn't like it, your opinion means nothing.

Re: The struggle with Rust

#70

Post by jackmott »

tejinderss wrote: post #15
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…

Not related to the topic but how do you find ocaml as compared to python or rust? Do you think its worth learning today as opposed to rust for high level general purpose programming?

It is worth looking at F# as well, which is basically OCaml on the .NET platform. With the advantages of having the entire .NET ecosystem of libraries available for use, being able to use more than one core of your cpu, a solid IDE, and some other features like type providers. There are some disadvantages as well, such as not being able to compile to a native executable.

Anyway the syntax is so similar you can learn one and switch to the other with very little pain.

Post reply on HN