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

221–230 of 318 posts

Re: Go hits the concurrency nail on the head

#221

Post by XorNot »

AnimalMuppet wrote: post #159
ken wrote: post #60

Earlier quoted context omitted.

So, in the world of concurrency, are imperative languages good for every person and every use case? :-) My intention was not to single out functional languages. Those were just the first languages I thought of with the best concurrency support. (I don't think it's mere coincidence, though, that so many concurrency-aware languages are functional. If concurrency is a major concern, perhaps one should consider that "mai…

> So, in the world of concurrency, are imperative languages good for every person and every use case? :-) Clearly, no. I think it comes down to the question of shared mutable state. Functional languages say "don't do that, it's evil" - with some justification. If the problem doesn't push you toward shared mutable state, then consider functional languages. When could the problem push you toward shared mutable state? I…

Where this shows up a lot is the types of business problems which functional programming finds itself in. The least surprising thing in the world is that Haskell and functional Scala work pretty okay for Hadoop ETL work, for example.

Re: Go hits the concurrency nail on the head

#222

Post by zzzcpan »

Matthias247 wrote: post #220
zzzcpan wrote: post #203

Earlier quoted context omitted.

Lack of blocking support in runtime cannot prevent you from implementing waiting. Either through higher-order event driven code or just plain busy-waiting style message exchanging until you receive your message.

Busy waiting won't work, since there will potentially never run another thread that changes the thing you are waiting for (that's why e.g. in JS everything needs to be async). There might be ways to model things a bit different (like using Promises and other monadic abstractions), but things will never look the same as in a blocking environment.

It's a model, it doesn't matter how it looks.

Re: Go hits the concurrency nail on the head

#223

Post by XorNot »

cube2222 wrote: post #47
CydeWeys wrote: post #30

Earlier quoted context omitted.

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.

It's the only thing really holding me back from going more into Rust. At the same time, there is a sweet spot in popularity, when there is a very good quality/noise ratio in the library ecosystem, I'm not sure though, if rust's there at the moment.

Losing static compilation, Go-style, holds me back from Rust. The sheer number of platforms I can target with Go without doing anything special is amazing, whereas Rust forces me down the libc merry go round again.

A reliable recipe for 0 dependency Rust binaries so long as I stayed in the Rust ecosystem would be a good motivator to use it.

Re: Go hits the concurrency nail on the head

#224

Post by akavel »

pdeuchler wrote: post #208
akavel wrote: post #196

Earlier quoted context omitted.

Why exactly do you say Go is backwards to C++ with regards to concurrency and race conditions? Really curious. I worked on a sizeable C++ codebase, and it had a home-grown, buggy thread-pooling & task cancellation (similar to Go's context.Context) engine. Go's builtin goroutines were a breeze afterwards. Also, I debugged a race condition in this codebase. Once , and it took me a few weeks full steam digging, thinking…

Your experience mimics my experience almost exactly (although it sounds like you've worked on much larger and more complex C++ projects than I have), however I've been lucky enough to work with some extremely talented C++ programmers that have been able to accomplish astounding things with good, clean, C++ code. The problem, of course, is that 99.9% of us are not extremely talented C++ programmers.

Ok; so if you confirm my experience, I don't understand how you can at the same time claim Go is "backwards to C++" w.r.t. concurrency & race conditions. Did you mistype "superior" as "backwards"? Btw, we also had extremely talented C++ programmers. Some of them sent ISO C++ proposals from time to time, and I think were even accepted.

Re: Go hits the concurrency nail on the head

#225

Post by steveklabnik »

XorNot wrote: post #223
cube2222 wrote: post #47

Earlier quoted context omitted.

It's the only thing really holding me back from going more into Rust. At the same time, there is a sweet spot in popularity, when there is a very good quality/noise ratio in the library ecosystem, I'm not sure though, if rust's there at the moment.

Losing static compilation, Go-style, holds me back from Rust. The sheer number of platforms I can target with Go without doing anything special is amazing, whereas Rust forces me down the libc merry go round again. A reliable recipe for 0 dependency Rust binaries so long as I stayed in the Rust ecosystem would be a good motivator to use it.

As long as you’re on Linux, it’s quite easy to use MUSL. Other platforms don’t offer something comparable, so we’re kinda stuck.

Re: Go hits the concurrency nail on the head

#226

Post by [deleted] »

zimablue wrote: post #215
pdeuchler wrote: post #142

Earlier quoted context omitted.

Nothing you're saying is wrong, but your perspective is totally off. For someone experienced with C++, or say, Rust (ahem), obviously Go is a bit backwards when it comes to concurrency and race conditions. Obviously you can mimic go's goroutine stacks, obviously you can obtain fast thread switching. But Go isn't targeting C++ or Rust, and it's not targeting the domains those languages are best at (although admittedly…

It seems weird to switch from python to go. Python is lispy in that it maximises flexibility and developer power at the cost of speed and inbuilt correctness checks. Go is Javaish in that it limits what the developer can do heavily (crippled typesystem) for speed, correctness. I checked my assumptions, you're kind of right about python developers switching but it's hard to know the real base distribution of people wh…

[deleted]

Re: Go hits the concurrency nail on the head

#227

Post by Const-me »

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…

> actors, futures/promises and async/await style co-routines which are all extremely available in all of the major languages

Language features are indeed available. Runtime features backing them are only available in Go, erlang and .NET.

If you only need concurrency for CPU bound calculations, even C++ has decent options, e.g. OpenMP works great for my tasks. However, OpenMP offers nothing for IO. The point of go’s co-routines or .NET’s async-await, they allow to run a mix of CPU bound and IO bound code, and do so in parallel utilizing all available hardware threads.

Re: Go hits the concurrency nail on the head

#228

Post by EpicEng »

fnordsensei wrote: post #163
EpicEng wrote: post #83

Earlier quoted context omitted.

>Yes. Because mainstream is what you should select for when choosing your tools It's a hugely important consideration. More devs, larger community, better support, more/better tooling, more libs, etc. If you don't think those matter then you're only concerned with pet/toy projects.

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.

Re: Go hits the concurrency nail on the head

#229

Post by EpicEng »

enraged_camel wrote: post #145
CydeWeys wrote: post #30

Earlier quoted context omitted.

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.

If everyone chose mainstream languages we would never invent and adopt any other language ever.

Luckily we don't live in that world and never will.

Re: Go hits the concurrency nail on the head

#230

Post by Matthias247 »

pcwalton wrote: post #184
Matthias247 wrote: post #179

Earlier quoted context omitted.

> The only real difference for most code is that it pushes you very hard to use channels directly, as they're the only type-safe option. It is, but it is also a super important difference: Go provides inbuilt libraries to make inter-thread synchronization more bearable for the average user, e.g. channels and waitgroups. These are lot harder to misuse than bare mutexes and condition variables. Since those are not avai…

I think more languages should have typed channels, but untyped channels are readily available via OS primitives. Unix has had pipe() since 1973.

True! Haven't thought about it, but it's actually an OS-backed untyped channel, which even supports select().

Guess the differences are: It operates on bytes and not on objects, so a custom protocol is needed on top of it. And it can't provide the same guarantees as an unbounded channel, where there are certain guarantees that sending an item actually reached the other site, and which makes guaranteed resource handoff through channels a bit easier.

Post reply on HN