Go hits the concurrency nail on the head • Hacker News Board

Re: Go hits the concurrency nail on the head

#161

Post by ZainRiz » Thu, Oct 04, 2018, 8:50 PM UTC

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…

He does. He referenced it when referring to the color of functions: "I've enjoyed Bob Nystrom's What Color is Your Function[1] for explaining how annoying the model of "non-blocking only here, please" is."

The linked article [1] explains his take on why those futures, etc not good enough.

[1]http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...

Re: Go hits the concurrency nail on the head

#162

Post by pjmlp » Thu, Oct 04, 2018, 8:51 PM UTC

Sharlin wrote: post #150

dnautics wrote: post #140

Earlier quoted context omitted.

Erlang is AOT, the vm reads compiled and optimized bytecode.

The point is that Erlang (like Java etc) needs a runtime, Go doesn't.

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?

Re: Go hits the concurrency nail on the head

#163

Post by fnordsensei » Thu, Oct 04, 2018, 8:55 PM UTC

EpicEng wrote: post #83

mirceal wrote: post #22

Earlier quoted context omitted.

Yes. Because mainstream is what you should select for when choosing your tools. On a more serious note: I’m very wary of people that have discovered the one true language, framework, etc. That’s how you end up with 100 lines of go instead a one line bash script. That’s how you end up with “java developers” that are more concerned with design patterns instead of actual working code. I could go on. Learn about as many…

>Yes. Because mainstream is what you should select for when choosing your tools It's a hugely important consideration. More devs, larger community, better support, more/better tooling, more libs, etc. If you don't think those matter then you're only concerned with pet/toy projects.

There's also a zero chance of working with anything that's better than mainstream.

Re: Go hits the concurrency nail on the head

#164

Post by presscast » Thu, Oct 04, 2018, 8:55 PM UTC

nimish wrote: post #44

ken wrote: post #31

> I'm happy to go on record claiming that Go is the mainstream language that gets this really right. And it does so by relying on two key principles in its core design... The unmentioned third principle that it relies on is: "Curly braces, so it looks almost like C if you squint". That's what makes a language "mainstream" these days. It looks like Go is very good at concurrency, but from everything I've read, I don't…

Yeah, irritatingly. Erlang had this nailed years before. It's a bit too weird syntactically, and doesn't have the full force of Google pushing it, so it gets ignored :(

It's also not simple... at all.

Re: Go hits the concurrency nail on the head

#165

Post by steveklabnik » Thu, Oct 04, 2018, 8:56 PM UTC

reacharavindh wrote: post #141

steveklabnik wrote: post #89

Earlier quoted context omitted.

You can use tokio with stable Rust. Async/await is in nightly, but won’t be stable until early next year. As part of that work, some of the APIs are changing, but there is/will be a compatibility layer to make upgrading from the stuff today to tomorrow’s stuff easier. That said, to address the question directly, rust-the-language provides a stronger guarantee than Go: rust code is free of data races at compile time.…

Thanks for the patient and detailed response Steve. I don't have a particular need for Async at the moment, and commented impulsively, but ended up learning more about current state of affairs from your response :-)

You’re welcome! It’s been... confusing. Such is life on the edge!

Re: Go hits the concurrency nail on the head

#166

Post by spinningslate » Thu, Oct 04, 2018, 9:01 PM UTC

tomjakubowski wrote: post #147

spinningslate wrote: post #131

Earlier quoted context omitted.

Erlang doesn't do shared memory. It's a message passing, shared-nothing model. I believe GO is the same.

Go is not shared-nothing: if you write a slice to a channel between two goroutines, for example, the memory that the slice references is now shared between the goroutines

thanks for the correction.

Re: Go hits the concurrency nail on the head

#167

Post by thinkpad20 » Thu, Oct 04, 2018, 9:01 PM UTC

jerf wrote: post #104

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…

In terms of raw capability, Haskell is the concurrency winner. Not only does it have basically every paradigm, they even all work together reasonably well. (Not perfectly, but reasonably well.) But I don't think you can argue Haskell is mainstream. It continues to be on a fairly slow growth trajectory from what I see, but it's not in any danger of cracking into the top tier language set anytime soon. Go just might in…

True, but I think that the "mainstream-ness" of Go (debatable as it is) was of secondary importance to the article, which didn't even mention that there are other languages out there which solve the concurrency problem in other/better ways. Whether or not a language is mainstream is more or less a matter of opinion, in any case. Certainly Haskell, Rust or Erlang (to name a few) are probably less widely used than Go, but none of them are obscure, so to not mention them at all suggests that the author is either being disingenuous, is not aware of those languages' capabilities, or simply forgot.

Re: Go hits the concurrency nail on the head

#168

Post by aczerepinski » Thu, Oct 04, 2018, 9:02 PM UTC

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…

"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-watch and make sure I'm citing the right talk.

Re: Go hits the concurrency nail on the head

#169

Post by jashmatthews » Thu, Oct 04, 2018, 9:06 PM UTC

notriddle wrote: post #115

alberth wrote: post #12

Earlier quoted context omitted.

I really wish someone like Mike Pall (of LuaJIT fame) would work on BEAM to make it computationally as fast as Go on raw performance.

The BEAM is already much more performant than, for example, the Ruby reference implementation. And look at what people have managed to build with Ruby!

Erlang 19 is only 10% faster than CRuby 2.3 on a simple factorial bench. Web throughput is even closer as lots of it is C extensions.

I haven't made the comparison myself for a while but I suspect it's still very close.

Re: Go hits the concurrency nail on the head

#170

Post by qznc » Thu, Oct 04, 2018, 9:07 PM UTC

pjmlp wrote: post #162

Sharlin wrote: post #150

Earlier quoted context omitted.

The point is that Erlang (like Java etc) needs a runtime, Go doesn't.

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 runs. You don't have to care about the version of some "runtime" already on your server.