10 ms·

> extensive and consistent standard library yes > implicit interfaces no > composition over inheritance yes > static builds no > built-in concurrency s

> 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.
    - dragonwriter 11y ago
      > A modern Linux kernel has excellent thread scalability, and you can customize thread stack sizes to improve memory usage. Cross-platform code can't count on always running on a modern Linux kernel, though. But, sure, I'd think that M:N (which is never free) is going to be less likely to be worth the cost if you are specifically targeting an underlying platform reduces the cost of high numbers of native threads and the cost of native thread switching so that the price for user-level threading in the runtime isn't buying you improvements in those areas.
- pcwalton 11y ago
  Why is it nicer to use than that of Rust?
  - cgag 11y ago
    Well, if what you're saying about not needing M:N to get thread scalability is true, I'm probably wrong. I really like being able to run tons of threads and write synchronous code, letting the the haskell RTS swap threads when I block. My mental model, which probably comes from everyone complaining about apaches thread-per-request model a few years ago, is that you basically either consume lots of resources with lots of threads, or you write ugly cps style code. I view haskell/go as giving the best of both worlds, but perhaps they aren't separate worlds after all.
    - Scramblejams 11y ago
      I feel the same about Erlang processes. It's so much easier on my brain to write synchronous code that's preemptively executed and communicating by message passing. Wish Rust gave me that option, speed hit and all, but I understand why it doesn't.
      - pcwalton 11y ago
        How does Rust not give you that option? The choice of 1:1 and M:N does not affect the programming model at all. It is simply an implementation detail. M:N scheduling is no more a requirement for CSP than Unix is for TCP.
        Scramblejams 11y ago
        Maybe I'm using terms incorrectly -- is there a good green thread library for Rust which supports the kind of Erlangy experience I've described? I looked around a couple of months ago but didn't find anything that seemed suitable.
        pcwalton 11y ago

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.
  - dragonwriter 11y ago
    > A modern Linux kernel has excellent thread scalability, and you can customize thread stack sizes to improve memory usage. Cross-platform code can't count on always running on a modern Linux kernel, though. But, sure, I'd think that M:N (which is never free) is going to be less likely to be worth the cost if you are specifically targeting an underlying platform reduces the cost of high numbers of native threads and the cost of native thread switching so that the price for user-level threading in the runtime isn't buying you improvements in those areas.
pcwalton 11y ago
Why is it nicer to use than that of Rust?
- cgag 11y ago
  Well, if what you're saying about not needing M:N to get thread scalability is true, I'm probably wrong. I really like being able to run tons of threads and write synchronous code, letting the the haskell RTS swap threads when I block. My mental model, which probably comes from everyone complaining about apaches thread-per-request model a few years ago, is that you basically either consume lots of resources with lots of threads, or you write ugly cps style code. I view haskell/go as giving the best of both worlds, but perhaps they aren't separate worlds after all.
  - Scramblejams 11y ago
    I feel the same about Erlang processes. It's so much easier on my brain to write synchronous code that's preemptively executed and communicating by message passing. Wish Rust gave me that option, speed hit and all, but I understand why it doesn't.
    - pcwalton 11y ago
      How does Rust not give you that option? The choice of 1:1 and M:N does not affect the programming model at all. It is simply an implementation detail. M:N scheduling is no more a requirement for CSP than Unix is for TCP.
      - Scramblejams 11y ago
        Maybe I'm using terms incorrectly -- is there a good green thread library for Rust which supports the kind of Erlangy experience I've described? I looked around a couple of months ago but didn't find anything that seemed suitable.
        pcwalton 11y ago