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

301–310 of 318 posts

Re: Go hits the concurrency nail on the head

#301

Post by tmerr »

apta wrote: post #286
tmerr wrote: post #261

Earlier quoted context omitted.

Eh? I can't speak for all of Google but I like me some Go. It has a culture of minimalism both in language and code, which makes it easy to pick up and read others' work. I wouldn't recommend it for all problems, but it's at least nice for backend services. Java is a victim of its own success: it has lived through style evolutions which have lead to fragmentation in the ecosystem. Some code uses mutable datastructure…

> it has lived through style evolutions The same can be said for C++, C#, etc. that have been around for a long enough time. Golang is relatively speaking still new. Look back at this again if golang adds generics and other features that will change how code in it is written. > Another imperfection: GC pauses can cause request timeouts and are annoying to debug. That's not an issue with Java, but how the GC is tuned.…

>Look back at this again if golang adds generics and other features that will change how code in it is written.

Absolutely. I was surprised by the number of proposed changes in Go 2, especially regarding error handling. Curious whether old code will be migrated or left behind.

>That's not an issue with Java, but how the GC is tuned

Good point, I haven't done much GC tweaking personally but that sounds worth learning more about. However I think language might have something to do with it: In Java almost everything is a referenceable object, while in Go one can put values directly inside structs. So Go has less work to do. Without that advantage I doubt it would seem competitive with Java GCs.

Re: Go hits the concurrency nail on the head

#302

Post by _ph_ »

tralarpa wrote: post #117
_ph_ wrote: post #110

Earlier quoted context omitted.

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.

Oberon (which is a successor of Modula-2)

While I used Modula-2 a lot in a long distant past, I unfortunately never got into Oberon, so I didn't consider it in my comment. Though if Go is a successor to Oberon and Oberon is a successor to Modula-2, Go is also a successor to Modula-2 :).

Re: Go hits the concurrency nail on the head

#303

Post by floitsch »

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…

Failed programming languages are not popular, which is why it is hard to remember them. For example, Ceylon (backed by Redhat) never got any traction, and most people forgot about it or never heard about it.

Re: Go hits the concurrency nail on the head

#304

Post by sagichmal »

int_19h wrote: post #300
sagichmal wrote: post #214

Earlier quoted context omitted.

My point is that you can program with the actor model in Go, if you want to.

You can program with it in C, if you want to. But Go is clearly not designed with that in mind. It's a language that is very opinionated about how concurrency should work. And so whether it's a good opinion or a bad opinion becomes very important.

The actor model in Go looks like this:

    type actor struct {
        c chan message
    }
    
    func (a *actor) foo(...) {
        a.c
This is perfectly idiomatic Go for a large class of problems. Therefore it's not correct to say that "Go is clearly not designed with [actors] in mind."

To be fair, it is probably correct to say that Go provides CSP natively, and leaves actors to be implemented by the programmer, and that this "hierarchy", that CSP makes a better foundation for actors than vice-versa, is an opinion codified by the language.

Re: Go hits the concurrency nail on the head

#305

Post by cozos »

zzzcpan wrote: post #210
toast0 wrote: post #201

Earlier quoted context omitted.

I'm not the person you're asking, but I want one thread per connection, and I want one million connections per host.

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.

Can you elaborate on what you mean by "the whole shared memory multithreading model breaking"? I would love to hear ;)

Re: Go hits the concurrency nail on the head

#306

Post by kureikain »

TheDong wrote: post #126
kureikain wrote: post #121

Earlier quoted context omitted.

> Backed by major corporation I don't think Go success has anything to do with Google. Google engineers probably favors Java/Python. I think the key thing to make Go adopt is because the Docker project and Hashi Corp. The second most important thing is it is super easy to compile Go program and run it and adopt by DevOps teams

You're welcome to your opinion. Anecdotally, I've heard from many people that Go only took off in China because chinese programmers like google and it was sold as a language by google. > Google engineers probably favors Java/Python That's irrelevant. The fact of the matter is that Go has a company backing it and providing a constant stream of well-paid developers and infrastructure. Most small languages can barely af…

Let's look at it from different angle. When first release, AWS Lambda or even Google Cloud FUnction didn't support Go. NodeJS always get there. Python is there always.

So the point of big company backing it doesn't add much value. Even Google didn't support Go for their Google Cloud Function.

Re: Go hits the concurrency nail on the head

#307

Post by apta »

tmerr wrote: post #301
apta wrote: post #286

Earlier quoted context omitted.

> it has lived through style evolutions The same can be said for C++, C#, etc. that have been around for a long enough time. Golang is relatively speaking still new. Look back at this again if golang adds generics and other features that will change how code in it is written. > Another imperfection: GC pauses can cause request timeouts and are annoying to debug. That's not an issue with Java, but how the GC is tuned.…

>Look back at this again if golang adds generics and other features that will change how code in it is written. Absolutely. I was surprised by the number of proposed changes in Go 2, especially regarding error handling. Curious whether old code will be migrated or left behind. >That's not an issue with Java, but how the GC is tuned Good point, I haven't done much GC tweaking personally but that sounds worth learning…

Java will be getting value types in an upcoming version. C# already has value types (called structs). The JVM also does escape analysis to avoid heap allocation when it can.

Re: Go hits the concurrency nail on the head

#308

Post by pjmlp »

_ph_ wrote: post #302
tralarpa wrote: post #117

Earlier quoted context omitted.

Oberon (which is a successor of Modula-2)

While I used Modula-2 a lot in a long distant past, I unfortunately never got into Oberon, so I didn't consider it in my comment. Though if Go is a successor to Oberon and Oberon is a successor to Modula-2, Go is also a successor to Modula-2 :).

Go's method definitions are copied from Oberon-2 syntax.

Re: Go hits the concurrency nail on the head

#309

Post by tracker1 »

anothergoogler wrote: post #73
tracker1 wrote: post #67

Earlier quoted context omitted.

Kind of, though your tone seems a bit dismissive. In the end, the Node/JS community, mostly because of npm, has a lot to offer and that is the ability to create a working product more quickly than most other options in most conditions.

Pardon my snark! In all seriousness, isn't it possible that you're more productive with Node because you're more familiar with it and its ecosystem?

Not really, I've also been active in C#, at one point more Java, and a few other communities (Ruby on Railes) along the way. I'm not really tied to it so much as choose it.

I've never had the vitriol towards JS that other devs have had in the past, I've always recognized DOM issues vs. language issues, and many of the "good parts" long before the book.

In the end it comes down to the massive ecosystem. Which has some drawbacks, but in the end allows for unparalleled productivity gains.

Re: Go hits the concurrency nail on the head

#310

Post by wahern »

apta wrote: post #287
wahern wrote: post #171

Earlier quoted context omitted.

All of those interfaces are trivial to implement in Go precisely because Go implements a much stronger abstraction. By contrast, if you only have those other abstractions you're quite limited in how you can structure your code. (You might not realize how limited you are, however, if those are your only options.) As the article says, most languages settle for those interfaces because they can mostly be implemented as…

> If you think actors, futures, and async/await are so great, imagine having to write every single function invocation in that manner. I don't see how: val f = Future { foo() } // do work... f match { case Success(res) => useRes(res) case Failure(error) => handleError(error) } Is any more difficult than: done := make(chan bool) var res int go foo(done, &res) As a matter of fact, the first one is much easier. I don't…

You're not understanding (or at least not appreciating) the function color problem mentioned in the article. See, e.g., http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...
Post reply on HN