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

Re: Go hits the concurrency nail on the head

#101

Post by kazinator » Thu, Oct 04, 2018, 7:10 PM UTC

dreamcompiler wrote: post #29

kazinator wrote: post #7

Earlier quoted context omitted.

Actually it's very easy to avoid data-structure related deadlocks: - avoid holding two locks simultaneously: that guarantees no deadlocks. - if you have to hold several locks, always acquire them in the same order in all scenarios. The "avoid holding multiple locks" rule also harmonizes very well with "minimize the durations/sizes of critical regions". That is, hold a lock over the minimum number of machine instructi…

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

Re: Go hits the concurrency nail on the head

#102

Post by nicheftw93 » Thu, Oct 04, 2018, 7:10 PM UTC

mmjaa wrote: post #45

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.

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

Anecdote time: making yourself too specialized makes you easily replaceable too.

At a previous gig, a problem dev, who insisted on only using Erlang, was painted into a corner by eng at large who did not want to learn/support another language (Ruby, Python, JS, Java, and R were all over).

This dev eventually got fired, as they didn't really contribute much to "the big picture". Since their efforts were so limited in scope, their Erlang work was quickly replaced using the other languages, and consumers of the results never noticed.

YMMV. But that's a old standard that should probably die

Re: Go hits the concurrency nail on the head

#103

Post by jerf » Thu, Oct 04, 2018, 7:12 PM UTC

andy_ppp wrote: post #61

le-mark wrote: post #16

Earlier quoted context omitted.

How are the deployment, library ecosystem, build, and tooling stories for Elixir? Note I don't really care about the answer to the above, I just wish as a profession we could get past the tribalism and boosterism and have rational technical dicussions about things that matter as opposed to banal declarations about 'expressiveness' etc.

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 anything at all. (Though I have recently been in the "three libraries that all seem like 80% of the job is done with varying degrees of quality" situation. But you still get that in Erlang in similar places too, as far as I know.)

Re: Go hits the concurrency nail on the head

#104

Post by jerf » Thu, Oct 04, 2018, 7:14 PM UTC

thinkpad20 wrote: post #18

I think the author might be overstating how unique Go’s position is in terms of making concurrency easier. Haskell has the best concurrency story of any language I’ve used. Super lightweight green threads, simple concurrency primitives like MVar and STM, good performance (possibly requiring tweaks, but not bad out of the box). Referential transparency (by which I basically mean immutable data) makes sharing data acro…

In terms of raw capability, Haskell is the concurrency winner. Not only does it have basically every paradigm, they even all work together reasonably well. (Not perfectly, but reasonably well.) But I don't think you can argue Haskell is mainstream. It continues to be on a fairly slow growth trajectory from what I see, but it's not in any danger of cracking into the top tier language set anytime soon. Go just might in another 5 years.

Re: Go hits the concurrency nail on the head

#105

Post by jerf » Thu, Oct 04, 2018, 7:18 PM UTC

bunderbunder wrote: post #54

> Programming with threads is hard - it's hard to synchronize access to data structures without causing deadlocks; it's hard to reason about multiple threads accessing the same data, it's hard to choose the right locking granularity, etc. That's a list of problems that are specific to mutable state that is shared among threads. As the old saying goes, "If it hurts, don't do it." We've had ways of doing multithreaded…

"We've had ways of doing multithreaded code that are easier to reason about for decades. They really do work quite well. Why people doggedly insist on pretending they don't exist is a perennial mystery to me."

The real advantage to Go in a lot of ways was just starting over again with a couple decades more experience with multithreaded coding, and making the community default to a set of those more sane concurrency primitives. Nothing nominally stops you from doing the same thing in a number of other older threaded languages, but you're trying to bootstrap a new set of libraries from scratch, and that's not just a neutral operation, you are actively fought by the existing bulk of libraries for your existing language.

It's sort of weird that sometimes it's literally easier to start an entirely new language than fix an existing ecosystem and I can't say I've necessarily gotten my head wrapped around it, but observationally the evidence seems quite strong.

Re: Go hits the concurrency nail on the head

#106

Post by roganartu » Thu, Oct 04, 2018, 7:18 PM 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. It actually makes data races easier than in languages like C++, because it has no concept of const, even as a lint. Race detectors have long existed in C++ as well, at least as far back as Helgrind.

While it can't guarantee correctness outside of runtime (and even then, obviously only if whatever you are running actually triggers the race), a race detector has been part of the Go core since 2012[1].

[1]: https://blog.golang.org/race-detector

Re: Go hits the concurrency nail on the head

#107

Post by tschellenbach » Thu, Oct 04, 2018, 7:19 PM 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…

Doesn't catch everything, but it catches a lot: https://golang.org/doc/articles/race_detector.html

Re: Go hits the concurrency nail on the head

#108

Post by Scarbutt » Thu, Oct 04, 2018, 7:20 PM UTC

weberc2 wrote: post #77

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 :(

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

Who do you think pays for almost all of Go's development?

Re: Go hits the concurrency nail on the head

#109

Post by tschellenbach » Thu, Oct 04, 2018, 7:21 PM UTC

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…

For most use cases of async programming you never need to touch channels and goroutines. If you build a webserver in go it will be highly concurrent out of the box. as a developer you just write synchronous code. here's a nice tutorial: https://getstream.io/blog/go-1-11-rocket-tutorial/

Re: Go hits the concurrency nail on the head

#110

Post by _ph_ » Thu, Oct 04, 2018, 7:21 PM UTC

pjmlp wrote: post #75

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…

Modula-2 used to fit all those points, except backed by major corporation, unless we consider GM a major corporation.

I consider Go as a Modula-2 successor. It shares most traits I liked a lot with Modula-2. I prefer the C-style syntax to the more long-winded one though. The familiarity is no surprise though, considering that Robert Griesemer is a student of Wirth.