Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go hits the concurrency nail on the head

eli.thegreenplace.net

Post reply on HN
Print view View original

281–290 of 318 posts

Re: Go hits the concurrency nail on the head

#281

Post by dnautics »

thinkpad20 wrote: post #18

I think the author might be overstating how unique Go’s position is in terms of making concurrency easier. Haskell has the best concurrency story of any language I’ve used. Super lightweight green threads, simple concurrency primitives like MVar and STM, good performance (possibly requiring tweaks, but not bad out of the box). Referential transparency (by which I basically mean immutable data) makes sharing data acro…

I think the BEAM languages "pure functions... well except for message passing" is perfect for concurrency. With haskell you have to use monads which are less convenient. And idiomatic BEAM defaults to actor model if you consider OTP to be "out of the box (you should)". Finally, pattern matching function guards are incredibly useful for parsing incoming messages that might be polymorphic.

Haskell is kind of designed to make programming as pure as possible and the BEAM was designed with concurrency as the first priority; it's "pure functional" to the point where its advantages (referential transparency) help concurrency and the impurities are the precise set of compromises you need to make concurrency easy.

Re: Go hits the concurrency nail on the head

#282

Post by [deleted] »

vvanders wrote: post #2

> Programming with threads is hard - it's hard to synchronize access to data structures without causing deadlocks; it's hard to reason about multiple threads accessing the same data, it's hard to choose the right locking granularity, etc. It's almost as if we need a language that has a focus on data races, concurrency and fearless threading.

[deleted]

Re: Go hits the concurrency nail on the head

#283

Post by [deleted] »

vvanders wrote: post #2

> Programming with threads is hard - it's hard to synchronize access to data structures without causing deadlocks; it's hard to reason about multiple threads accessing the same data, it's hard to choose the right locking granularity, etc. It's almost as if we need a language that has a focus on data races, concurrency and fearless threading.

[deleted]

Re: Go hits the concurrency nail on the head

#284

Post by fixermark »

jeremejevs wrote: post #273
fixermark wrote: post #48

Earlier quoted context omitted.

That exists, so we can look at at least one concrete attempt to evaluate the question. [ https://github.com/go-gl/mathgl ]. And right off the bat, the first thing a person notices is that there are two identical sub-libraries, mgl32 and mgl64, to work around the language's constraint that the core numeric type in the library cannot be parameterized at the language level without performance-losing reflection.

mgl64 is generated from mgl32 though [0], so no big deal, no? Who's hurt by this? [0] https://github.com/go-gl/mathgl#contributing

Well, let me just do a quick text-based search for the Vec3 implementation and...

... oh. There's three. The one in mgl64, the one in mgl32, and the canonical one that a developer should edit to make changes. And they only all stay synchronized if the developer remembers to follow the contributor practice and run that gen script, which is not enforced by anything.

On a small project like this, not a big deal. But it's indicative of the over-arching problem of the approach go is necessitating here. There's noise here that a developer has to think around, and as a project scales up, that noise is going to become louder and trend towards intractable complexity.

Re: Go hits the concurrency nail on the head

#285

Post by chrchang523 »

fulafel wrote: post #84
weberc2 wrote: post #77

Earlier quoted context omitted.

> full force of Google pushing it This trope is getting old. Variations include "Go is only popular because Google spends millions marketing it!". There is a small team at Google that work on the language along with the open source community. I'm pretty sure none of Google's marketing team works to promote the language, and I'm sure that its success is much less important to Google than Erlang's success was to Ericcs…

Ericsson abandoned Erlang, or Erlang abandoned Ericsson, depending on how you look: Ericsson banned it internally, and shortly afterwards when the Erlang team managed to get it open sourced, they resigned from Ericsson and founded their own Erlang company. (source: http://webcem01.cem.itesm.mx:8005/erlang/cd/downloads/hopl_e... )

Armstrong was rehired by Ericsson in 2004 [1], and a team at Ericsson maintains the language today (see e.g. [2]).

1: http://erlang.org/pipermail/erlang-questions/2006-July/02136... 2: http://blog.erlang.org/

Re: Go hits the concurrency nail on the head

#286

Post by apta »

tmerr wrote: post #261
kureikain wrote: post #121

Earlier quoted context omitted.

> Backed by major corporation I don't think Go success has anything to do with Google. Google engineers probably favors Java/Python. I think the key thing to make Go adopt is because the Docker project and Hashi Corp. The second most important thing is it is super easy to compile Go program and run it and adopt by DevOps teams

Eh? I can't speak for all of Google but I like me some Go. It has a culture of minimalism both in language and code, which makes it easy to pick up and read others' work. I wouldn't recommend it for all problems, but it's at least nice for backend services. Java is a victim of its own success: it has lived through style evolutions which have lead to fragmentation in the ecosystem. Some code uses mutable datastructure…

> it has lived through style evolutions

The same can be said for C++, C#, etc. that have been around for a long enough time. Golang is relatively speaking still new. Look back at this again if golang adds generics and other features that will change how code in it is written.

> Another imperfection: GC pauses can cause request timeouts and are annoying to debug.

That's not an issue with Java, but how the GC is tuned. Golang provides only 1 gc that is tuned for latency. And even that is not hard real time. The JVM has several GCs you can choose from, including latency optimized ones.

Re: Go hits the concurrency nail on the head

#287

Post by apta »

wahern wrote: post #171
kasey_junk wrote: post #82

Its fairly interesting that this article doesn't mention actors, futures/promises and async/await style co-routines which are all extremely available in all of the major languages available today and broadly used (with the possible exception of golang). Frankly, I think the concurrency story is one of the weaknesses of golang. Contrary to what this article says you cannot stop thinking about concurrency in your code…

All of those interfaces are trivial to implement in Go precisely because Go implements a much stronger abstraction. By contrast, if you only have those other abstractions you're quite limited in how you can structure your code. (You might not realize how limited you are, however, if those are your only options.) As the article says, most languages settle for those interfaces because they can mostly be implemented as…

> If you think actors, futures, and async/await are so great, imagine having to write every single function invocation in that manner.

I don't see how:

    val f = Future { foo() }
    // do work...
    f match {
       case Success(res) => useRes(res)
       case Failure(error) => handleError(error)
    }
Is any more difficult than:

    done := make(chan bool)
    var res int
    go foo(done, &res)
As a matter of fact, the first one is much easier. I don't have to create and pass a channel, and manually handle returning a success or failure. The first approach is much better

Re: Go hits the concurrency nail on the head

#288

Post by apta »

kasey_junk wrote: post #266
tandr wrote: post #264

Earlier quoted context omitted.

Would you be so kind and explain what term "high concurrency levels" implies? thank you in advance.

Consumer facing systems. System wide throughput between 6-12 million QPS (daily low/high) (query body average size is 1.5KB). Each server tops at ~130K QPS. On a system with 2 1 GB NICs we pop the NIC. On a 10G we pop the CPU. Current bottleneck is the golang http/net libs. Would likely need to rewrite it from the NIC up to do better.

Do you think the JVM would have faired better at this? Otherwise, perhaps something like Rust would be a better fit.

Re: Go hits the concurrency nail on the head

#289

Post by apta »

Const-me wrote: post #257
kasey_junk wrote: post #254

Earlier quoted context omitted.

Take a look at quasar for the JVM. In practice I’ve found it outperforms* golang in my workloads. * there is a small fixed overhead increase in memory.

There’re indeed multiple third-party libraries for that in many languages. E.g. for C++ we have lubuv, boost.asio, etc. However, built-in solutions have upsides. They work out of the box i.e. deployment is simpler. They’re integrated into the language, e.g. most network IO in golang is asynchronous under the hood, compiler and runtime do that automatically. They’re integrated into standard libraries, e.g. in .NET all…

The JVM is getting coroutines with Project Loom. The same Quasar devs are integrating it into the JVM.

Re: Go hits the concurrency nail on the head

#290

Post by apta »

kasey_junk wrote: post #254
Const-me wrote: post #253

Earlier quoted context omitted.

Scheduling is not enough. For efficient IO you need a scheduler that’s tightly coupled with OS-specific kernel mode APIs for async IO. Java has support for that in java.nio.channels but that’s limited and is not integrated with the rest of their standard library. C++ can do that, too, but quite hard in practice. Runtimes like Go, .NET and erlang already have that stuff included. There’re some limitations (e.g. erlang…

Take a look at quasar for the JVM. In practice I’ve found it outperforms* golang in my workloads. * there is a small fixed overhead increase in memory.

Quasar is going to be integrated into the JVM by means of project Loom.
Post reply on HN