6 ms·

reinventing a lot of Java-1.4-era (because the language itself is essentially that) design patterns Really? Java 1.4 had an extensive and consistent standard l

reinventing a lot of Java-1.4-era (because the language itself is essentially that) design patterns Really? Java 1.4 had an extensive and consistent standard library, implicit interfaces, composition instead of inheritance, static builds, and built-in concurrency? Go is not early Java, it's more like C 2.0, and I don't really see anything faux about the simplicity, it really is pretty simple, perhaps too simple for some tastes, but it's not pretending to be simple, nor is it simplistic. Which specific design patterns did you have in mind?

chadaustin 11y ago
> extensive and consistent standard library yes > implicit interfaces no > composition over inheritance yes > static builds no > built-in concurrency sure, with an 1:1 thread model as opposed to an M:N thread model. M:N is not always a clear win over 1:1: https://mail.mozilla.org/pipermail/rust-dev/2013-November/006550.html https://mail.mozilla.org/pipermail/rust-dev/2013-November/00... http://xiao-feng.blogspot.com/2008/08/thread-mapping-11-vs-mn.html http://xiao-feng.blogspot.com/2008/08/thread-mapping-11-vs-m... Also, to be very clear, Java's threads ("green threads") were _originally_ M:N but they switched back to 1:1.
- grey-area 11y ago
  The comparison offered by the OP was Java 1.4 to Go 1.4. I think the standard library is debatable (see the infamous early Java Date class), Java encourages using inheritance (so not composition instead of inheritance) - something Gosling later remarked as his biggest regret, and concurrency had improved tools in Java 2, not sure the story was as good in early Java.
- dragonwriter 11y ago
  > Also, to be very clear, Java's threads ("green threads") were _originally_ M:N but they switched back to 1:1. Java's "green threads" were N:1 threads, not M:N threads. While both are sometimes referred to as "green threads", they are very different things. (N:1 tends to give cheap concurrency but no parallelism, M:N tends to give cheap concurrency with as much parallelism as the hardware can handle, but with more overhead than 1:1 threads.)
- cgag 11y ago
  I don't know if the programming model of threads and channels that's used by haskell and golang strictly depends on the existence of M:N threading, but it sure is nicer to use than the model in java/rust.
  - threeseed 11y ago
    Go's channels/threading model already exists in Java: https://github.com/puniverse/quasar https://github.com/puniverse/quasar
    - skj 11y ago
      It wasn't immediately obvious from scanning that link. Does it provide channel select? Because that's the hard part. Threadsafe queues are easy, select on them is hard.
      - pron 11y ago
        Of course it does. Java: http://docs.paralleluniverse.co/quasar/javadoc/co/paralleluniverse/strands/channels/Selector.html http://docs.paralleluniverse.co/quasar/javadoc/co/parallelun... Clojure: http://docs.paralleluniverse.co/pulsar/api/co.paralleluniverse.pulsar.core.html#var-select http://docs.paralleluniverse.co/pulsar/api/co.paralleluniver... We'll have a nice slect API for Kotlin, too, very soon.
  - dragonwriter 11y ago
    It doesn't strictly depend on it, but it is strongly supported by M:N threading since that threading model decouples the supportable degree of concurrency from the supportable degree of parallelism (unlike 1:1), without abandoning parallelism (unlike N:1). You can do Erlang-style concurrency with 1:1 or N:1 threading models (and there are libraries for languages whose many implementations are N:1 or 1:1 rather than M:N that do that), but it makes most sense when you have M:N.
    - pcwalton 11y ago
      > It doesn't strictly depend on it, but it is strongly supported by M:N threading since that threading model decouples the supportable degree of concurrency from the supportable degree of parallelism (unlike 1:1), without abandoning parallelism (unlike N:1). A modern Linux kernel has excellent thread scalability, and you can customize thread stack sizes to improve memory usage. (Thread memory use is kind of independent of 1:1 vs. M:N, honestly; the thing that can improve scalability is relocatable stacks, which is really not the same thing.) It's instructive to look at the history of M:N versus 1:1 in the days of NPTL and LinuxThreads and compare that to the history of programming languages. In that world it was received wisdom that M:N would be superior for the reasons always cited today, but at the end of the day 1:1 was found to be better in practice, because the Linux kernel is pretty darn good at scheduling and pretty darn fast at syscalls. Nobody advocates M:N anymore in the Linux world; it's universally agreed to be a dead end. Now, to be fair to Golang, relocatable stacks do change the equation somewhat, but (a) as argued above, I think that's really independent of 1:1 vs. M:N; (b) any sort of userspace threading won't get you to the performance of, say, nginx, as once you have any sort of stack per "thread" you've already lost.
vorg 11y ago
> Go is not early Java, it's more like C 2.0 Or perhaps Go is C+
- grey-area 11y ago
  ;)
- e12e 11y ago
  Technically, that'd be "float C2 = C + 0.5"? (And remember to treat C2 as a float, not an int!)
duaneb 11y ago
Go is not very much like c. Pointers are very close to reified addresses, but much of their use comes from manual memory management. If you have to use GC, its not clear what you gain from the semantic similarities with c. Furthermore, it is a prescriptive ecosystem that is quite restrictive. The runtime is not very friendly to ffi. It is not a suitable systems language due to the GC and associated complexities (interfaces should not mandate GC roots).

chadaustin 11y ago

> extensive and consistent standard library yes > implicit interfaces no > composition over inheritance yes > static builds no > built-in concurrency sure, with an 1:1 thread model as opposed to an M:N thread model. M:N is not always a clear win over 1:1: https://mail.mozilla.org/pipermail/rust-dev/2013-November/006550.html https://mail.mozilla.org/pipermail/rust-dev/2013-November/00... http://xiao-feng.blogspot.com/2008/08/thread-mapping-11-vs-mn.html http://xiao-feng.blogspot.com/2008/08/thread-mapping-11-vs-m... Also, to be very clear, Java's threads ("green threads") were _originally_ M:N but they switched back to 1:1.

grey-area 11y ago
The comparison offered by the OP was Java 1.4 to Go 1.4. I think the standard library is debatable (see the infamous early Java Date class), Java encourages using inheritance (so not composition instead of inheritance) - something Gosling later remarked as his biggest regret, and concurrency had improved tools in Java 2, not sure the story was as good in early Java.
dragonwriter 11y ago
> Also, to be very clear, Java's threads ("green threads") were _originally_ M:N but they switched back to 1:1. Java's "green threads" were N:1 threads, not M:N threads. While both are sometimes referred to as "green threads", they are very different things. (N:1 tends to give cheap concurrency but no parallelism, M:N tends to give cheap concurrency with as much parallelism as the hardware can handle, but with more overhead than 1:1 threads.)
cgag 11y ago
I don't know if the programming model of threads and channels that's used by haskell and golang strictly depends on the existence of M:N threading, but it sure is nicer to use than the model in java/rust.
- threeseed 11y ago
  Go's channels/threading model already exists in Java: https://github.com/puniverse/quasar https://github.com/puniverse/quasar
  - skj 11y ago
    It wasn't immediately obvious from scanning that link. Does it provide channel select? Because that's the hard part. Threadsafe queues are easy, select on them is hard.
    - pron 11y ago
      Of course it does. Java: http://docs.paralleluniverse.co/quasar/javadoc/co/paralleluniverse/strands/channels/Selector.html http://docs.paralleluniverse.co/quasar/javadoc/co/parallelun... Clojure: http://docs.paralleluniverse.co/pulsar/api/co.paralleluniverse.pulsar.core.html#var-select http://docs.paralleluniverse.co/pulsar/api/co.paralleluniver... We'll have a nice slect API for Kotlin, too, very soon.
- dragonwriter 11y ago
  It doesn't strictly depend on it, but it is strongly supported by M:N threading since that threading model decouples the supportable degree of concurrency from the supportable degree of parallelism (unlike 1:1), without abandoning parallelism (unlike N:1). You can do Erlang-style concurrency with 1:1 or N:1 threading models (and there are libraries for languages whose many implementations are N:1 or 1:1 rather than M:N that do that), but it makes most sense when you have M:N.
  - pcwalton 11y ago
    > It doesn't strictly depend on it, but it is strongly supported by M:N threading since that threading model decouples the supportable degree of concurrency from the supportable degree of parallelism (unlike 1:1), without abandoning parallelism (unlike N:1). A modern Linux kernel has excellent thread scalability, and you can customize thread stack sizes to improve memory usage. (Thread memory use is kind of independent of 1:1 vs. M:N, honestly; the thing that can improve scalability is relocatable stacks, which is really not the same thing.) It's instructive to look at the history of M:N versus 1:1 in the days of NPTL and LinuxThreads and compare that to the history of programming languages. In that world it was received wisdom that M:N would be superior for the reasons always cited today, but at the end of the day 1:1 was found to be better in practice, because the Linux kernel is pretty darn good at scheduling and pretty darn fast at syscalls. Nobody advocates M:N anymore in the Linux world; it's universally agreed to be a dead end. Now, to be fair to Golang, relocatable stacks do change the equation somewhat, but (a) as argued above, I think that's really independent of 1:1 vs. M:N; (b) any sort of userspace threading won't get you to the performance of, say, nginx, as once you have any sort of stack per "thread" you've already lost.

vorg 11y ago

> Go is not early Java, it's more like C 2.0 Or perhaps Go is C+

grey-area 11y ago
;)
e12e 11y ago
Technically, that'd be "float C2 = C + 0.5"? (And remember to treat C2 as a float, not an int!)

duaneb 11y ago

Go is not very much like c. Pointers are very close to reified addresses, but much of their use comes from manual memory management. If you have to use GC, its not clear what you gain from the semantic similarities with c. Furthermore, it is a prescriptive ecosystem that is quite restrictive. The runtime is not very friendly to ffi. It is not a suitable systems language due to the GC and associated complexities (interfaces should not mandate GC roots).