I’m curious to the reasoning behind moving a bunch of standard library stuff to external packages, listed at the end of the blog post. Faster compiling? Smaller executables? Faster development for each now separate package?
I don’t know the specific motivation here but in general it’s for package development to not be tied to the language release. People also generally have different backwards compatibility expectations for the stdlib vs a regular library and that constrains the development of the package. In Python the meme is that stdlib is where packages go to die. Not all large stdlib languages feel that way. Clojure, for example, has a pretty sizeable stdlib while being code frozen without a lot of demand for change. In general, however, language developers prefer not having things in stdlib.
I saw that list, and figured that they were distancing themselves from obsolete encryption (MD5 & SHA-1), as well as remove database management from their scope (which seems like the right move, IMO).
I’m curious to the reasoning behind moving a bunch of standard library stuff to external packages, listed at the end of the blog post. Faster compiling? Smaller executables? Faster development for each now separate package?
I don’t know the specific motivation here but in general it’s for package development to not be tied to the language release. People also generally have different backwards compatibility expectations for the stdlib vs a regular library and that constrains the development of the package. In Python the meme is that stdlib is where packages go to die. Not all large stdlib languages feel that way. Clojure, for example, has a pretty sizeable stdlib while being code frozen without a lot of demand for change. In general, however, language developers prefer not having things in stdlib.
I saw that list, and figured that they were distancing themselves from obsolete encryption (MD5 & SHA-1), as well as remove database management from their scope (which seems like the right move, IMO).