This is an argument I've never come across before and I'm curious - why does web development require the use of garbage collection? Recent blogs I've seen suggest that at very large scale, garbage collection in languages like Go have severe side-effects, although obviously there's very few of us running at that scale.

The question shouldn't be "why does web development require the use of garbage collection" but "why would you not use a language with a GC when you have the opportunity". Before Rust (and after the 90s or whenever hardware became sufficiently cheap) it would've been very odd to consider a non-GCed language for something like webdev. Even for things like high-frequency trading where reliable low latency is very important, some companies think using GCed languages like Java and inventing hacks to avoid GC pauses when necessary is a worthwhile tradeoff because of the productivity gain from having a GC.

Certainly Rust has done lots of cool stuff to make living without a GC easier. And maybe it has sufficient compensating advantages to make it worth using for things like webdev (although I wish more of its proponents would try different statically typed functional languages that share some of those advantages but don't make you manage memory manually). But lacking a GC is still pretty clearly a disadvantage outside of a few areas (namely, those where people often use C++).

> Web development without garbage collector sounds like a bad idea.

Before rust, all the mainstream non-gc'ed languages (i.e C/C++) were not recommended mainly due to potential security issues.

The only options left were gc'ed languages (e.g Python, Java, Go).

Now Rust enters which addresses a lot C/C++ issues but the ergonomics, lack of tooling & learning curve is too much for lot of basic web services.

For large scale web services, investing in Rust makes sense to make it more performant & resource efficient, especially a lot of $$ is riding on it.

definitely not relevant to all web-dev, but Discord found that the garbage collection in go was causing bad performance spikes and switched to go for one of their read-state services: https://blog.discord.com/why-discord-is-switching-from-go-to...

This is such a great article. It's one of the examples that comes to mind when people ask me about great engineering blog posts. The TL;DR is the Go GC was causing some fairly large latency spikes under load. Since Rust doesn't do GC, because of its ownership model, these latency spikes didn't exist in their Rust implementation of the service.

Also, pflock you have a small typo there. You probably meant to say from Go to Rust, not Go to Go :)

Keep in mind this post is lolspeed porn, not a compelling argument against using a GC in your new project. If you're successful enough to have these problems, you can afford to rewrite in anything.

The author does seem to use Rc and Arc references, which collect garbage using reference counting.

could you provide any reasoning for that, please?