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

Re: Go hits the concurrency nail on the head

#31

Post by ken » Thu, Oct 04, 2018, 5:51 PM UTC

> 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 see how it's any better than Erlang or Clojure. The only controversial part of Eli's claim is the implication that other languages that get concurrency right aren't "mainstream". That's not a well-defined term and so naturally this is going to irk many people.

Perhaps the title would have been more accurate as "Go hits the concurrency nail on the head, using the hammer of K&R style". :-)

Re: Go hits the concurrency nail on the head

#32

Post by sitkack » Thu, Oct 04, 2018, 5:52 PM UTC

seanmcdirmid wrote: post #27

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.

Have they moved on from Starship?

Re: Go hits the concurrency nail on the head

#33

Post by the_clarence » Thu, Oct 04, 2018, 5:52 PM UTC

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…

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

Re: Go hits the concurrency nail on the head

#34

Post by LukeShu » Thu, Oct 04, 2018, 5:53 PM UTC

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…

"avoid holding two locks simultaneously" only guarantees no deadlocks if locks are your only form of inter-thread-blocking. If you have synchronization points or channels/pipes or anything else, that needs to be expanded to include "avoid using a channel while you hold a lock" and similar for every blocking primitive.

Re: Go hits the concurrency nail on the head

#35

Post by tracker1 » Thu, Oct 04, 2018, 5:53 PM UTC

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. That said, I think that starting more monolithic an breaking pieces off as needed is a strong approach, best started with Node. From there, you want different pipelines/processes/queues/workers in other platforms, great. Write that piece in go+grpc and call it from your api endpoint server.

So many times I see devs want to go the optimal X, without even considering if "optimal" is needed, and if it's prudent to start with.

Re: Go hits the concurrency nail on the head

#36

Post by CydeWeys » Thu, Oct 04, 2018, 5:54 PM UTC

JepZ wrote: post #17

erokar wrote: post #10

Earlier quoted context omitted.

I agree Go is more popular than Elixir — but is it actually a popular language? At least I wouldn't consider it mainstream in the sense Java, C# and Python are.

Well, just ask the Toibe index: https://www.tiobe.com/tiobe-index/ It looks like Elixier ist by far less popular than the other discussed languages.

Huh, I'm super surprised that VB .NET is growing. I used it at my last job briefly for unfortunate historical reasons and we were trying to run screaming away from it as fast as possible to C#. It felt like the runt of the litter of the .NET ecosystem; so many things worked better in C#.

Re: Go hits the concurrency nail on the head

#37

Post by dreamcompiler » Thu, Oct 04, 2018, 5:54 PM UTC

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

Re: Go hits the concurrency nail on the head

#38

Post by tracker1 » Thu, Oct 04, 2018, 5:54 PM UTC

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

Also, can always front with gopher (written in go) and defer to other systems via reverse proxy.

Re: Go hits the concurrency nail on the head

#39

Post by david-cako » Thu, Oct 04, 2018, 5:55 PM UTC

GatoVolador wrote: post #11

PHP is way better with this than Go, and much easier to learn.

low quality bait

Re: Go hits the concurrency nail on the head

#40

Post by pythonaut_16 » Thu, Oct 04, 2018, 5:55 PM UTC

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…

I don't think Go has better concurrency than Erlang, but go does have generally better raw performance. Ultimately I think both are good languages they just make different trade offs.

If I was designing a command line app I'd probably choose Go, if I was designing a web service I'd probably choose Elixir/Erlang. Of course those can easily flip; there are classes of command line apps where I might choose Elixir/Erlang and there are classes of web services where I might choose Go.

I can't speak to Clojure though.