[dgb23]

“Web server” is a pretty big use case though.

But I agree that graphics is often overlooked in std libs. However that’s a bit of a different beast. Std libs typically deal with what the OS provides. Graphics is its own world so to speak.

As for Wasm: first, that’s a runtime issue and not a language issue. I think GC is on the roadmap for Wasm. Second, Go and C# obviously predate Wasm.

In the end, not every language should be concerned with every use case. The bigger question is whether it provides a std lib for the category of programs it targets.

To take a specific example: JS isn’t great at efficiently and conveniently generating dynamic HTML. You can go far without (or minimal) dependencies and some clever patterns. But a lot of pain and work hours would have been saved if it had something that people want to use out of the box.

[ffsm8]

> “Web server” is a pretty big use case though.

You don't consider games, desktop and mobile applications big use cases, each being multi billion industries?

I don't know man, I feel like you're arguing in bad faith and are intentionally ignoring what the athrowaway3z said: it works there because they're essentially languages specifically made to enable web development . That's why their standard lib is plenty for this domain.

I can understand that web development might be the only thing you care about though, it's definitely a large industry - but the thesis of a large standard lib solving the dependency issue really isnt true, as (almost) every other usecase beyond web development shows.

[dgb23]

> but the thesis of a large standard lib solving the dependency issue really isnt true, as (almost) every other usecase beyond web development shows.

I don't think the dependency issue can be solved by a good std lib, but it certainly can be mitigated as some languages show.

I think JS is a very pronounced case study here.

[nicce]

Web is likely bigger than all of those together. And large part of mobile and desktop apps depends on the web tech these days.

[galangalalgol]

Specifically those languages are back end focused so about 28% of developers. 55 focus on front end. If you add up games desktop and mobile, oddly you get 28% as well. So not bigger but the same size good intuition! That leaves out embedded 8% and systems (8-12%). Which are probably more what rust is used for. There is obviously overlap and we haven't mentioned database or scientific programming at 12 and 5 percent respectively.

Edit: after rereading this I feel like I may have come across sarcastic, I was legitimately impressed a guess without looking it up would peg the ratio that closely. It was off topic as a response too. So I'll add that rust never would have an asynch as good as tokio, or been able to have asynch in embedded as with embassy, if it hadn't opted for batteries excluded. I think this was the right call given its initial focus as a desktop/systems language. And it is what allowed it to be more than that as people added things. Use cargo-deny, pin the oldest version that does what you need and doesn't fail cargo deny. There are several hundred crates brought in by just the rust lang repo, if you only vet things not in that list, you can save some time too.

[mort96]

"Web server" is, more or less, about converting a database into JSON and/or HTML. There are complexities there, sure, but it's not like it's some uniquely monumental undertaking compared to other fields.

[dgb23]

Not all web servers deal in HTML or JSON, many don't have databases outside of managing their internal state.

Even ignoring that, those are just common formats. They don't tell you what a particular web server is doing.

Take a few examples of some Go projects that either are web servers or have them as major components like Caddy or Tailscale. Wildly different types of projects.

I guess one has to expand "web server" to include general networking as well, which is definitely a well supported use case or rather category for the Go std lib, which was my original point.

[andybak]

> Web server" is, more or less, about converting a database into JSON and/or HTML

You seem to have a very different definition of "web server" to me.

[lcnPylGDnU4H9OF]

Just to explain this confusion, the term “web server” typically refers specifically to software that is listening for HTTP requests, such as apache or nginx. I would use the term “application server” to refer to the process that is processing requests that the web server sends to it. I read “web server” in their comment as “application server” and it makes sense.

[andybak]

Yes. That's the same distinction I would expect. Although I'm not sure that the database stuff is the role I'd usually look for in the application server itself.

Maybe it's a language community thing.

[lcnPylGDnU4H9OF]

Ah, yeah, I did mean “application”. You’re right about the “application server” being a weird place for db connections.