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

131–140 of 318 posts

Re: Go hits the concurrency nail on the head

#131

Post by spinningslate »

notriddle wrote: post #112
spinningslate wrote: post #100

Don't disagree with the challenges about other languages being equally applicable. My first thought was also "Erlang does it at least as well as Go". Reasonable challenges on whether Erlang (or Elixir/Pony/...) are mainstream though. For me the more valuable point is not that Go specifically gets it right: it's that async - as implemented in javascript/python/java/c# and so on - is fundamentally wrong. These two quot…

Shared-memory threads are worse than async/await. I'd rather have GOTO than data races, since, while it might be hard to model in your head, at least it's deterministic and using it wrong doesn't cause UB. p.s. https://vorpus.org/blog/notes-on-structured-concurrency-or-g...

Erlang doesn't do shared memory. It's a message passing, shared-nothing model. I believe GO is the same.

Re: Go hits the concurrency nail on the head

#132

Post by erik_seaberg »

camgunz wrote: post #78
erik_seaberg wrote: post #65

> Proper use of channels removes the need for more explicit locking If you're lucky. Sharing mutable state is unsafe by default (map writes can crash!) yet very common and the language doesn't help you avoid it. A good language for concurrency would also make it easy to switch between sync and async method calls; the trouble with channels is they don't support passing errors and panics without rewriting everything to…

Go's answer to this is tooling, -race in this case. I think Go's general strategy of moving complexity/functionality to external tools is a little underexamined -- it's definitely interesting, especially as it's kind of a middle path between "language with lots of helper stuff" and "IDE with lots of helper stuff".

It's better than nothing, but it's so expensive they don't really expect anyone to use it at prod scale. That's a recipe for letting catastrophic bugs do damage for hours or days.

Re: Go hits the concurrency nail on the head

#133

Post by mirceal »

CydeWeys wrote: post #30
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…

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.

I'm sorry but that argument does not hold much water. Any developer with [maybe] the exception of people fresh out of school can and should be able to learn new things. Fast. On-the-job. If you really believe that you're going to use X because it's mainstream and really popular and be okay you're kidding yourself. Also, as you grow older, you learn to see the matrix and appreciate new things that come along when/after you use them and are able to see how they are better or worse iterations on ideas that were already out there.

Also to answer your comment directly. Being mainstream != lots of help, resources, answers, samples, high quality/well maintained libraries. Being mainstream means that a lot of people have heard about you and a lot of people try using you / pick you up. Sometimes mainstream things do get to that place, sometimes you find yourself in an immense "the emperor has no clothes" ecosystem where everyone wants to use X because it's the cool/hot new thing. If you don't understand what the tool you want to use is good for and you forge ahead, most of the times, you will have a bad time.

Re: Go hits the concurrency nail on the head

#134

Post by mirceal »

fixermark wrote: post #49
mmjaa wrote: post #45

Earlier quoted context omitted.

.. and of course, the old standard, if its mainstream .. you are replaceable.

Totally agree, with the added observation that as a software engineer, I want to be replaceable. If my software can't be divorced from its creator, it can't outlive me. I don't want to be glued to my work inextricably; if you can't be replaced, you can't be promoted.

being replaceable is a noble goal. the problem is that maybe some people don't want to be replaceable and maybe they want/seek to gain some kind of job security through the tooling they use, their idiosyncratic processes or just through rejection of new technology. those people are IMHO doomed to obsolescence.

Re: Go hits the concurrency nail on the head

#135

Post by mirceal »

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…

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 or do you want to have someone that can pick the right tool for the job pick the tech? sometimes, not building something or various parts of something is more valuable that building something that you don't need fast.

Re: Go hits the concurrency nail on the head

#136

Post by AnimalMuppet »

ken wrote: post #69
virmundi wrote: post #46

Earlier quoted context omitted.

Go doesn’t need a VM. That’s key. You get good concurrency with an easy to deploy binary that can target the major chips.

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…

Major backing can get you publicity, but don't think that's the deciding factor. What really matters is that major backing gets you the resources to produce a really solid, complete standard library. That is a critical component to language success.

Re: Go hits the concurrency nail on the head

#137

Post by mirceal »

hmschreck wrote: post #42
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…

We had a developer interview here who was an Elixir zealot - and I use that word entirely purposefully. He was very adamant that we needed to rewrite our entire platform in Elixir because it was obviously better. We ended up not hiring; he refused to touch certain technologies that make up a core part of our stack (Node being the biggest issue), and he was honestly something of a massive tool -- on our take-home thin…

a zealot is a zealot is a zealot. you don't get much info from the strong preferences of a zealot. you just quickly learn that you need to avoid them. refusing to touch the tech stack of the person that pays your bills if flat out stupid. if you don't touch it why am I hiring you? depending on how much experience this person had this behavior may be correctable if he/she is lucky enough to find a more senior developer that can show them how their [stupid] choices impact the project and how they can eliminate whole classes of problems by choosing the right tool.

Re: Go hits the concurrency nail on the head

#138

Post by [deleted] »

fixermark wrote: post #41
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.…

And the main reason to not use Node: JavaScript.

[deleted]

Re: Go hits the concurrency nail on the head

#139

Post by dreamcompiler »

kazinator wrote: post #101
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.

Multiple locks are not always in the same scope. Method Foo::Update acquires a lock, then without releasing the lock calls into another class/object where Bar::Commit also acquires its own lock.

Yep. That's certainly one of the tradeoffs.

Re: Go hits the concurrency nail on the head

#140

Post by dnautics »

ngrilly wrote: post #94
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 :(

True, but Go and Erlang don't occupy the same niche. Go is imperative, while Erlang is mostly functional. Go is AOT (ahead-of-time) compiled, while Erlang runs on a VM. Go is statically typed, while Erlang is dynamically typed (I know about Dializer). Go concurrency primitives are designed to coordinate goroutines living in the same process, while Erlang concurrency primitives are designed to coordinate Erlang "proce…

Erlang is AOT, the vm reads compiled and optimized bytecode.
Post reply on HN