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

241–250 of 318 posts

Re: Go hits the concurrency nail on the head

#241

Post by nelsonje »

lachlan-sneff wrote: post #235
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…

I've never heard of cilk before, but it seems fascinating. Is there any material I could read on how this is implemented?

This is the canonical Cilk paper: http://supertech.csail.mit.edu/papers/cilk5.pdf

Re: Go hits the concurrency nail on the head

#242

Post by xor1 »

mirceal wrote: post #135
xor1 wrote: post #97

Earlier quoted context omitted.

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

a senior developer, by definition, will hit the ground running with mostly anything you use. that's the senior part in senior developer. also if you believe that people need years of use to be good in any language/tools/framework you need to figure out how to attract better people. also, the question you need to ask yourself is: do you want to build something with a technology you've selected and think it's the best…

>a senior developer, by definition, will hit the ground running with mostly anything you use. that's the senior part in senior developer.

a senior developer also gets to be picky in what stacks they want to work with. usually it's what they are familiar and comfortable with, or something similar to it

>also if you believe that people need years of use to be good in any language/tools/framework you need to figure out how to attract better people.

even the best engineers have ramp-up time when starting a new job that involves a new code base. that ramp-up time is increased significantly when it's a language that they aren't familiar with. feel free to convince me otherwise, im all ears

>sometimes, not building something or various parts of something is more valuable that building something that you don't need fast.

what about when it's not?

Re: Go hits the concurrency nail on the head

#243

Post by marcosdumay »

dboreham wrote: post #217
zzzcpan wrote: post #210

Earlier quoted context omitted.

But then with a million of threads either M:N or 1:1 you have other problems, namely the whole shared memory multithreading model breaks and you can forget about all the locks/channels if you want to actually do something useful with that.

I believe there are boxes in production with 1E6 live connections.

If they exist, they are running software written on either C or Rust, that can avoid memory efficiency traps and can schedule their workers on a more optimum way than a general purpose language.

That said, I'm not sure such thing exists. Just the memory overhead some common libraries impose on connections is enough to fill some 32GB.

Re: Go hits the concurrency nail on the head

#244

Post by pcwalton »

jules wrote: post #207
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…

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.

Re: Go hits the concurrency nail on the head

#245

Post by jules »

nelsonje wrote: post #241
lachlan-sneff wrote: post #235

Earlier quoted context omitted.

I've never heard of cilk before, but it seems fascinating. Is there any material I could read on how this is implemented?

This is the canonical Cilk paper: http://supertech.csail.mit.edu/papers/cilk5.pdf

Here is the paper describing the lazy thread spawning implementation: https://ece.umd.edu/~barua/ppopp164.pdf

Re: Go hits the concurrency nail on the head

#246

Post by marcosdumay »

weberc2 wrote: post #178
pjmlp wrote: post #162

Earlier quoted context omitted.

Every programming language has a runtime, even Assembly if the CPU is micro-coded. How do you think that the GC, go-routine scheduler, cgo marshaling get managed?

I thought it was pretty obvious that the OP was using "runtime" to refer to an external interpreter program. The significance being the simplicity of deployment.

I didn't think it was all that obvious, and after I read the OP's answers I thought he was complaining about distributable size, instead of deployment procedures.

Re: Go hits the concurrency nail on the head

#247

Post by lostmsu »

pdeuchler wrote: post #193
aczerepinski wrote: post #168

Earlier quoted context omitted.

"But Go isn't targeting C++ or Rust.. Go is trying to replace Ruby"... If you listen to Ken Thompson and Rob Pike talk about the first days of Go, it was directly targeting C++. They mention the absurdly slow compilation times of C++ code at Google, and the high complexity of code that folks were writing. I believe Steve Francia's "Standing on the shoulder" talk goes into this, but I don't have time right now to re-w…

This is correct, but they quickly pivoted to targeting the Python codebases. Rob Pike has a talk where he talks about how Google used C++ and C to rewrite hot Python paths and how they wanted Go to be able to completely replace that whole pattern. Russ also has a blog post (maybe? it also could have been a comment in a github issue, tbh I can't remember) where he mentions converting python programmers was orders of m…

Well, why did not they just use C#? It already had most, maybe even all of Go's current features.

Hell, the main thing of Go, the go op is basically await.

Re: Go hits the concurrency nail on the head

#248

Post by marcosdumay »

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.

Every time I see people saying stuff like that I remember of this:

http://james-iry.blogspot.com/2009/05/brief-incomplete-and-m...

> His lambda calculus is ignored because it is insufficiently C-like. This criticism occurs in spite of the fact that C has not yet been invented.

Anyway, it's not because C-like languages are any easier. It's just that nearly all programmers learn to code in a C-like language. Most of them won't ever learn a second language, the number that will do the work of learning something actually different is minuscule.

Re: Go hits the concurrency nail on the head

#249

Post by lostmsu »

HeyImAlex wrote: post #123
kasey_junk wrote: post #82

Its fairly interesting that this article doesn't mention actors, futures/promises and async/await style co-routines which are all extremely available in all of the major languages available today and broadly used (with the possible exception of golang). Frankly, I think the concurrency story is one of the weaknesses of golang. Contrary to what this article says you cannot stop thinking about concurrency in your code…

Just my own anecdote, but I write go and typescript daily and I’d take goroutines and go’s other concurrency primitives over aysync/await any day of the week.

What is the difference?

Re: Go hits the concurrency nail on the head

#250

Post by marcosdumay »

the_clarence wrote: post #33
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.)

Neither is concurrency. But if you need concurrency, functional is very visibly the way to go.
Post reply on HN