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

21–30 of 318 posts

Re: Go hits the concurrency nail on the head

#21

Post by brightball »

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.

You’re not wrong. No matter the available constructs, there on concurrency guarantees that you can’t make in any language with a shared memory model.

Everything has tradeoffs.

Re: Go hits the concurrency nail on the head

#22

Post by mirceal »

vvanders wrote: post #4
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 think the main argument is that Elixir isn't as mainstream which is a fair point. That said I agree with everything, Erlang pioneered in this space and has shown to scale very well[1] in a proven way over the last few decades. [1] https://phoenixframework.org/blog/the-road-to-2-million-webs...

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 things possible, form your own opinions, choose the right tool for the job.

Re: Go hits the concurrency nail on the head

#23

Post by nemothekid »

eatbitseveryday wrote: post #19
rubiquity wrote: post #8

Earlier quoted context omitted.

Hah! Good one. To anyone else not in on the joke, parent is referring to the language that is often discussed on HN and known for having a sometimes overly enthusiastic community, Pony: https://www.ponylang.io/

Hah! You must be in on another joke, because OP was referring to Rust ;) > Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety. www.rust-lang.org edit: /s

Wooosh

Edit: I made this post, but I thought afterwards, what if you were you being dense on purpose, and I didn't get the joke?

Re: Go hits the concurrency nail on the head

#24

Post by [deleted] »

eatbitseveryday wrote: post #19
rubiquity wrote: post #8

Earlier quoted context omitted.

Hah! Good one. To anyone else not in on the joke, parent is referring to the language that is often discussed on HN and known for having a sometimes overly enthusiastic community, Pony: https://www.ponylang.io/

Hah! You must be in on another joke, because OP was referring to Rust ;) > Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety. www.rust-lang.org edit: /s

[deleted]

Re: Go hits the concurrency nail on the head

#25

Post by pknopf »

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?

Yes

Re: Go hits the concurrency nail on the head

#26

Post by xyproto »

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.

Implementing a 3D vector or quaternion library in Go feels like a really bad fit, mainly due to the lack of operator overloading (which can easily be abused, like >> in C++). But it is an example of a field where Go allows programmer to express their ideas in a less direct way.

I think Go is great, but I don't think describing parts of it as less expressive than some other languages is banal.

Expressiveness has a sweet spot, though. Too many keywords and constructs makes a language harder to learn, and makes it too easy for developers to build their own little weird worlds that discourages team work and lowers readability.

Re: Go hits the concurrency nail on the head

#27

Post by seanmcdirmid »

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.

Jefferson’s Timewarp did that with “virtual time” using optimistic rather than pessimistic concurrency constructs so popular today outside of transactions.

Re: Go hits the concurrency nail on the head

#28

Post by [deleted] »

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?

[deleted]

Re: Go hits the concurrency nail on the head

#29

Post by dreamcompiler »

kazinator wrote: post #7
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.

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.

Re: Go hits the concurrency nail on the head

#30

Post by CydeWeys »

mirceal wrote: post #22
vvanders wrote: post #4

Earlier quoted context omitted.

I think the main argument is that Elixir isn't as mainstream which is a fair point. That said I agree with everything, Erlang pioneered in this space and has shown to scale very well[1] in a proven way over the last few decades. [1] https://phoenixframework.org/blog/the-road-to-2-million-webs...

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