--- title: "Comment by Vishwa Bhat on \"Go vs Java in terms of memory efficiency. Beauty of go routines and their variable stack size limit.\" | Hashnode" description: "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 approac" url: "https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594/comment/5c87ada178aaa7537d3dec17" --- [Discussion](https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594) Comment [Go vs Java in terms of memory efficiency. Beauty of go routines and their variable stack size limit.](https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594) [Vishwa Bhat](https://hashnode.com/@cruci161) [Mar 12, 2019](https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594/comment/5c87ada178aaa7537d3dec17) There are several parts where I disagree with your points; 1. All the programming languages must use _OS Thread(s)_ to achieve concurrency. It's just the approach to achieve the concurrency differs. 2. 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)_ 3. 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 1. Memory consumption standpoint as you mentioned 2. IO calls In-case you want a benchmarks on the performance: 1. [Web Server Performance](https://www.techempower.com/benchmarks/#section=data-r17&hw=cl&test=fortune) 2. [Core Performance](https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go.html) 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! [j](https://hashnode.com/@chilimatic) [Mar 12, 2019](https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594/comment/5c87ada178aaa7537d3dec17#reply-5c87c03cce7e150913f30dc1) 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](https://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](https://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. [Vishwa Bhat](https://hashnode.com/@cruci161) [Mar 12, 2019](https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594/comment/5c87ada178aaa7537d3dec17#reply-5c87c99f6c4fc65e35805ab1) Actors are certainly different than Coroutines. What I was referencing to is the _concept of separating the tasks into micro-operations and execute them in a concurrent fashion in a single thread_. As I mentioned, the approach followed to achieve this is different by different languages, like Actors in Scala/Erlang/Elixir or Coroutines in Kotlin or Goroutines. Actor Model/System is way bigger concept than just execution of micro-operations. They have failover strategies, actors can be individually scalable etc. My whole answer was pertaining to single-thread/single-CPU. In Multi-core architecture, the concept of parallelism gets more highlight over concurrency because of work-stealing algorithms(like ForkJoin Pool in Java). Also, in the end, as you said, Go has an advantage of binary compiled unlike JVM based languages. [j](https://hashnode.com/@chilimatic) [Mar 12, 2019](https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594/comment/5c87ada178aaa7537d3dec17#reply-5c87dfe4492428912578e97c) thx for the elaboration :) [Sébastien Portebois](https://hashnode.com/@sportebois) [Mar 12, 2019](https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594/comment/5c87ada178aaa7537d3dec17#reply-5c883b05aec4f5f1641a6c3e) > 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…](https://dave.cheney.net/2015/08/08/performance-without-the-event-loop) [Vishwa Bhat](https://hashnode.com/@cruci161) [Mar 13, 2019](https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594/comment/5c87ada178aaa7537d3dec17#reply-5c886a84257958207d863f50) [Sébastien Portebois](https://hashnode.com/@sportebois) I'm not sure if your comment misses a question to ask or it is explaining in detail on my briefed point. I completely agree to what you explained about _how Goroutines work and the design decisions behind Goroutines_ but my point was in reference to author's statement: > It does not create OS threads. Instead, it creates a much lighter go routines. The concept of "goroutine" is just an abstraction over _managed threads and runtime scheduling of operations_ where it actually uses internally spawned OS threads to run the scheduled operations in a concurrent way. So, you write a goroutine to run a piece of code concurrently but the the concept of goroutine does not drive down to OS level as an alternative to Threads. Cheers! [PRASHANTH H N](https://hashnode.com/@prahashnode) [Mar 13, 2019](https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594/comment/5c87ada178aaa7537d3dec17#reply-5c887bf2ccbad0dc0937acc2) When I said ' go doesn't create os threads ', I meant that it doesn't create os threads to achieve concurrency. Go routine is go's way of achieving concurrency. Ultimately it has to create a os threads. But the main thing is how many go routines are getting executed in that thread. It totally depends on what each go routine does. And thanks for info that java has something similar to nodejs's event loop. I lacked this information. [PRASHANTH H N](https://hashnode.com/@prahashnode) [Mar 13, 2019](https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594/comment/5c87ada178aaa7537d3dec17#reply-5c887d67ccbad0dc0937acc6) I have a couple of questions to ask. I could google them up but anyways I will ask. 1. Does kotlin or scala require runtime to be installed ? 2. Are there any complied languages other than go which supports platform independent building? [Vishwa Bhat](https://hashnode.com/@cruci161) [Mar 13, 2019](https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594/comment/5c87ada178aaa7537d3dec17#reply-5c8886f8ccbad0dc0937ad3e) [PRASHANTH H N](https://hashnode.com/@prahashnode) Well the statement `It doesn't create threads but it creates a much lighter go routines` sounds different, anyway, my bad. Regarding questions; 1. Yes. Both Scala and Kotlin are JVM based languages so they require runtime to be installed to run on it 2. I didn't understand that question. [PRASHANTH H N](https://hashnode.com/@prahashnode) [Mar 13, 2019](https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594/comment/5c87ada178aaa7537d3dec17#reply-5c8887eaccbad0dc0937ad42) I should take care of the way I put the words into sentences. Thanks for coming back. Anyways the questionis , for example , if I want to build a c++ application to run on Linux then I have build in in Linux machine. But in go I can do it in windows or os X or Linux. I just wanted to know if there are any other compiled languages with this feasibility. [Vishwa Bhat](https://hashnode.com/@cruci161) [Mar 13, 2019](https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594/comment/5c87ada178aaa7537d3dec17#reply-5c888dc2ccbad0dc0937ad4f) Not that I'm aware of. So far, I've come across only JVM based/Golang/Interpreted languages supporting cross-platform [PRASHANTH H N](https://hashnode.com/@prahashnode) [Mar 13, 2019](https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594/comment/5c87ada178aaa7537d3dec17#reply-5c88a3dcaee80e162a882aa1) Thanks. [j](https://hashnode.com/@chilimatic) [Mar 13, 2019](https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594/comment/5c87ada178aaa7537d3dec17#reply-5c88a4c2aee80e162a882aa5) [Vishwa Bhat](https://hashnode.com/@cruci161) [PRASHANTH H N](https://hashnode.com/@prahashnode) 1. rust allows multitarget compilation 2. any VM based language (C# for example) 3. most languages with their own Runtimes (node, java, erlang) there are loads :) I think for example C _gg_ as long as you don't access native functionality. [Vishwa Bhat](https://hashnode.com/@cruci161) [Mar 13, 2019](https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594/comment/5c87ada178aaa7537d3dec17#reply-5c88ac5425dac18a3cef39e3) [j](https://hashnode.com/@chilimatic) Rust is still in my learning basket, I heard it's worthy to learn. [PRASHANTH H N](https://hashnode.com/@prahashnode) [Mar 13, 2019](https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594/comment/5c87ada178aaa7537d3dec17#reply-5c88c3f86ac67d214c92d727) I thought C# does not require any VM. It is very interesting to know that it requires VM to run. By the way I do not know anything about C#. Iss't it a compiled language where in we can build .exe and .dlls ? As [j](https://hashnode.com/@chilimatic) is telling that it requires VM then I wonder what will be the format of file that we finally build to run a C# program ! [j](https://hashnode.com/@chilimatic) [Mar 13, 2019](https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594/comment/5c87ada178aaa7537d3dec17#reply-5c88e59a8d5c82cc615ceb38) [Vishwa Bhat](https://hashnode.com/@cruci161) I am organizing a rust meetup and I really like the language. I leave the decision up to you :D [PRASHANTH H N](https://hashnode.com/@prahashnode) [stackoverflow.com/questions/9556354/if-c-sharp-is…](https://stackoverflow.com/questions/9556354/if-c-sharp-is-not-interpreted-then-why-is-a-vm-needed) :) don't confuse the runtime with a vm :)