5 ms·

I know for a fact LinkedIn dropped Scala because of dissatisfaction over Scala. Things like maintainability, the fact it was just a single company developing S

I know for a fact LinkedIn dropped Scala because of dissatisfaction over Scala. Things like maintainability, the fact it was just a single company developing Scala, etc that caused them to switch away. Kafka is deprecating their Scala clients because of maintainability issues as well. Scala keeps making breaking changes on dot releases, making it impossible to maintain long term.

airless_bar 10y ago
Well, then we got different sources. Scala is developed by the EPFL, Lightbend, and ScalaCenter. That's three, not one. > Scala keeps making breaking changes on dot releases, making it impossible to maintain long term. That hasn't been true for more than half a decade.
- pfarnsworth 10y ago
  Sorry, I meant minor releases, like 2.10 to 2.11, etc.
  - airless_bar 10y ago
    These are not minor releases.
    - pfarnsworth 10y ago
      By definition those are minor releases.
      - airless_bar 10y ago
        Scala's versioning scheme is publicized and well-understood. Are you trying to blame Scala for not adopting SemVer before SemVer even existed? Very silly.
        rrdharan 10y ago
        Note that the use of major.minor.revision actually predates the formal SemVer specification by something like 20 years. That doesn't mean you're wrong; but it does explain the confusion. I'm a fan of Scala but I'll admit I was confused by this as well when getting started with it since I've been trained to see everything after the first decimal as "minor".
kod 10y ago
That's funny, when I talked to Neha (ex-Linkedin, cofounder of Confluent) she explicitly denied this meme about moving away from Scala. The new Kafka client library is in Java just to reduce the number of dependencies, the server is still written in Scala. Strangely, using Java hasn't stopped Confluent from making breaking changes on dot release of the client... which really puts the lie to your explanation.
- pfarnsworth 10y ago
  I specifically said the Scala clients are being deprecated. Go ask Neha to confirm this.
  - kod 10y ago
    No, you specifically said they're being deprecated because of maintainability issues inherent to scala, which is not true.
    - pfarnsworth 10y ago
      Nope. They were getting sick of having to maintain different versions of the Scala clients because of breaking changes, as per a Kafka committer.
      - kod 10y ago
        Even if some random kafka committer that you can't source believes that, the reasoning doesn't add up: SBT makes it fairly straightforward to cross publish for different dot releases of Scala, and libraries in the Scala ecosystem do it all the time. Scala dot releases are far apart. It's been over 2 years since 2.11, and 2.10 released in 2012. By contrast, the JAVA client that the Kafka project published in November is already undergoing breaking changes for the current release candidate. It's pretty clear that avoiding breaking changes is not an overriding concern for them, and even if it is, it's equally clear that Scala was not the inherent problem.

airless_bar 10y ago

Well, then we got different sources. Scala is developed by the EPFL, Lightbend, and ScalaCenter. That's three, not one. > Scala keeps making breaking changes on dot releases, making it impossible to maintain long term. That hasn't been true for more than half a decade.

pfarnsworth 10y ago
Sorry, I meant minor releases, like 2.10 to 2.11, etc.
- airless_bar 10y ago
  These are not minor releases.
  - pfarnsworth 10y ago
    By definition those are minor releases.
    - airless_bar 10y ago
      Scala's versioning scheme is publicized and well-understood. Are you trying to blame Scala for not adopting SemVer before SemVer even existed? Very silly.
      - rrdharan 10y ago
        Note that the use of major.minor.revision actually predates the formal SemVer specification by something like 20 years. That doesn't mean you're wrong; but it does explain the confusion. I'm a fan of Scala but I'll admit I was confused by this as well when getting started with it since I've been trained to see everything after the first decimal as "minor".

kod 10y ago

That's funny, when I talked to Neha (ex-Linkedin, cofounder of Confluent) she explicitly denied this meme about moving away from Scala. The new Kafka client library is in Java just to reduce the number of dependencies, the server is still written in Scala. Strangely, using Java hasn't stopped Confluent from making breaking changes on dot release of the client... which really puts the lie to your explanation.

pfarnsworth 10y ago
I specifically said the Scala clients are being deprecated. Go ask Neha to confirm this.
- kod 10y ago
  No, you specifically said they're being deprecated because of maintainability issues inherent to scala, which is not true.
  - pfarnsworth 10y ago
    Nope. They were getting sick of having to maintain different versions of the Scala clients because of breaking changes, as per a Kafka committer.
    - kod 10y ago
      Even if some random kafka committer that you can't source believes that, the reasoning doesn't add up: SBT makes it fairly straightforward to cross publish for different dot releases of Scala, and libraries in the Scala ecosystem do it all the time. Scala dot releases are far apart. It's been over 2 years since 2.11, and 2.10 released in 2012. By contrast, the JAVA client that the Kafka project published in November is already undergoing breaking changes for the current release candidate. It's pretty clear that avoiding breaking changes is not an overriding concern for them, and even if it is, it's equally clear that Scala was not the inherent problem.