Live data from Hacker News

Go hits the concurrency nail on the head

eli.thegreenplace.net

141–150 of 318 posts

Re: Go hits the concurrency nail on the head

#141

Earlier quoted context omitted.

I thought this was one of the "not strong" points of Rust? It had Tokyo, futures, async/await but I vaguely remember many libraries waiting for the async story to settle down? Is there a one standard way to do async now in Rust stable?

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 :-)

Re: Go hits the concurrency nail on the head

#142

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 there are some overlaps between Go and Rust). Go is trying to replace Ruby, Python, and JS. For programmers who only know those languages, or haven't had the opportunity to work in more "heavy" languages, Go makes it dead simple and intuitive to do things that previously would have been completely out of reach. All you're arguing is that if you go farther "down" the stack so to speak you can accomplish everything Go does, which of course is true, since it's turtles all the way down.

The fact of the matter is, if someone boots up a brand new linux laptop goroutine switching _will_ be faster than thread switching. That doesn't mean Go is super crazy performant, or better than C++ or Rust, it means someone who's only programming experience is Rails apps can now write performant multi threaded code with orders of magnitude less domain experience. Same with race detectors. Multithreaded Python is a complete minefield for race conditions. Sure, you might not segfault, but you have to think if you use fork() or spawn() depending on the OS, you have to install libraries to detect races, you have to write special tests. With Go all of that comes out of the box and it makes it _easy_.

Go does nothing new, and a lot of languages do things a lot better. Erlang is mentioned in other comments, Erlang is a fantastic language for concurrency and a fantastic language in general. It's also incredibly hard to find programmers who code in it, or are willing to learn it. It's also incredibly hard to sell to the business people higher up. It's also very hard to find Ops people who can competently support an Erlang stack. C++ gives you the power to build formally correct real time systems, but it also gives you the power to blow your whole leg off if you don't know _exactly_ what you're doing. I can go even further down the stack with C and assembly but I think you get the point, it's all about tradeoffs. Go allows programmers to reason and think about concurrency without having to worry about linux kernel PRs, without having to worry about how to share memory, without having to worry about stack performance.

*edited for clarity

Re: Go hits the concurrency nail on the head

#143
post #77
post #44

Earlier quoted context omitted.

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 :(

> 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…

Anecdotally, there are at least three people at work who say that "go is used at google so it will be around forever and I can be sure there will be support for it".

Re: Go hits the concurrency nail on the head

#144

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…

Describing its concurrency model as one of its weakness is a bold statement, because it's probably one of the biggest reason it became widely adopted.

Everyone is different, but Go 's concurrency model has been the easiest for me to reason about. And I've dealt with my fair share of "async/await".

Re: Go hits the concurrency nail on the head

#145
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…

I've found that being mainstream is the most important factor in choosing tooling. Being mainstream has incredible advantages. It means you're going to find lots of help, resources, answers to questions, sample code, and high quality and well maintained libraries.

If everyone chose mainstream languages we would never invent and adopt any other language ever.

Re: Go hits the concurrency nail on the head

#146
post #71

Earlier quoted context omitted.

I think syntax actually matters a lot more then people tend to give credit for in a language's success. I suspect this is why functional languages have struggled to became very popular while languages with C like syntax have added some functional features instead. The learning curve for imperative programming structure just seems easier for people to understand and work with.

The impact of syntax is really undervalued. Syntax matters because many people are exposed to new languages through familiarity with other languages, as opposed to cramming a guide in isolation. And since programming languages are for humans, the cognitive load of understanding through reading and expressing through writing depends on one's ability to map the concepts to the code and vice versa. This is easier when s…

Anecdotally, it was really difficult for me to convince myself to learn SQL specifically due to the syntax and the fact that unlike the imperative languages I normally use it was declarative.

Re: Go hits the concurrency nail on the head

#147

Earlier quoted context omitted.

Shared-memory threads are worse than async/await. I'd rather have GOTO than data races, since, while it might be hard to model in your head, at least it's deterministic and using it wrong doesn't cause UB. p.s. https://vorpus.org/blog/notes-on-structured-concurrency-or-g...

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

Re: Go hits the concurrency nail on the head

#148
post #93
post #84

Earlier quoted context omitted.

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... )

So does Ericsson still use Erlang in their recent network hardware etc?

I recall hearing no, somewhere. I am under the understanding, (don't know where from) that Cisco DOES use Erlang in their stack, and there is a group of people at VMware that does.

Re: Go hits the concurrency nail on the head

#149

Earlier quoted context omitted.

I think syntax actually matters a lot more then people tend to give credit for in a language's success. I suspect this is why functional languages have struggled to became very popular while languages with C like syntax have added some functional features instead. The learning curve for imperative programming structure just seems easier for people to understand and work with.

Yeah, but is it because people actually like the syntax? Some languages seem to be attractive to people right from the start, like Python. Some take a while to grow on you but then you realise their brilliance and don't want anything else, like Lisp. C isn't either of those.

FWIW, I've disliked the look of Python from the first time I saw it and loved Lisp-like syntax immediately. Can agree on C though.

Re: Go hits the concurrency nail on the head

#150
post #94

Earlier quoted context omitted.

True, but Go and Erlang don't occupy the same niche. Go is imperative, while Erlang is mostly functional. Go is AOT (ahead-of-time) compiled, while Erlang runs on a VM. Go is statically typed, while Erlang is dynamically typed (I know about Dializer). Go concurrency primitives are designed to coordinate goroutines living in the same process, while Erlang concurrency primitives are designed to coordinate Erlang "proce…

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

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