4 ms·

No, it is Java that is the prime example of what the alternative looks like. And in spite of all problems with Java and its standard library, there's something

No, it is Java that is the prime example of what the alternative looks like. And in spite of all problems with Java and its standard library, there's something very liberating about having code written in 1997 that still compiles and works in 2017. And the beauty of Java is that it became a platform, so if you hate the language, you can pick another that's closer to what you think programming should be, like Scala, Clojure, JRuby, Groovy, Kotlin, etc. and still benefit from that piece of code written in 1997, all made possible due to Sun's fanatical devotion to backwards compatibility.

Recurecur 10y ago
I've been a heavy Java platform user for years, mainly Java language but also with some Groovy and Scala. I agree with what you're saying to as far as it goes. Where Swift excels is that it has the performance of C for the most part, and it will continue to improve. Another strength is ARC over Java style GC. As the slides point out, to get the same performance with GC, you need 4x the memory. With only 2x the memory, you get 70% lower performance with Java. Most important, though, is determinism. GC is simply not suitable for real time, hard or soft. I'm very excited about Swift, and the current version of Xcode is working pretty well for me. I love the aggressive goal of replacing the C family of languages down the road...
- yxhuvud 10y ago
  > As the slides point out, to get the same performance with GC, you need 4x the memory. I'd take that claim with a pretty big grain of salt. The paper they referenced used an experimental GC without use in production. Who knows how well or bad the default collector in the JVM would perform. Also, it is not exactly recent. Hardware changes could have shifted the result in any direction.
  - Recurecur 10y ago
    The exact numbers are worth a grain of salt. The general point aligns well with my JVM experience. Requiring at least double the working set for decent performing GC doesn't seem congruent with running the leanest possible data centers. Regardless, determinism is the really big win. :-)
vorg 10y ago
Scala and Apache Groovy benefit from the JVM's backwards compatibility, but programmers can't benefit from backwards compatibility in those languages. Groovy even broke compatibility between various 1.x releases.
- bad_user 10y ago
  Which is a pity. We take backwards incompatible changes too lightly. I'm working with Scala for example and love the language, but it breaks binary compatibility between major versions because Scala's features don't map that well to the JVM's bytecode and the encoding of things like traits are fragile. Well, the community is kind of coping with it by having libraries support multiple major versions at the same time. Well, it's not much, but at least the tools have evolved to support this (e.g. SBT, IDEs, etc). That said, if you're looking for a language that has kept backwards compatibility, that's Clojure. Rich Hickey has a recent keynote that I found very interesting: https://www.youtube.com/watch?v=oyLBGkS5ICk https://www.youtube.com/watch?v=oyLBGkS5ICk I don't know how to feel about it. On one hand this means Clojure will probably never fix some obvious mistakes in its standard library, without changing its name (like what they did with ClojureScript). On the other hand, as I said, it is liberating to have code written in Clojure 1.0 still working in 1.8.

Recurecur 10y ago

I've been a heavy Java platform user for years, mainly Java language but also with some Groovy and Scala. I agree with what you're saying to as far as it goes. Where Swift excels is that it has the performance of C for the most part, and it will continue to improve. Another strength is ARC over Java style GC. As the slides point out, to get the same performance with GC, you need 4x the memory. With only 2x the memory, you get 70% lower performance with Java. Most important, though, is determinism. GC is simply not suitable for real time, hard or soft. I'm very excited about Swift, and the current version of Xcode is working pretty well for me. I love the aggressive goal of replacing the C family of languages down the road...

yxhuvud 10y ago
> As the slides point out, to get the same performance with GC, you need 4x the memory. I'd take that claim with a pretty big grain of salt. The paper they referenced used an experimental GC without use in production. Who knows how well or bad the default collector in the JVM would perform. Also, it is not exactly recent. Hardware changes could have shifted the result in any direction.
- Recurecur 10y ago
  The exact numbers are worth a grain of salt. The general point aligns well with my JVM experience. Requiring at least double the working set for decent performing GC doesn't seem congruent with running the leanest possible data centers. Regardless, determinism is the really big win. :-)

vorg 10y ago

Scala and Apache Groovy benefit from the JVM's backwards compatibility, but programmers can't benefit from backwards compatibility in those languages. Groovy even broke compatibility between various 1.x releases.

bad_user 10y ago
Which is a pity. We take backwards incompatible changes too lightly. I'm working with Scala for example and love the language, but it breaks binary compatibility between major versions because Scala's features don't map that well to the JVM's bytecode and the encoding of things like traits are fragile. Well, the community is kind of coping with it by having libraries support multiple major versions at the same time. Well, it's not much, but at least the tools have evolved to support this (e.g. SBT, IDEs, etc). That said, if you're looking for a language that has kept backwards compatibility, that's Clojure. Rich Hickey has a recent keynote that I found very interesting: https://www.youtube.com/watch?v=oyLBGkS5ICk https://www.youtube.com/watch?v=oyLBGkS5ICk I don't know how to feel about it. On one hand this means Clojure will probably never fix some obvious mistakes in its standard library, without changing its name (like what they did with ClojureScript). On the other hand, as I said, it is liberating to have code written in Clojure 1.0 still working in 1.8.