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

81–90 of 301 posts

Re: The struggle with Rust

#81

Post by jackmott »

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 don't think they are any error classes that OCaml/F# will let you make that Rust won't.

Re: The struggle with Rust

#82

Post by valarauca1 »

JepZ wrote: post #62
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.

    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.
I don't want to sound snarky but Rust really does have amazing error messages, and they literally do offer direct solutions/suggestions using literal examples and raw samples of your source code.

It even offers the `rustc --explain EXXXX` (where XXXX is an error code) that give an in terminal deep dive + examples on why this is an error/how it is failing.

    I never wrote a single line of rust
:|

Re: The struggle with Rust

#83

Post by sametmax »

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.

It depends a lot of what you code and your constraints. Believe it or not they are a huge crowd of people making a living out of code that is easy to write but crashes. And they are happy about it.

E.G: one of my friend has a streaming website. He make banks with ads despite the site having problems all the time. He doesn't care the least. He is not an expert coder and just want to be able to build the features he needs, even if it's not perfect. Types are way too much for him. It took 2 years to master git basics.

Another example: my current clients are geomaticians. They code in Python a lot. They produce only small codes, and don't want something complex. They are experts in maps, not code, and love Python to have the balance of cost / reward they want.

HN is a bubble of expert devs, but the world is full of PHP plumbers, data manglers, sys admin and other professional that have a legitimate needs for "smooth brain to text programming".

Re: The struggle with Rust

#84

Post by the_af »

rubber_duck wrote: post #28
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.

Yes but going from one to the other is relatively straightforward and possible in small steps of progression - Rust forces you to deal with a lot of things up front which is why people complain. eg. if you're a C++ developer you'll pick up Java very fast, it will take a while to be super productive but you can start working really fast.

That's because a lot of things (let's not debate exactly how many here) translate well between C++ and Java. But my point wasn't about going between relatively similar languages; it was about learning something radically different for the first time, like it was when you learned your first programming language.

Re: The struggle with Rust

#85

Post by camus2 »

the_af wrote: post #79
camus2 wrote: post #50

Earlier quoted context omitted.

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

> 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

Because they are required to be productive fast. A professional usually doesn't learn a new language just for the sake of it. If the language doesn't yield instant benefits then most people aren't going to bother learning it.

If a steep learning curve is expected for rust then the language will never be popular around the people who could potentially make use of it, i.e. C or C++ developers.

Re: The struggle with Rust

#86

Post by rev_null »

the_duke wrote: post #45
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…

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.

Re: The struggle with Rust

#87

Post by zzzcpan »

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

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

There might be an easy solution, they could provide more flexibility on using safety features, kind of like Perl did it, i.e. let anyone disable/enable a particular strict feature for a particular scope, for example "no borrowcheck;" or something. This will make it easier and more flexible for everyone, newcomers will be able to gradually learn more about the language and still get things done in the meantime, and power users will understand where satisfying the compiler is not worth it and will be more productive as a result without worrying about overly broad unsafe.

Re: The struggle with Rust

#88

Post by burntsushi »

pron wrote: post #75
burntsushi wrote: post #61

Earlier quoted context omitted.

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

It's not very surprising to me. Paraphrasing, "once I got past the initial hurdle of the borrow checker, programming in Rust became much easier," is frequently uttered in the Rust community.

I'm not trying to make a very nuanced claim here. All I'm saying is that there's clearly a lot of people who struggle while learning Rust, but that this is very different than paying an eternal development cost similar to that struggle. We should be careful not to conflate them.

(I did not meant to get into a broader philosophical discussion about using a type system. That's a different conversation IMO, and I disagree with your analysis because you only focus on the upfront cost while neglecting the maintenance costs in the absence of such proofs.)

Re: The struggle with Rust

#89

Post by Etzos »

leshow wrote: post #69

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.

I don't typically respond to comments like this anywhere, but I think this kind of view is dangerous to have. And it's one the Rust community at large seems to try to shy away from.

This kind of attitude towards people trying out a new language is damaging to the person trying the new language and to people who are part of that languages community. The former because it will give them the notion that the community is hostile towards them and newcomers in general and the latter because it can enforce a dogmatic view of the language ("you do it our way or no way!" kind of feel).

A language's ability to have people pick it up easily is important. In Rust's case there is definitely always going to be a bit of a hump for people to get over, but the concern put forth in this article seems like a legitimate one, but one the Rust community seems to be aware of. Acknowledging and helping people with these problems (while searching for a way to potentially avoid such a situation for the next newcomer) is important and it's critical that you not simply dismiss someone's opinion because they don't know or understand "the right way to do it" yet.

Re: The struggle with Rust

#90

Post by stonemetal »

jackmott wrote: post #81
smt88 wrote: post #67

Earlier quoted context omitted.

> 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 don't think they are any error classes that OCaml/F# will let you make that Rust won't.

Rust prevents data races, OCaml/F# don't provide such guaranties. Though it isn't so much of a problem in OCaml since it doesn't have concurrent threads.
Post reply on HN