<story><title>Golang’s most important feature is invisible</title><url>https://blog.devgenius.io/golangs-most-important-feature-is-invisible-6be9c1e7249b?gi=21e47786496b</url></story><parent_chain><item><author>ricardobeat</author><text>Which part of the example go code looks synchronous? It’s using a callback function. That’s a hallmark of async code, nothing invisible.&lt;p&gt;I also can’t quite grasp the comparison with Java. It’s passing a class instance to the server handler, and that could be doing &lt;i&gt;anything&lt;/i&gt;. Nothing there tells you how async or not the server implementation is, and that `os.write()` call might be using a thread pool underneath.</text></item></parent_chain><comment><author>kgeist</author><text>It&amp;#x27;s not about the callback at all, the example is poor and the explanation is lacking. In Go, many standard I&amp;#x2F;O functions use async I&amp;#x2F;O under the hood. When you call such a function (inside the handler callback, that is), the current goroutine is suspended yielding to other goroutines, so waiting for I&amp;#x2F;O doesn&amp;#x27;t block the OS thread inside the request handler. It&amp;#x27;s basically what you&amp;#x27;d do in C# with async&amp;#x2F;await, except it&amp;#x27;s implicit and you don&amp;#x27;t have to mark functions as asynchronous manually.  I.e. you write simple synchronous code and Go makes it asynchronous under the hood. There are several disadvantages, though: it&amp;#x27;s not tunable, and if there&amp;#x27;s a CGO call (call to a C func) which uses I&amp;#x2F;O itself it will block an entire worker thread because the Go runtime isn&amp;#x27;t aware of any of it.&lt;p&gt;As far as I know, Java&amp;#x27;s new virtual threads have the same idea.</text></comment>
<story><title>Golang’s most important feature is invisible</title><url>https://blog.devgenius.io/golangs-most-important-feature-is-invisible-6be9c1e7249b?gi=21e47786496b</url></story><parent_chain><item><author>ricardobeat</author><text>Which part of the example go code looks synchronous? It’s using a callback function. That’s a hallmark of async code, nothing invisible.&lt;p&gt;I also can’t quite grasp the comparison with Java. It’s passing a class instance to the server handler, and that could be doing &lt;i&gt;anything&lt;/i&gt;. Nothing there tells you how async or not the server implementation is, and that `os.write()` call might be using a thread pool underneath.</text></item></parent_chain><comment><author>foolfoolz</author><text>agreed. the examples don’t show the real pain. it is when every method returns Future or Promise. and you have to map each result. and many languages don’t have good support for that so you end up with lots of nesting. writing synchronous function signatures is much simpler to maintain.&lt;p&gt;there’s 2 language level syntax features i see that make this better:&lt;p&gt;one is scalas for comprehension. this lets you write async code that reads like imperative synchronous lines. the other is async&amp;#x2F;await, which let’s you write synchronous code that behaves like async</text></comment>