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

Re: Go hits the concurrency nail on the head

#71

Post by niftich » Thu, Oct 04, 2018, 6:31 PM UTC

gonehome wrote: post #58

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

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 similar languages look and -- through the power of abstraction, appear to -- work in similar ways. Go benefits from looking similar to the wider C family, while Erlang suffers from a syntactic heritage that never achieved as much prominence. The prevalence of languages in the syntactic style of C allows people unfamiliar with Go to be able to glean a lot of what's going on, and develop their understanding of Go-specific features gradually.

Re: Go hits the concurrency nail on the head

#72

Post by reacharavindh » Thu, Oct 04, 2018, 6:35 PM UTC

lurker_level_53 wrote: post #9

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.

Is this a RUST reference?

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?

Re: Go hits the concurrency nail on the head

#73

Post by anothergoogler » Thu, Oct 04, 2018, 6:36 PM UTC

tracker1 wrote: post #67

anothergoogler wrote: post #50

Earlier quoted context omitted.

What a lovely fusion of the blub paradox and a middlebrow dismissal.

Kind of, though your tone seems a bit dismissive. In the end, the Node/JS community, mostly because of npm, has a lot to offer and that is the ability to create a working product more quickly than most other options in most conditions.

Pardon my snark! In all seriousness, isn't it possible that you're more productive with Node because you're more familiar with it and its ecosystem?

Re: Go hits the concurrency nail on the head

#74

Post by pjmlp » Thu, Oct 04, 2018, 6:37 PM UTC

virmundi wrote: post #46

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…

Go doesn’t need a VM. That’s key. You get good concurrency with an easy to deploy binary that can target the major chips.

Modula-2 did it first in 1978.

With co-routines and static compilation.

Re: Go hits the concurrency nail on the head

#75

Post by pjmlp » Thu, Oct 04, 2018, 6:39 PM UTC

ken wrote: post #69

virmundi wrote: post #46

Earlier quoted context omitted.

Go doesn’t need a VM. That’s key. You get good concurrency with an easy to deploy binary that can target the major chips.

That's a good point. Modern programming languages are all pretty big and complex and whenever someone tries to nail down " this is why it's good/popular" there always seem to be other significant factors that got missed. After all, if it were just one factor that leads to programming language popularity, we could design the Next Big Language by just following that recipe! In the case of Go, I can imagine many of its…

Modula-2 used to fit all those points, except backed by major corporation, unless we consider GM a major corporation.

Re: Go hits the concurrency nail on the head

#76

Post by sagichmal » Thu, Oct 04, 2018, 6:42 PM UTC

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.

Re: Go hits the concurrency nail on the head

#77

Post by weberc2 » Thu, Oct 04, 2018, 6:43 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 :(

> 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 Ericcson. I don't know very much about Ericcson, but it wouldn't surprise me to find out they spent many times the amount on Erlang that Google spends on Go.

There are probably lots of reasons why Go is successful, but I'm positive that it has more to do with simplicity, learning curve, tooling, ecosystem, etc than it does with corporate sponsorship or marketing.

Re: Go hits the concurrency nail on the head

#78

Post by camgunz » Thu, Oct 04, 2018, 6:44 PM UTC

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…

Go's answer to this is tooling, -race in this case. I think Go's general strategy of moving complexity/functionality to external tools is a little underexamined -- it's definitely interesting, especially as it's kind of a middle path between "language with lots of helper stuff" and "IDE with lots of helper stuff".

Re: Go hits the concurrency nail on the head

#79

Post by macintux » Thu, Oct 04, 2018, 6:44 PM UTC

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.

Erlang, I think, is crippled out of the box wrt performance by its emphasis on immutable data, live troubleshooting, small processes with lots of messaging, etc.

These are the things that make it a brilliant language for use cases where it's well-suited. Not every language has to be a kitchen sink language like Java, thankfully. I like opinionated languages with well-defined strengths and weaknesses.

Re: Go hits the concurrency nail on the head

#80

Post by siscia » Thu, Oct 04, 2018, 6:45 PM UTC

Leave aside the extremely interesting engineer behind th go scheduler and goroutine.

The abstraction that goroutine provides is a simple, indipendent, isolated unit of execution.

You start it, and that is all you can do with it.

No way to set priorities, decided when to stop it or inspect it.

After the goroutine start the only interface that you get is a channel where to push and pop stuff from. Which is just too limited consider the complete lack of genetics.

It is really the best we can come up with?