Vishwa Bhat

Technology Enthusiast

Mar 12, 2019

There are several parts where I disagree with your points;

All the programming languages must use OS Thread(s) to achieve concurrency. It's just the approach to achieve the concurrency differs.
You mentioned

Go does not create OS threads. Instead, it creates a much lighter go routines

No, you have to define a go-routine to achieve concurrency for which Go schedules the task defined inside go-routine and it will be executed inside the pre-spawned thread through the concept of Communicating Sequential Process(CSP)
Goroutine is not a new concept. Actors(Scala), Coroutines(Kotlin), for that matter, it can be introduced in Java too, through a library -- Quasar Fibers or Scala Actors (interoperated). When you see any documentation mentioning lightweight/green threads, what they actually mean is to provide concurrency through scheduling the tasks instead of spawning new threads for each task. And to manage Stack size of several isolated tasks in a single thread is difficult wrt JVM based languages, particularly Java, whereas Golang smartly called it segmented stack to dynamically grow the stack size because it directly utilises OS threads.

Now comes my primary point:

Why there is a relation established between Stack Size and Concurrency?

Let's look at the general definition of both. Stack Size is the capacity provided to store the function/procedure calls or in simple terms, the stack of line numbers of the function call hierarchy. Concurrency is the ability to perform tasks simultaneously such that idle resources are completely utilized regardless of no. of threads or CPUs. So, Stack-Size plays around the flow of the function and Concurrency plays around the flow of program-logic. The only time both meets at a point is during recursion but that's no where suffice to jump into conclusion on concurrency just because the stack-size of two languages are different.

Talking about Web Server;

I completely agree to the point that Golang handles incoming requests through go-routines but the Java neither spawns a new thread for each request nor it adds the request to the thread stack.

Earlier, Java used to have Thread-based Servers (until Servlets v4.0) where a Pool of Worker Threads are created initially and all the requests are delegated to that thread pool. This caused C10K Problem -- Handling Concurrent 10K Connections. This is where people used to Spin-up more Worker Threads in the Pool. In the recent years, the concept of Multi-threaded Event pool concept is pretty common in all the Java Web Servers like Netty, Servlets 4.1+, Jersey etc. which acts like NodeJS event loops but multiple event loops. Long gone are the days where you actually create threads.

The only places where Golang hits up is

Memory consumption standpoint as you mentioned
IO calls

In-case you want a benchmarks on the performance:

Having said that; I like both the languages. Java because of its stability and ecosystem and Golang because of its simplicity. Both are ridiculously performant, though IO is not Java's best suite because of blocking JDBC driver.

If anyone has different view on my comment, I'd be happy to discuss. :)

Cheers!

actors are not coroutines those are different models of concurrency to my knowledge.

Coroutines are computer program components that generalize subroutines for non-preemptive multitasking, by allowing execution to be suspended and resumed

en.wikipedia.org/wiki/Coroutine

although I guess assume a lot of actor models are built on coroutines they are not necessary the same.

The actor model in computer science is a mathematical model of concurrent computation that treats "actors" as the universal primitives of concurrent computation.

en.wikipedia.org/wiki/Actor_model

so one thing is mainly about messaging and the other about being able to be suspended and resumed.

they both depend on each other in modern implementation, but I think you can create an actor model without coroutines by using two computers that pass messages over a serial bus.

Although we could argue about multi-core chip architectures and how we perceive the distribution mechanism and in theory if the distribution mechanism in the kernel actually would do network messaging via serialization, which I think is unlikely, they could be perceived similar. well not exactly but as a general idea they have some similarities.

and in the end it's always the kernel how else could you access memory if the OS wouldn't allow it :). Go also has a compile target so it could not do it as a small binary if it would not utilize the Kernel APIs. (Correct me if I am wrong)

Anyhow I agree with everything you said :P.

No, you have to define a go-routine to achieve concurrency for which Go schedules the task defined inside go-routine and it will be executed inside the pre-spawned thread through the concept of Communicating Sequential Process(CSP)

IIRC, goroutines are run in an OS thread, but multiple goroutines might run in the same os thread, and the go runtime handles all the complexities of spawning new OS threads when required, and try to collocate go routines across thread as smartly as possible. And this is why a goroutine can be so lightweight (because a single goroutine does not imply spawning a new thread under the hood)

This might sound like nitpicking, but as a developer, it makes a huge difference because as a developer you don’t have to think about how the memory will be managed, you focus on how you design the logic. And I believe this is the key idea: threads are an implementation decision, whereas goroutines and channels are a design decision: you build for concurrency, even if it doesn’t run in parallel. (whereas with threads you try to force the CPU to work as much in parallel as you’d want, but you have to do it wisely depending on the underlying resources. goroutines abstract that concern from you)

here’s more details about goroutines and their underlying os-threads: dave.cheney.net/2015/08/08/performance-without-th…

Search Hashnode