[bigdubs]

There is a deeper strategy here with go vs. node; having a standard library maintained by professionals.

I would rather build on a common set of libraries secured by people who are paid full-time to maintain them, and maybe have slightly worse ergonomics, than have a community of libraries that come and go and have inconsistent quality.

This standard library approach yields fewer dependencies, fewer changes over time, and better consistency between projects.

[kelnos]

The downside of the standard library approach is that things tend to ossify. While I agree that slower change can be a good thing sometimes, putting things like a HTTP server in the standard library means less experimentation around different ways of doing things, and more difficulty getting performance and other improvements into the hands of language users.

Sure, people can make a third-party module that implements a HTTP server, but the incumbent default that's shipped with the language has an inherent (and often unfair) advantage and a lot of inertia behind it.

I don't really care about the whole "professionals" bit. Sure, I don't want to be relying on something mission-critical to me that's maintained by one person doing it in their spare time. But there is a world of possibilities between that and having a dedicated paid team. Consider, also, that the Go team is only funded so long as Go is important to Google's corporate strategy. Once it isn't, funding will start to dry up, and Go will have to look for a new funding and governance model. That's not necessarily a bad thing, and I'm sure Go would still succeed despite that. But that's kinda my point: this whole "maintained by funded professionals" thing doesn't really matter all that much.

[hrns]

Isn't Node API an equivalent of go standard library?

[jgod]

Yes but it's super barebones. Its successor, Ryan Dahl's second attempt at JS runtime, Deno, has a much fuller standard library (inspired by Go).

[tormeh]

I wish we'd stop trying to make broken languages work. This feels like hill-climbing into the strangest local optimum possible. JS is not the best example of an interpreted language. Wouldn't it be better to put Python in the browser than to put JS on the server? Can't wait for WASM to be a first-rate citizen on the web so we don't have to deal with this anymore.

[coder543]

I think you would be surprised to learn that more developers love TypeScript than Python these days, according to one popular survey.[0]

All of this is subjective, of course. WASM isn't going to make Python the language of choice for browsers any time soon.

[0]: https://insights.stackoverflow.com/survey/2021#section-most-...

[tormeh]

I don't think the comparison is entirely fair since one of the main attractions of TS is that it runs in the browser. Python can unfortunately not fill the same role right now. So I'd keep that in mind while looking at that ranking. But yes, I see many people like it. Maybe I'm missing something, but it's still too JavaScript-y for me.

[gmfawcett]

> Wouldn't it be better to put Python in the browser than to put JS on the server?

I think that's a categorical "no", because Python isn't an objectively better language than JavaScript. I'm saying this as a Python developer since v1.5 (>20 years).

Subjective opinions are a different matter.

[bigdubs]

Yes Node.js ships with what is effectively a very thin standard library for some low level things like interacting with the file system, the process model, some security features like TLS.

[tgsovlerkhgsel]

The Fetch API, supported by browsers for over 5 years now, is only now making it into the official Node API https://blog.logrocket.com/fetch-api-node-js/

[maple3142]

Node.js had `http` in its standard library for a long time though.

[dezren39]

so, cathedral vs bazaar