logoalt Hacker News

tasnyesterday at 8:24 PM3 repliesview on HN

These are two sides of the same coin. Go has its quirks because they put things in the standard library so they can't iterate (in breaking manners), while Rust can iterate and improve ideas much faster as it's driven by the ecosystem.

Edit: changed "perfect" to "improve", as I meant "perfect" as "betterment" not in terms of absolute perfection.


Replies

aatd86yesterday at 9:01 PM

There is a moral hazard here. By accepting that APIs are forever, you tend to be more cautious and move toward getting it right the first time. Slower is better... And also faster in the long run, as things compose. Personally, I do believe that there is one best way to do things quite often, but time constraints make people settle.

At least it is my experience building some systems.

Not sure it is always a good calculus to defer the hard thinking to later.

JetSetIllyyesterday at 10:55 PM

The golang.org/x/ namespace is the other half of the standard library in all but name. That gets iterated often.

For stuff in the standard library proper, the versioning system is working well for it. For example, the json library is now at v2. Code relying on the original json API can still be compiled.

incrudibleyesterday at 8:41 PM

The cost of "perfecting" an idea here is ruining the broader ecosystem. It is much much better for an API to be kinda crappy (but stable) for historical reasons than dealing with the constant churn and fragmentation caused by, for example, the fifth revision of that URL routing library that everyone uses because everyone uses it. It only gets worse by the orthogonal but comorbid attitude of radically minimizing the scope of dependencies.

show 3 replies