@zetalyrae, given you implemented Austral in OCaml I'd really like to know what you think about Rust vs. OCaml ;-)
Two Years of Rust
61–69 of 69 posts
Re: Two Years of Rust
#62Earlier quoted context omitted.
>I agree, but that's kind of my point - that's all these Rust praise articles are ever showing :). Then they are completely misrepresenting what error handling is about. Rusts error handling is good because programs only crash where you allow them to crash. If you are using the error handling correctly, you only crash wherever there is an error you believe should be unrecoverable. >Not comparing to other languages/ap…
> Then they are completely misrepresenting what error handling is about That's fine, but the commenter didn't pull this out of nowhere. It's in the article. Your reply makes it sound like you didn't read it, as if OP is giving a rare hypothetical that most Rust programmers don't support. This is common error handling advice in the Rust community. And this is representative of what you may run into when reading other…
I do not think you understood the conversation as I did.
Rusts error handling works by defining potential crashes with unwraps. A program never crashes unexpectedly there, as this is where you expect it to crash. The general pattern is fine and widely used, the other commenter did not understand that this kind of behavior results from unwrapping where you really do not want to unwrap.
Re: Two Years of Rust
#63Earlier quoted context omitted.
It's a surprising choice that Rust made to have the unit of compilation and unit of distribution coincide. I say surprising, because one of the tacit design principles I've seen and really appreciated in Rust is the disaggregation of orthogonal features. For example, classical object-oriented programming uses classes both as an encapsulation boundary (where invariants are maintained and information is hidden) and a d…
The history here is very interesting, Rust went through a bunch of design iteration early, and then it just kinda sat around for a long time, and then made other choices that made modifying earlier choices harder. And then we did manage to have some significant change (for the good) in Rust 2018. Rust's users find the module system even more difficult than the borrow checker. I've tried to figure out why, and figure…
Sorry if my comment wasn't clear: I'm saying that I think in both the module and trait object case, Rust has done a good job of cleanly separating features, unlike in classic (Java or C++) style OOP.
I'm surprised the module system creates controversy. It's a bit confusing to get one's head around at first, especially when traits are involved, but the visibility rules make a ton of sense. It quite cleanly solves the problem of how submodules should interact with visibility. I've started using the Rust conventions in my Python projects.
I have only two criticisms:
First, the ergonomics aren't quite there when you do want an object-oriented approach (a "module-struct"), which is maybe the more common usecase. However, I don't know if this is a solvable design problem, so I prefer the tradeoff Rust made.
Second, and perhaps a weaker criticism, the pub visibility qualifiers like pub(crate) seems extraneous when re-exports like pub use exist. I appreciate maybe these are necessary for ergonomics, but it does complicate the design.
There is one other piece of historical Rust design I am curious about, which is the choice to include stack unwinding in thread panics. It seems at odds with the systems programming principle usecase for Rust. But I don't understand the design problem well enough to have an opinion.
Re: Two Years of Rust
#64Earlier quoted context omitted.
> Then they are completely misrepresenting what error handling is about That's fine, but the commenter didn't pull this out of nowhere. It's in the article. Your reply makes it sound like you didn't read it, as if OP is giving a rare hypothetical that most Rust programmers don't support. This is common error handling advice in the Rust community. And this is representative of what you may run into when reading other…
I do not think you understood the conversation as I did. Rusts error handling works by defining potential crashes with unwraps. A program never crashes unexpectedly there, as this is where you expect it to crash. The general pattern is fine and widely used, the other commenter did not understand that this kind of behavior results from unwrapping where you really do not want to unwrap.
> the other commenter did not understand [...]
That's not the case, I understand the issue at hand quite well. Please don't do this.
I didn't reply to your other comment because this conversation isn't/wasn't going anywhere.
Re: Two Years of Rust
#65Earlier quoted context omitted.
I do not think you understood the conversation as I did. Rusts error handling works by defining potential crashes with unwraps. A program never crashes unexpectedly there, as this is where you expect it to crash. The general pattern is fine and widely used, the other commenter did not understand that this kind of behavior results from unwrapping where you really do not want to unwrap.
> the other commenter did not understand [...] That's not the case, I understand the issue at hand quite well. Please don't do this. I didn't reply to your other comment because this conversation isn't/wasn't going anywhere.
Oh, I presumed you didn't because, even when I asked you, you didn't point out why you disliked it, what you would improve or how it compared to alternatives.
Re: Two Years of Rust
#66Earlier quoted context omitted.
The history here is very interesting, Rust went through a bunch of design iteration early, and then it just kinda sat around for a long time, and then made other choices that made modifying earlier choices harder. And then we did manage to have some significant change (for the good) in Rust 2018. Rust's users find the module system even more difficult than the borrow checker. I've tried to figure out why, and figure…
Sorry if my comment wasn't clear: I'm saying that I think in both the module and trait object case, Rust has done a good job of cleanly separating features, unlike in classic (Java or C++) style OOP. I'm surprised the module system creates controversy. It's a bit confusing to get one's head around at first, especially when traits are involved, but the visibility rules make a ton of sense. It quite cleanly solves the…
Ah, yeah I slightly misunderstood, no worries :)
> the pub visibility qualifiers like pub(crate) seems extraneous
I feel this way too, but some people seem to use them.
> which is the choice to include stack unwinding in thread panics. It seems at odds with the systems programming principle usecase for Rust.
In what way?
Re: Two Years of Rust
#67Earlier quoted context omitted.
The history here is very interesting, Rust went through a bunch of design iteration early, and then it just kinda sat around for a long time, and then made other choices that made modifying earlier choices harder. And then we did manage to have some significant change (for the good) in Rust 2018. Rust's users find the module system even more difficult than the borrow checker. I've tried to figure out why, and figure…
> Rust's users find the module system even more difficult than the borrow checker. I've tried to figure out why, and figure out how to explain it better, for years now. The module system in Rust is conceptually huge, and I feel it needs a 'Rust modules: the good parts' resource to guide people. (1) There are five different ways to use `pub`. That's pretty overwhelming, and in practice I almost never see `pub(in foo)`…
Full agree with 1, I do use 2 depending (if I'm making a tree of modules for organization, and a module only contains imports of other modules, I'll use the curly brace form to save the need of making a file), and I'm not sure why 4 makes it harder? Wouldn't it be more confusing if order mattered? maybe I need to see a full example :)
Thank you!
Re: Two Years of Rust
#68Earlier quoted context omitted.
I really wish there was more of a discussion on Nim.
I've never looked closely at Nim because I think I don't need another fast GC language in addition to Go. What's your pitch for someone like me?
Go is too verbose for my taste. Nim can be pretty concise while staying readable. One feature I love in Nim and miss most when using other languages is templates - it reduces a lot of boilerplate.
Also, type system is very nice, probably one of the best amongst non-functional programming languages. Overloading, generics, type inference, distinct type aliases, first-class functions, subranges, etc. etc.
I've seen Go have praise over not supporting OOP. Nim got some of it too =D. No classes, only structs and functions. In fact every operator is a function and you can overload them for custom types. OOP is still possible, but it's harder to make inheritance monster with factory factory factories.
Nim gives you power, just remember that with power comes responsibility.
This is my pitch for Nim language.
Re: Two Years of Rust
#69Earlier quoted context omitted.
> Rust's users find the module system even more difficult than the borrow checker. I've tried to figure out why, and figure out how to explain it better, for years now. The module system in Rust is conceptually huge, and I feel it needs a 'Rust modules: the good parts' resource to guide people. (1) There are five different ways to use `pub`. That's pretty overwhelming, and in practice I almost never see `pub(in foo)`…
Full agree with 1, I do use 2 depending (if I'm making a tree of modules for organization, and a module only contains imports of other modules, I'll use the curly brace form to save the need of making a file), and I'm not sure why 4 makes it harder? Wouldn't it be more confusing if order mattered? maybe I need to see a full example :) Thank you!
In `use foo::bar; use bar::foo;`, am I importing an external crate called foo that has a submodule bar::foo, or vice versa?
This bit me when trying to write a static analysis tool for Rust that finds missing imports: you essentially need to loop over imports repeatedly until you reach a fixpoint. Maybe it bites users rarely in practice.