Our great sponsors
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
> I think library authors should be more relentless and break compatibility every few years. We just need some conventions to not do so very often.
I indeed did this years ago---I'm the original author of Chrono [1]---and it wasn't well received [2] [3] [4]. To be fair, I knew it was a clear violation of semantic versioning but I didn't see any point of obeying that until we've reached 1.0 so I went ahead. People complained a lot and I had to yank the problematic release. By then I realized many enough people religiously expect semantic versioning (for good reasons though) and it's wiser to avoid useless conflict.
[1] https://github.com/chronotope/chrono
[2] https://github.com/chronotope/chrono/issues/146#issuecomment...
[3] https://github.com/chronotope/chrono/issues/156
[4] https://github.com/chronotope/chrono/blob/main/CHANGELOG.md#...
I regularly hear that the tooling of Python is bad, but we've had Poetry for a while now and it just works.
Unfortunately, I'm not experienced in Rust so I cannot really compare it to cargo. However, Poetry does everything I would expect from dependency management and packaging/publishing and I've never had problems with it.
Also, there is ruff [2] (ironically written in Rust) and mypy [3] (they recently left 0ver!) for static analysis, black for code formatting (I really miss an opinionated formatter like this in other languages), etc. They also work just fine. Python tooling doesn't seem bad to me.
[1] https://python-poetry.org/