5 ms·

Whenever we read about new improvement in Java,it is always inevitably followed by concerns for viability of Kotlin or Scala. However these concerns are never a

Whenever we read about new improvement in Java,it is always inevitably followed by concerns for viability of Kotlin or Scala. However these concerns are never applicable for Closure. I am glad I went all in on Clojure.

Thaxll 5y ago
Isn't closure on its way out though, not like Perl level but going downhill? Kotlin on the other hand is raising.
e40 5y ago
Can you explain that for the Java noobs here, like me?
- nikanj 5y ago
  Scala and Kotlin tried to be a better Java (i.e. Algol-esque syntax). Clojure tries to be a better Lisp, an entirely different family of language. Though a good flamewar can be had on 1) Is Scala closer to Pascal 2) Is Pascal Algol-descendant
  - JulianMorrison 5y ago
    Clojure tries to be an immutable-data, copy-on-write, threadsafe by default dialect of Lisp, which none of the other Lisps do.
    - filoeleven 5y ago
      It’s not really copy-on-write though. That implies greater systemic performance losses than what Clojure provides, because it uses HAMTs (Hash Array Mapped Trie) internally. They enable much faster copies of immutable data than copy-on-write does. Your other points are good ones, I just don’t want people to be put off by copy-on-write performance assumptions. You take a ~50% performance hit from choosing Clojure over Java, but the gains in dev speed, maintenance, robustness, and flexibility to changing requirements are supposed to outweigh that. Especially when you include simpler parallelization, which you covered with thread safety.
      - JulianMorrison 5y ago
        There was an issue I ran into with regular Java, JDOM 2 Documents, One thing saves a reference, the other thing snips a piece out to use in the response... oops, the first reference points to a snipped Document. Worse, that behaviour changed without interface changes between JDOM 1 and 2, and it mattered to the code I was editing. Easy enough to fix with a ".clone()" but still... it's not just parallelisation. Immutable data would mean immutable to weird action at a distance like that. Thankfully the unit tests caught it before it could have gone live. (More precise issue... JDOM 1 lets you splice a piece of A into B while it still is part of A. JDOM 2 insists it be detached first. Detaching it removes it, and that removal can be seen through a reference.)
        filoeleven 5y ago
        Huh. I don’t know enough about JDOM to ask more than stupid questions, especially when we’re talking about two different languages on the same VM. So please bear with me or ignore at your leisure. This all happened within Clojure? Their Java interop is reportedly good, but the docs also say you lose the immutability safeguards when you interact directly with Java classes. I dunno if “regular Java” means literally that, or while working with Java inside of Clojure. Which is it? “One thing saves a reference” - if this was interop, did you convert that to a Clojure data structure as early as possible, and do no more interop after that until a final return? I’ve avoided deep interop so far, so I don’t understand the mechanics of the interface, and I’m not clear if your response is about that.
        JulianMorrison 5y ago
        Sorry for being confusing, it was intended as an illustration of why Clojure's approach is good. Non-immutable data being shared around is basically a recipe for weird action at a distance, is the point. In what was intended to be a "compatible API, just change the imports" update, code broke because an unchecked invariant became a checked one, and then broke again because the workaround mutated data that was being referred to somewhere else.
- dunefox 5y ago
  Clojure has many functional features and properties that are unique to Lisps and functional languages and aren't shared by Java. Kotlin and Java are much more similar than either to Lisp, so when Java gets more modern features it might cut into Kotlins 'market share' since it makes it less powerful when compared to Java.
sgt 5y ago
Yeah I think most Java devs are a bit in awe of Clojure, just not sure about the leap needed to get there.
- hota_mazi 5y ago
  Anyone who values static typing will never be in awe of Clojure. Or any dynamically typed language, for that matter. And Java developers care a lot about static typing.
  - Twisol 5y ago
    > And Java developers care a lot about static typing. With the amount of reflection and annotation-based magic I've seen in the ecosystem, I'm not sure I actually believe this? Maybe it's just lack of exposure, but most of the Java devs I've met seem very happy to undercut the type system whenever it's convenient.
    - abraxas 5y ago
      Java annotations are type safe. And dynamic types is precisely what turns me off of Clojure
      - Twisol 5y ago
        Java annotations aren't executable on their own, so they're trivially type safe. The systems that do things depending on those annotations are typically reflection-based, which does an end-run around the static type system and usually requires a lot of casts. I like static typing myself, but having experienced languages with better type systems, Java's feels like a straitjacket. It's unsurprising that so much of the ecosystem (such as in Spring) leverages reflection and dynamic classloading shenanigans. Props to Dagger for doing compile-time dependency injection well, though.
        kaba0 5y ago
        I think what op meant is that dependency injection is type safe, in that in case of going through a constructor, they have to indeed type check with the dynamically provided instances.
The_Colonel 5y ago
It's not applicable, because Clojure already lost the momentum and sinks deeper and deeper into its niche.
- fulafel 5y ago
  I don't think Clojure was ever growing at a huge clip, but it seems to be doing about the same as Scala, see eg the pie at https://snyk.io/blog/kotlin-overtakes-scala-and-clojure-to-become-the-2nd-most-popular-language-on-the-jvm/ https://snyk.io/blog/kotlin-overtakes-scala-and-clojure-to-b... Kotlin is just Java with improvements and it has major corporate push from Google, so it's natural for it to ride the big volumes. I think long term Clojure is going to keep doing well, despite modest pie slice of JVM dev, because lots of people continue to prefer its simplicity + dynamic FP + unique approach to data, plus the excellent ClojureScript side, and it doesn't really have competition or alternatives on the JVM (unlike Scala, where Kotlin/Java are co-opting features).

Thaxll 5y ago

Isn't closure on its way out though, not like Perl level but going downhill? Kotlin on the other hand is raising.

e40 5y ago

Can you explain that for the Java noobs here, like me?

nikanj 5y ago
Scala and Kotlin tried to be a better Java (i.e. Algol-esque syntax). Clojure tries to be a better Lisp, an entirely different family of language. Though a good flamewar can be had on 1) Is Scala closer to Pascal 2) Is Pascal Algol-descendant
- JulianMorrison 5y ago
  Clojure tries to be an immutable-data, copy-on-write, threadsafe by default dialect of Lisp, which none of the other Lisps do.
  - filoeleven 5y ago
    It’s not really copy-on-write though. That implies greater systemic performance losses than what Clojure provides, because it uses HAMTs (Hash Array Mapped Trie) internally. They enable much faster copies of immutable data than copy-on-write does. Your other points are good ones, I just don’t want people to be put off by copy-on-write performance assumptions. You take a ~50% performance hit from choosing Clojure over Java, but the gains in dev speed, maintenance, robustness, and flexibility to changing requirements are supposed to outweigh that. Especially when you include simpler parallelization, which you covered with thread safety.
    - JulianMorrison 5y ago
      There was an issue I ran into with regular Java, JDOM 2 Documents, One thing saves a reference, the other thing snips a piece out to use in the response... oops, the first reference points to a snipped Document. Worse, that behaviour changed without interface changes between JDOM 1 and 2, and it mattered to the code I was editing. Easy enough to fix with a ".clone()" but still... it's not just parallelisation. Immutable data would mean immutable to weird action at a distance like that. Thankfully the unit tests caught it before it could have gone live. (More precise issue... JDOM 1 lets you splice a piece of A into B while it still is part of A. JDOM 2 insists it be detached first. Detaching it removes it, and that removal can be seen through a reference.)
      - filoeleven 5y ago
        Huh. I don’t know enough about JDOM to ask more than stupid questions, especially when we’re talking about two different languages on the same VM. So please bear with me or ignore at your leisure. This all happened within Clojure? Their Java interop is reportedly good, but the docs also say you lose the immutability safeguards when you interact directly with Java classes. I dunno if “regular Java” means literally that, or while working with Java inside of Clojure. Which is it? “One thing saves a reference” - if this was interop, did you convert that to a Clojure data structure as early as possible, and do no more interop after that until a final return? I’ve avoided deep interop so far, so I don’t understand the mechanics of the interface, and I’m not clear if your response is about that.
        JulianMorrison 5y ago
        Sorry for being confusing, it was intended as an illustration of why Clojure's approach is good. Non-immutable data being shared around is basically a recipe for weird action at a distance, is the point. In what was intended to be a "compatible API, just change the imports" update, code broke because an unchecked invariant became a checked one, and then broke again because the workaround mutated data that was being referred to somewhere else.
dunefox 5y ago
Clojure has many functional features and properties that are unique to Lisps and functional languages and aren't shared by Java. Kotlin and Java are much more similar than either to Lisp, so when Java gets more modern features it might cut into Kotlins 'market share' since it makes it less powerful when compared to Java.

sgt 5y ago

Yeah I think most Java devs are a bit in awe of Clojure, just not sure about the leap needed to get there.

hota_mazi 5y ago
Anyone who values static typing will never be in awe of Clojure. Or any dynamically typed language, for that matter. And Java developers care a lot about static typing.
- Twisol 5y ago
  > And Java developers care a lot about static typing. With the amount of reflection and annotation-based magic I've seen in the ecosystem, I'm not sure I actually believe this? Maybe it's just lack of exposure, but most of the Java devs I've met seem very happy to undercut the type system whenever it's convenient.
  - abraxas 5y ago
    Java annotations are type safe. And dynamic types is precisely what turns me off of Clojure
    - Twisol 5y ago
      Java annotations aren't executable on their own, so they're trivially type safe. The systems that do things depending on those annotations are typically reflection-based, which does an end-run around the static type system and usually requires a lot of casts. I like static typing myself, but having experienced languages with better type systems, Java's feels like a straitjacket. It's unsurprising that so much of the ecosystem (such as in Spring) leverages reflection and dynamic classloading shenanigans. Props to Dagger for doing compile-time dependency injection well, though.
      - kaba0 5y ago
        I think what op meant is that dependency injection is type safe, in that in case of going through a constructor, they have to indeed type check with the dynamically provided instances.

The_Colonel 5y ago

It's not applicable, because Clojure already lost the momentum and sinks deeper and deeper into its niche.

fulafel 5y ago
I don't think Clojure was ever growing at a huge clip, but it seems to be doing about the same as Scala, see eg the pie at https://snyk.io/blog/kotlin-overtakes-scala-and-clojure-to-become-the-2nd-most-popular-language-on-the-jvm/ https://snyk.io/blog/kotlin-overtakes-scala-and-clojure-to-b... Kotlin is just Java with improvements and it has major corporate push from Google, so it's natural for it to ride the big volumes. I think long term Clojure is going to keep doing well, despite modest pie slice of JVM dev, because lots of people continue to prefer its simplicity + dynamic FP + unique approach to data, plus the excellent ClojureScript side, and it doesn't really have competition or alternatives on the JVM (unlike Scala, where Kotlin/Java are co-opting features).