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

My Struggles with Rust

compileandrun.com

Post reply on HN
Print view View original

81–90 of 329 posts

Re: My Struggles with Rust

#81

Post by bpicolo »

erickt wrote: post #31

Hello Justin Turpin! Sorry to hear your struggles with rust. It's always going to be a bit more verbose using rust than Python due to type information, but I think there are some things we could do to simplify your code. Would you be comfortable posting the 20 line code for us to review? I didn't see a link in your post. Anyway, so some things that could make your script easier: * for simple scripts I tend to use the…

4 chained function calls from config -> read a key from it is quite an ask. Though I realize there's reason for it. There are many cases I'd be happy to have panics occur for invariants. config.strictString('foo') or something of that nature seems like it could be a more ergonomic choice in cases like thise.

Re: My Struggles with Rust

#82

Post by bluejekyll »

AlphaSite wrote: post #75
erickt wrote: post #65

Earlier quoted context omitted.

If I recall correctly we just couldn't come up with a great name for it. To me "expect" is a positive action, but the argument is about it failing to meet the expectation. Semantically I like `thing.unwrap_or(|| panic!("failure message"))`. It feels more like what I would want to say, but it just is so wordy. Ultimately I'm happy we just picked something and moved on, but still mildly annoys me whenever I write it. I…

The java optional api uses orElseThrow which I think is quite clear.

Agreed, I've never liked 'expect' either; 'or_else_panic(msg)' would be much clearer

Edit: 'or_panic(msg)' would be shorter and also good.

Re: My Struggles with Rust

#83

Post by AsyncAwait »

AlphaSite wrote: post #75
erickt wrote: post #65

Earlier quoted context omitted.

If I recall correctly we just couldn't come up with a great name for it. To me "expect" is a positive action, but the argument is about it failing to meet the expectation. Semantically I like `thing.unwrap_or(|| panic!("failure message"))`. It feels more like what I would want to say, but it just is so wordy. Ultimately I'm happy we just picked something and moved on, but still mildly annoys me whenever I write it. I…

The java optional api uses orElseThrow which I think is quite clear.

It is, but also quite long, which I do not think suits Rust naming conventions.

Re: My Struggles with Rust

#84

Post by Manishearth »

ajross wrote: post #39
dbattaglia wrote: post #26

I was under the impression that the (somewhat) verbose syntax for error handling and memory management via the type system was a necessary side effect of Rusts entire point of existence: a compiler-guaranteed safe systems language. Neither Python nor C force you in any way to pay attention to errors, making simple scripts much easier to write. I guess I'm just surprised people think that Rust should be as simple to u…

I think the complaint is more that Rust has seemingly tried very hard to make error handling "simple". But in the process it has managed to invent a whole series of new idioms and special syntax that is alien to pretty much everyone. There's a thread in /r/rust about this same article where you can look and see people suggesting all sorts of ways to write this that are split into clear sedimentary layers depending on…

> At this point the cognitive load required to read and understand Rust implementations of "typical" practical problems is rather higher than it is for C++.

I code in Rust and C++ every day, and am mostly equally experienced in both (maybe more Rust now, but this wasn't always the case). I disagree. Rust has some ergonomics issues that C++ does not, but the reverse is true too. Looking at rust from C++ you'll only see one and not the other, because you're used to the other.

(And as burntsushi said your characterization of the thread is inaccurate, people are suggesting things that are best for different use cases)

Rust hasn't really tried "hard" to make error handling simple. We have what we had during 1.0, and then we have the ? operator, which always existed as try!().

Re: My Struggles with Rust

#85

Post by bluejekyll »

bpicolo wrote: post #81
erickt wrote: post #31

Hello Justin Turpin! Sorry to hear your struggles with rust. It's always going to be a bit more verbose using rust than Python due to type information, but I think there are some things we could do to simplify your code. Would you be comfortable posting the 20 line code for us to review? I didn't see a link in your post. Anyway, so some things that could make your script easier: * for simple scripts I tend to use the…

4 chained function calls from config -> read a key from it is quite an ask. Though I realize there's reason for it. There are many cases I'd be happy to have panics occur for invariants. config.strictString('foo') or something of that nature seems like it could be a more ergonomic choice in cases like thise.

What he is showing is how someone who knows Rust well, would potentially approach this problem.

What you're point out is that it's a large bar to ask a new comer to the language to do this because it requires a deeper understanding of the language to use.

Is it not appropriate to show that you can reduce the complexity of a program by using other features of the language?

It's not significantly different from reducing

   x + x + x + x
To

   4x

Re: My Struggles with Rust

#86

Post by jackcviers3 »

bpicolo wrote: post #81
erickt wrote: post #31

Hello Justin Turpin! Sorry to hear your struggles with rust. It's always going to be a bit more verbose using rust than Python due to type information, but I think there are some things we could do to simplify your code. Would you be comfortable posting the 20 line code for us to review? I didn't see a link in your post. Anyway, so some things that could make your script easier: * for simple scripts I tend to use the…

4 chained function calls from config -> read a key from it is quite an ask. Though I realize there's reason for it. There are many cases I'd be happy to have panics occur for invariants. config.strictString('foo') or something of that nature seems like it could be a more ergonomic choice in cases like thise.

Each function call is a transformation on the previous argument. Whether or not you assign the results to a variable first before calling the second doesn't change the behavior of the code.

But yes, it does appear that the config library needs an extra wrapper that loads from files and returns configs (in a context) that does the common work for you.

Re: My Struggles with Rust

#87

Post by erickt »

bluejekyll wrote: post #82
AlphaSite wrote: post #75

Earlier quoted context omitted.

The java optional api uses orElseThrow which I think is quite clear.

Agreed, I've never liked 'expect' either; 'or_else_panic(msg)' would be much clearer Edit: 'or_panic(msg)' would be shorter and also good.

I think that was one of the proposed variations, but we ended up picking the shorter .expect to cut down on repetition. We expected (ha) that this function would be used in these one-offs, so we wanted something more efficient.

Re: My Struggles with Rust

#88

Post by mikebenfield »

grahn wrote: post #21
cousin_it wrote: post #13

Rust's aversion to exceptions is exactly like Go's aversion to generics - a strongly held position that doesn't actually make anyone's life easier.

The Go people don't have an aversion for generics, just a very conservative approach to adding language features. To quote their FAQ: "Generics may well be added at some point. We don't feel an urgency for them, although we understand some programmers do."[1] [1] http://golang-jp.org/doc/faq#generics

Sounds like an aversion to me. By the time Go was developed, there was no doubt in my mind that generics (or some kind of polymorphism along those lines) were an essential feature for any new statically typed programming language. The fact that Go's developers "don't feel an urgency for them" to me makes it sound like they are living in the 1980s.

Re: My Struggles with Rust

#89

Post by gaius »

dbattaglia wrote: post #26

I was under the impression that the (somewhat) verbose syntax for error handling and memory management via the type system was a necessary side effect of Rusts entire point of existence: a compiler-guaranteed safe systems language. Neither Python nor C force you in any way to pay attention to errors, making simple scripts much easier to write. I guess I'm just surprised people think that Rust should be as simple to u…

a compiler-guaranteed safe systems language

When I need that, I use OCaml.

Re: My Struggles with Rust

#90

Post by burntsushi »

mikebenfield wrote: post #88
grahn wrote: post #21

Earlier quoted context omitted.

The Go people don't have an aversion for generics, just a very conservative approach to adding language features. To quote their FAQ: "Generics may well be added at some point. We don't feel an urgency for them, although we understand some programmers do."[1] [1] http://golang-jp.org/doc/faq#generics

Sounds like an aversion to me. By the time Go was developed, there was no doubt in my mind that generics (or some kind of polymorphism along those lines) were an essential feature for any new statically typed programming language. The fact that Go's developers "don't feel an urgency for them" to me makes it sound like they are living in the 1980s.

> were an essential feature

Do you mean, "this feature is required for me to write code in that language"? Or do you mean, "this feature is required for any project in the language to flourish"?

If the former, why do you think your preferences generalize? If the latter, how do you explain the large number of successful Go projects? Are we all stuck in the 1980s? And if so, what does that even mean?

Post reply on HN