Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I think this is a rather confusing article for beginners. I would say that request processing in an HTTP framework isn’t exactly a practical use case to demonstrate Go concurrency features. Most real-world applications are based on REST, which is stateless. In fact I would not associate HTTP server frameworks (in Go or in whatever language) with internal shared state management in an entry level article. For people interested in Go concurrency features there’s this great curated list instead:

https://github.com/golang/go/wiki/LearnConcurrency



I am unfamiliar with how Go HTTP frameworks do things but in Elixir each request is a new process... and running in BEAM which was designed for massive concurrency from the beginning. Go is frequently compared to BEAM solutions so I'm curious if each request in a Go web framework spawns a separate process per request.


Go’s web framework does spawn a goroutine for each request.


Go shouldn't be compared to BEAM at all. It doesn't have processes. It spawns a lightweight thread (goroutine) on each request.


BEAM's "processes" are lightweight too AIUI, pretty similar to goroutines.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: