
Ask HN: What is your experience with Scala? - wsieroci
Hello,<p>what is your experience with Scala language? Do you like it? Would you use it for your next project? Are you thinking of something else?<p>Cheers,
Wiktor
======
allengeorge
I wouldn't use it again. While I appreciate the concision and the strong
collections API I'm not pleased with the ecosystem:

    
    
      * Neither IDEA or Eclipse are particularly great (I routinely get types that can't be introspected, and both require inordinate amounts of RAM to work well)
      * SBT is a productivity sink to do anything beyond the basics with
      * The compiler is slow (and yes, it does matter)
      * The compiler's error messages are poor
      * I find the code in many Scala libraries impenetrable (which matters a lot while debugging).
    

Moreover, I notice a lot of "WTF" moments with the language. Often, this means
that the effect of the code you're looking at isn't always obvious.

The unexpected side-effects and the library situation frustrates me the most:
I feel like I'm always dealing with "code in progress" written by people
who're enamored with the features Scala provides over building something
robust and easy to understand.

Obviously, my opinion. There are plenty of people out there who love Scala.

~~~
merb
Don't get me wrong I use Scala on my Day to Day job, but some of your things
are just wrong.

I.e when you get types that can't be introspected you definitly don't work
with simple scala. I've been playing around with really big projects and even
made some contributions to the Playframework project:
([https://github.com/playframework/playframework](https://github.com/playframework/playframework))
and even that has barly/no types that won't work. (Oh while working on
Multipart I had Java Code that didn't worked on IntelliJ 15 (works in 2016.X
now)). I know there are certain libraries that are akward to work with in any
ide but these libraries should be avoided. And they are mostly based on scalaz
and I would even consider specs2 as harmful. But nothing applies to scalatest
its imo way faster.

While you see SBT as a productivity sink you can stick to gradle or maven,
both are supporting Scala. Still even the slowness of sbt (which isn't so slow
it just needs to do everything twice in IntelliJ when you use it inside the
console and your ide) isn't so bad for me since it's really simple to make
AutoPlugins (this isn't so simple in Maven/Gradle) What error message is poor
for you? I barly had issues with them. My issue's were more some stack traces
but on Java the same stack traces annoyed me aswell but that was on runtime
crashes.

Actually its true that some libraries are akward. But my ruling for libraries
is anyway: use as few as possible. You prolly don't need a library for leftpad
but that applies to all libraries I even was on the golang Ecosystem for a
while predates even the 1.0 dates I even have a book for ~0.7 and there were
some libraries that were pretty akward and messy, things evolved but there are
still some code around which you shouldn't barly touch and even for http, you
prolly don't need a library for most of your stuff and still people use them.

P.S.: Nothing against the compiler slowness but from day-to-day you barly
notices only a sbt clean compile could be slow but our app (which is quite big
these days only takes a few seconds). Even play! compiles fast on my machine:

    
    
        sbt clean compile
        // ommitted everything in between
        [success] Total time: 95 s, completed 04.06.2016 23:54:53
    

Which isn't the compile time its the time the whole command i.e. clean +
compile took. And I wouldn't consider that "slow". I mean slower than what?
Go, of course. But its the _only_ language that __compiles __so fast. Also
Scala 2.12 will likely bring some improvements (soon tm).

~~~
photon_off
This is the typical Scala apologists' reply. It's not a problem with Scala,
it's a problem with you.

When it takes several dense paragraphs to explain simple problems, it means
that problem is not solved easily. For some programmers easiness is very
important -- this seems like something Scala supporters refuse to understand.

~~~
merb
It's still wrong. Actually he said

> I appreciate the concision and the strong collections API

Everybody who said that, didn't worked with it. The Collections API is the
Weak Point of Scala. You ever tried to make your own? Fine work with
CanBuildFrom Blabla stuff. It's nearly impossible to understand it.

And IntelliJ made a real progress in the last years. I mean sometimes IntelliJ
fucked up pretty badly. SAM support is one example it messed scalac's
"-experimental". But as already said even Java didn't worked correctly all the
time. When you work with a lot of generics you stumble across some types that
just won't work in IntelliJ but compile.

And types that won't work in Scala, I've seen them, but mostly that was a
problem of the Library.

And another thing. If you don't upgrade IntelliJ you will mostly won't get bug
fixes for the Scala Plugin. I've started with IntelliJ 12 and from that point
I always needed to upgrade the whole IDE when there was a new version since
they didn't backport most bugfixes.

And when you use a lot of Macro's the implementation of them definitly has
some non introspectable code. And as said if you did them wrong their usage
will be red, too.

------
rvense
I've used Scala for a few years, at work designing and implementing a backend
REST API.

The language has well-documented warts. I don't like all parts of the Play
framework that we use. It's slow to compile and sometimes the error messages
are weird. If you miss a close-curly brace you'll sometimes just get a
completely impenetrable type error, things like that.

But honestly, all that I can live with. Case classes, sealed traits, function
types, generics, monadic error handling... So much application logic can be
expressed at the type level where it gets mechanically checked. The only
errors that get past the compiler are in JSON parsing and database
interaction. Everything else just works after it compiles. I've refactored and
redone abstractions that touch all other components of the code, and I'll do
it and deploy on a friday afternoon and go home without worrying. I trust the
code, even after changing it. I have integrations tests that spin up the
backend with a real database and send it HTTP requests, but nothing like
complete test coverage. I'd like to add that out of principle, but it doesn't
feel necessary.

Scala has warts. But it works well and it has static types without the
verbosity of Java. I can't imagine going back to an untyped language plus
tests again.

------
kev009
I used it exclusively on top of the Playframework for web development from
2011-2014 full time, and occasionally thereafter (job switch). I find it a
very sturdy way to build web applications, and the time penalty of initial
development is quickly paid off during refactor and extension.

If you are a one language trick, you might have a bad time, but if you have
been exposed to multiple languages (like a typical CS education) it shouldn't
be too hard to be productive and even fairly idiomatic code in a couple
months.

Overwhelming pros:

* Type system is awesome, massive time saver once a project is underway

* Operator overloading very well done. Infix, postfix, prefix operators can allow for very readable, concise DSLs. Apache Spark being a great example but also many DB libs.

* Excellent frameworks like Playframework, Apache Spark to build on top of

* Being stacked on the JVM - you have access to tons of production worthy libs for just about anything

* ScalaJS.. really awesome if still young project to unify web development in a much more reliable way than weak JS and $backend.

Overwhelming cons:

* Compile time is quite bad

* Operator overloading can cause some really bizarre syntaxes like SBT. SBT is probably better than the mainstream Java build systems, but it's often a head scratcher.

* Being stacked on the JVM - you soon desire native Scala libs for everything

In 2016 I would also heavily consider Java 8 for the same team usage vs when I
started using Scala in 2011. I think Java 8 really slowed the adoption of
Scala down which may be worrisome for long term market share.

~~~
Roboprog
Thanks. God, I _HATE_ operator overloading.

I didn't even realize Scala had it, until a few months ago when somebody was
doing a demo that involved some SBT. It was quite frightening. (Did we learn
_NOTHING_ from the C++ debacle???)

Come to think of it, I've come to dislike "operators" in general (as opposed
to function calls). Memorize these operator precedence rules? No thanks, just
do the inside parens first, now you're trained.

C might be a good step up from assembler (though it, and its spawn need to go
away as app dev languages), but I think Lisp got this aspect (no special,
jacked up, operator syntax) right, in a "less is more" kind of way.

~~~
whateveracct
Scala doesn't have operator overloading technically. It had two orthogonal
language features that give rise to operators:

1\. Methods can use symbols

2\. Single-arg methods can be called infix

Scala doesn't have operator precedence rules. All operators (infix methods
really) are left associative unless they end in a colon in which case they are
right associative. Examples

2 + 1

Is

2.+(1)

2 :: 1 :: Nil

Is

Nil.::(1).::(2)

The colon thing is the sort of thing that on paper seems hacky but in practice
Just Works and is seldom used. But when you do use it it really helps a lot.

~~~
cottonseed
> Scala doesn't have operator precedence rules.

That's not true. The operator precedence is determined by the first character
of the operator:

    
    
      (all letters)
      |
      ^
      &
      < >
      = !
      :
      + -
      * / %
      (all other special characters)
    

Precedence is different than associativity.

------
ryanobjc
Been and seen two serious production apps in it. It's a mixed bag imo. People
are very excited about the language features, but don't talk about the
complexity. People talk about how great the JVM platform is, but don't talk
about GC problems and excessive garbage generation in Scala. (eg: You can't
use the map data structures without generating temporary tuples)

I think that for "programming in the large" that Scala is not going to be a
winner here. I'm talking about a single code base with hundreds of engineers
with a big eye towards maintainability. Because lets face it, for a 1 person
small project, it doesn't matter what language you use as long as it provides
single developer productivity. But once you talk about large team projects,
things get very difficult. Scala only compounds this imo.

~~~
saryant
My experience is the opposite. I find that Scala works just fine in very large
teams, hundreds or even 1000+ engineers.

~~~
derwiki
What 1000+ engineer dev team on Scala are you referring to?

~~~
kev009
Twitter might have come close to that at some point

------
runT1ME
I've used it for a while, and overall I love it. Easily my favorite language
by a large margin I've been paid to use.

We use it exclusively on the server side at Verizon Labs, and it's quite
beloved by all. We lean hard on the functional side of things and make heavy
use of what some people call 'advanced features', but because of our micro
services infrastructure even the teams new to Scala can be productive in a
less functional style, and refactor later to be more idiomatic.

I do think large teams need to have enough language experts to help from
making some bad design decisions, but I have plenty of productive coworkers
who are new to the language and learning as they go.

I really don't agree about the 'maintainability fears' or 'write only'
language criticisms. 'Bad' Scala is still so much better than bad java, and
good scala is phenomenal to work with. _Because_ of the type system, I have a
high level of confidence when working with unfamiliar code and making minor
changes.

Smart folks with no exposure to functional programming are picking up the
'advanced' features very quickly with the right training and guidance. I would
_not_ recommend it to a team who has on one with any experience in the
language, but if a team can hire those who have experience with the language,
even if it's just a fraction of the overall team, I'd be confident they could
succeed.

There are real downsides:

* slow compile times

* IDEs can struggle with advanced libraries (Scalaz)

* some language features are 'sharp' (implicit conversions)

* finding developers who know scala

We're overcoming the first one by the fact that we're already a microservices
shop.

The IDE issue doesn't affect me, I'm on Vim, many coworkers on Sublime/Ecmacs.

If you go crazy with implicit conversions it can cause issues, but again we
try to mitigate this with some training and having enough advanced users of
the language/code reviews to show everyone how to relegate using conversions
for syntactic sugar or typeclass conversions.

~~~
hocuspocus
> finding developers who know scala

There's a good side to it though. I took my current job because I wanted to
use Scala more and my manager admitted (after the fact, sneaky bastard :) that
hiring Java+Scala developers helped him filter/attract curious and talented
people.

------
photon_off
This is coming from me being most comfortable with OOP and dynamic languages.

If you want to write Scala to actually get things done, you will find that
it's a miserable language to learn and that you will need to invest
significant amounts of time, energy, and sanity to learn it. Furthermore,
there are no shortages of Scala apologists who are so utterly enamored with
the cleverness of the language that they will not concede how much of a pain
in the ass it is to learn. They will claim it is easy, and then they will have
no empathy for your plight. It is actually quite shameful.

The attitude in Scala-land is that _you_ are the problem, and not Scala. When
you do encounter a roadblock to a seemingly simple problem, which will be
quite often, you're lucky if you find a 20 paragraph explanation on
StackOverflow. Otherwise, you can hopefully find a lengthy blog post about
something closely related. In either case, the attitude is that it is _not_
Scala's fault that solving problem XYZ requires you to understand several
chapters of advanced concepts -- it's _your_ fault for not already knowing it.

------
0xfaded
Scala is a superpower, the language features are rich and flexible enough that
boilerplate can be eliminated and per LoC productivity integer times
increased. You get all the benefits of a compiled language, and compile time
is nothing compared to restarting an interpreter.

But it's difficult to master and therefore difficult to sell to others without
a scala background. You're also competing with the finance industry and
salaries for decent practitioners easily top 200k.

So my verdict is good for an individual contributor, bad if you need to
convince others to use it.

Also, scalajs is awesome and just works, with the exception of some reflective
calls. Otherwise normal scala compiles to good JavaScript, and interop is as
good as coffeescript (i.e. perfect).

------
aaron-santos
5+ years here writing Java professionally in the video surveillance industry
and I switched to writing geospatial systems in Scala six months ago. I'm past
the initial Scala learning curve and am at least as productive in Scala as I
was in Java. I've also been writing personal projects at home in Clojure for 4
years.

My initial impressions of Scala:

1\. There is an unavoidable learning curve when onboarding. My personal
experience with Clojure lowered the curve a noticeable amount. While I was
tackling learning a new syntax, my team mates were struggling with syntax +
functional concepts. People with exposure to functional concepts will have an
easier time.

2\. Our experience was made more difficult in that there were no in-house
Scala experts/mentors to whom we could ask questions and get answers.
Bootstrapping Scala knowledge takes some time and I admit that while I'm
productive writing Scala, I know I'm not at the level where I can analyse
design trade-offs, extol best practices, or use my language knowledge to pre-
empt and avoid problems like I can in Java. We had a good experience with a
consultant + videos + books + online articles, but it isn't the same as having
a mentor colleague.

3\. I write a LOT less boilerplate. Both my Java work and Scala work involve
consuming and producing JSON data. In Java-land I used Jackson to annotate
classes and used builders to build that as the data classes themselves were
made to be immutable. It was a lot of repetitive code and mind numbing to
write. Now you could argue that the code should be generated automatically,
and you're not wrong. But it feels like something is broken in the language if
this is the best solution.

In Scala, I find myself using case classes and spray-json and typically write
two lines of code for a JSON-serializable class definition. (1 for the case
class, and one for the implicit JsonFormat definition. Occasionally I have to
break out RootJsonFormat and write more code, but it's short and concise and
non-boilerplaty. I like writing Scala much more than Java and I'm because I
like it I'm more productive.

4\. Some of the libraries feel like a force multiplier. Specifically Spark,
and to a lesser extent Akka let me do things I wouldn't consider trying in
Java. Sure, they can be used outside of Scala, but the way they are presented
in Scala is beautiful and makes the programmer feel powerful because when
using them, the are.

------
edko
I have used it for 5 years, as my primary development language. At the
beginning, it was exclusively for back-end stuff, and now, with ScalaJS, it
truly has become a full-stack language. The recent announcement of Scala-
Native, which is already available as pre-release, and will also target iOS
and Android, makes it even more exciting.

------
jacobn
I've used it for years and love it. Came from a C, C++, Java, Ruby (on Rails),
and Delphi background. I'd describe it as a love child of Ruby and Java that
turned out great. It offers great flexibility, which means you can definitely
shoot yourself in the foot, and some libs have definitely done that, but I
prefer to restrict myself rather than have the language force me.

We've created several in house DSLs and used them to great effect.

Compiler is slow, though it has gotten better over the years.

Very much looking forward to DOT (next gen of compiler and language, union
types will be awesome).

Use it on four production websites, about to transition a Ruby on Rails site
to it soon.

------
pnathan
Hi,

Disclaimer: I spent some time December 2014 over a Christmas break whacking
away at a small Play app. I've not been back since due to a number of
"hygiene" factors.

* I loved having type-safe templates.

* I found that object and class distinctions were weird and the multiple namespaces (iirc) didn't make a great deal of sense.

* The language felt very grab bag: things didn't seem to "fit" logically together well.

* Scala still has null.

* The tooling is _slow_. The tooling is _fat_. The tooling didn't run on my (few years old) laptop with 4Gigs of ram. More on this below.

* High-class documentation about the language is hard to find. The Java (and scala) ecosystem is filled with really ignorant people and really low-level docs.

* And implicits were stabbing me in the face because they are unusual and technical descriptions of what they are were hard to find.

* The compiler error messages are hard to scrute. This is definitely less of a problem than above. (I've used C++ templates, so after that, it's hard to complain too much).

Regarding the bloat.

I have Haskell, OCaml, Lisp, Java, Clojure, Python, Ruby, Rust, and ... others
on my machine. Of these, exactly one has ever had a problem for my home
machines: Rust, years ago, when self-compiling would alloc more than 3 gigs of
ram - and my 3 gig machine would reap the process. Only Scala has presented
the memory and speed issues I encountered. Given that its ecosystem is kind of
designed to use an IDE, this is terrible.

My takeaway from building this (small) web app well over a year ago is that
Scala probably works well in a team with the funding to buy hefty machines and
the ability to maintain an operative knowledge of the Scala Lore. If you
_need_ the JVM, and you _need_ advanced type systems, it's the only choice.
Otherwise Java 8 is probably adequate.

Eating my own dogfood - I'm working on another well-typed smaller web app at
home, and my ordered preference list from top to bottom looks something like
this: [OCaml, Java 8 (9?), Rust, Haskell, Scala].

------
airless_bar
Yes, Scala is great. Way ahead in terms of providing developers with useful
tools compared to most other languages. (It's not the usual run-of-the-mill
language which takes Java and adds some syntactic sugar, so some effort in
learning and understanding the language is required.)

------
mindcrash
Java is great for doing backend work. Scala only makes it better due to the
fact that you can apply functional principles if the problem you are trying to
solve requires it besides having a great set of OO features aswell (but never,
ever mix the two within a monolith architecture, because that will end with
tears.). Nice plus is Scala.js which can transpile Scala to JavaScript so you
can write Scala code both for frontend and backend purposes.

A great contender to Scala is starting to rise though, in the form of Clojure
and ClojureScript. Clojure is starting to become pretty great for backend work
and once you start using ClojureScript and topple it off with a framework such
as Om or Reagent for building React based reactive UIs you will never look
back.

~~~
edko
I think Clojure and ClojureScript are really very nice, and a good contender
to Scala if you like dynamic type systems.

I think the biggest potential competitor to Scala may be Swift, now that it is
open source. If it becomes as multi-platform as Scala is, and good back-end
libraries become available, then Apple's support may be very hard to compete
against. There were even rumours that Google was considering using it for
Android.

It is nice to see that Scala will soon be available for mobile development
too. In a short time, there will be a nice overlap of platforms supported and
language features, which will provide for interesting competition.

------
jcadam
I got into using Scala a few years ago and initially loved it (took a couple
of Coursera courses on it (FP using Scala and Reactive Programming)). The
problem is most other devs I've worked with haven't been interested in
learning to use anything other than Java. My current lead in particular has
flatly refused to consider it ("I want a pure Java system!"). He's also told
me that since Java 8 has introduced some "functional" features it's a moot
point anyway (Java 8 lambdas suck. Java 8 streams really suck. The hacked-on
functional interfaces really, _really_ suck).

Now, I have been able to use Scala along with Akka on some smaller projects at
work (usually where I'm working solo), not that I bothered asking for
permission or anything :) At home, I've started using Clojure on a side
project and I generally find it to be a more pleasant language to use than
Scala (but Scala is still vastly superior to Java, of course). But it leans
more toward FP than Scala does, so I know if Scala is a no-go at work, Clojure
isn't even worth asking about :)

So, yea, if I'm ever in a position to select languages/technology stacks for a
new project (hasn't happened yet) I'd definitely lean toward Clojure for a
true 'greenfield' project. If I needed to integrate with an existing Java
codebase, Scala might be a better choice.

~~~
sheepmullet
Interesting, I've found Clojure-Java interop to be really smooth.

------
mafribe
I've been using Scala as my main development language since 2011. I came from
a strong functional programming and C++ background, consequently learning
Scala wasn't hard for me, and I find all claims about Scala's complexity
overblown.

I'd say Scala, used pragmatically (e.g. avoiding advanced stuff like Shapeless
or Scalaz), is currently the best mainstream programming language, meaning it
offers the best _compromise_ between language power, maturity of
implementations and library eco-system.

My main criticism has always been the slow compiler which was eyewateringly
terrible in 2011. With SBT's incremental compilation and faster machines the
situation has become bearable.

------
wpietri
I took Odersky's online course and used it for one project. It runs my home
lighting system. My experience was definitely mixed.

I liked the language for its ambition. I think the notion that OO and
functional approaches are complementary worked very well for me. There were a
lot of interesting ideas in the language and the ecosystem.

However, there were a number of downsides. I came across a couple of bugs that
were well known and apparently people were just expected to work around them.
As others have said, compile times were terrible, and the tooling wasn't
great. And at a one day Scala unconference one of the prominent Scala
community members was a flaming asshole to me, which definitely didn't help.

What really put me off, though, was what Bruce Eckels described: "I’ve come to
view Scala as a landscape of cliffs – you can start feeling pretty comfortable
with the language and think that you have a reasonable grasp of it, then
suddenly fall off a cliff that makes you realize that no, you still don’t get
it." [http://bruceeckel.github.io/2015/08/29/what-i-
do/](http://bruceeckel.github.io/2015/08/29/what-i-do/)

This was backed up for me by a talk by Paul Phillips, a major contributor to
the Scala compiler:
[https://www.youtube.com/watch?v=4jh94gowim0](https://www.youtube.com/watch?v=4jh94gowim0)

So in the end, I'm likely to look elsewhere. The next language I'm trying out
is Kotlin:

[https://kotlinlang.org/](https://kotlinlang.org/)

It's from the IntelliJ IDEA people, who I trust a great deal, and I just got
done working through their nice in-browser IDE tutorial:

[http://try.kotlinlang.org/](http://try.kotlinlang.org/)

So far it seems to have all of the things I like about Scala plus a number of
improvements. E.g., fast compile times were a clear goal, and I didn't come
across anything that struck me as language astronautics.

~~~
partisan
I had a similar experience. I took the Odersky course and thought it was love,
but soon found myself uncomfortable with the cryptic syntax of the ancillary
libraries and wondered whether I wanted to be comfortable with writing or
reading inscrutable code.

I am currently giving Kotlin a shot and so far I do like it. I downloaded and
installed IntelliJ, then the kotlin-dropwizard github repo and imported it
into IntelliJ with no problems. It runs well and the code is clean and
legible.

~~~
wpietri
Yeah. I definitely had the same issue with the libraries. For me the point of
a language is to reduce cognitive load to something manageable. It wasn't
clear to me than any human is smart enough to use Scala well, but I fell over
enough of Eckel's cliffs that I was pretty sure I was not a good match.

------
gexla
How do people stumble across Scala? It seems to me that the best programming
languages for any given developer is that which sort of emerges into your life
by luck of the draw. Probably the first was through your first job or your on-
ramp into gig work. Then you may pick up more as you land on other projects.
Sure, it's good to pick up ideas by learning other programming languages, but
you can only get so far into the learning curve before you start cutting into
time that could better be spent elsewhere. Is Scala (with its steep learning
curve) the sort of language you would pick up just to improve your programming
skills?

I would think the answer to the original question would be that if you have to
ask then probably it's not the right direction for you. This is especially the
case if you are looking for something for your next project. You have a big
learning curve before you even get started.

Start at the end and work your way backwards. What's the fastest way you can
get from point A to showing off your project? Even better. What's the fastest
way to get from point A to making a dollar?

Pick up something that's already on your shelf, throw up a sketch of something
finished on your wall and then get to THAT as fast as possible. No project
should start with "learn Scala" unless you're being paid to learn it.

------
bajsejohannes
I'm a huge fan of functional programming, but Scala didn't cut it for me. It
didn't feel like it fit the underlying runtime well. For example, you have
both an option types and `null`, and libraries being inconsistent in which
they pick.

I'd rather stick a functional language built from ground up without the
baggage. Or even straight Java. You can do pretty nice functional stuff with
Java 8 streams, but it's not trying to be something it's not.

~~~
allengeorge
For all my frustration with Scala, I've never seen an idiomatic Scala library
that uses nulls. Which one are you using that does this?

------
fishnchips
I don't have any production experience with Scala but I played around a little
bit. It's a thoroughly modern language which can use all these Java libraries
produced over the years so what's not to like.

The only reason I'm not using it is that my professional Java-related tasks
tend to be small enough that pulling in an extra dependency is an overhead.

Mind you, I haven't looked at Clojure or Kotlin, both of which offer the same
benefits I find attractive in Scala.

------
trengrj
I've used Scala mainly for Apache Spark applications and do enjoy it.

Pros:

    
    
        * The type system 
        * Being able to mix functional and OO design coherently
        * Less verbose than Java
        * Utilise existing Java libraries
    

Cons:

    
    
        * Huge amount of syntax to learn
        * Fragile and slow package managers
        * sbt uses Ivy and so downloads package files in a single thread. In Australia this is horrible
        * too slow for scripting due to JVM boot time

------
chokma
I've been using it for a couple of months for Apache Spark - it allows me to
create succinct big data jobs running on a Hadoop cluster. Short code which
does not try to be too clever for its own good is really great at making the
algorithms be more comprehensible.

One problem I have is sbt - our projects are all defined in Maven, and for
many library / dependency problems, Google leads me to sbt solutions which are
hard to understand. Guess I will have to learn another build system.

I would like to use Scala again in a larger project, but there are so many
existing Java frameworks out there that can solve the problems we have. So it
is hard to define a business use case that requires experienced Java
developers on the team to switch to Scala and use libraries and frameworks
that are not as thoroughly tested and supported compared to the already known
ones.

Tooling: The Scala plugin for IntelliJ is getting better, but it had some bugs
like suggesting to remove required imports which broke classes. I like the
easy navigation between Java and Scala libs - sure, you get "null problems"
from using Java, but you can use almost all your existing Java code (Just
don't try to use commons.StringUtils.join instead of Scala .mkString ;) ).

------
kafkaesq
There have been many, many discussions about Scala generally over the years.
You might want to try the unofficial search engine
([http://hn.alogolia.com/](http://hn.alogolia.com/)) and ask again about
something more specific, or more current.

------
brianbarker
Some data scientists I work with prefer Julia or Erlang, but the real interest
is now Spark. Since Scala works with Spark and is more of a datsci's type of
language (similar to Julia, Erlang, functional languages), people are moving
to it. Spark made Scala relevant and interesting.

~~~
DrNuke
This. But all three languages still very niche and worringly so, considering
that Spark is niche too. Have they a future?

------
probinso
I have used a lot of programming languages, and Scala is stylistically
interesting. What I did find though is unless you have a lot of experience
with the Java ecosystem, the tooling is very distracting. You can think a lot
of time in to build systems, and figuring out where or how you are supposed to
install languages to support your ides.

My favorite thing about Scala is how well it supports DSLs , and it being the
base language for a probabilistic programming language called Figaro.

The biggest problem with the language, is that it is huge. There are a lot of
language features, like implicits, that run the risk of being abused.
Additionally many Scala developers don't write code like salad of Elders but
rather like Java developers trying to learn functional programming.

------
dskrvk
I have used it for about 2 years total, in two production projects.

The first project used Spark, so Scala was a natural choice. One big-ish issue
at the time was that our team didn't have anyone with experience in the
language, so the code base ended up being very Wild West-like, with different
styles mixed and heavy usage of implicits. However, none of my teammates had
much difficulty becoming productive in Scala (not being an expert, but just
being able to produce sane code, quickly), even though they came from mostly
non-functional backgrounds (Java, C#). I did struggle with the type system
initially - needed some time before it all "clicked", e.g. when to use
'flatMap' instead of 'map', things like that.

The second project uses Akka, which is by itself pretty neat. This time
however, I'm the only engineer with experience in Scala and writing production
code in general. I feel like the type system provides a lot of protection
against silly mistakes that newbies sometimes make (especially with the poor
test coverage, such as it is), and the code is much more concise that Java
would've been, so yay smaller code reviews! The rest of the team is familiar
with traditional C-like syntax, so it's easy for them to get started. I try
not to push too hard for the functional features initially, instead showing
people how their imperative code could be rewritten in a more clear and
concise way.

One major problem is the IDE support. It's 2016, yet IntelliJ is still slow as
hell with Scala, and I've abandoned Eclipse long ago.

I do notice that the language seems to promote in some people a certain
tendency to write esoteric code and use some very cryptic features just for
the sake of it, but I haven't been bitten by this in the libraries we use, and
try to be pragmatic in our own codebase.

Lastly, the value of the infrastructure - the JVM, the rich set of libraries
for Scala and Java, Scala itself with stuff like Scala.js and Native - should
not be underestimated by anyone who considers the language for production use.

Oh, and I do have some comments about Clojure as well, if anyone's interested.

------
mindcrime
I've gone as far as writing "Hello World" and that's about it. My initial
impression of Scala is somewhat favourable, but I am a little concerned by all
the optional syntax. I keep thinking that Scala is going to turn out to be a
"write only" language as a result, although I'd be interested to hear more
data on that point from people who have actually used it extensively.

Would I use it? Maybe. I don't know it well enough to do anything substantial
yet, and lately I've been more focused on learning R, Octave and brushing up
on Python. But there is a new Scala specialization that just showed up on
Coursera that has me intrigued...

------
aswanson
I've been meaning to play around with scala for a while now. Can anyone
recommend a starter project for a seasoned dev to target with it, as a
learning exercise?

