Python's stdlib is leaky, Go's is great, Rust's is stuck
Better Batteries
A programmer argues the standard library debate should focus on social architecture, not size. Python's uneven stdlib still enabled the data science revolution, Go's team delivers well-designed APIs, while Rust's capacity for design decisions is limited, leaving gaps like OS randomness unresolved.
The problem with Python’s stdlib is its, ahem, uneven quality.
- exceptione
`Included batteries` and type safety are not the only but imho surely the most important criteria for software projects (I am excluding throw-away code and scripts). The article raises an important point but fails to teach the reader about the JVM ecosystem and the .net core ecosystem. The standard libraries of these two zoo's of programming languages vastly eclipse what the discussed languages offer (Go, Python and Rust).
For example, this is asp.net core: <https://learn.microsoft.com/en-us/aspnet/core/?view=aspnetco...>. This is the std lib: <https://learn.microsoft.com/en-us/dotnet/api/?view=net-10.0>. This is EF core: <https://learn.microsoft.com/en-us/ef/core/>.
There are many more (optional) technologies coming built-in. Your code will typically depend for 98% on official, trusted and vetted code. It might sound like hyperbole but it's reasonable to state that JVM and .net core have no competition if you select for these aspects.
I know, programming languages and religion... So do whatever you want with this information.
- nicoburns
Currently we generally have a trade-off between:
- The standard library, which is both trusted/blessed and perma-stable
- A package ecosystem which is neither
I would love to see more exploration of the space in between:
- An extended stdlib which ships versioned libraries which use semver rather than being perma-stable.
- Better support for managing verification and assurance of package ecosystems.
- noelwelsh
I think Unison has the most interesting take here: https://www.unison-lang.org/docs/the-big-idea/
If you look at any language that has been around a while, with Java being a great example, you'll see many libraries that use an outdated coding style. Compare the different date/time libraries in Java, for example. Evolving these is always a problem, which I think Unison addresses in a way that lets the language evolve without having to carry too much baggage forward, while still not breaking others' code.