>I am still torn about this. I can see the usefulness of it from python and go, but I also fear that it brings an unnecessary large maintenance burden.
Http standards are evolving and soon the implementation will get stale,
Why would it "get stale"? It doesn't get stale in Golang.
If anything, being part of the standard library is a greater assurance for more eyes going into it, and not having it get stale, as opposed to the language having 5-6 half-abandoned third party libs...
Keep in mind that a HTTP server is only useful for a subset of users, it might be an "obvious" requirement for you, but it definitely isn't for me ;) Features like this should go into libraries, but not the standard library. When looking for a Go or Python alternative, Zig doesn't immediately come to mind TBH.
Also: Go (or python) has no UI system or 3D API wrapper in the standard library, but those are (probably) useful for at least as many people as a HTTP server. Does that mean that Go should get UI and 3D-rendering support in the standard library?
>Keep in mind that a HTTP server is only useful for a subset of users, it might be an "obvious" requirement for you, but it definitely isn't for me ;)
Yes, but that "subset" is huge.
>Also: Go (or python) has no UI system or 3D API wrapper in the standard library, but those are (probably) useful for at least as many people as a HTTP server.
Not in the backend/network server world that Go primarily targets...
Why would it "get stale"? It doesn't get stale in Golang.
If anything, being part of the standard library is a greater assurance for more eyes going into it, and not having it get stale, as opposed to the language having 5-6 half-abandoned third party libs...