4 ms·

Having lightweight userland threads fundamentally changes the way that you write concurrent programs. There is no need to worry about creating too many threads

Having lightweight userland threads fundamentally changes the way that you write concurrent programs. There is no need to worry about creating too many threads or of thread creation being too heavy. Old school patterns like process/thread/goroutine per connection are very natural to write in Go and result in dead simple code that performs well under load. Reasoning about threads & basic blocking calls is a simpler mental model compared to async/await style concurrency in my opinion. Go is fundamentally designed for developing backend applications, not high perf mathematical/scientific computing. Features like unrolling for-loops across hundreds of cores or offloading to GPU's would be out of place in the language.

dragontamer 5y ago
> Having lightweight userland threads fundamentally changes the way that you write concurrent programs. There is no need to worry about creating too many threads or of thread creation being too heavy. Old school patterns like process/thread/goroutine per connection are very natural to write in Go and result in dead simple code that performs well under load. Well... there's still a problem in the tens-of-millions of Goroutines. But the issue is that OS-threads generally had issues at the ~100,000 of OS-threads. Making something "more lightweight" than pthreads makes sense, because 10,000,000 coroutines is a fundamentally different program design than 100,000 pthreads.
Zababa 5y ago
There is sometimes a problem, when you run out of file descriptors for example.
eptcyka 5y ago
Async/await gets you the same thing as go routines sans the for loop unrolling for yield points, no?
- deleted 5y ago
  [deleted]
- initplus 5y ago
  Sure, you can rewrite a program using lightweight threads to an async/await model and vice versa. I find the difference is in how easy it is to reason about concurrency in the program. With threads I find I can more easily mentally organise which code in my application is executing in parallel. In async/await land, you end up with 2 classes of functions async & non async functions, it's up to the callee to determine wether it is a blocking call or not. With threads you just block by default, and let the caller determine whether it's appropriate to block or execute the function on another thread. See https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... for someone mere eloquent than myself.

dragontamer 5y ago

> Having lightweight userland threads fundamentally changes the way that you write concurrent programs. There is no need to worry about creating too many threads or of thread creation being too heavy. Old school patterns like process/thread/goroutine per connection are very natural to write in Go and result in dead simple code that performs well under load. Well... there's still a problem in the tens-of-millions of Goroutines. But the issue is that OS-threads generally had issues at the ~100,000 of OS-threads. Making something "more lightweight" than pthreads makes sense, because 10,000,000 coroutines is a fundamentally different program design than 100,000 pthreads.

Zababa 5y ago

There is sometimes a problem, when you run out of file descriptors for example.

eptcyka 5y ago

Async/await gets you the same thing as go routines sans the for loop unrolling for yield points, no?

deleted 5y ago
[deleted]
initplus 5y ago
Sure, you can rewrite a program using lightweight threads to an async/await model and vice versa. I find the difference is in how easy it is to reason about concurrency in the program. With threads I find I can more easily mentally organise which code in my application is executing in parallel. In async/await land, you end up with 2 classes of functions async & non async functions, it's up to the callee to determine wether it is a blocking call or not. With threads you just block by default, and let the caller determine whether it's appropriate to block or execute the function on another thread. See https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... for someone mere eloquent than myself.