Earlier quoted context omitted.
Yes, that's why. When ? Can be used in main, we will switch to that en mass.
Which RFC is this?
My Struggles with Rust
301–310 of 329 posts
Re: My Struggles with Rust
#302Earlier quoted context omitted.
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…
> 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). Since you brought this up, the one thing that really (but irrationally!) winds me up about Rust's syntax is that variables are: let foo: Bar = ... ; And functions are: fn foo() -> Bar { ... } Why not use a colon for the return type of…
"returns" and "is of type" are different concepts, so having different syntax for them makes sense.
- In your first example, foo is of type "Bar"
- In your second, foo is of type "function that returns Bar".
ie, if you stored your foos in separate variables they would be:
let my_var: Bar = ...
let my_function: fn() -> Bar = ...
Re: My Struggles with Rust
#303Earlier quoted context omitted.
> 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 gazin…
C is one of those things that hasn't meaningfully changed in decades now. So yes, technically it is a mainstream language without generics (and many other things) - but I don't think that's a viable role model. The only reason why C is what it is, is because of all the legacy code written in it.
Who said anything about C being a role model? I think your chosen language is somewhat misleading, so it's worth pointing out.
Re: My Struggles with Rust
#304Earlier quoted context omitted.
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.
I'm aware of how Result works, I've written a little Rust. I was wondering how Rust libraries specifically deal with non-fatal error handling in parts of the library that are abstracted away from the library consumer, such as my example of a GUI library that has retry behavior that is not exposed to the user.
Is there currently a convention for dealing with such "encapsulated but interesting" errors occuring in Rust libraries?
It seems obvious to me that a web framework would have a logging hook but non-obvious how that API would function; would it call a logging callback with a severity and a string? Just a string? Or an error message and some kind of "related data" (such as a stack trace or relevant structs) container?
It doesn't seem obvious to me to log only text in the context of a GUI library. I'm thinking of building a native cross-platform GUI library in Rust (borrowing concepts from IUP[0] but adding more typing) and I feel like there would be value in having structured data as part of the nonfatal error interface, so I'm curious if there are existing patterns to learn from.
Re: My Struggles with Rust
#305Earlier quoted context omitted.
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.
I'm aware of how Result works, I've written a little Rust. I was wondering how Rust libraries specifically deal with non-fatal error handling in parts of the library that are abstracted away from the library consumer, such as my example of a GUI library that has retry behavior that is not exposed to the user. Is there currently a convention for dealing with such "encapsulated but interesting" errors occuring in Rust…
Ah, I see.
For logging, the `log` crate[1] provides the interface that libraries can use, which defines macros for each log level.
For partial success/failure, I actually don't think there is much convention. On the one hand, you might consider logging as sufficient enough, depending on your use case. In some cases, I have adopted a form of partial errors. That is, instead of:
fn foobar() -> Result { ... }
fn foobar() -> (Value, Option) { ... }
Since this isn't something people need too often, the syntactic overhead of this approach is considerably clunkier, so I definitely wouldn't want this to be a pervasive part of a library. Nevertheless, if you can get both a success value and an error value, then your return type is inherently a product, not a sum, which is at odds with the `Result` sum.
Re: My Struggles with Rust
#306Earlier quoted context omitted.
> I didnt say it was unsafe, I said it crashes. Your phrasing implied that you said the crash was not safe, as you put "unsafe" in quotes and contrasted it with the crash. At least, that's what I understood you to be saying too.
meh. I feel like any time someone mentions the word 'safe' regardless of context, the rust safety pedants roll out of the woodwork to dispute to dispute any minute detail of what's been said, regardless of if its relevant to the discussion at hand. I shouldn't have put 'safe' in the comment at all, what a waste of a thread. My point had nothing to do with safety; it was purely that having given advice being to write…
In the context of this article and discussion, panics via unwrap (or better, expect) is a fine answer, and I'm not sure why you think it is hypocritical to suggest it, especially to Rust newcomers who are looking to write script-like programs.
Panics mostly match the verbosity, ergonomics, and functionality of the analogous python script.
Now I agree that a caveat should follow advice like using unwrap and expect, perhaps a small blurb about how they should eschewed for better error handling when you want to catch the errors and make decisions because of them (especially when writing libraries) but that's quite a bit short of hypocritical to me.
Re: My Struggles with Rust
#307Earlier quoted context omitted.
If you don't mind me asking, what in particular were you searching for? I agree that Nim's documentation needs a lot of love but would like suggestions on what specifically you had trouble with so that I can at least improve that (for now) :)
Unfortunately I can't remember the details at this point. There was something I couldn't figure out with the `new` function and heap allocation in general, and I also got frustrated trying to understand some things about the type system. I do know one thing about `new` was that it took me forever to figure out how to allocate anything on the heap at all, only to find a couple lines about `new` in the API docs. At lea…
No worries, thank you for replying :)
Re: My Struggles with Rust
#308Earlier quoted context omitted.
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 diffe…
If it is something that OCaml, Haskell and Lisp are not lacking, it is books written about them. We can argue on technical points. But the existence of documentation is a non-issue for all of these languages.
https://ocaml.org/learn/books.html
https://wiki.haskell.org/Books
It could well be, that these books are written for experienced programmers who don't need basic concepts (control flow, object orientation, etc.) explained. But that was not the point.
The absence of an easy road for these langauges is because they need to teach some powerful abstractions first that have no equivalence in Python, Java or C.
Re: My Struggles with Rust
#309Earlier quoted context omitted.
Which is why people cannot just state "In C++ the thing X happens" without regarding what the standard says, instead of what the installed compiler does. Language != Implementation. If the language would be "In GCC the thing X happens when ...", then ok.
For all practical purposes, the most popular implementations are the language. You can only ignore that in an academic context.
Popular where? Not everyone uses GCC.
Re: My Struggles with Rust
#310Earlier quoted context omitted.
meh. I feel like any time someone mentions the word 'safe' regardless of context, the rust safety pedants roll out of the woodwork to dispute to dispute any minute detail of what's been said, regardless of if its relevant to the discussion at hand. I shouldn't have put 'safe' in the comment at all, what a waste of a thread. My point had nothing to do with safety; it was purely that having given advice being to write…
In the context of this article and discussion, panics via unwrap (or better, expect) is a fine answer, and I'm not sure why you think it is hypocritical to suggest it, especially to Rust newcomers who are looking to write script-like programs. Panics mostly match the verbosity, ergonomics, and functionality of the analogous python script. Now I agree that a caveat should follow advice like using unwrap and expect, pe…
> a caveat should follow advice like using unwrap and expect, perhaps a small blurb about how they should eschewed for better error handling when you want to catch the errors and make decisions because of them.
That is literally the definition of hypocrisy; the behavior of people who do things that they tell other people not to do.
"When you do this, do it like this, but properly with error handling." :P
Anyhow, as I said its my oppinion that unwrap() is lazy, and `?`, `expect` and `assert!` cover the same functionality in more explicit and meaningful way.
You're welcome to your own opinion.