alt Hacker News> so if the API is bad, you're pretty screwed.
Is this really that big a downside? It encourages good APIs.
The alternative of everything being public is the kind of feature that quickly becomes a big disadvantage in larger systems and teams, where saying “just don’t footgun yourself” is not a viable strategy. If there’s a workaround to achieve some goal, people will use it, and you end up with an unmaintainable mess. It’s why languages whose names start with C feature so prominently on CVE lists.
Replies
There are always corner cases where you might need to do something differently. I had three memorable cases in my career: 1. Python 2.6x had a a stdlib bug where windows event logging did crash the process when the user had some rights set differently. Fix submitted but for the meantime we simply overwrote the private function and could ship. 2. Also python: scikit-learn had a primitive "print everything" strategy, but we need to get it into a logging framework. We overwrote their print wrapper and could ship. 3. In C#, a third party lib insisted on dumping a result to a file. We used reflection to get that as a stream.
All three are not ideal - but I think having escape hatches is important. I also think private/public is overrated. Having it as a signal is ok. Forbidding access to privates is too strong.
Because no one has ever deliberately used the wrong tool for business reasons. Or thought they had a perfectly reasonable argument.
It's better to have escape hatches for in case you need them, but anyone who feels that way probably isn't using Rust to start with.
Maybe that's a bit harsh. I'm sure there are some problem domains where the other trait is desirable, but IMO it's not generic systems programming.
The problem is it only takes one bad or incomplete API needed for your specific use case. I ran into this a lot when I used cpal. For example, the data stream enum type (i16, u8, f32, etc) didn't have Hash or Eq derived, so I had to create a wrapper class for the data stream type. But, the type was marked non exhaustive, so I wouldn't be able to tell if my wrapper would get out of sync with theirs. It was a pain to work around.
In other cases, I couldn't work around, so I had to vendor some things. I ended up implementing my own graph library, because the existing one wouldn't let me reach into change some invariants for undo/redo. Which I mean, fair enough if that's what's needed, but it's a real pain to reimplement something because the API was incomplete. And of course, now if something from another library needs petgraph, I'd have to convert my graph to its graph.
So yes, in theory, if we had great APIs this wouldn't be a problem. Unfortunately, APIs are always a work in progress, and sometimes need escape hatches in order to send values between libraries.