8 ms·

Although I agree with most of what the author says here about scala and its benefits and features, this is hardly a debunking and more of a strongly opinionated

Although I agree with most of what the author says here about scala and its benefits and features, this is hardly a debunking and more of a strongly opinionated defense. Some of the arguments are along the lines of "hey SBT isn't just a bunch of symbols" or "I upgraded my MacBook and compilation times are not a problem" or "tooling is better now". Reassurances yes, debunking hardly. Scala compilation time is probably the worst problem I have with scala, and it still is frankly. I have seen no evidence that this has improved from personal experience and after talking with devs I know working in large scala code bases (Foursquare, Twitter). Even if there are speed improvements in the scala compiler in future versions, the author doesn't address binary incompatibility between major scala versions either which, along with slow compilation times, makes it a serious PITA to upgrade to a scala version that might actually compiler faster. [edit] hit submit too early last time, re-edited after regathering my thoughts.

tonetheman 11y ago
Compilation time is still a problem though it is not as big of a deal to me personally. Complexity or learning the language is still the biggest issue I see. That has not changed in 5 years.
- merb 11y ago
  > Complexity or learning the language is still the biggest issue I see. That has not changed in 5 years. That's not true. Most things are them same or easier than on Java8. If you don't lear Lambda's on Java8 you are missing everything. And most things in Scala's are like Lambda map/foreach all over the place. and generators making things easier to read and easier to understand. Java8 doesn't have this future you end up writing flatmap(data -> return flatmap .. return flatmap return flatmpap) that's awkward. On scala if you don't use the hard things the language is way easier than the most languages outside of the jvm ecosystem.
gilbertw1 11y ago
I'll address the binary compatibility concern. I think at this point for the average scala developer, binary compatibility isn't really a big deal anymore. At this point the releases require very few (if any) changes to the codebases and all the library maintainers have stepped up their game with releases corresponding with new versions. Sure, it'd be great to have binary compatibility, but I think the ability to make changes to the language unhindered by supporting byte code from previous languages is more valuable. For example with the 2.11 release, I had three different non-trivial sized projects and for each I was able to simply change the scala version in my sbt file and everything worked just as it had before with no library or compile issues. I will agree that it was a huge issue in the past with 2.7 - 2.9, but in my world it hasn't bitten me in a long time. Definitely not trying to say it isn't an issue or something that wouldn't be great to be fixed, but at this point I have a tough time seeing it being considered a barrier to entry in any way. Also, I just throw in that for me compile time hasn't been an issue for me lately either. I work on reasonably sized projects, but definitely nothing on the twitter / foursquare scale.
bad_user 11y ago
Scala developers end up on the defensive because many of the claims are either because of misunderstandings or are fashion driven, being repeated ad-nauseam many times by people with only a superficial experience of the language. For example I'm going to make the claim that SBT indeed isn't just a bunch of symbols, but rather one of the best build management tools in existence. For anybody going to challenge that I'm going to start mentioning the complete clusterfuck of other platforms and languages, like that of C/C++, or that of Python, or that of Javascript, or that of C#/.NET, or that of Haskell. SBT not only does demonstrably a better job than most, but works well out of the box and is relatively pain free. It has its own set of problems of course, but what tool doesn't. Compatibility issues are real. But you know, the nice thing about those compatibility issues is that it forced the community to come up with solutions. At least Scala and SBT are addressing compatibility issues, whereas the transition from Java 6 to later versions is proving to be next to impossible and I don't think I have to mention Python 3 or ECMAScript 6. Compilation times haven't been that much of an issue for us because our codebase is split into services and libraries that have a reasonable size. And on the switch from Scala 2.10 to 2.11 I definitely saw an improvement, with the claims of 30% being about right. I do agree that they can do better, taking a look at similar languages with a slightly better story, like Haskell. However what people are usually missing is that this is usually a trade-off with compile-time safety. The more static a language is, the harder it is to compile it. The compilation cost for a dynamic language like Javascript is zero, the cost being completely amortized with everything happening directly at runtime. When going from Javascript to Java or C#, for people that prefer Java or C#, people go from zero to a very noticeable and resource intensive AOT compilation step and many times this tradeoff is worth it (depending on whom you ask) for safety, performance or tooling reasons. Well, Scala is a more static language than Java, it infers a lot of things, it has better generics, it does implicits which can then model type-classes and even the infamous CanBuildFrom pattern and so on, giving you a nice balance between productivity and safety in a static language. And that doesn't come for free.
- bigtunacan 11y ago
  I'm not quite sure what you are trying to say with this statement, "I don't think I have to mention Python 3 or ECMAScript 6". ECMAScript 6 is finalized and many people are running it today in production environments either using Node on the backend or on the front-end using a build process that integrates with something like Babel. The following quote implies that you believe JavaScript is runtime evaluated, when in fact the standards body does not specify runtime evaluation or compilation. That is a decision left up to the implementation. All major browsers today and Node.js use just in time compilation for JavaScript rather than runtime evaluation. "The compilation cost for a dynamic language like Javascript is zero, the cost being completely amortized with everything happening directly at runtime." [EDIT] I have added a link to the JavaScript entry on Wikipedia where you can verify that modern browsers compile rather than interprest JavaScript. https://en.wikipedia.org/wiki/JavaScript https://en.wikipedia.org/wiki/JavaScript
whateveracct 11y ago
Full-pass Scala compilation is slow, true. It takes my codebases at work a couple of minutes to compile currently. But 1) sbt incremental compilation is basically immediate. This facilitates tight feedback loops for running tests and using the repl 2) Scala's type system does so much more than fast-compiling languages (Go, Java, etc) that it's definitely worth it. What you lose in compile-time, you gain in speed to a correct and sound solution.

tonetheman 11y ago

Compilation time is still a problem though it is not as big of a deal to me personally. Complexity or learning the language is still the biggest issue I see. That has not changed in 5 years.

merb 11y ago
> Complexity or learning the language is still the biggest issue I see. That has not changed in 5 years. That's not true. Most things are them same or easier than on Java8. If you don't lear Lambda's on Java8 you are missing everything. And most things in Scala's are like Lambda map/foreach all over the place. and generators making things easier to read and easier to understand. Java8 doesn't have this future you end up writing flatmap(data -> return flatmap .. return flatmap return flatmpap) that's awkward. On scala if you don't use the hard things the language is way easier than the most languages outside of the jvm ecosystem.

gilbertw1 11y ago

I'll address the binary compatibility concern. I think at this point for the average scala developer, binary compatibility isn't really a big deal anymore. At this point the releases require very few (if any) changes to the codebases and all the library maintainers have stepped up their game with releases corresponding with new versions. Sure, it'd be great to have binary compatibility, but I think the ability to make changes to the language unhindered by supporting byte code from previous languages is more valuable. For example with the 2.11 release, I had three different non-trivial sized projects and for each I was able to simply change the scala version in my sbt file and everything worked just as it had before with no library or compile issues. I will agree that it was a huge issue in the past with 2.7 - 2.9, but in my world it hasn't bitten me in a long time. Definitely not trying to say it isn't an issue or something that wouldn't be great to be fixed, but at this point I have a tough time seeing it being considered a barrier to entry in any way. Also, I just throw in that for me compile time hasn't been an issue for me lately either. I work on reasonably sized projects, but definitely nothing on the twitter / foursquare scale.

bad_user 11y ago

Scala developers end up on the defensive because many of the claims are either because of misunderstandings or are fashion driven, being repeated ad-nauseam many times by people with only a superficial experience of the language. For example I'm going to make the claim that SBT indeed isn't just a bunch of symbols, but rather one of the best build management tools in existence. For anybody going to challenge that I'm going to start mentioning the complete clusterfuck of other platforms and languages, like that of C/C++, or that of Python, or that of Javascript, or that of C#/.NET, or that of Haskell. SBT not only does demonstrably a better job than most, but works well out of the box and is relatively pain free. It has its own set of problems of course, but what tool doesn't. Compatibility issues are real. But you know, the nice thing about those compatibility issues is that it forced the community to come up with solutions. At least Scala and SBT are addressing compatibility issues, whereas the transition from Java 6 to later versions is proving to be next to impossible and I don't think I have to mention Python 3 or ECMAScript 6. Compilation times haven't been that much of an issue for us because our codebase is split into services and libraries that have a reasonable size. And on the switch from Scala 2.10 to 2.11 I definitely saw an improvement, with the claims of 30% being about right. I do agree that they can do better, taking a look at similar languages with a slightly better story, like Haskell. However what people are usually missing is that this is usually a trade-off with compile-time safety. The more static a language is, the harder it is to compile it. The compilation cost for a dynamic language like Javascript is zero, the cost being completely amortized with everything happening directly at runtime. When going from Javascript to Java or C#, for people that prefer Java or C#, people go from zero to a very noticeable and resource intensive AOT compilation step and many times this tradeoff is worth it (depending on whom you ask) for safety, performance or tooling reasons. Well, Scala is a more static language than Java, it infers a lot of things, it has better generics, it does implicits which can then model type-classes and even the infamous CanBuildFrom pattern and so on, giving you a nice balance between productivity and safety in a static language. And that doesn't come for free.

bigtunacan 11y ago
I'm not quite sure what you are trying to say with this statement, "I don't think I have to mention Python 3 or ECMAScript 6". ECMAScript 6 is finalized and many people are running it today in production environments either using Node on the backend or on the front-end using a build process that integrates with something like Babel. The following quote implies that you believe JavaScript is runtime evaluated, when in fact the standards body does not specify runtime evaluation or compilation. That is a decision left up to the implementation. All major browsers today and Node.js use just in time compilation for JavaScript rather than runtime evaluation. "The compilation cost for a dynamic language like Javascript is zero, the cost being completely amortized with everything happening directly at runtime." [EDIT] I have added a link to the JavaScript entry on Wikipedia where you can verify that modern browsers compile rather than interprest JavaScript. https://en.wikipedia.org/wiki/JavaScript https://en.wikipedia.org/wiki/JavaScript

whateveracct 11y ago

Full-pass Scala compilation is slow, true. It takes my codebases at work a couple of minutes to compile currently. But 1) sbt incremental compilation is basically immediate. This facilitates tight feedback loops for running tests and using the repl 2) Scala's type system does so much more than fast-compiling languages (Go, Java, etc) that it's definitely worth it. What you lose in compile-time, you gain in speed to a correct and sound solution.