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

191–200 of 318 posts

Re: Go hits the concurrency nail on the head

#191

Post by pjmlp »

qznc wrote: post #170
pjmlp wrote: post #162

Earlier quoted context omitted.

Every programming language has a runtime, even Assembly if the CPU is micro-coded. How do you think that the GC, go-routine scheduler, cgo marshaling get managed?

I assume what people want to say is that Go requires nothing which other languages install via the system package manager. While "runtime" is not the correct term, the desire is real. With Java you first install a JVM. With Python you install the interpreter and batteries. This always leads to version conflicts at some point. In contrast, with Go your CI builds an executable, you transfer that to your server and it r…

Using the wrong terms leads to urban myths and misunderstandings.

You don't need to install Java at all, because the JVM can be bundled with the application, and for anyone that actually cares to pay for them, the large majority of commercial Java third party vendors have AOT compilers on their JDKs.

Likewise with Python, there are several solutions how to bundle a set of scripts with an executable.

Re: Go hits the concurrency nail on the head

#192

Post by dboreham »

pcwalton wrote: post #177
weberc2 wrote: post #175

Earlier quoted context omitted.

> Goroutines are threads. So the idea the "Go has eliminated the distinction between synchronous and asynchronous code" is only vacuously true, because in Go, everything is synchronous. Abstractly, I agree, but practically the distinction is important. In Go you don't have to use a frustrating async interface to get decent performance. You don't have to manage a threadpool or other tricks. You pretty much get the thr…

Let's be clear: the one-OS-thread-per-connection model does yield decent performance. We used to call async I/O "solving the C10K problem"—i.e. serving 10,000 clients simultaneously. I'm speaking from experience here, having tried to implement M:N and abandoning it in favor of 1:1, which yielded better performance. Can M:N yield better performance than 1:1? Sure, in some circumstances. But I think that, ideally, we s…

All true. But I have been waiting nearly 30 years for a 1:1 implementation that scaled to the #threads I want to have. Still waiting...

The point of M:N schemes isn't to achieve better performance but rather to achieve higher scaling.

Re: Go hits the concurrency nail on the head

#193

Post by pdeuchler »

aczerepinski wrote: post #168
pdeuchler wrote: post #142

Earlier quoted context omitted.

Nothing you're saying is wrong, but your perspective is totally off. For someone experienced with C++, or say, Rust (ahem), obviously Go is a bit backwards when it comes to concurrency and race conditions. Obviously you can mimic go's goroutine stacks, obviously you can obtain fast thread switching. But Go isn't targeting C++ or Rust, and it's not targeting the domains those languages are best at (although admittedly…

"But Go isn't targeting C++ or Rust.. Go is trying to replace Ruby"... If you listen to Ken Thompson and Rob Pike talk about the first days of Go, it was directly targeting C++. They mention the absurdly slow compilation times of C++ code at Google, and the high complexity of code that folks were writing. I believe Steve Francia's "Standing on the shoulder" talk goes into this, but I don't have time right now to re-w…

This is correct, but they quickly pivoted to targeting the Python codebases. Rob Pike has a talk where he talks about how Google used C++ and C to rewrite hot Python paths and how they wanted Go to be able to completely replace that whole pattern. Russ also has a blog post (maybe? it also could have been a comment in a github issue, tbh I can't remember) where he mentions converting python programmers was orders of magnitude easier within Google, as the C++ programmers often had rose colored glasses about their own abilities and the tradeoffs of C++.

It's interesting, as I don't think Go would have been successful without the pivot, but I also don't think it would have been as successful if they had started off trying to replace Python.

Re: Go hits the concurrency nail on the head

#194

Post by tsmarsh »

fnordsensei wrote: post #160
hmschreck wrote: post #42

Earlier quoted context omitted.

We had a developer interview here who was an Elixir zealot - and I use that word entirely purposefully. He was very adamant that we needed to rewrite our entire platform in Elixir because it was obviously better. We ended up not hiring; he refused to touch certain technologies that make up a core part of our stack (Node being the biggest issue), and he was honestly something of a massive tool -- on our take-home thin…

Being selective about the language you work with is entirely valid. But why would you go to an interview where they're not looking for your language and try to convince them otherwise? It seems futile.

I had a weird experience where I was offered an interview at a company I respected, but who used ruby a lot. I explained that to everyone in the chain that I'd want to try and work to change that, and eventually got rejected because I didn't like ruby.

It was a weird experience. But I got a nice lunch out of it. I'm still not sure what they got out of it.

Re: Go hits the concurrency nail on the head

#195

Post by weberc2 »

erik_seaberg wrote: post #65

> Proper use of channels removes the need for more explicit locking If you're lucky. Sharing mutable state is unsafe by default (map writes can crash!) yet very common and the language doesn't help you avoid it. A good language for concurrency would also make it easy to switch between sync and async method calls; the trouble with channels is they don't support passing errors and panics without rewriting everything to…

If you're using channels "properly", then you only have one thread writing to the map at a time. In this case, "proper" use of channels is easy enough, but there are plenty of cases where "proper" use of channels is (in my opinion) a fair bit harder than proper use of mutexes, which is one of the problems Go's concurrency scheme was meant to solve.

I will say that even in spite of the above criticism, I've found that writing safe, concurrent Go is quite a lot easier (channels are still useful if not the panacea they were made out to be), but it still takes a bit of planning to minimize the risk of creating race conditions (minimizing the interaction points between goroutines, not throwing goroutines at every problem, etc). This takes experience which requires social controls instead of technical controls, which is a bummer, but on balance still better (IMHO) than the problems brought by other languages with technical controls for this particular problem.

Re: Go hits the concurrency nail on the head

#196

Post by akavel »

pdeuchler wrote: post #142
pcwalton wrote: post #92

Go concurrency is just threads. It's a particularly idiosyncratic userland implementation of them. There are two claims here I'd like to unpack further: 1. "I've measured goroutine switching time to be ~170 ns on my machine, 10x faster than thread switching time." This is because of the lack of switchto support in the Linux kernel, not because of any fundamental difference between threads and goroutines. A Google eng…

Nothing you're saying is wrong, but your perspective is totally off. For someone experienced with C++, or say, Rust (ahem), obviously Go is a bit backwards when it comes to concurrency and race conditions. Obviously you can mimic go's goroutine stacks, obviously you can obtain fast thread switching. But Go isn't targeting C++ or Rust, and it's not targeting the domains those languages are best at (although admittedly…

Why exactly do you say Go is backwards to C++ with regards to concurrency and race conditions? Really curious.

I worked on a sizeable C++ codebase, and it had a home-grown, buggy thread-pooling & task cancellation (similar to Go's context.Context) engine. Go's builtin goroutines were a breeze afterwards. Also, I debugged a race condition in this codebase. Once, and it took me a few weeks full steam digging, thinking and mental construction. I didn't even know I have one at the beginning, just had this nagging feeling. (Valgrind would take the app to a crawl, and it was speed-critical.) In Go, I can just run tests with -race flag, and it finds me truckload races at a blink, pointing to the exact place where they happened, with a stack trace sprinkled on top. I really find it hard to understand how you find Go experience backwards here. But I'm also open and listening, and very curious whether I could maybe learn something enlightening!

Re: Go hits the concurrency nail on the head

#197

Post by GordonS »

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…

> By contrast, if you only have those other abstractions you're quite limited in how you can structure your code.

OK... but what languages only have those abstractions?

Re: Go hits the concurrency nail on the head

#198

Post by pcwalton »

dboreham wrote: post #192
pcwalton wrote: post #177

Earlier quoted context omitted.

Let's be clear: the one-OS-thread-per-connection model does yield decent performance. We used to call async I/O "solving the C10K problem"—i.e. serving 10,000 clients simultaneously. I'm speaking from experience here, having tried to implement M:N and abandoning it in favor of 1:1, which yielded better performance. Can M:N yield better performance than 1:1? Sure, in some circumstances. But I think that, ideally, we s…

All true. But I have been waiting nearly 30 years for a 1:1 implementation that scaled to the #threads I want to have. Still waiting... The point of M:N schemes isn't to achieve better performance but rather to achieve higher scaling.

How many threads do you want?

Re: Go hits the concurrency nail on the head

#199

Post by zzzcpan »

sagichmal wrote: post #76
dreamcompiler wrote: post #37

Or you could just use the Actor model, which I like much better than CSP. (Or at least I think I'll like it better when I finally understand it.)

The Actor model is trivially implementable with CSP.

CSP can be implemented with Actor model and rather trivially. You can think of an actor as a programmable channel. But not the other way around. Because you can't implement unbounded nondeterminism with bounded.

Re: Go hits the concurrency nail on the head

#200

Post by weberc2 »

pjmlp wrote: post #189
weberc2 wrote: post #178

Earlier quoted context omitted.

I thought it was pretty obvious that the OP was using "runtime" to refer to an external interpreter program. The significance being the simplicity of deployment.

That is an interpreter as you very well mention.

Sometimes things have multiple names :shrug: I really like your contributions; this one seemed unnecessarily pedantic.
Post reply on HN