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

61–70 of 318 posts

Re: Go hits the concurrency nail on the head

#61

Post by andy_ppp »

le-mark wrote: post #16
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.

How are the deployment, library ecosystem, build, and tooling stories for Elixir? Note I don't really care about the answer to the above, I just wish as a profession we could get past the tribalism and boosterism and have rational technical dicussions about things that matter as opposed to banal declarations about 'expressiveness' etc.

Libraries are considerably better than Golang and more all encompassing because you have 20 years of Erlang libraries that you can just use.

Deployment is getting better and you can just great a release in a docker image and deploy that like you would anything else. Obviously it's no way near as small (or simple) as FROM scratch is with Golang binaries.

Tooling is fantastic in some ways and poor in others - for example you can get an interactive IEx terminal running onto your Elixir cluster to debug issues, although I'm not sure about the other parts. Dependancy management is fantastic and something Golang struggles with. Not sure about other tools for Golang though!

The final thing I'd say is once you have a runtime that has Supervision and restarting of processes you never want to go back to worrying about what to do in the cases you haven't considered.

Re: Go hits the concurrency nail on the head

#62

Post by bunderbunder »

Izkata wrote: post #59
bunderbunder wrote: post #54

> 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. That's a list of problems that are specific to mutable state that is shared among threads. As the old saying goes, "If it hurts, don't do it." We've had ways of doing multithreaded…

> We've had ways of doing multithreaded code that are easier to reason about for decades. They really do work quite well. Why people doggedly insist on pretending they don't exist is a perennial mystery to me. Not a single one was mentioned during my CS undergrad; shared-memory threads were, many times. I think simple ignorance is the answer.

I think a simple love of complexity is also part of it. It's fun to do things that make you feel clever.

One experience I've had more often than I'd care to admit is diving into a multithreaded module with the intent of fixing a race condition bug, and finding that I could simultaneously remove the bug and realize a healthy performance improvement by making it single-threaded.

Which, for that matter, is another reason to be wary of mutexes and shared mutable data: Memory barriers do really impolite things to pipelines and caches in a modern CPU.

Re: Go hits the concurrency nail on the head

#63

Post by cube2222 »

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.

I don't agree. It's just that the familiar is easier. If you first teach someone programming with haskell, they'll have the same hard time switching to C.

Re: Go hits the concurrency nail on the head

#64

Post by dev_dull »

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.

Go made tradeoffs that maybe didn’t make it “better” at concurrency, but it really did make it easier than alternatives.

Re: Go hits the concurrency nail on the head

#65

Post by erik_seaberg »

> 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 wrap them in a pseudo-generic struct.

Re: Go hits the concurrency nail on the head

#66

Post by another-cuppa »

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.

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.

Re: Go hits the concurrency nail on the head

#67

Post by tracker1 »

anothergoogler wrote: post #50
tracker1 wrote: post #35

Regarding one of the last comments, I'd say the two biggest reasons for using Node over Go, at least initially. Prototyping speed, and a stronger connection to a web front-end. I've really not seen any other language/platform work faster for developing a huge variety of implementation details than JS/Node. IT's a really good balance of performance, flexibility and ease of development. Is it a Panacea? Of course not.…

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.

Re: Go hits the concurrency nail on the head

#68

Post by siscia »

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.

The architecture of the BEAM is quite complex.

I don't believe you could reach the same raw performance that you have with go.

However it is an unfair comparison, BEAM processes do much more than coroutines.

Re: Go hits the concurrency nail on the head

#69

Post by ken »

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.

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 attributes are significant:

- Good concurrency model

- Familiar style for imperative C/Algol-family programmers

- Requires no VM

- Backed by major corporation

- Runs on all major OSs

- etc

Actually, I think I'm changing my mind. I'd put "corporate backing" higher on the list. Some languages have gotten a huge boost by being backed by a major corporation (classic example: Objective-C), and I'm having trouble thinking of a general-purpose programming language backed by a major company that did not become popular (Dart would be my best guess but even that seems to be doing alright).

Re: Go hits the concurrency nail on the head

#70

Post by siscia »

Izkata wrote: post #59
bunderbunder wrote: post #54

> 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. That's a list of problems that are specific to mutable state that is shared among threads. As the old saying goes, "If it hurts, don't do it." We've had ways of doing multithreaded…

> We've had ways of doing multithreaded code that are easier to reason about for decades. They really do work quite well. Why people doggedly insist on pretending they don't exist is a perennial mystery to me. Not a single one was mentioned during my CS undergrad; shared-memory threads were, many times. I think simple ignorance is the answer.

I don't believe this holds.

We are suppose to be engineers, we need to do our research on design and methodologies before to code.

And even if we really don't find simpler solutions, there is supposed to be a more senior engineer check our code and provide feedback.

Ignorance should not be an excuse...

Post reply on HN