> having batteries included for things like HTTP is a win for any language I actually kind of disagree with this. I was a super early Go contributor and helpe

> having batteries included for things like HTTP is a win for any language I actually kind of disagree with this. I was a super early Go contributor and helped a tiny bit on the HTTP library (back then it was the core `http` package, now it's under `net/http`). Imo, a lot of HTTP stuff tends to be very "grey area" (what are sensible timeouts? how do you handle different socket errors? should we allow self-signed certificates?) so a lot of opinionated design debate ends up happening, and there's also a lot of scope creep, including having to include things like SSL/proxying if you really want "batteries" to be included which is a lot of non-trivial work (all of a sudden, you also need a elliptic curve cryptography lib, too) that basically has nothing to do with the language itself. I know we live in an "HTTP world" and it's a lot easier to sell a language that can also do stuff on the web, but it would be pretty far down my list.