Better Batteries
matklad.github.io
Better Batteries
1–10 of 26 posts
Re: Better Batteries
#2I was fully expecting a comparison of recent battery chemistries, and forgot the "batteries included" saying being used for programming.
As someone who doesn't use the mentioned languages often, it's surprising to hear that Python's stdlib is inconsistent given how old it is / how much work has probably gone into it.
Re: Better Batteries
#3Currently 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.
Re: Better Batteries
#4> it seems that the reason for Rust not having an API to get a stream of random bytes from the OS
This is already in nightly[1]. I don't see what "getting money in peoples pockets" has to do with its stabilization.
[1]: https://doc.rust-lang.org/std/random/trait.Rng.html#tymethod...
Re: Better Batteries
#5Yes! I've never been against languages with batteries included. In fact nowadays I prefer them. It's one of my biggest issues with Rust, but the problem also exists in Haskell. Funnily enough, in Node.js, which gave birth to npm, you can now do many stuff without external dependencies (last one I've seen are the sqlite functions).
But yes, in languages with batteries included sometimes they feel like an afterthought. It's not just Python. Java also used to have a big standard library, with many useful things including GUI programming which has been neglected a little bit.
Re: Better Batteries
#6> it seems that the reason for Rust not having an API to get a stream of random bytes from the OS This is already in nightly[1]. I don't see what "getting money in peoples pockets" has to do with its stabilization. [1]: https://doc.rust-lang.org/std/random/trait.Rng.html#tymethod...
"Already" seems to do a lot of heavy lifting there.
Re: Better Batteries
#7> it seems that the reason for Rust not having an API to get a stream of random bytes from the OS This is already in nightly[1]. I don't see what "getting money in peoples pockets" has to do with its stabilization. [1]: https://doc.rust-lang.org/std/random/trait.Rng.html#tymethod...
Open since 2024. Perhaps if people were paid this would be merged in sooner?
Re: Better Batteries
#8I was fully expecting a comparison of recent battery chemistries, and forgot the "batteries included" saying being used for programming. As someone who doesn't use the mentioned languages often, it's surprising to hear that Python's stdlib is inconsistent given how old it is / how much work has probably gone into it.
It's about backwards compatibility and that the naming conventions weren't stabilized until after a bunch of libs entered the language.
Re: Better Batteries
#9> it seems that the reason for Rust not having an API to get a stream of random bytes from the OS This is already in nightly[1]. I don't see what "getting money in peoples pockets" has to do with its stabilization. [1]: https://doc.rust-lang.org/std/random/trait.Rng.html#tymethod...
"Already" seems to do a lot of heavy lifting there.
It's also not a trivial problem. Rust supports a few dozen more platforms than CPython.[1][2]
[1]: https://pythondev.readthedocs.io/platforms.html
[2]: https://doc.rust-lang.org/nightly/rustc/platform-support.htm...
Re: Better Batteries
#10Earlier quoted context omitted.
"Already" seems to do a lot of heavy lifting there.
It's also not a trivial problem. Rust supports a few dozen more platforms than CPython.[1][2] [1]: https://pythondev.readthedocs.io/platforms.html [2]: https://doc.rust-lang.org/nightly/rustc/platform-support.htm...
The tier 3 list is enormous yea.