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

151–160 of 318 posts

Re: Go hits the concurrency nail on the head

#151

Post by Sharlin »

dnautics wrote: post #143
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…

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

I'm sure somebody said the same thing about GWT too.

Re: Go hits the concurrency nail on the head

#152

Post by gonehome »

ken wrote: post #87
gonehome wrote: post #58

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.

Syntax is a crucial component of any programming language. I would disagree, though, that there's anything inherently easier about imperative languages. Could it not be that it's simply more familiar to people today? People don't (IME) learn to program in school. They learn by futzing around with whatever free thing is on their computer. In the 1980's we had BASIC, and today we have JavaScript, and Python/Ruby/Java/C…

It's hard to disambiguate familiarity, but I'd suggest that imperative languages are more similar to spoken/written human language, particularly english.

I'd suspect if you gave someone who didn't know lisp or java a simple program and had them try and explain what it was doing they'd have more luck with understanding the java syntax.

Re: Go hits the concurrency nail on the head

#153

Post by AnimalMuppet »

another-cuppa wrote: post #66
gonehome wrote: post #58

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.

I don't know about that. I grokked C's syntax immediately, just from reading K&R, without actually having a compiler to try anything on. It just made sense to me.

I suspect (but cannot prove) that certain languages and/or programming styles make more sense for certain people, and others do so for other people. (There also is almost certainly some bias toward familiarity.)

Re: Go hits the concurrency nail on the head

#154

Post by AnimalMuppet »

weberc2 wrote: post #77
nimish wrote: 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…

Tooling and ecosystem: Yes, but how much did Google spend on developing the tooling and ecosystem? Forget the marketing - libraries, tooling, and ecosystem are where corporate support pays off for a language.

Re: Go hits the concurrency nail on the head

#155

Post by iainmerrick »

Do people really find CSP a good approach to concurrency? I've always thought that channels were a relatively poor choice of fundamental primitive -- channel-based concurrency is tricky to get right and not very composable.

Most viable concurrency primitives are in some sense equivalent (you can build condition variables out of channels and vice-versa, say) but that doesn't mean they're equally good.

Java has per-object "synchronized" and "notify" as its core constructs, but it's a bad idea to use those directly for day-to-day concurrency tasks. Much better to use library classes like ThreadPoolExecutor and Future.

In Go, do you tend to use channels directly, or do you use higher-level wrappers?

Re: Go hits the concurrency nail on the head

#156

Post by rozap »

alberth wrote: post #12
erokar wrote: post #3

According to the author Go make concurrent programming "the best experience, by far, compared to other popular programming languages today." I beg to differ. I fail to see why I should choose Go over Elixir/Erlang for concurrency. Elixir's cuncurrency mechanisms are at least as good — and I would argue better — than Go's, and Elixir as a language has an expressiveness that Go lacks.

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.

I don't think it's going to happen, due to the stack+heap per process and lack of shared memory (ok yea ETS sure) which you need for fault tolerance, necessarily requiring more copying than conventional languages. I think there are different tradeoffs that make good CPU bound performance (like Java or Go) on BEAM pretty much impossible.

Re: Go hits the concurrency nail on the head

#157

Post by pdeuchler »

weberc2 wrote: post #77
nimish wrote: 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…

I don't think most of this is true... the Go core team is at least 20ish people, and that's just engineers not PMs, Managers, or other support staff. Plus the tools and kubernetes/gcloud teams. It's also kind of disingenuous to call any team lead by Rob Pike and Ken Thompson "small"... yeah they might not have hundreds of people but they can certainly wield a hell of a lot of influence.

Google also spends quite a decent amount promoting Go and donating to OSS that promotes Go.

You're not wrong about the comparison to Ericcson/Erlang though, or most of the reasons for Go's success, but you can't discount the Google factor.

Re: Go hits the concurrency nail on the head

#158

Post by pkaye »

dreamcompiler wrote: post #29
kazinator wrote: post #7

Earlier quoted context omitted.

Actually it's very easy to avoid data-structure related deadlocks: - avoid holding two locks simultaneously: that guarantees no deadlocks. - if you have to hold several locks, always acquire them in the same order in all scenarios. The "avoid holding multiple locks" rule also harmonizes very well with "minimize the durations/sizes of critical regions". That is, hold a lock over the minimum number of machine instructi…

- Or if you have to hold several locks, grab them all atomically and if even one grab fails, release them all and try again later. - If you really need all the locks right now, steal the ones you don't own from another thread, and make sure all threads can deal with lock theft. It's not always easy to sort out the best way to deal with deadlocks. Each approach has significant tradeoffs.

How would you do this in Go? If not Go, what language has the capability?

Re: Go hits the concurrency nail on the head

#159

Post by AnimalMuppet »

ken wrote: post #60
the_clarence wrote: post #33

Earlier quoted context omitted.

You’re mentioning functional languages. That’s not for everyone or every usecase. (I love Erlang.)

So, in the world of concurrency, are imperative languages good for every person and every use case? :-) My intention was not to single out functional languages. Those were just the first languages I thought of with the best concurrency support. (I don't think it's mere coincidence, though, that so many concurrency-aware languages are functional. If concurrency is a major concern, perhaps one should consider that "mai…

> So, in the world of concurrency, are imperative languages good for every person and every use case? :-)

Clearly, no.

I think it comes down to the question of shared mutable state. Functional languages say "don't do that, it's evil" - with some justification. If the problem doesn't push you toward shared mutable state, then consider functional languages.

When could the problem push you toward shared mutable state? I worked on a video router. You had maybe 100 video sources, maybe 80 video destinations, and six different sources of control. All six sources of control needed to see the same state of what inputs were connected to what outputs. So the fundamental nature of the problem was one giant shared mutable state.

Re: Go hits the concurrency nail on the head

#160

Post by fnordsensei »

hmschreck wrote: post #42
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…

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.
Post reply on HN