4 ms·

What in the world are you talking about?

by jpeterson 14y ago

tptacek 14y ago
I too am very puzzled by this comment.
- evmar 14y ago
  6 days ago the poster was calling it their "language of choice" and saying other nice things[1], so perhaps they're just having a bad day with debugging a deadlock. [1] http://news.ycombinator.com/item?id=4677022 http://news.ycombinator.com/item?id=4677022
  - eternalban 14y ago
    Go has many strengths, but for Rob Pike to claim that Go addresses concurrency for the modern CPUs better than Java is just clearly b.s. Doug Lea, Cliff Click, Brian Goetz, et al. addressed multicore before Go even existed. I call b.s. when I see it. (The nearly cult-like mentality of some of Go programmers is really quite annoying.)
    - jlouis 14y ago
      It goes deeper than that. The prime difference is in the stance: "Is concurrency a library or is it a built-in feature?". In Java, it is the former, whereas in Go, it is the latter. In my experience, having concurrency primitives in the language tend to integrate better than having them in a library - for the simple fact it saves some space when writing and reading programs. As for the choice of `java.util.concurrent` over goroutines it again depends on your stance. j.u.c provides you with some excellent high-level primitives on which to build concurrency. But these primitives are easy to build in Go with its concurrency primitives. Some, like `BlockingQueue<E>` or `Future<V>` are directly isomorphic to a channel or a simple goroutine/channel invocation respectively. It is a matter of opinion whether or not one should actually do these kinds of implementations themselves. A more important difference, however, is that Java operates on Threads as the "smallest" primitive, whereas a goroutine is a light-weight "thread". That is, you can easily have tens of thousands of goroutines running, but you do probably not want the same amount of threads in a Java system. For that, you need stuff like kilim. In my experience, I am a professional Erlang programmer, the ability to run extremely concurrent threads/processes is a game changer for much of the code you will be writing.
      - eternalban 14y ago
        > The prime difference is in the stance: "Is concurrency a library or is it a built-in feature?". In Java, it is the former, whereas in Go, it is the latter. Fully agree. But in case of Go, the language feature is non performant. cd $GOROOT/src grep -r Lock * You are strongly motivating me to write Go channel semantics over Java's (nio) Selectors and j.u.c to demonstrate a point... (Don't. I've other things to do.)
        jlouis 14y ago
        I would not be surprised if it turned out to perform extremely well - and perhaps even outperform Go. On the other hand, performance is not everything when it comes to writing large software systems. Again, my Erlang experience is that even if we are "hellishly slow" because every message is a copy in Erlang, it doesn't matter. For large software systems it turns out that the architectural design is what is the driving factor to program speed. How fast you pass a message is only part of the whole thing. The real question to ask is how good a language is for the large scale software design. Certainly Java has proven itself to be there. Go is still young, but it specifically targets some of the problems in the same area as well. In my experience, debugging and the ease of doing so is also very important. And I don't know much about how easily this is to do in Go.
        eternalban 14y ago
        If it didn't, the fault would be mine. A dip to unsafe and it is effectively as bare metal as Go. > The real question to ask is how good a language is for the large scale software design... Agreed. A comparison with Java at this point would be unfair given the massive investment made by the industry in tweaking of the platform over nearly 2 decades. I think Go is a very promising language. One simply hopes that the leading lights of the language/industry do not stoop to making threadbare (npi;) claims of superiority over other, equally viable, languages. After all, "it's just code". (PL religious wars are entirely boring.) > debugging Go has very good profiling and data race [1] detection tools. As far as debugging goes, I'm in the printf school of debugging (even on Java) and so far so good, so I can not speak to that. [1]: it is not a pure CSP system. See this very interesting thread: https://groups.google.com/d/topic/golang-nuts/8k59RgkeJ6s/discussion https://groups.google.com/d/topic/golang-nuts/8k59RgkeJ6s/di... (grep for Andrei Alexandrescu of D fame and read on ..)

What in the world are you talking about?

tptacek 14y ago

I too am very puzzled by this comment.

evmar 14y ago
6 days ago the poster was calling it their "language of choice" and saying other nice things[1], so perhaps they're just having a bad day with debugging a deadlock. [1] http://news.ycombinator.com/item?id=4677022 http://news.ycombinator.com/item?id=4677022
- eternalban 14y ago
  Go has many strengths, but for Rob Pike to claim that Go addresses concurrency for the modern CPUs better than Java is just clearly b.s. Doug Lea, Cliff Click, Brian Goetz, et al. addressed multicore before Go even existed. I call b.s. when I see it. (The nearly cult-like mentality of some of Go programmers is really quite annoying.)
  - jlouis 14y ago
    It goes deeper than that. The prime difference is in the stance: "Is concurrency a library or is it a built-in feature?". In Java, it is the former, whereas in Go, it is the latter. In my experience, having concurrency primitives in the language tend to integrate better than having them in a library - for the simple fact it saves some space when writing and reading programs. As for the choice of `java.util.concurrent` over goroutines it again depends on your stance. j.u.c provides you with some excellent high-level primitives on which to build concurrency. But these primitives are easy to build in Go with its concurrency primitives. Some, like `BlockingQueue<E>` or `Future<V>` are directly isomorphic to a channel or a simple goroutine/channel invocation respectively. It is a matter of opinion whether or not one should actually do these kinds of implementations themselves. A more important difference, however, is that Java operates on Threads as the "smallest" primitive, whereas a goroutine is a light-weight "thread". That is, you can easily have tens of thousands of goroutines running, but you do probably not want the same amount of threads in a Java system. For that, you need stuff like kilim. In my experience, I am a professional Erlang programmer, the ability to run extremely concurrent threads/processes is a game changer for much of the code you will be writing.
    - eternalban 14y ago
      > The prime difference is in the stance: "Is concurrency a library or is it a built-in feature?". In Java, it is the former, whereas in Go, it is the latter. Fully agree. But in case of Go, the language feature is non performant. cd $GOROOT/src grep -r Lock * You are strongly motivating me to write Go channel semantics over Java's (nio) Selectors and j.u.c to demonstrate a point... (Don't. I've other things to do.)
      - jlouis 14y ago
        I would not be surprised if it turned out to perform extremely well - and perhaps even outperform Go. On the other hand, performance is not everything when it comes to writing large software systems. Again, my Erlang experience is that even if we are "hellishly slow" because every message is a copy in Erlang, it doesn't matter. For large software systems it turns out that the architectural design is what is the driving factor to program speed. How fast you pass a message is only part of the whole thing. The real question to ask is how good a language is for the large scale software design. Certainly Java has proven itself to be there. Go is still young, but it specifically targets some of the problems in the same area as well. In my experience, debugging and the ease of doing so is also very important. And I don't know much about how easily this is to do in Go.
        eternalban 14y ago
        If it didn't, the fault would be mine. A dip to unsafe and it is effectively as bare metal as Go. > The real question to ask is how good a language is for the large scale software design... Agreed. A comparison with Java at this point would be unfair given the massive investment made by the industry in tweaking of the platform over nearly 2 decades. I think Go is a very promising language. One simply hopes that the leading lights of the language/industry do not stoop to making threadbare (npi;) claims of superiority over other, equally viable, languages. After all, "it's just code". (PL religious wars are entirely boring.) > debugging Go has very good profiling and data race [1] detection tools. As far as debugging goes, I'm in the printf school of debugging (even on Java) and so far so good, so I can not speak to that. [1]: it is not a pure CSP system. See this very interesting thread: https://groups.google.com/d/topic/golang-nuts/8k59RgkeJ6s/discussion https://groups.google.com/d/topic/golang-nuts/8k59RgkeJ6s/di... (grep for Andrei Alexandrescu of D fame and read on ..)