Hacker News new | past | comments | ask | show | jobs | submit login

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.




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?




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: