I write both python and haskell for my day job. I think the latter has much better project management when it's paired with Nix. Even without Nix, stackage and even just dealing with Cabal is much easier than the mess in the Python ecosystem.

The stability of the Haskell ecosystem is something I just can not understand.

It's not enforced by policies, the tooling isn't much more helpful than in any other language, and it is not more mature than any widely used ecosystem. It feels like Haskell libraries just need less changes.

In my opinion it's because Haskell sits at the intersection of a lot of high power-to-weight-ratio features that let you build very robust and expressive pieces of functionality at any abstraction level. That means that libraries can easily build on each other. A lot of cool gadgets in Haskell would have to be built into Python at the language level to be usable (note the proliferation of keywords in Python..).

(I've never seriously used Haskell) I wonder if the strong static typing has something to do with that. That eliminates many if the common bugs found in Python programs.

In my experience, type errors in Python get discovered during testing. So, I doubt that's the reason.

Perhaps the nature of Haskell discourages changes, making the community more stable.

> In my experience, type errors in Python get discovered during testing

That would be the optimistic view. In reality, `NoneType has no attribute Foo` errors happen in production all the time.

Perhaps because someone got into the (bad) habit of returning Nones instead of raising errors. Errors should never pass silently, etc. The older Python APIs have that C habit of sentinel values, but more modern style is to raise an error on failure.

Functions implicitly returns None if you forget to provide a return value on any of the branches. This is an error that can easily slip past eyeball reviews, since this is caused by the absence of something.

Shouldn't unit tests be exploring all the code paths? I know that's tough to enforce, but it's ideal. Regardless of whether you use a static analyzer.

And Python does have static analyzers, including for typing.

I don't think it's strong types either. It is not about the libraries having less bugs, but about they keeping compatibility for much longer (and when they break it, they tend to break in smaller ways).

Could be because of extra flexibility those types grant you, but it's not about bugs.

Come on, you only have to take a look at the javascript ecosystem to know what I´m talking about. Tenths of bundlers, a cuple of good dependency resolvers, a myriad of test frameworks, etc... In python you are lucky if you have one of each.