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

Re: Go hits the concurrency nail on the head

#261

Post by tmerr » Fri, Oct 05, 2018, 3:40 AM UTC

kureikain wrote: post #121

ken wrote: post #69

Earlier quoted context omitted.

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…

> Backed by major corporation I don't think Go success has anything to do with Google. Google engineers probably favors Java/Python. I think the key thing to make Go adopt is because the Docker project and Hashi Corp. The second most important thing is it is super easy to compile Go program and run it and adopt by DevOps teams

Eh? I can't speak for all of Google but I like me some Go. It has a culture of minimalism both in language and code, which makes it easy to pick up and read others' work. I wouldn't recommend it for all problems, but it's at least nice for backend services.

Java is a victim of its own success: it has lived through style evolutions which have lead to fragmentation in the ecosystem. Some code uses mutable datastructures with for loops, others immutable datastructures with the stream API. Some code uses dependency injection, while some doesn't. As a result it takes more time to mentally calibrate to the style when pulling up a .java file. Another imperfection: GC pauses can cause request timeouts and are annoying to debug.

Python's not perfect either: aside from the obvious performance issues, use of the awkward retrofitted type system makes me wonder why a statically typed language isn't being used to begin with. The lack of good static analysis is especially annoying at Google where the tooling is quite good.

Just my 2c

Re: Go hits the concurrency nail on the head

#262

Post by tejasmanohar » Fri, Oct 05, 2018, 3:44 AM UTC

gjm11 wrote: post #98

dmead wrote: post #43

This picture is a bit rosey, no? Literally the only deadlock I've come across in years has been in go.

What fraction of the concurrent programming you've done over those years has been in Go?

Same question. I've come across deadlocks in popular databases for heck sake haha.

Re: Go hits the concurrency nail on the head

#263

Post by devxpy » Fri, Oct 05, 2018, 4:10 AM UTC

pcwalton wrote: post #92

Go concurrency is just threads. It's a particularly idiosyncratic userland implementation of them. There are two claims here I'd like to unpack further: 1. "I've measured goroutine switching time to be ~170 ns on my machine, 10x faster than thread switching time." This is because of the lack of switchto support in the Linux kernel, not because of any fundamental difference between threads and goroutines. A Google eng…

> Finally, Go doesn't do anything to prevent data races, which are the biggest problem facing concurrent code

I've been working on a multiprocessing library -- built a wrapper function that makes any function, an atomic operation on the state.

https://zproc.readthedocs.io/en/next/user/atomicity.html

(Since it's protected by the actor model, not locks it's an enforcing mechanism)

Do you think this is a step in the right direction?

Re: Go hits the concurrency nail on the head

#264

Post by tandr » Fri, Oct 05, 2018, 4:12 AM UTC

kasey_junk wrote: post #236

jy3 wrote: post #144

Earlier quoted context omitted.

Describing its concurrency model as one of its weakness is a bold statement, because it's probably one of the biggest reason it became widely adopted. Everyone is different, but Go 's concurrency model has been the easiest for me to reason about. And I've dealt with my fair share of "async/await".

Maybe. But I’ve been developing golang full time in high scale concurrency environments for 4 years and working with a team of similar people. It’s an opinion that is near universally shared on that team. At high concurrency levels almost everything abandons standard golang concurrency patterns and tools.

Would you be so kind and explain what term "high concurrency levels" implies?

thank you in advance.

Re: Go hits the concurrency nail on the head

#265

Post by opportune » Fri, Oct 05, 2018, 4:22 AM UTC

xor1 wrote: post #97

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…

>Yes. Because mainstream is what you should select for when choosing your tools. Ease of hiring experienced developers should absolutely be a part of selection criteria, but of course it should not be the only one. What good is it going to do you when you picked Elixir/Scala/Rust over Python/Go/Ruby, you need to hire senior engineers who can hit the ground running ASAP, and you have limited resources/budget? It's goi…

I don't think it makes sense to group Scala with Elixir and Rust because it interfaces so easily with Java and is used a lot for Spark applications

Re: Go hits the concurrency nail on the head

#266

Post by kasey_junk » Fri, Oct 05, 2018, 5:07 AM UTC

tandr wrote: post #264

kasey_junk wrote: post #236

Earlier quoted context omitted.

Maybe. But I’ve been developing golang full time in high scale concurrency environments for 4 years and working with a team of similar people. It’s an opinion that is near universally shared on that team. At high concurrency levels almost everything abandons standard golang concurrency patterns and tools.

Would you be so kind and explain what term "high concurrency levels" implies? thank you in advance.

Consumer facing systems. System wide throughput between 6-12 million QPS (daily low/high) (query body average size is 1.5KB). Each server tops at ~130K QPS. On a system with 2 1 GB NICs we pop the NIC. On a 10G we pop the CPU.

Current bottleneck is the golang http/net libs. Would likely need to rewrite it from the NIC up to do better.

Re: Go hits the concurrency nail on the head

#267

Post by jrs95 » Fri, Oct 05, 2018, 5:42 AM UTC

TheDong wrote: post #212

vthallam wrote: post #15

Earlier quoted context omitted.

I think you are being down-voted for just making a generalized claim with no mention of why? care to explain, what areas does PHP out-perform Go?

PHP's concurrency model is really nice: Spawn a process per request, and otherwise don't do concurrency because that's a mistake. Yes, you can use CGI to get the same model in practically any language, but we see very few languages these days making this tradeoff. For some reason, people decided they wanted the performance gain of spawning threads per request instead of processes per request. Honestly, it's ridiculou…

PHP no longer works like this in practice. FastCGI etc uses persistent processes with a thread per request, and thread per request is pretty standard for most platforms that don't have good async support at this point.

Re: Go hits the concurrency nail on the head

#268

Post by IloveHN84 » Fri, Oct 05, 2018, 7:03 AM UTC

pcwalton wrote: post #92

Go concurrency is just threads. It's a particularly idiosyncratic userland implementation of them. There are two claims here I'd like to unpack further: 1. "I've measured goroutine switching time to be ~170 ns on my machine, 10x faster than thread switching time." This is because of the lack of switchto support in the Linux kernel, not because of any fundamental difference between threads and goroutines. A Google eng…

Just focus on C++

Re: Go hits the concurrency nail on the head

#269

Post by fulafel » Fri, Oct 05, 2018, 7:22 AM UTC

pcwalton wrote: post #244

jules wrote: post #207

Earlier quoted context omitted.

That Go concurrency is threads is the point of the article. It says this explicitly: "You can think of goroutines as threads, it's a fairly good mental model. They are truly cheap threads". If OS threads become as cheap as userland threads then the implementation of userland threads becomes unnecessary, but the conceptual model stays the same. In other languages, asynchronous APIs return futures or have explicit call…

Note that there is a widely-used implementation of Cilk for Rust, known as Rayon, used in Firefox Quantum among other projects.

After a web search I read that Rayon is a word play on Cilk, but neither are dictionary words.. Would someone explain the word play in the names for us non-native speakers?

Re: Go hits the concurrency nail on the head

#270

Post by loonyphoenix » Fri, Oct 05, 2018, 7:57 AM UTC

fulafel wrote: post #269

pcwalton wrote: post #244

Earlier quoted context omitted.

Note that there is a widely-used implementation of Cilk for Rust, known as Rayon, used in Firefox Quantum among other projects.

After a web search I read that Rayon is a word play on Cilk, but neither are dictionary words.. Would someone explain the word play in the names for us non-native speakers?

Rayon[1] is artificial silk.

[1]: https://en.wikipedia.org/wiki/Rayon