Ask HN: Why do people have a hatred for Scala?

37 points by lnk2w ↗ HN
I'm learning Java and Ruby, and I saw few posts about functional programming. So I thought that the next step should be learn a FP language. But I saw so many people hating Scala. Is there a reason for this?

edit: Ok, Hatred is a strong word. I shoud have used dislike instead.

133 comments

[ 3.8 ms ] story [ 206 ms ] thread
Hatred is such a strong word ....
Here's one: http://blog.gmane.org/gmane.comp.lang.scala.debate/month=201...

Apart from occasional issues in the community Scala is criticised for being too complex: https://www.youtube.com/watch?v=uiJycy6dFSQ

You realize that the sender of this post (a) has been banned from all Scala mailing lists (b) has become one of the strongest Scala haters since?
Doesn't Paul Phillips still use Scala? He's actually forked the Scala compiler: https://github.com/paulp/policy

I think Paul Phillips agree with the overall direction of Scala and thinks it's the best programming language out there, but disagrees on design details and compiler inner workings.

He's still someone one frequently encounters when looking for help or getting started with Scala. He's still pretty high-up in scalaz.
Interesting that they were working on a scalaz course and book in 2011. I guess that became Functional Programming in Scala. I'd still like a course on scalaz.
(comment deleted)
People who actually use Scala love it. For instance, Scala is one of the most loved languages in the recent StackOverflow developer survey. The survey had more than 26'000 respondents, so this is pretty significant.

http://stackoverflow.com/research/developer-survey-2015#tech...

But you are completely right that there's also a lot of negative sentiment around it. Here are two possible reasons I can think of (I am sure there are others).

1. Scala does not form part of an established programming language tribe. It is neither a better Java nor a Haskell on the JVM. So people are challenged in their assumptions; they don't know what it is, and react negatively in order not to have to learn more.

2. Scala is pretty successful. So people in neighbouring language communities sometimes feel frustrated that a seemingly (to them) inferior language gets traction and their perfect language gets less. I saw some of that when Java eclipsed Smalltalk in the 90's. I never met a community as spiteful of Java as the Smalltalk one.

We used Scala for major projects; love the language, hate the infrastructure / documentation / frameworks / sbt / attitudes of many in the community. I believe this is a pretty common sentiment.
Basically I've seen this in person. Scala was driving the last startup I was in to the ground.

The thing that fascinates me is scala is like an art. It's like a new Obfuscated Perl Contest, but for functional programming. It doesn't really serve a purpose in legitimate business.

Scala code doesn't scale, it compiles too slow due to having too many features in the syntax. They took features normally meant for a standard library / external projects and literally augmented them into the syntax.

Scala, in it's current form, is a pipe dream. It really needs to be start over, but drastically simplified. Perhaps it should try to take a hit from Golang for compiler time advice: Simple languages compile fast and are easier to optimize.

I would think that "people" were driving the company to the ground. I'm working on a large-scale Scala project that has been going on for years. The codebase is clean, methods are easy to reason about. It not as verbose as Java would be, there's no monkey-patching like you might see in Ruby, refactoring is much safer than it would be in JavaScript, and it runs on Linux much better than C# would. And thanks to FP the code is thread-safe and mostly free of side-effects (except where they're explicitly required). I wouldn't trade Scala for any other language, for this kind of work.
What kind of project is it? Genuinely curious.
Web app with complex, distributed back-end processing.
Is it an accident that you picked the worst offenders for each category? :)

Not as verbose as Java -> Java is probably the most verbose compiled OOP language

Refactoring is safer than it would be in JS -> I think with the IDEs this means almost nothing.

Runs faster on Linux than C# -> I mean seriously, Java's biggest advertised feature was multi-platform support while we know that Redmond guys don't care about other platforms too much.

I feel like you are trying to justify Scala by comparing it to other languages and picking a feature or property of those languages that is the worst or almost the worst.

How about this:

- Scala has such a nice type system that it blows out OCaml from the water - Scala running faster on Linux than C++

etc.

I would expect honesty when it comes to using languages that would drive this twisted and wicked developer world to something better. If we keep using the worst languages to compare to we are not going to improve. This is what I think.

It's a way of saying that I value a language that is not too verbose, that doesn't encourage monkey-patching, that has strong types, and that works on Linux without too much trouble. The languages I listed do not meet at least one of my requirements, that's why I prefer not to work with them.
Scala isn't the best at any of these things though. It's great because it's an all-rounder language.

How about this:

Scala doesn't - quite - have the safety and conciseness of Haskell. But it's close.

Scala doesn't - quite - have the enterprise support and tooling infrastructure (monitoring/instrumentation, profiling, debugging, IDEs, library ecosystem) that Java does. But it's close.

Scala doesn't - quite - have the clarity of Python. But it's close.

Scala doesn't - quite - have the performance of C++. But it's close.

What scala does is sloppily bolt on everything without putting any checks or balances.

I don't doubt your sincerity.

Try to pull yourself out and understand it as an investor:

$500 a day to pay for a scala engineer. Not a word about the bottom line.

Python? Ruby? Are they algorithmically fast? No, but they ship and sell.

Depends what you're making. http://www.joelonsoftware.com/articles/HighNotes.html can apply - what I'm working on right now with Spark I dread to think how you'd do reliably in any other language.

> $500 a day to pay for a scala engineer. Not a word about the bottom line.

Maybe - I don't make that much and I have 5 years' Scala experience. (I have a relaxed environment and great culture though, so I'm not complaining). What I really don't get is Java companies where developers are chomping at the bit to use Scala and management says no - your devs are volunteering to become devs that companies would pay 2x for, the least you can do is let them.

What did it bolt on? Where are the checks missing?

The last major version and the next major version don't ship with any new feature at all, and removing some stuff, so it's a bit hard to see were you are coming from.

http://www.scala-lang.org/download/changelog.html

Python has PEP's. C and C++ have a ISO standards body. JDK has JEP. Adding a new library feature, let alone overhauling core types, is something scala added as if it was no big deal.

In python, when "new classes" were introduced, it was a big honking deal! You can bet it was heard about everywhere, in the documentation, etc. cpython interpreters like python 2.6 have support going back 5 years, and the changes between 2.x python versions are small compared scala.

There's a reason why enterprise languages move like a toad. We can't have legacy systems breaking. We want our legacy libraries to keep working. In 2015, I write python 2.6 code that works in python 3.5-dev, because they carefully planned releases and I write idiomatically.

Ask yourself if uninitiated generalist prorgammers can really grasp those hieroglyphic walls of text. It's encoding too much information too densely, and inside the density, there's so many clever tricks that block could doing.

It entices solipsistic programming. Long evenings and hard work goes into programming blocks of logic that aren't portable or readable as a future consolidation. This is where scala user's get protective. Their mental thought is legitimate, the output however means nothing to fellow coders.

With java, you could say we satisfy the longterm code quality. Even though I'm cynical of the JVM, I realize that my time and effort would hold out on the long term and my team would have code that would be a legacy into the future.

With scala, their is a sense of urgency coupled with a legitimate sense of eureka! But it all ends up looking like schizophrenic scribbling on a napkin to others.

Scala must limit the grammar in your programming language.

I'm not even sure which point you are trying to make.

Did you even read the link you posted? It supports what I said.

You keep writing walls of text which are either wrong or don't relate to the topic at hand. Many of the mistakes should be obvious to a person who has used Scala for more than 5 minutes, so I'm really wondering what's your issue here ...

Not liking Scala is perfectly fine. It's not necessary to make up claims (which don't hold up to 5 seconds of scrutiny).

Edit: Instead of editing you post trying to evoke a more emotional response from people, why not focus on correcting your false claims?

It's amazing that you keep doing edits which are literally begging for an emotional response, but couldn't manage to take a few minutes to check your claims against the reality.
Right. Let me take this from a different angle. I like to hear about projects moving away from technology much more than jumping onto a band wagon. Right now, Scala feels to me as a band wagon. Some of the guys who moved to use Scala from Java just simply moved back because they realized that almost all of the features are available (emphasis on almost) in Java (especially in Java 8). On the other hand, learning Scala takes time so for a while you are writing inefficient code. On the top of that you need to make sure everybody is on the same page in your team, that is also additional effort. All of these were driving projects (like Kafka) away from Scala (look at the new producer code).

To summarize: Scala to me is just a better Java with too many trade offs.

That's interesting, because weren't Kotlin and Ceylon created because people wanted to have "just a better Java", which Scala is not really interested in being?

> they realized that almost all of the features are available

Interesting too. Looking at the stuff I'm currently doing, there is plenty of stuff which is just impossible in Java.

By the way, isn't "Scala has such a nice type system that it blows out OCaml from the water" already the case?

> weren't Kotlin and Ceylon created because people wanted to have "just a better Java", which Scala is not really interested in being?

Scala was that at first. Arguably that's still Typesafe's primary interest.

> By the way, isn't "Scala has such a nice type system that it blows out OCaml from the water" already the case?

Yes and no. It's more featureful (higher-kinded types are really nice), but less elegant and type inference works less well (in part because scala has both inheritance and typeclasses).

To my mind the bandwagon has been and gone, with those companies moving away from Scala being those who arrived on the bandwagon and departed with it. But I guess it looks different from the inside.

If you're treating Scala as "just a better Java" then you're not writing inefficient code; you're writing code that could be better Scala code but is still better than the Java you would otherwise have written. Even if you never move beyond the "Java without semicolons" stage, hey, it saved you writing all those semicolons.

But Scala absolutely is a full language and not just a better Java; Java 8 barely scratches the surface of what you can do in Scala. I don't think I could bear to work in a language without higher-kinded types again.

Kafka has some very particular constraints that I don't think apply in general; remember they're making a framework rather than an application.

We use Scala for major projects too, I love the language and also the documentation, frameworks, (even sbt) and attitude of the MAJORITY of the community. Can you give concrete examples of what caused you to hate all of the above? Especially I'm interested in the community aspect. I've found the community very friendly and helpful, but perhaps I'm going to the wrong (i.e. right) places?
Erlang is a pretty big omission in that list
The problem with a survey asking people how much they love their language is that people will employ all kinds of biases to suppress the cognitive dissonance of choosing a terrible language.

The harder something was to succeed at, the harder you'll try to convince yourself it wasn't wasted effort.

I wouldn't say hate. Scala is a OO-functional language, so it's bound to have people who dislike it from both of those camps.

I started learning Scala (it got me into functional programming) but dumped it for the same reasons as Java. It's bloated. I also question Scala's longevity.

I'm happily using Elixir and Clojure these days, but I mainly do web stuff so YMMV.

You question the longevity of Java and Scala, and this is why you use mini niche languages? Seriously.
(comment deleted)
Corrected.

Elixir as a language may or may not last. I'm betting it will, but even if it doesn't, it works well with Erlang which is going nowhere.

There's more a case against Clojure, granted. I think because Scala is seen as a bridge language is the another reason why it won't last.

Also the compiler drama... http://www.infoq.com/news/2014/09/scala-compiler-forks

Isn't it positive that the community is so large that it can sustain multiple compilers?

Some time ago people complained that Scala had only one compiler ... so now they complain about the opposite?

> Some time ago people complained that Scala had only one compiler ... so now they complain about the opposite?

I suspect the "they" that are complaining now about multiple compilers are mostly not the same people that were complaining about one compiler previously.

Hate is too strong a word, but I've seen some poorly written Scala that over used overridden operators and it left a bad taste in my mouth.
(comment deleted)
I don't hate Scala but I did not pursue it after only a few 'lessons' : transitioning from Java to Scala was smooth and not intellectually stimulating. On the other hand , Clojure programming forces me to think differently and the solutions are more elegant. I understand Scala is also functional but it is too permissive and I slide back in imperative all too easily. Clojure is highly disciplinarian and opinionated and I find that refreshing.
But how effective is Clojure in writing server side code? I've never used it so I have no way to know.
One of the best decisions I made was to transition from J2EE server code (Spring+ hibernate + Jsf/(some)SpringMVC ) to Clojure ring + Moustache. The code is smaller, simple to understand and concurrency is a breeze. The only downside is you can't write a SOAP server as XML namespace support is missing in its xml library.

edit : typo

I've used it a little and haven't had any problems. You can run it on Jetty, so performance is excellent, and you get access to the whole Java ecosystem. Things like Core.async, Pulsar (modeled after Go's coroutines/Erlang's actors) and Software Transactional Memory make parallel/concurrent programming a breeze. The biggest "issue" some people have with it is that it's generally dynamically typed, but if you don't mind that then it's at least as effective as other server side dynamic languages.
Interesting, that was exactly my reason for preferring Scala. With Clojure I could see it would take me weeks to get productive. With Scala I could write Java-without-semicolons and be slightly more productive on day 1, hour 1 even, and then gradually pick up the more advanced features.
Not hate, but I had a feeling that it was a kitchen sink language, also too much academic influence leaves a bad taste.
In my opinion (and I have worked on large scale development in Scala in the past) it is just unnecessarily complicated.

Random annoyances off the top of my head - you can't necessarily understand an isolated function unless you know what implicits are being used, crazy overuse of operator overloading and slow compilation times (this has improved over the years).

You don't have to learn Scala, you could learn Clojure, F#, OCaml or Haskell. They would all teach you interesting aspects of programming and then you could come back and examine Scala with a broader perspective.

That actually sounds like you encountered code that shouldn't have been or you had people using Scalaz (which has weird operators taken from Haskell, looking at you <*>.)
Scalaz is evil. Some of the operators are even non-ASCII.

Anyway, scala needs less weird operators, not more. Looking at you, parser combinator library.

For those who don't understand: Scalaz is an additional layer of syntax and tricks on top of what is already there. It seems to have quite a lot of power!

    implicit val option = new Traverse[Option] with MonadPlus[Option] {
    def point[A](a: => A) = Some(a)
    def bind[A, B](fa: Option[A])(f: A => Option[B]): Option[B] = fa flatMap f
    override def map[A, B](fa: Option[A])(f: A => B): Option[B] = fa map f
    def traverseImpl[F[_], A, B](fa: Option[A])(f: A => F[B])(implicit F: Applicative[F]) =
      fa map (a => F.map(f(a))(Some(_): Option[B])) getOrElse F.point(None)
    def empty[A]: Option[A] = None
    def plus[A](a: Option[A], b: => Option[A]) = a orElse b
    def foldR[A, B](fa: Option[A], z: B)(f: (A) => (=> B) => B): B = fa match {
      case Some(a) => f(a)(z)
      case None => z
    }
  }
Excerpt from https://github.com/scalaz/scalaz#type-class-instance-definit....
Looks pretty readable and reasonable.
That part is fine. The trouble with Scalaz is it adds a bunch of extra operators (that is, methods - the distinction doesn't exist in Scala) like |+|, \*> and >=>.
> crazy overuse of operator overloading

F# might not be the best place to go then:

http://stackoverflow.com/questions/2210854/can-you-define-yo...

https://msdn.microsoft.com/en-us/library/dd233204.aspx

Most languages have similar capabilities. E.g. in Java you can define a method called ★★★ if you want (edit: this specific example doesn't seem to work, but certainly non-ascii method names are possible). The difference is cultural; Java libraries generally wouldn't define such a method, while certain Scala libraries might.
+1 Implicits. We put very strict limits on use of implcits. They make code extremely difficult to reason about, but can also be incredibly dangerous. I once stumbled upon an implicit cast of Int to Float... Oh, my.
Is there any linters available for IDE's to ensure conformance with a vanilla ruleset of scala? If that existed, scala would be able to shape itself up nicely.
Any modern scala IDE highlights implicit conversions with a green underline, which I find is plenty to make them readable.
Their are linters available for scala (e.g. wartremover). Also, the Scala compiler supports a number of flags to warn you if your code is using some of Scala's 'more questionable' features. You can even tell the compiler to fail if any of these warnings occur. A list of useful flags can be found at https://tpolecat.github.io/2014/04/11/scalac-flags.html.

You might also want to look at this excellent talk titled 'Toward a Safer Scala' at https://docs.google.com/presentation/d/1tCmphnyP3F5WUtd1iNLu... that recommends a number of best practices that can be followed using Scala.

If you're using sbt, I put together a giter8 template for scala/sbt projects that follows these best practice recommendations at https://github.com/hohonuuli/basicscala.g8

Agreed that implicits were one of the critical things that caused me to move away from Scala. I really couldn't justify in my head the use of such a thing.
The one case I can make for implicit conversions (implicit parameters are brilliant and useful and not normally what people complain about) is the spray-routing DSL, e.g. https://github.com/spray/spray/blob/master/examples/spray-ro... . What would be a separate config file in any other framework is instead ordinary Scala code following the rules of ordinary Scala, which is wonderful - you can factor out and reuse common parts of your routing really easily, because it's all just code.
I don't like Scala for the same reason as C++. Scala has an incredible semantic complexity with a Perl-like syntax. Too much magic going on.
Yes magic is one thing that makes it difficult to get into a language and to maintain code written in that language, where of course maintaining can mean going back to code you wrote last month.

One of my pet hates in C++ was implicit casting and I'm hearing that Scala does similar, which is putting me off it.

Scala has implicit conversions but the IDEs highlight when they're happening, so they're not completely invisible.

To my mind Scala is a very unmagic language; very complex libraries are written for it, but they're never magic, they're always ordinary Scala code and ordinary Scala features, just combined in clever ways. E.g. typeclasses are a language feature in Haskell, but in Scala they're just a pattern that you implement using implicit parameters. Actors and messages are a language feature in Erlang, but in Scala they're just a library with methods that you call. Type-level functions are a language feature in e.g. Idris, but in Scala (e.g. Shapeless) they're just a technique making use of implicit resolution.

I dabbled in scala for a while a few years ago and ultimately decided not to invest the time becoming an expert in it for the following reasons. 1) Slow compile times, I really value fast feedback and if it takes me over a second to compile and run a unit test that just doesn't cut it for me. 2) No clear idiomatic style and having many different ways of doing things each of which can imply different behaviour in different contexts.
I used to feel the same way about fast feedback, but after working on slower to compile applications for a few years, I'm not sure it's a good way of working.

When I used to work like that, I'd write code, and constantly be checking that it compiled. I'd be watching my test dashboard and feel happy turning the lights green. But it was definitely a crutch.

If you asked me to code without a compiler I'd make basic syntax errors. I'd let basic, predicable bugs slip through because they weren't covered by my tests. In my rush to turn the next light green, I wasn't thinking enough.

Maybe that's not how you work, but if it is, try building once a day and turning syntax highlighting off for a couple weeks. For me, (being forced to) work like that for a while has helped me long term.

In 2015, XML is a first class citizen but JSON get a third class treatment. JSON parsing in Scala is ridiculous. http://www.reddit.com/r/scala/comments/2l7v5u/json_parsing_i...
XML is in the process of being demoted.

spray-json is quite possibly the best JSON library I've ever seen, in any language.

I use play-json (on a Play Framework project) and it serves its purpose well.
We use both play-json and json4s. They're both pretty cool and easy to use
Bloated,complex, perl syntax, slow compilation times, bad attidude of the Scala community. Please, don't waste your time trying to learn Scala.
Everyone agrees Scala is too complicated. Beyond that, there's a flexibility problem: Scala allows you to write a global mutableMonadFactoryFactoryMonad.

That said, nothing does exactly what Scala does. Fluently mixing imperative, lazy, OO and functional styles isn't really common. Neither is the wealth of concurrency constructs available to Scala programmers through the standard library and Akka.

I'm writing a compiler in (not for) Scala right now and it's pretty sweet.

> Everyone agrees Scala is too complicated.

This is not true.

Everyone who hasn't used it for at least a year or more than three.
I've been using it for five years and I don't think it's too complicated. (There are plenty of places where I think complication is a necessary evil for the sake of Java compatibility)
Programming languages are a new thing for humanity. I'm pretty sure that we aren't making programming languages correctly yet. And even worse there almost definitely isn't a One True Programming Language (it seems suspiciously like there's going to be more than one "right" programming language per domain (ie embedded, web, server side, etc) and to make things even even worse the right language to use might even be different based on the person using it).

If you find yourself in the future "hating" all the programming languages, this isn't necessarily problematic, it might just mean you have a good understanding of programming languages. Just try to remain polite and remember that there's more than one way to see most scenarios.

I was a big fan of SML, and really wanted to like Scala. The reason I didn't pursue it was the language is really complex (imo) kitchen sink as others have said, and as others have also said, there's no one best way to do things, no clear idiomatic style. Plus there was a bit of churn in the language in the beginning. I concluded that if I was going to use the jvm, may as well just stick with Java, or another jvm language with more wide spread acceptance (jython, groovy, ...).
Jython or groovy have more market share than scala?
Where does 'market share' appear in my post? At no point do I make any claims on market share. Thanks for the charity[1]

My intent was to imply that since jython is a python implementation, the language itself is more widely 'accepted'. Where accepted may mean "in general use and considered to be a good langauge". Groovy has been called a better java by some. Another example would be JRuby.

[1] http://en.wikipedia.org/wiki/Principle_of_charity

Your post said groovy and jython had more "wide spread" acceptance than Scala, and I thought you meant market acceptance. It is a reasonable reading of your post.

Your intended meaning requires a big leap in what side spread acceptance means, so I hope you can see the confusion.

It is patently absurd to claim jython or groovy have more marketshare (as you define accepatance). Thats where the principal charity kicks in and oneone might ppose since the claim seems absurd, perhaps the author meant something else. Perhaps the leap was too great, but i stand by it.
I think it's because they went into it for the wrong reasons. If you jump into a language because it is the latest fashion, and not for solid engineering reasons, then it will be an uphill struggle to reach your goals.

I have only dabbled in Scala myself, kicked the tyres as it were. My question was, is this an Ocaml or Haskell with good interop with the Java ecosystem? The answer is no but I don't hate Scala for it, I just moved on. But many folks would have persisted and tried to make it into something it's not and gotten miserable in the process.

There's actually a port of OCaml to the JVM that has pretty good interop with the Java ecosystem, or at least it will once it's out of beta: http://www.ocamljava.org/.
Looking back at my blog, this was in 2011. I am not doing much OCaml these days either, actually.
Taste.

Just like how people won't touch Python because of its whitespace, people won't touch Scala because of the JVM.

What's wrong with the JVM? I thought it's one of the most well regarded computing abstractions.
JVM can't be the reason people won't touch Scala or any other JVM language. Actually, being JVM-compatible is an attraction point.
> JVM can't be the reason people won't touch Scala or any other JVM language.

It can be -- and is -- for some people.

> Actually, being JVM-compatible is an attraction point.

Sure, for some people. People have different preferences.

I'm currently learning Scala (background in Python and Haskell) and I have encountered a few road blocks:

1. The REPL is not very helpful: You cannot look up documentation a la IPython (i.e. myFunc?) or inspect objects easily to find out how things work

2. There always seem to be 10 ways to do the same thing. This makes it much harder to understand other people's code than when there is just one way to do it.

3. The type system seems less helpful than Haskell's (e.g. why is "asdf" + 3 not a type error?)

(3) is because Scala attempts to preserve Java semantics for strings. I agree that this is a mistake.
(2) Isn't this true for all languages, and in fact isn't that the hallmark of a _good_ programming language? One could also argue that this provides evidence of simplicity, as many smaller building blocks can be assembled in different orders to produce the same (complex) result.

The antithesis is when we see posts about how "Go's too simple".

"Isn't this true for all languages". No, not at all. Many languages have an idiomatic way to write things. Python definitely does and so does Haskell (to a lesser degree).

"One could also argue that this provides evidence of simplicity" Or one could argue that it provides evidence of complexity, since you need to hold much more information in your head to achieve the same results.

From 'The Zen of Python' - "There should be one-- and preferably only one --obvious way to do it."

I'm not sure I've seen any "Python's too simple" posts. Maybe Go's criticism is based on some other factor?

2. There are places where this is true, but a lot of people seem to get hung up on the syntactic differences between e.g. "a.foo(b)" and "a foo b", which really are superficial and you learn to read past very quickly.

3. Some of these are backwards compatibility. You can get a more helpful typesystem by setting a few flags: https://tpolecat.github.io/2014/04/11/scalac-flags.html

Scala grew really fast off of an interesting, new academic ideas. There are a lot of stretch marks.
Could you give an example?
Slow compilation, many ways of doing things instead of a well-defined Scala-style, inheriting lots of Java libraries and having their perhaps very un-Scala-like behavior littered all around, two communities of programmers (roughly) the Java-alikes and the Haskell-alikes
How is slow compilation an "academic feature"? Same for the rest?

There might be valid criticism, but to me your comment doesn't make a good job bringing the "stretch marks" across ...

The stretch marks come from bringing a small academic endeavor up to "production strength", not that there are specific academic ideas.
A lot of Scalaz and Shapeless duplicates things that were implemented less well in the standard library. E.g. standard-library tuples can't be abstracted over (supposedly will be addressed in Don Giovanni but that's at least 3 years away). Standard-library futures aren't completely controlled (and overuse implicits) so there is scalaz-concurrent Future which is almost but not quite the same. The macro implementation is clunky and really needs a couple of minor changes that are going to be in the next release but aren't at the moment, quite possibly because it was implemented by an academic whose time didn't quite sync up with the scala language release cycle.
There has been an... unfortunate community attitude. Some people were quite unwelcoming to newcomers. I think this is down to two individuals; nowadays many friendlier folks are writing Scala libraries and hopefully the community will improve.

I get the sense the Java community is also unused to interacting with other languages, because for a long time the JVM was a world unto itself. Most languages have a spectrum of "neighbour" languages and so users are used to working with at least slightly different alternatives. Scala is possibly Java's closest neighbour (Groovy is not really popular enough to show up on the radar of most Java devs) and it's become something very different, so there's a real culture shock just trying to talk to each other. A lot of Scala folks take a lot of assumptions for granted that are very alien to Java folks.

None of which really takes away from the language itself, if you're willing to learn on your own or tolerate a few insults when you ask for help. IMO it is very much worth it: Scala is genuinely the best practical language available today (it has more than its fair share of warts but they're mostly for JVM/Java compatibility, which makes it so much easier to introduce to business than e.g. Haskell).

I know the plural of anecdote is not data, but every time I've asked a question in #scala I've received nothing but helpful and welcoming responses.
Most of the time that's what you'll get. But there are (or at least were when last I was there) two or three people who will respond unpleasantly, and I want to be honest about that.
Is this why I don't see you there anymore? This has in my opinion made #scala a markedly less pleasant place to hang out.
Thanks, and sorry to be absent. That's more about work circumstances; it's been an awkward month or so, and I do intend to come back once things shake themselves out.
This has also been my experience in Stack Overflow and in the Play Framework user group.
I'm a professional java dev - groovy definitely does show up on our radar as it's used as the glue for a lot of tools related to our "production" code.

For example gradle buildscripts are groovy, as is the spock test framework.

Groovy is to the JVM what Bash is to Linux. It's used for writing quick and short scripts that manipulate Java classes and for building them, but you wouldn't use it to write actual systems despite the static typing features made available in Groovy 2.x. Use Java or Scala for that. But even Gradle's use of Groovy is in question -- Gradleware just employed one of the 2 Groovy developers who became unemployed after VMWare's Pivotal stopped funding Groovy last month. I suspect Gradleware will get him to replace the Groovy monstrosity with their own lightweight version of the language which does what a build DSL needs and not much more. This could be a reaction against Grails 3.0, a 130Mb download released alongside Grails 2.5 last month, bundling Gradle in an apparent attempt to take control of its distribution channel, in the same way they bundled Spring with Grails 1.0 back in 2008 then got their company bought out by Spring later that year. When a language's development is driven more by corporate maneuvering than providing functionality for a particular purpose then would you even trust it for scripting? Perhaps look at Xtend or Clojure!

You can read the other unemployed developer's take on Groovy's development history at http://blackdragsview.blogspot.com/2015/04/about-being-paid-...

Plenty of Java shops use it, but plenty don't. My impression is that most people who are aware of Groovy will also be aware of Scala, whereas there are a lot of Java developers for whom Scala is the only "other JVM language" that they've heard of. But that's just my experience.
I don't hate it. Scala looks cool and I might use it if I had to use the JVM.

What turns be off from looking into it much:

Verbosity. It seems that it can't infer types in as many places as an ML. I prefer rather succinct code. I understand Scala has a powerful type system and it isn't always possible, but... ugh.

OO. Scala seems to want to really embrace Java's OO model fully, and that's a bit ugly. It's probably a good practical decision but feels like a turn off. Again, I haven't used Scala, this is just an impression I have.

You really want a lot of type annotation anyway. They make error messages a lot more informative.

Scala is, by definition, a superset of Java. It's not ideal, but there aren't really any good alternatives.

> Verbosity. It seems that it can't infer types in as many places as an ML. I prefer rather succinct code. I understand Scala has a powerful type system and it isn't always possible, but... ugh.

I think the problem is that Hindley-Milner type inference doesn't play with OO type hierarchies, and so Java interop (which is a key motivating purpose of Scala) means worse inference than ML-family langs for Scala. Its not really that its a powerful type system that is the issue (Haskell has a more powerful type system, but better inference.)

> OO. Scala seems to want to really embrace Java's OO model fully, and that's a bit ugly.

I think "embrace" is a bit strong, but it wants to support it fully, because its a key part of the interop story.

I can speak from my own experience with using it on a growing team: Don't.

It's a very powerful and expressive language. That translates to "completely unreadable by people without at least a few months direct experience in it." If you plan on introducing people with little to no scala experience to your code base regularly you will probably want a different language or to severely limit your allowed feature set.