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

101–110 of 329 posts

Re: My Struggles with Rust

#101

Post by Const-me »

Inufu wrote: post #4

My main gripe with Rust so far has been the unnecessary profusion of Result types, making it hard to process and forward errors. Case in point: the example in the article from the rust documentation that converts errors to strings just to forward them: https://doc.rust-lang.org/book/error-handling.html#the-limit... In practice, I find a type like Google's util::StatusOr ( https://github.com/google/lmctfy/blob/master/…

> I've yet to encounter a case where these ~15 codes were insufficient

Insufficient on Windows.

There’re thousands error codes you can get from any Windows-provided API.

You can pack each of them into a single int32 value (using HRESULT_FROM_WIN32 macro for old-style error codes, the newer APIs already return HRESULT), but still, significantly more than 15.

Re: My Struggles with Rust

#102

Post by scriptkiddy »

dep_b wrote: post #7

The big question is would the Python script crash or handle the error when obvious problems like not valid JSON or file not found happen? My experience with Swift vs Objective-C is that clean Swift is crash free but more verbose when all other things are equal. If you don't need that level of security because it's just a small script Python was the right choice.

Depending on where it crashed, the Python script would raise an exception. It would most likely be an `IoError`, `KeyError`, or `ValueError`. Then it would show an error message with a line number, column number, and traceback. Using a debugger would allow you to step backwards through the traceback to determine if the error was caused by something further up the line or where the exception was raised.

All of Python's exceptions are an instance of `Exception`. In order to catch and handle any exception that can be raised, you can use a `try, except` block with the base `Exception` class. This, however, is bad practice as there may be some exceptions you want to ignore and, generally, you also want to print a different error message depending on which exception was raised.

Re: My Struggles with Rust

#103

Post by AsyncAwait »

nathan_f77 wrote: post #56
rvense wrote: post #3

Earlier quoted context omitted.

These struggles are indeed real, but at least as far as verbose error handling goes, remember that Rust is forcing you to handle a lot of things that are silently ignored in Python. Truly equivalent Python code would include a bunch of exception handling and checks for nil.

I haven't done much Rust, but why isn't there a safe way to do some of this implicitly? If you don't want to think about errors and just want to crash, then I feel like there should be a sane way to crash the script with a default error message. Could you write a thin abstraction to achieve this? Maybe there could be a new crate called "rust-script" or something, where the goal is to write code as easily as Python or…

There's unwrap() and panic!, does that not do what you want?

Re: My Struggles with Rust

#104

Post by eximius »

tyingq wrote: post #38
pornel wrote: post #2

These struggles are real. I don't see a way around them other than just learning them (and then they go away, because you know what code won't work, and don't fight it). It's probably because Rust looks and operates mostly like a high-level language, but still satisfies low-level constraints. e.g. the confusing difference between `&str` and `String` is equivalent of C's `const char * str = ""` vs `char * String = mal…

I don't know Rust, or the general direction of the community around it. Is there some chance, that over time, most popular functionality will end up in well architected crates that abstract away some of these complaints? A bad example, perhaps, because they probably go too far with it, but a lot of java's verbosity fades away because there's a rich ecosystem of libraries that already know how to do what you're trying…

There is currently an effort to make Rust more 'batteries included' by auditing and improving many of the most commonly used libraries (emphasizing crates outside of std).

Re: My Struggles with Rust

#105

Post by e12e »

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.

otherwise(msg)?

Re: My Struggles with Rust

#106

Post by hsivonen »

frik wrote: post #93

Rust is important, it has a great chance being a first modern native system language (memory safety). Though, I wish it has less exotic syntax. It's like C++ and Erlang had a baby. Look at modern languages with nice syntax like Go, Julia, Swift and compare it to Rust. Someone coming from C, C++, C#, Java, PHP and JavaScript has to learn a lot of new syntax twists that look uncommon and different for little reason. Su…

It continues to puzzle me when people think of Rust's syntax as particularly exotic.

It's much closer to C/Java/JavaScript than e.g. Python or Bash are. Rust still has curly braces for blocks, uses ampersand and asterisk in ways that aren't too far from C, uses dot in a way that's not too far from C or Java and uses less-than and greater-than to denote generics like C++ and Java.

Personally, what keeps tripping me up when moving between languages is either forgetting to put parentheses around "if" conditions in non-Rust languages after writing Rust or having the Rust compiler complain to me about unnecessary parentheses after writing non-Rust code.

But if new languages couldn't do things like omit unnecessary parentheses around the "if" condition or improve readability by moving the return type to come after the function name, that would seem like too big of a restriction on trying to make some syntactic progress.

Edit: Plus it makes sense to have types after the variable name when they are optional in most cases (and then to have them in the same order in function signatures for consistency).

Re: My Struggles with Rust

#107

Post by mikebenfield »

burntsushi wrote: post #90
mikebenfield wrote: post #88

Earlier quoted context omitted.

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?

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 clear about, but I feel like Go's developers are biased against anything that smells at all academic. So for instance they didn't want to implement a super fancy, cutting-edge type system. Which is somewhat understandable... but as a result they ignored 30 years of programming langauge research and implemented a primitive type system that basically provides nothing over C. I do not understand this mentality.

Re: My Struggles with Rust

#108

Post by grahn »

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.

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 have been following some of the discussions on the topic, and so far I haven't seen anything suggesting that the language developers have an aversion to it. What they do have, however, is a fear that an improperly designed generics concept could badly screw up the language in a way that can't be reversed by any practical means once it is launched.

They are basically very careful about adding stuff, without fully understanding the consequences at all levels. You (or I) can disagree with that approach, but it's not accurate to say that they have an aversion for generics, or even to say that they don't want it.

Re: My Struggles with Rust

#109

Post by bombless »

nathan_f77 wrote: post #56
rvense wrote: post #3

Earlier quoted context omitted.

These struggles are indeed real, but at least as far as verbose error handling goes, remember that Rust is forcing you to handle a lot of things that are silently ignored in Python. Truly equivalent Python code would include a bunch of exception handling and checks for nil.

I haven't done much Rust, but why isn't there a safe way to do some of this implicitly? If you don't want to think about errors and just want to crash, then I feel like there should be a sane way to crash the script with a default error message. Could you write a thin abstraction to achieve this? Maybe there could be a new crate called "rust-script" or something, where the goal is to write code as easily as Python or…

Your answer is simply `unwrap`. OP know it but struggles to believe it, it's that simply.

Re: My Struggles with Rust

#110

Post by scriptkiddy »

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've been working with nim on some toy projects recently myself. I don't think there is a lack of documentation so much as there is bad organization of the documentation. Pretty much everything in the language and it's standard library is documented somewhere. You can use the documentation index to find it.

Here are some links you may find useful if you decide to try again:

Documentation index: https://nim-lang.org/docs/theindex.html (everything)

Official Tutorial: https://nim-lang.org/docs/tut1.html

Standard library documentation: https://nim-lang.org/docs/lib.html

Language Manual: https://nim-lang.org/docs/manual.html (information on syntax, type system, GC, etc.)

Compiler user guide: https://nim-lang.org/docs/nimc.html

Backend docs: https://nim-lang.org/docs/backends.html (nim cmpiles to C, C++ and js)

Built in templating docs: https://nim-lang.org/docs/filters.html

How to tune the GC: https://nim-lang.org/docs/gc.html

Development tools docs: https://nim-lang.org/docs/tools.html

More about the compiler: https://nim-lang.org/docs/intern.html

All of these links come from nim-lang.org's documentation page here: https://nim-lang.org/documentation.html

Post reply on HN