Golang’s most important feature is invisible

https://blog.devgenius.io/golangs-most-important-feature-is-invisible-6be9c1e7249b?gi=21e47786496b

by geekydev • 5 years ago

117 96 5 years ago

blog.devgenius.io

ferdowsi2• 5 years ago

Well, golang.org does specifically call this out at the top:

Built-in concurrency and a robust standard library

I think that the joy of Go's async-first design really makes sense most to people who have experienced the awful pains of colored async-await in other languages.

bestinterest• 5 years ago

What about project loom? Will that not solve this case providing you start the server with a virtual thread pool?

I guess thats what he was getting at however, not having to do that.

tomohawk• 5 years ago

Having used both languages for many years, it was unexpectedly irritating to pick up Java again after doing golang for a few years. So much unneeded complexity to do simple things.

azth5• 4 years ago

What are some examples of unneeded complexity?

closeparen• 5 years ago

Loom is an awesome research project that might begin to be relevant in the actual practice of production Java once it is 1-2 LTS releases old.

lostcolony• 5 years ago

Yeah; really hard to guess at the effect a feature that hasn't been finalized, has been in progress for years, and has yet to land in a release in any form, will actually have in an environment that is as slow to roll out updates and adopt new features as enterprise Java dev tends to be.

Optimistically we may be able to answer op's question sometime in 2024.

travisd• 5 years ago

My impression of the article is just that the author is a fan of green threads (goroutines). Green threads don’t really make sense without an integration into some kind of IO runtime, so calling out how Go does do this seems moot. Other languages with green threads also with this way (Julia comes to mind).

karmakaze• 4 years ago

The article is not very well informed. It doesn't even make a distinction between os threads and green threads.

To get this performance out of Java you would need to add threadpools, futures or some other async library.

What Java needs to be as efficient is the work of Project Loom: Fibers and Continuations. Go also has value types (e.g. arrays and nested structs with inline memory layout) that's the work of Java's Project Valhalla.

zik• 4 years ago

goroutines aren't really green threads, they're more lightweight than conventional green thread implementations due to having a segmented stack. Millions of goroutines can run comfortably on a standard machine. This isn't possible with any green thread implementation I've seen.

https://blog.cloudflare.com/how-stacks-are-handled-in-go/

kortilla• 4 years ago

They are cheaper but conceptually aren’t any different.

lucian1900• 4 years ago

You can run that many Erlang processes or more.

Millions is typical of green thread implementations.

nasretdinov2• 4 years ago

By the way, while Go did initially have segmented stacjs, they've long abandoned it in favour of a contiguous one.

bborud3• 5 years ago

It isn’t that it’s invisible. It’s just that you didn’t get it until now.

I am not saying that to belittle the author. This is more an observation of how programming seems to have gone from understanding both yourself and what you are doing to shopping bits and pieces and then gluing them together.

ferdowsi2• 5 years ago

Not really, "invisible" is a fair way to describe complexity that developers never interact with. Especially when most other popular languages forces developers to deal with irritating async/await bookkeeping when it comes comes to concurrency.

zozbot234• 4 years ago

How so? The point of async/await is to reduce bookkeeping. The Go model is at its core an implementation of M:N user threads, and it creates plenty of complexity wrt. e.g. interfacing with other languages. Which is why M:N threading was mostly abandoned elsewhere.

bborud3• 4 years ago

Go is marketed as having a programming model that is heavily influenced by CSP. This is one of the big selling points for Go and it is at the core of how it offers concurrency. It is hardly some footnote that is hidden away. It is pretty much in your face.

hahnchen• 4 years ago

Love the tldr at the start: “ The Go standard runtime allows for asynchronous coding while allowing the developer a simply synchronous interface”

ridiculous_fish• 4 years ago

How does Go handle syscalls which can't be multiplexed? If I call stat() from 500 goroutines, what does the Go runtime do regarding kernel threads?

tedunangst• 4 years ago

500 kernel threads.

smallerfish• 4 years ago

Techempower benchmarks beg to differ.

https://www.techempower.com/benchmarks/#section=data-r20&hw=...

There's a lot of Java above the first occurrence of Go. Also - nobody writes Java web applications using the Sun httpserver. It's verbose and old.

TheDong2• 4 years ago

It seems to me like the go ecosystem would rather have a less performant language if it means more similar code between projects.

Take for example json: Go's stdlib json implementation is wildly slow. It has to be implemented in reflection, it can't use any code-generation anything, and for backwards compatibility it can never trim any feature, no matter whether it has a performance implication for all users of the package. It's well known to be a slow implementation.

In java, json isn't part of the stdlib. There's jackson if you want one flavor of fast json, jetty ships its own json serializer, etc. This means that if you pick up a new java codebase written in a different framework, it's possible you have to learn the right pattern to json serialize things.

By nature of these third party libraries in java being out of the stdlib, they've been able to grow and become more performant and compete with each other.

Go sits on the opposite side. The stdlib http implementation is a little slow. The stdlib json implementation is incredibly slow. No one wants to build these features outside of the stdlib though, and people would rather every codebase have the same looking go code, even if that means the actual code itself is slower.

sofixa• 4 years ago

Go sits on the opposite side. The stdlib http implementation is a little slow. The stdlib json implementation is incredibly slow. No one wants to build these features outside of the stdlib though, and people would rather every codebase have the same looking go code, even if that means the actual code itself is slower.

What? There are multiple json parsing and http server implementations for Go.

raggi2• 4 years ago

Sure, but also no one should be benching servers with 'ab' either...

sinsterizme• 4 years ago

Why’s that?

ricardobeat• 4 years ago

Which part of the example go code looks synchronous? It’s using a callback function. That’s a hallmark of async code, nothing invisible.

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 anything. Nothing there tells you how async or not the server implementation is, and that `os.write()` call might be using a thread pool underneath.

foolfoolz• 4 years ago

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.

there’s 2 language level syntax features i see that make this better:

one is scalas for comprehension. this lets you write async code that reads like imperative synchronous lines. the other is async/await, which let’s you write synchronous code that behaves like async

recroad• 4 years ago

I thought I was the only one who wasn’t getting it.

kgeist5• 4 years ago

It's not about the callback at all, the example is poor and the explanation is lacking. In Go, many standard I/O functions use async I/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/O doesn't block the OS thread inside the request handler. It's basically what you'd do in C# with async/await, except it's implicit and you don'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's not tunable, and if there's a CGO call (call to a C func) which uses I/O itself it will block an entire worker thread because the Go runtime isn't aware of any of it.

As far as I know, Java's new virtual threads have the same idea.

spongechameleon• 4 years ago

In the case of a CGO call you could prefix the enclosing function definition with the "go" keyword to manually initiate a new goroutine? Am I understanding this correctly?

kgeist5• 4 years ago

Nothing there tells you how async or not the server implementation is, and that `os.write()` call might be using a thread pool underneath.

It depends on the contract of the method. If it promises to throw an exception if the call failed, then the current thread of execution can't proceed before the call returns, or it would break the semantics. So even if it uses a thread pool, the current thread will have to block, waiting for some acknowledgement by os.write(), wasting an entire OS thread. As far as I know, Go won't block, the scheduler will just switch to a different goroutine in the meantime. Java's new virtual threads will allow to have mechanism similar to Go's.

ankurdhama• 4 years ago

The writing of response (the write to the socket).

Go: fmt.Fprintln(w, "Goodbye, World!")

Java: os.write(response.getBytes());

oxplot• 4 years ago

TL;DR The Go standard runtime allows for asynchronous coding while allowing the developer a simply synchronous interface.

I didn't read the article but this TL;DR captures the essence of simplicity of programming in Go when writing IO apps. Go essentially optimizes for the majority case: run these things one after another. All the await/async fluff in other languages is evidence of poor/old language design. Every non-trivial production code you see these days in Javascript is littered with await/async as is the case in Python, etc. Why the heck do I have to repeat a keyword 1000s of times when that's expected in majority of languages.

Yes, Go may not cover every case perfectly (e.g. mentioned by sibling re CGO blocking OS thread), but when you look at real world stats of how often this is an actual issue, you find that it's almost noise (i.e. do a code search across Github for instance for such workarounds).

vips7L3• 4 years ago

The comparison with Java is awful. Especially the performance comparison since the sun http server isn’t meant to be used and isn’t a part of the language spec.

jeffbee2• 4 years ago

Unfortunately the batteries-included runtime of Go effectively forecloses any really high performance server code that scales well to huge machines. What it offers is moderately good and that's all you'll ever get. A Go web server will work OK on 8 cores and it will only go a bit faster on 32 cores and not at all faster, possibly slower, on 256 cores. Meanwhile Java async programs are still scaling up. These results are apparent if you look at the gRPC multi-language benchmarks.

There's only one way to write a server in Go and that has pros and cons.

technosamay20• 4 years ago

Thanks for sharing this insight. Is this a issue with just the web server.

If I have a standalone task, which tires to use 128 cores and manages parallel tasks using goroutines communicating via channels - will I be able to successfully leverage 128 cores.

jeffbee2• 4 years ago

If your tasks are large enough to dominate, then the non-scalability of the goroutine scheduler and the network stack won’t be an issue. For example, if your task is compressing some huge hunk of a video and it takes a second to do it, then it will scale fine. Then again, you can get this scalability from anything, including `xargs`.

rawoke083600• 4 years ago

Interesting.. Any sources or examples ?

recursivedoubts3• 4 years ago

I think what the author is saying is that go has very good async support, but it is no less visible than it is in java, from what I can see. Certainly better syntax, but still visible.

I am working on a front end scripting language that does try to make this stuff invisible:

https://hyperscript.org/docs/#async

It's slow as all get out, but it does, for the most part, hide all the async stuff from the script writer so they can write stuff like:

  fetch /someurl
  put the results into #a-div
  wait 2s
  transition #a-div's opacity to 0
  remove #a-div

And all the async stuff in there (the fetch, the wait, the transition) all happen w/o callbacks, async annotations, etc.

Yoric3• 4 years ago

That's going to make data race conditions invisible, no?

How will developers cope with that?

kgeist5• 4 years ago

Data races happen when there are multiple writers/readers of the same data. If one virtual thread of execution is multiplexed on several OS threads/workers/callbacks/you name it, there's still only one reader/writer at a time, because different parts of a multiplexed function don't run at the same time, they go one after another sequentially as before, with the difference is that there are now implicit continuation points where execution can hop from thread to thread (callback to callback). Can't say for hyperscript, but generally you need to protect your data with the same synchronization primitives as before, such as locks for example. It's only incompatible with thread locals and thread affinity, I'm not sure if JS has those.

recursivedoubts3• 4 years ago

To an extent yes, but consider the context: front end scripting

The javascript threading model is that there is a single thread executing so within a given bit of code you can be reasonably sure things are safe. The hyperscript runtime only allows one instance of a given event handler to execute at a time (unless otherwise specified) so the primary source of concurrency issues (the same code executing concurrently) is typically not an issue. By structuring your code such that it is on the same element (perhaps triggered by events elsewhere) you can effectively synchronize code in an intuitive manner.

I certainly wouldn't recommend the language for the back end though!

solarkraft• 4 years ago

What are the major issues with this concept? I often wonder why async isn't the standard and we have to manually decide to use it (what if a function we thought would be fast actually takes long?).

Considering that it seems to be a "best practice" to use async functions whenever remotely required, it would be bad developer experience (and lead to unwanted results) to make people do extra work to use it.

recursivedoubts3• 4 years ago

i think it is because async came so much later in the life of javascript, and there are some pretty serious perf implications to do it completely transparently

KingOfCoders2• 4 years ago

I'm also thinking about a language where async is default.

https://hirolang.org/

And what major issues and downsides this has. One I can identify it would be non obvious on how to do `map` on a Future/Promise, because there is none. So there is no easy way to execute on the green thread code with the result of the remote call, e.g.

   let f = asyncFuture()
   f.map(|v|: v + 1) // executes also async
   let s = await m
   println(s)

If f is transparently handled as a future, this is no longer possible, we would have:

   let s = asyncFuture()
   s = s + 1 // not async
   println(s)

One would also, to be safe, always use immutable data structure and copy semantics on other classes (e.g. functional lenses and prisms everywhere transparently) - with the performance impact of immutable data structures.

int_19h5• 4 years ago

The issue is that the moment you cross the boundary into some other language (and note that this usually includes the APIs provided by the OS!), the caller and the callee have to agree on how green threads work.

It's not an issue with explicit async/await model, because that one desugars into callbacks, which can be described entirely in terms of the already-existing C ABI that is the baseline for FFI in any modern language.

halpert• 4 years ago

This type of synchronous code is most impressive to those who come from JavaScript where everything is clearly asynchronous. For instance, in Go you can read a file synchronously using os.ReadFile and it will generally be performant. In NodeJS, you need a callback to achieve the same result.

apatheticonion• 4 years ago

It's a weird one.

The fact that callbacks in Go may be on a different thread means it's so damn easy to use a variable reference from an outer scope within in a callback. This increases the chances that someone inadvertently causes a race condition. Something that requires additional awareness and screening during code reviews.

This by itself isn't an indictment of the language as threading is essential to quality GUI applications and as such Go is a great language for writing client applications - which it is largely not used for.

You really need to evaluate the value the overhead Go's thread management brings when used in the context of web servers - where we typically split processes up using container orchestration, making them functionally threaded any way.

Comparatively, TypeScript running on Node or Deno is single threaded yet asynchronous. Using it as a web server means you have a better type system which follows a similar structural typing model to go (interfaces and such) and you don't have to screen for race conditions. In K8 or ECS, you spawn as many processes as you have CPUs and Bob's your unkle.

Personally, I would love it if Go focused on GUI application development but I can _bearally_ write GTK apps with it. Windows and MacOS applications are near-to or impossible to write. Don't even talk to me about Web Assembly. Such a missed opportunity.

tgv• 4 years ago

That’s a weird critique of Go: you make it sound as if you must use threads. But nothing stops you from using callbacks and promises (which have become a bit more comfy with the addition of generics).

And if the there’s one domain where I see an advantage in using inheritance, it’s GUIs.

Thorrez• 4 years ago

Just looking at the numbers, Go is 71% faster. That could be due to the Go HTTP library being more efficient than the Java HTTP library, rather than language or runtime features.

lenkite• 4 years ago

Nobody uses that internal Oracle HTTP server - it is not meant for production. It isn't even in the Java namespace -your static analysers will complain about using 'com.sun.*' packages.

Use the Java Jetty server and Go will hide itself in a corner in shame when benchmarked.

vips7L3• 4 years ago

Undertow has better performance for the example program:

https://www.reddit.com/r/programming/comments/sanusb/comment...

est• 4 years ago

TLDR: The Go standard runtime allows for asynchronous coding while allowing the developer a simply synchronous interface.

I am happy for Golang users but Gevent is more "synchronous" and easier to write.

kgeist5• 4 years ago

I am happy for Golang users but Gevent is more "synchronous" and easier to write.

Can you give an example to substantiate your post?

bvrmn• 4 years ago

Hmm. If you pack real blocking code (instead of writing a couple of bytes) into Go's handler it would definitely turn into crippled turtle under high concurrency load. There is no magic in Go's runtime.

pcwalton• 4 years ago

Every operating system kernel also presents a synchronous interface to asynchronous I/O. What Go provides is more efficient multithreading in certain cases, primarily because the kernel scheduler doesn't need to be involved on context switches. But this could be fixed at the kernel level with something like Windows' fibers or Google's SwitchTo patches.

frizlab• 4 years ago

https://vorpus.org/blog/notes-on-structured-concurrency-or-g...

torginus• 4 years ago

I kind of disagree with the article's premise - that the fact that Go uses async/await like Js and C#, but presents them as green threads is a good thing.

Imo it creates false expectations in programmers, who are surprised, that long-running compute code doesn't get preempted, since the compiler doesn't insert preemption points.

It also robs us of the possibility, of writing event-driven UI applications, where one can make an asynchronous call on the UI thread safely, which will get marshalled back to the UI thread.

nasretdinov2• 4 years ago

By the way, Go does have async preemption. It didn't have it in version 1.0, but it does now.

https://medium.com/a-journey-with-go/go-asynchronous-preempt...

KingOfCoders2• 4 years ago

The author is right in principle, i I think Golangs async scheduler which automatically moves blocking code outside Golangs goroutine scheduler is amazing, but his code and explanations are all wrong. also "Java’s green threads" shows a deep lack of understanding.

The author shows a junior level of understanding which co tradicts "I’ve worked professionally with Go for a couple of years"

PYTHONDJANGO• 4 years ago

If you want to show a senior level of understanding coding discussions, please understand that you always should write with a scientific mindset.

This means: not only say "x is good" or "x is bad" without explanation like a little child - but also deliver the source of your knowledge or the proof.

Then your contributions will be seen as mature additions to collective wisdom.

Golang’s most important feature is invisible

Related Stories