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

271–280 of 318 posts

Re: Go hits the concurrency nail on the head

#271

Post by GordonS »

wahern wrote: post #240
GordonS wrote: post #197

Earlier quoted context omitted.

> By contrast, if you only have those other abstractions you're quite limited in how you can structure your code. OK... but what languages only have those abstractions?

I think it's fair to say that neither JavaScript, Perl, nor Python, notwithstanding Web Workers or rough POSIX threading support; but Lua and Scheme do even though their threading construct is not based on the system threading model (though strictly speaking it's likewise available to those languages). What I really meant to get at was that Go provides a flavor of threading that is lightweight, simple, and ergonomic.…

> I think it's fair to say that neither JavaScript

Ah yes, how could I forget Javascript :)

> The fact that languages like Python, C#, and C++ use async/await terminology shows how they put the cart before the horse

Of these, I'm very familiar with C# (15+ years' experience). C# had great threading constructs long before it added async/await, and still does. It actually provides a great variety of threading constructs - you can go low level with mutexes, wait handles, and threads; then there's the Task.Run abstraction, Parallel.ForEach, the TPL...

When async/await in C# was first announced, it was hailed as making concurrency much simpler for devs, but I've always found threads much simpler to reason about and debug, while async/await gives you a variety of footguns that can be difficult to debug.

FWIW, I've been using async/await in C# for years now, but coming from much more of a threading background, I confess it's only now beginning to feel intuitive. I dunno, maybe if new devs come to concurrency from the async perspective first, it's easier to grok.

Re: Go hits the concurrency nail on the head

#272

Post by fnordsensei »

EpicEng wrote: post #228
fnordsensei wrote: post #163

Earlier quoted context omitted.

There's also a zero chance of working with anything that's better than mainstream.

Ummm... ok? I don't know about you, but I like building things that solve problems. Tools are important, but they're not a goal unto themselves. If your 'better' language is beautiful, but lacks the ecosystem people solving real problems actually need to get work done, it's not actually better.

Language is too restrictive to consider in isolation if we're talking about "the tools". And I'm personally more interested in effectiveness than beauty, although I'll grant that beauty could have some influence on effectiveness perhaps.

Ecosystem is not a binary proposition: either there, or not there. At some point the ecosystem becomes solid enough for some purposes.

Finally, if no outliers were ever a better choice than the status quo, the status quo would never change. Therefore, there are always some outliers that can be chosen for greater effect at the cost of accepting some perceived risk. Using tooling smack in the middle of the average zeroes the potential increase in effectiveness as well as the perceived risk.

Re: Go hits the concurrency nail on the head

#273

Post by jeremejevs »

fixermark wrote: post #48
xyproto wrote: post #26

Earlier quoted context omitted.

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

That exists, so we can look at at least one concrete attempt to evaluate the question. [ https://github.com/go-gl/mathgl ]. And right off the bat, the first thing a person notices is that there are two identical sub-libraries, mgl32 and mgl64, to work around the language's constraint that the core numeric type in the library cannot be parameterized at the language level without performance-losing reflection.

mgl64 is generated from mgl32 though [0], so no big deal, no? Who's hurt by this?

[0] https://github.com/go-gl/mathgl#contributing

Re: Go hits the concurrency nail on the head

#274

Post by andy_ppp »

jerf wrote: post #103
andy_ppp wrote: post #61

Earlier quoted context omitted.

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

"Libraries are considerably better than Golang and more all encompassing because you have 20 years of Erlang libraries that you can just use." I'm wouldn't be sure of that anymore. For instance, Go has an official AWS SDK but Erlang does not. Go's been around for 8 years now and it is almost certainly significantly more popular than Erlang. It's been a while since I reached for a library for Go and couldn't find anyt…

It's the whole importing packages is just a checkout from master that makes me concerned about package stability. Semver exists for a reason. I realise this is nearly fixed but it's very slow in coming.

To be honest I feel you really will struggle in Golang to make software that is as reliable as Erlang/Elixir simply because the language is immutable and allows for concurrency by using many serial processes (Actor model) and has supervision of processes (let it crash) and also worth noting once you have used compile time macros the way Elixir does it you never want to go back to repeating yourself the way Golang forces you to. In fact I should write up my proposal for macros being added to Golang as an alternative to Generics...

If you are building something like Docker I'd argue Golang is maybe a more suitable choice but for Web software and stable concurrency Elixir is miles ahead.

Re: Go hits the concurrency nail on the head

#275

Post by gatestone »

TheDong wrote: post #130
weberc2 wrote: post #77

Earlier quoted context omitted.

> full force of Google pushing it This trope is getting old. Variations include "Go is only popular because Google spends millions marketing it!". There is a small team at Google that work on the language along with the open source community. I'm pretty sure none of Google's marketing team works to promote the language, and I'm sure that its success is much less important to Google than Erlang's success was to Ericcs…

> There is a small team at Google that work on the language How many languages are lucky enough to have paid developers working on them? Many languages have been labours of love with 1 developer getting paid, at best, pennies or doing it on the side. I think there's a reasonable middle ground where you can claim "Go made good choices, but it also wouldn't exist as it does nor be as popular without google throwing mon…

If Pike, Thompson, Cox et al. had stayed at Bell Labs, they would have created Go there as salaried researchers? Or because no one would have forced them to do C++, they maybe would not have bothered... ;-)

Re: Go hits the concurrency nail on the head

#276

Post by gatestone »

pkaye wrote: post #158
dreamcompiler wrote: post #29

Earlier quoted context omitted.

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

How would you do this in Go? If not Go, what language has the capability?

"...shared values are passed around on channels and, in fact, never actively shared by separate threads of execution. Only one goroutine has access to the value at any given time. Data races cannot occur, by design." [...if you stick to this style of programming...]

Re: Go hits the concurrency nail on the head

#277

Post by zzzcpan »

NightlyDev wrote: post #260
marcosdumay wrote: post #243

Earlier quoted context omitted.

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.

3 million connections: https://medium.freecodecamp.org/million-websockets-and-go-cc... Heck, you can probably handle a million connections using PHP(with swoole).

In the article they got rid of goroutines to get to 3 million connections.

Re: Go hits the concurrency nail on the head

#278

Post by hyperpape »

ZainRiz wrote: post #161
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…

He does. He referenced it when referring to the color of functions: "I've enjoyed Bob Nystrom's What Color is Your Function[1] for explaining how annoying the model of "non-blocking only here, please" is." The linked article [1] explains his take on why those futures, etc not good enough. [1] http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...

I don't know who owns the term "futures", but the limitations of javascript promises are just choices that javascript made.

In Java, you can write:

    List> futures = new ArrayList();
    ...loop that populates futures
    List strings = futures.stream().map(Future::get);
The loop will run a series of futures (potentially asynchronously...the use of a Future is decoupled from the actual choice of thread pool, etc). The map will collect the results in a blocking fashion. And Future.get() will rethrow any errors that were uncaught in the execution.

Re: Go hits the concurrency nail on the head

#279

Post by lostmsu »

JeremyBanks wrote: post #252
lostmsu wrote: post #247

Earlier quoted context omitted.

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.

C# would be a good option today, but at the time it was an expensive proprietary closed-source blob maintained by one of their primary competitors, and async/await was still years away. I don't like Go very much, but it was a reasonable choice for Google.

In 2008 Mono was already in quite a good shape.

Re: Go hits the concurrency nail on the head

#280

Post by dboreham »

marcosdumay wrote: post #243
dboreham wrote: post #217

Earlier quoted context omitted.

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.

>That said, I'm not sure such thing exists.

Just to clarify : my knowledge on this is pretty deep so the only reason I didn't say "they exist" is that I don't personally have one in my DC (I've only managed up to 200k live connections). I know people very well who do. But yes of course the application would be written in some efficient language fit for the purpose like C, Rust, Go, Erlang. Probably not Java.

Also 32GB is not much memory these days.

Post reply on HN