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

271–280 of 329 posts

Re: My Struggles with Rust

#271

Post by derefr »

p0nce wrote: post #254
kibwen wrote: post #170

Earlier quoted context omitted.

Er, it was a response to this line of yours: > Absolutely but using the same mechanism (unwrap/panic) for both types of errors - recoverable and recoverable Nobody is using panics with the intent to recover, in the classic sense of "recoverable error".

See above where one user is using .unwrap for parsing errors (input errors are recoverable).

I think this discussion is muddying the meanings of "recoverable" between "recoverable as a class" and "recoverable in this instance."

Parsing errors are recoverable as a class—you haven't irretrievably corrupted your process memory when you encounter one. Therefore, the parser itself should not panic(); it should just return an option type.

Parsing errors may very well be unrecoverable in a particular instance. The code calling the parser has every right to decide to unwrap() the option type such that a panic() will happen if the parse failed. The code calling the parser is likely business-logic code of an application, and is privy to knowledge like "if there is no configuration supplied here, then later code that tries to consume the configuration will have to crash" and so can decide to early-exit with a user-comprehensible error ("you don't have a config file!") rather than letting the later code crash with some weird error about a config value being Nothing.

Re: My Struggles with Rust

#272

Post by resf »

twic wrote: post #161
p0nce wrote: post #111

Earlier quoted context omitted.

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.

I don't get it. .unwrap() turns an undesirable situation into printing an error message and exiting with a nonzero status. There are plenty of situations where that is exactly what you want, and not a bug at all. For example, in my production Rust code, i deal with all errors in reading and parsing config files with .unwrap() or .expect(). If a program cannot read its config file at startup, it cannot correctly do it…

Prints to where? stderr? Fine for a simple CLI tool, but people might want to do something more complicated when an "unrecoverable" exception occurs.

Take for instance a web framework like Django that responds with a 500 error page with a stack trace when an exception occurs.

There are interesting problems to be solved in the space of error handling, e.g. error handling in asynchronous code. But Rust is not even matching the state of the art achieved by Lisp and Python decades ago.

Re: My Struggles with Rust

#273

Post by jackmott »

dkarapetyan wrote: post #159
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…

Too much kool-aid. Most programmers are not writing system code and they'd be much better served with languages like Go, Nim, and D. In fact, the example the author is trying to port over would have been much easier in Nim. The actual question is then about the author learning a new paradigm and way of expressing system code. If that is the case these are just pains he has to go through because Rust will never be lik…

can nim handle gc across threads yet?

Re: My Struggles with Rust

#274

Post by grahn »

int_19h wrote: post #259
grahn wrote: post #108

Earlier quoted context omitted.

But Go does have polymorphism. It is achieved through the "interface" concept, which allows dynamic binding of any statically typed objects that match a given set of function signatures. In my experience, with the way it's been done it actually gets you pretty far in terms of problems you typically solve with generics in other languages. That said, personally I'd love to have generics on top of that. Consequently, I…

It is exactly the same kind of polymorphism that languages like Java and C# had before they adopted generics. In practice, what this means is that you have downcasts all over the place, which is tedious, non-typesafe, and is why both C# and Java have generics now. The fact is that Go is the only statically typed language, with any claim to being mainstream, that doesn't have generics. And it's not like generics are s…

If you want to understand the reasonings the Go maintainers have about generics, there is a GitHub issue[1] on it that is probably a better place to start than to argue with me. The thread references both recent academic research as well as other programming languages' take on the subject.

I don't think their crux is so much that generics "as such" needs more baking, but the specifics of how to implement them with the Go language. Mind you that some of the core goals of Go is to be simple, easy to parse, fast to compile, support good tooling, etc. so the question they're battling with is how to add generics to that mix without sacrificing any of those goals, and without making some mistake you can never go back from once every code base out there starts depending on it.

Now, by all means, we can argue that those priorities are wrong, or that yours would have been different. But I think it is disingenuous to suggest that they are effectively idiots who don't understand how to apply basic concepts, or are unaware of other programming languages.

[1] https://github.com/golang/go/issues/15292

Re: My Struggles with Rust

#275

Post by edmccard »

eriknstr wrote: post #57
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…

While it's too late to change the name "expect", could one create an alias for it and call it say, "on_error"?

In my Rust crates, I use a custom trait[1], with implementations for Option and Result, that provides an expected() method which, if it panics, prefixes the message with "expected: ". So you can write

  foo().pop().expected("foo length >= 1");
and if it fails, the error is something like "panicked at 'expected foo length >= 1'".

[1]https://gist.github.com/edmccard/8898dd397eec0ff3595c28ada52...

Re: My Struggles with Rust

#276

Post by quicknir »

vbezhenar wrote: post #24
jimktrains2 wrote: post #18

Earlier quoted context omitted.

I find result types to be much easier to understand and work with than exceptions. Result types can be handled by the type system, even when you have checked exceptions in java, there are still exceptions that aren't checked, and the syntax for the checking becomes monstrous.

Implicit return codes (e.g. return int, -1 means error, 0+ means OK) are equivalent to unchecked exceptions. Explicit return codes, where you must process them or compiler will yell at you are equivalent to checked exceptions. I think, that checked exceptions are a good idea, but they must be improved. E.g. Rust have syntax for almost implicit converting one error to another and return it; checked exceptions could us…

That equivalence is false. An unhandled exception bubbles up. An unhandled return code is ignored. This was exactly one of the biggest arguments against return codes.

Re: My Struggles with Rust

#277

Post by photojosh »

cupcakestand wrote: post #151
kstenerud wrote: post #122

One thing I've found with rust is that you struggle struggle struggle trying to do a simple task, and then finally someone says "Oh, all you need to do is this". Rust has already reached the point where it leaves the world behind. Only the people who have been there since the early days really understand it, and getting into rust gets harder and harder as time goes on. Yes, there's some awesome documentation, and the…

> Rust has already reached the point where it leaves the world behind. Only the people who have been there since the early days really understand it This was my feeling when I got into Ruby on Rails (years too late).

I got into Python/Django seriously in 2013, which is a fair way along in their history, and have loved it ever since. Now even doing async & websockets stuff using django-channels after thinking that would never be possible.

Wonder why the difference?

Re: My Struggles with Rust

#278

Post by throwaway7645 »

jpfr wrote: post #243
kstenerud wrote: post #122

One thing I've found with rust is that you struggle struggle struggle trying to do a simple task, and then finally someone says "Oh, all you need to do is this". Rust has already reached the point where it leaves the world behind. Only the people who have been there since the early days really understand it, and getting into rust gets harder and harder as time goes on. Yes, there's some awesome documentation, and the…

These are the exact same complaints of students learning to program for the first time. Have you tried functional programmng? Lisp? Ocaml? The complaints of newbie functional programmers are also nearly the same. The "struggle" is necessary. If there is no struggle, there is no learning of fundamentally new approaches you are not yet comfortable with. See it as part of the training regimen that lets people emerge as…

No, the training material for something like Python is orders of magnitude easier to get into than things like OCaml, Haskell, and Lisp. Python has doc and many many books taking you from A through Z. Many of these other languages have "A" and then pick back up at "S", but skip over "B"-"R". You basically get a feel for syntax, control flow, and a few other topics, but don't get the meat of why that language is different. Not everyone wants to learn by digging into open source projects.

Re: My Struggles with Rust

#279

Post by burntsushi »

cryptarch wrote: post #262
_pmf_ wrote: post #222

Earlier quoted context omitted.

> fail silently No. They are usually logged. The difference is that with exceptions, the logging will occur at a higher level and be done uniformly while in Rust you'll have to explicitly thread the error through the call stack manually to log it at a higher level.

On that point, does that mean Rust libraries tend to have logging hooks or are all errors emitted by Result's? What about non-fatal errors such as retries in a GUI library that loads an image from the web, how are they logged or otherwise propogated to the developer?

Errors in Rust are just normal values, so there's nothing special you have to do. You just write your retry logic, presumably after inspecting the kind of error that occurred.

Re: My Struggles with Rust

#280

Post by burntsushi »

int_19h wrote: post #259
grahn wrote: post #108

Earlier quoted context omitted.

But Go does have polymorphism. It is achieved through the "interface" concept, which allows dynamic binding of any statically typed objects that match a given set of function signatures. In my experience, with the way it's been done it actually gets you pretty far in terms of problems you typically solve with generics in other languages. That said, personally I'd love to have generics on top of that. Consequently, I…

It is exactly the same kind of polymorphism that languages like Java and C# had before they adopted generics. In practice, what this means is that you have downcasts all over the place, which is tedious, non-typesafe, and is why both C# and Java have generics now. The fact is that Go is the only statically typed language, with any claim to being mainstream, that doesn't have generics. And it's not like generics are s…

> It is exactly the same kind of polymorphism that languages like Java and C# had before they adopted generics.

That's false. Go provides a smattering of blessed polymorphic types (slices, maps, chans, pointers) and functions (len, append, delete, chan send, chan recv) that go a long way. They are horrifying to civilized PL enthusiasts, but they cover a lot ground.

As I said in one of my sibling comments, navel gazing isn't going to get you anywhere. And Go isn't the only statically typed language without generics. C has that designation as well.

Post reply on HN