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

111–120 of 329 posts

Re: My Struggles with Rust

#111

Post by p0nce »

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…

That and the bizarre thinking that ".unwrap" is a perfectly ok thing to write in some cases (don't worry it will never make it to production!).

No, ".unwrap" turns input errors into bugs, and there is no production code where this is more desirable than an exception.

Re: My Struggles with Rust

#112

Post by omginternets »

djhworld wrote: post #34

The author doesn't really justify why he needed to port the python script to rust in the first place. Pulling down some JSON, doing a bit of transformation and sending alerts seems like a perfect candidate for a high level language, I don't see any reason why you would port it to Rust unless you had significant performance concerns

>I don't see any reason why you would port it to Rust unless you had significant performance concerns

To learn Rust in a well-controlled environment?

Isn't that the usual/sane way to learn a new language? Take something trivial you understand well from language A and port it to new language B?

Note, of course, that this doesn't imply the result should be put into production.

Re: My Struggles with Rust

#113

Post by MaxGabriel »

e12e wrote: post #105
bluejekyll wrote: post #82

Earlier quoted context omitted.

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.

otherwise(msg)?

I would expect such a function to provide a default value

Re: My Struggles with Rust

#114

Post by zokier »

shadowmint wrote: post #76

It makes me sad to see the example. This is why I maintain `.unwrap()` is one of the worst things in rust. ...because people use it; and then say; 'but don't use unwrap...'; and then use it, and your 'safe' language then happily crashes and burns everytime something goes wrong. Blogs and documentation are particularly prone to it. Result and option types are good; but if you're gonna have unwrap, you basically have t…

> ... because people use it; and then say; 'but don't use unwrap...'; and then use it, and your 'safe' language then happily crashes and burns everytime something goes wrong

It might crash, but it doesn't burn, which is kinda the point of panic. Its behavior is well defined and predictable, which is great improvement over typical C UB.

Re: My Struggles with Rust

#115

Post by e12e »

chillingeffect wrote: post #55
tinco wrote: post #5

Being able to port a 20 line Python script to a 20 line Rust is the holy grail. Surely Rust has the ambition to one day achieve that, but it is by no means the main priority nor the original design goal of the language. Justin criticizes the file_double function, it being complex with nested maps and conditionals. All of this complexity is also in the Python code, just hidden away in abstractions, the library and the…

Rust hasn't made significant incursions into math modelling or industrial processing. It's advantages are slim there. Embedded will fracture into network interfacing and realtime where user input is less hostile, more predictable and doesn't require extensive constraint.

Isn't it this kind of thinking that leads to sql injections in number plate readers?

Re: My Struggles with Rust

#116

Post by bombless »

shadowmint wrote: post #76

It makes me sad to see the example. This is why I maintain `.unwrap()` is one of the worst things in rust. ...because people use it; and then say; 'but don't use unwrap...'; and then use it, and your 'safe' language then happily crashes and burns everytime something goes wrong. Blogs and documentation are particularly prone to it. Result and option types are good; but if you're gonna have unwrap, you basically have t…

Well if people say "don't use unwrap", they're simply wrong.

Re: My Struggles with Rust

#117

Post by burntsushi »

mikebenfield wrote: post #107
burntsushi wrote: post #90

Earlier quoted context omitted.

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

Well, at the time I would have thought it was required for the language to become widely used. But since that's clearly not true I suppose I have to downgrade that statement to say it's required for me to write code in the langauge and not feel like I'm constantly banging my head against a wall. Frankly, yeah, I think Go programmers are kind of stuck in the 1980s in some respects. This isn't something I'm completely…

I've used both Rust and Go daily for years (before they reached 1.0, respectively) and I'm generally happen with the experience that they give me. Not all languages need to have a type system as sophisticated as Rust's or Haskell's.

> but as a result they ignored 30 years of programming langauge research and implemented a primitive type system that basically provides nothing over C

As someone who also has a decent amount of C experience, I don't see how this is a reasonable conclusion to make. The first point in favor of Go is that it's mostly memory safe (sans data races), which is achieved not just with bounds checks, but with a stronger type system. The second point in favor of Go is that Go does have a limited form of polymorphism that is checked by the compiler. In C, the only way you get polymorphism is by subverting the type system entirely. Both of those points are huge, and there's undoubtedly a much longer list that I could craft of smaller benefits if I were so inclined.

As we march toward complex type systems that move more runtime errors to compile time, we must also be vigilant of the trade offs we're making. Moving things from runtime to compile time isn't necessarily free; there's almost always some new cognitive load that is implied. It's important because if that cognitive load is "too high," then people aren't going to switch to it, and no amount of navel gazing is going to fix that. This entire thread is a perfect demonstration of that trade off in action. On the one hand, we have the "clearly superior" Rust approach to error handling that checks a lot more at compile time than Go does, but on the other hand, Go programmers don't ever need to "learn error handling" at all. They have a simple convention with a reasonably low bug rate (IME, anyway).

We can't just judge programming languages by their theoretical strengths. We must also judge them by their practical strengths. And then we must do the impossible: balance them. Snubbing our collective noses isn't going to do any good. Our only hope is to understand why people are attracted to languages like Go (such as myself) and figure out how to reduce the aforementioned cognitive load without giving up those sweet sweet compile time checks. Rust is clearly pushing that boundary, and I'm happier for it.

Re: My Struggles with Rust

#118

Post by Recursing »

mikebenfield wrote: post #91
liveoneggs wrote: post #35

Isn't nim built for pythonists to do just this sort of thing?

I think Nim may be the most underdocumented project I've ever used. I spent a week or so with it, but quickly grew extremely frustrated as I was constantly scouring old forum posts to learn how to use the basic features of the language. That is not a tolerable situation for me.

I think the idea has great potential, but the absence of a strong community is killing it :(

Re: My Struggles with Rust

#119

Post by specialist »

kstenerud wrote: post #71
Sharlin wrote: post #44

Earlier quoted context omitted.

There are many ways to have both enforced error handling AND less boilerplate. Java's checked exceptions are much maligned but would work very well here. Another way would be having more syntactic sugar for Result-style monadic error handling, like the do notation in Haskell or for..yield in Scala. Another issue raised by the original post is the fact that Rust has no top-level concrete error type that is convertible…

Java's checked exceptions were a disaster. It essentially handcuffed you, limiting what you could do in an overridden method (because you can't add more exceptions to the throws list). So you end up wrapping in RuntimeExceptions and then later having the whole app fall over because the framework that's expecting your class was only designed to handle the checked exceptions. So yeah, want your implementation to consul…

Checked exceptions are the correct answer. Just handle it.

Exception obfuscation frameworks (Spring) just kick the can down the road, creating problems without any discernible benefit.

Re: My Struggles with Rust

#120

Post by plinkplonk »

tinco wrote: post #5

Being able to port a 20 line Python script to a 20 line Rust is the holy grail. Surely Rust has the ambition to one day achieve that, but it is by no means the main priority nor the original design goal of the language. Justin criticizes the file_double function, it being complex with nested maps and conditionals. All of this complexity is also in the Python code, just hidden away in abstractions, the library and the…

".. soon its community will make good implementations of almost every hard problem in software and Rust will be absolutely everywhere"

This is very unlikely. I can't see when Rust would solve the problems Julia (for example) does. And vice versa of course.

Nothing wrong in a language tackling a few domains really really well and not trying to solve "every hard problem in software"

Post reply on HN