
The myth of using Scala as a better Java - bontoJR
http://appliedscala.com/blog/2017/myth-of-scala-as-better-java/
======
k__
2009 I sucked it up too.

"Hey Java is pretty much shit and here is this new better language called
Scala, which you can use with your Java ecosystem!"

And I was hyped!

But, well then I saw the actual Java ecosystem...

Java itself is a pretty clunky language, especially for people like me, who
did scripting language programming all the time and are probably not
considered Real-Developers-TM to the Java folk. So the ideas of Scala
resonated with me pretty much.

Anyway, after trying to configure stuff like Kafka, Zookeeper and Maven and
setting up a SOAP API, I saw that the problem with Java isn't the language.
Yes it's ugly, but JavaScript is ugly too, well even Python has its ugly
parts. The problem also isn't performance, like so many C devs cry about
daily. The problem seems to be that Java devs like to create things more
complex than they need to be. Conglomerates of XML files, layers on layers on
layers... I just don't know anymore.

I didn't use Scala for long and it wasn't because it failed me, it did, it
brought its own complexity with implicit conversions and overloaded operators
etc. but that wasn't the reason, it was the ecosystem which usage Scala
enabled, the ecosystem that felt like it was still stuck in pre 2000. :\

~~~
bad_user
You're missing the forest from the trees. Java libraries and frameworks are
complicated because Java _the language_ is not expressive enough.

As I like saying, the status quo in Java land is Spring and Hibernate and
people bemoaning Scala's implicit parameters never wonder why such
monstrosities like Spring or Hibernate happened. Sure, blame the culture, but
that's only half the story.

The same thing happens with other inexpressive languages. One of them is
Python. And here we disagree again, as I think Python is chock full of ugly
parts.

It started with refusing powerful and multi-purpose language features, like
multi-line anonymous functions. As a result Python has been patched repeatedly
with multiple non-orthogonal features to supplant the need for multi-line
anonymous functions and/or to make up for its statement oriented nature. Oh,
now Python 3 got await/async as well, but somehow I don't think this will stop
people from monkey patching the socket module. I'm going to make the claim
that in fact Python is not a TOOWTDI platform, in spite of its much touted
"spirit" and anybody making that claim never tried working with Gevent or
Eventlet, trying to make it work with MySQL's client and being forced to use
the _native_ client because Django wasn't compatible with the pure one. Or
with an N-th iteration of Ruby inspired libraries that hack into its meta
programming features to make it smell like the DSLs in Ruby, but with
limitations and leaks. I don't even want to talk about the build and
dependency management tools in Python's land, because it should be self-
evident how broken the Python ecosystem has been.

Another language in this category is Go. It's still young enough that people
haven't used it much outside the niche it was created for and doesn't have
much reuse going on in libraries. Give it time, you'll see the same pattern,
same mistakes repeated again and again. Java was also a pioneer in dealing
with concurrency, Java introduced generics really late and it was also built
by famous engineers working for a sexy company, designed to appeal to
beginners and managers.

~~~
JustSomeNobody
No. It's not the Java language. It is the developers. They are the ones who
have to have 35 levels of abstraction. Why? Because for some reason they think
this will make modifying the software they write easier. In reality, no, it
doesn't because everyone gets frustrated wading through the abstractions. If I
can hold ten items in my brain's working memory and all ten are taken up by
keeping track of how many levels deep I'm in, then it is really hard to make
any real changes to the code.

~~~
digler999
> They are the ones who have to have 35 levels of abstraction.

Have you seen FizzBuzz: Enterprise Edition ?

[https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...](https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition)

~~~
Dove
I'm going to be laughing about this for days.

~~~
digler999
its beautiful, not only is it absurd and hilarious, but it says so much. Not
as a direct diss to java, but how badly a simple task can get over-designed to
the point of being indecipherable. What would be great is if they added some
kind of CRM or e-commerce to it, and donated the proceeds to charity. So like,
could "Pay as a service" or sign up for "fizzBuzz as a service" and pay to run
fizz buzz up to certain limits.

------
laichzeit0
After doing this shit professionally for more years than I could care for
anymore, when I see programming language or framework comparisons I
immediately think of something like[1]:

"Why Klein Cushion Grip screwdrivers are better than Wera Kraftform
screwdrivers", or in this case "The myth of using Kraftform as a better
screwdriver".

And then I imagine myself going back to using my shitty old Phillips
screwdriver set to screw in a few screws in a non-optimal fashion and someone
might say "Wow, thanks for hanging my door!" and I imagine the surprise on my
face as I realize that people want functioning doors and are not too bothered
about which brand of screwdriver was used to achieve that.

[1] [http://blog.cnccookbook.com/2015/08/19/8-brands-to-
consider-...](http://blog.cnccookbook.com/2015/08/19/8-brands-to-consider-for-
the-worlds-best-screwdriver/)

~~~
gotofritz
What a crap, supercilious comment. Yes _laypeople_ want functioning doors, but
this is not an article for laypeople, it's an article for engineers. What we
want are tools that allow us to build performant, maintainable, reliable code.

Besides, if all you do is to fix a door than you may be right. But we build
entire tower blocks, with doors, windows, elevators, ventilation systems,
structures able to hold up tons of material, and all the rest. Your
screwdriver metaphor may be good go way to score a cheap point with strangers
on an internet forum, but not much besides.

~~~
laichzeit0
I used Angular Material to build a website. I dunno if you've ever been to the
Angular Material website
*[https://material.angularjs.org/latest/](https://material.angularjs.org/latest/)),
but check it out if you haven't. You see that nifty looking navigation bar on
the left? You can't actually build that using Angular Material given all those
wonderful components they list there. There are entire blog posts created so
you can make a similar looking navigation menu [1][2]. There are so many
things missing or incomplete in this framework that you'll only realize when
you try and build a "real" application with it. Guess what? Angular Material
is dead. All the developers decided to start over with Angular Material 2
because there's a new screwdriver brand in town: Angular 2. Yay for the people
who just want functional doors.

[1] [http://blog.vizuri.com/creating-your-own-angular-material-
na...](http://blog.vizuri.com/creating-your-own-angular-material-navigation-
menu) [2] [http://stackoverflow.com/questions/28389671/create-a-menu-
li...](http://stackoverflow.com/questions/28389671/create-a-menu-like-in-
angularjs-material-website)

Let's talk about Material Design Lite. Go check that website, especially the
components page
([https://getmdl.io/components/index.html](https://getmdl.io/components/index.html)).
It's really nice and responsive, try changing the size of your browser window
and see how the navigation bar collapses to the top. Damn this looks like a
great framework, I'd like to do the same thing in my app. Imaging the surprise
when you can't actually do that using the framework out-of-the-box. Oh by the
way, forget about MDL, all the developers have moved on to Material Components
for the Web ([https://github.com/material-components/material-
components-w...](https://github.com/material-components/material-components-
web)). So much for the guys who just want to hang a door, there's a new brand
of screwdrivers on the block.

It would be great if the so-called "engineers" could spend some more time
creating a complete toolbox instead of reinventing new screwdrivers every
month.

~~~
imafish
You're forgetting that this is every web developer's dream. To always keep
learning new frameworks (to do the same fucking thing) over and over.

~~~
rtpg
I get that this is the easy way to see it from the outside, but:

\- You don't have to learn every new framework. Google has 10k+ Angular 1
projects, this stuff doesn't go away after hitting critical mass.

\- This constant iteration has lead to multiple production-ready UI paradigms
that were just relegated to FP research. Try using Angular 1 or vanilla React,
and then do something with vanilla Android. Or GTK+. Do we want GTK to be our
baseline for UI work? Qt is nicer, but it's definitely playing catch-up.

You can poke fun, but there's a reason everyone opts for things like Electron.
It's the most satisfying way to build frontends for a lot of people.

~~~
kuschku
> Everyone opts for electron

And I’m just sitting here, using
[https://github.com/ReactiveX/RxJavaFX](https://github.com/ReactiveX/RxJavaFX)

~~~
pas
Is JavaFX okay? Or maybe even good? What's wrong with it? (Not polished
enough, not maintained enough? Not updated fast enough?) RxJava seems pretty
okay.

~~~
_pmf_
Off the top of my head: misses some UI elements / widget types (spinner /
numeric entry). UI bindings require a lot of manual converters instead of
doing conversions that p.e. WPF does out-of-the-box (like double to string
when using a text box; principle of least surprise).

And (the worst) it's not conceptually compatible to the model classes
(abstract tree model) that almost every UI framework (including Swing)
provides. Instead, tree nodes have to be manually instantiated).

~~~
kuschku
> misses spinner

[https://docs.oracle.com/javase/8/javafx/api/javafx/scene/con...](https://docs.oracle.com/javase/8/javafx/api/javafx/scene/control/Spinner.html)

> UI bindings require a lot of manual converters instead of doing conversions
> that p.e. WPF does out-of-the-box (like double to string when using a text
> box; principle of least surprise).

You can use String.valueOf, but usually don’t want to do that. And how do you
want to represent the float? With Scientific notation, Engineering notation,
or purely decimal? This is not simple.

> And (the worst) it's not conceptually compatible to the model classes
> (abstract tree model) that almost every UI framework (including Swing)
> provides. Instead, tree nodes have to be manually instantiated).

Or you use the FXML bindings for creating them from XML?

------
itaysk
I really wanted to love Scala, and for the first few days I did. But it was a
never ending story learning this language. It is so complicated and feature
rich that there's just too much to learn. I couldn't just read someone's code
without stumbling on some special syntax or language feature that handles a
once in a lifetime use case that I didn't know about. Eventually I gave up on
Scala.

~~~
gbersac
I don't really understand all those complaints. I am using it professionally
since 8 month and I only had problems the first two month, then I felt good,
even if there is always something else to learn.

For the complexity problem, here is how I manage it : the functional
programming scala is scala, everything else is garbage included for java
compatibility. It works like a charm.

I can't think of a language I could feel better with.

~~~
the_af
Mostly agreed.

There are some pains associated with Scala, though. Sometimes self-inflicted
by people who want it to be like Java: for example, most ORMs for Scala suck.
A team at my office tried to use Hibernate to disastrous effects (Scala and
Hibernate's hostile takeover of collections don't play well). Even some DSLs
like Scalike tend to also be painful and unwieldy. I also dislike Play and its
multitude of quirks and incompatible versions.

It used to also be the case that both Eclipse (ScalaIDE) and IntelliJ IDEA
were almost unusable with Scala, in particular constantly resulting in
spurious compilation errors. I've no idea if Eclipse got better -- completely
got rid of it after decades of using it with Java -- but IntelliJ did get
better and mostly works (though it still cannot always compile Scalike DSLs).

But even with all of the above, when I have to work with Java code again I
cringe. Even with all the pain, Scala is simply better to work with for new
code.

~~~
cutler
Ever asked yourself why it's taken so long for Scala IDEs to be minimally
useful? The complexity of the language makes it difficult to optimise
compilation and the language is still suffering. Paul Phillips left Scala
because of this and he said it was impossible to rectify without re-inventing
the language. This shaky complexity is why I refuse to build valuable projects
with Scala.

~~~
virtualwhys
and yet Paul Phillips still, to this day, writes Scala. Think about that, he's
one of Scala's biggest critics; still Scala all day, everyday.

There's nothing "shaky" about Scala's complexity, it's quite stable, and not
going anywhere until Dotty lands circa 2020.

Despite everything (slow compiler, average tooling, implicit/operator
overloaded "magic" code bases, etc.) Scala will draw library creators (like
those behind Spark, Kafka, Akka, Play, etc.) which in turn draws developers,
resulting in the thriving ecosystem backing the language.

Scala will live on despite itself; the ecosystem is what will carry the
language to the Dotty land and beyond.

~~~
furrydog
True. Scala jobs growth is still very healthy too:
[https://www.indeed.com/jobtrends/q-scala.html](https://www.indeed.com/jobtrends/q-scala.html)

------
scalatohaskell
Ive used Scala as both "better java" and as "worse-haskell" in two different
teams. Both times it was much more pleasant than doing Java.

~~~
godmodus
Here here.

Im new to scala and I love it.

Also sbt > maven!

~~~
xxs
it's "hear, hear". The expression Comes from the English Parliament back in
the 17th century.

~~~
m3talridl3y
Now the really puzzling question is: How would someone learn about this
particular saying without seeing it in writing? Are there actually people
still using "hear hear" in everyday speech?

~~~
godmodus
Ironically, I've have an English bachelors degree,and I've never seen it in
writing before, till now! Language is active learning. There's no real way to
avoiding these pitfalls, besides reading and engaging with others. I'm OK with
it aslong as those offering corrections do it kindly.

I've learned German, too. German is 'difficult', not because of its grammar,
but because how mistakes are handled. Which is often with harsh commentary,
ridicule or confusion. Not sure why that is the case, but English speakers are
often kinder when offering corrections!

~~~
yellowapple
To disprove your last point: I'm curious as to how you achieved such a degree
while using "till" as shorthand for "until". Are you sure your Bachelor's
wasn't in agriculture? ;)

Joking aside, I think it's a consequence of English being a very complicated
language with all sorts of borrowing from different language families. There's
almost no such thing as "correct" English, and attempts to reason about it in
a prescriptive rather than descriptive manner will almost certainly fail.
Whether that's a good or bad thing is up for debate, but mistakes happen
either way, and I reckon the average English speaker to be a bit more
cognizant of that, recognizing that nobody - oneself included - really has a
perfect understanding of the English language.

~~~
ranko
"Till", in fact, predates "until".
[http://english.stackexchange.com/questions/6989/what-is-
the-...](http://english.stackexchange.com/questions/6989/what-is-the-
difference-between-till-and-until). See, for example, the marriage service in
the Book of Common Prayer (1662): "Till death us do part".

~~~
RandyRanderson
My advice as a native English speaker here: In my entire life, I've only seen
or heard "till" in the following contexts, given in order of frequency:

1 A cash register (noun)

2 In very poorly constructed resumes

3 In the farming sense (verb)

4 In internet forums alongside poorly written English

5 Shakespeare and other literature from several centuries ago.

So my advice: unless you're a time traveller, use "until".

------
sandGorgon
Kotlin 1.1 + Reactor ([http://projectreactor.io/](http://projectreactor.io/))
has erlang style messaging passing paradigms, world class tooling and is
gradually replaceable (class-by-class) for Java.

It's going to be interesting comparing the adoption curves of both these
languages especially after Java 9 and most importantly Graal
([http://openjdk.java.net/projects/graal/](http://openjdk.java.net/projects/graal/))
.

~~~
pmarreck
> erlang style messaging passing paradigms

Or you could, you know, go directly to the source while experiencing a pretty
nice language on its own [http://elixir-lang.org/](http://elixir-lang.org/)

~~~
hnbroseph
elixir is for rubyists, really. dynamnic typing.

~~~
pmarreck
Guards, pattern-matching (even down to the structural level) and typespecs
cover a lot of the ground that static typing would, without forcing the type
rigidity. Although Haskell seems to have admittedly cornered the static typing
market

------
cdegroot
I once drank the Scala cool-aid as well. Even wrote an enthusiastic article
about it [1]. Since then, my enthusiasm has been replaced by disappointment:
the JVM interop is a lie, as Java libraries often are a bad fit, people won't
have time to write the extensive wrapper code needed to hide it, and as a
result ugliness starts permeating your codebase - yes, bad, but that's how
teams under time pressure work; the multi-paradigm-and-widening (back in 2009,
Scala was a smaller language) is one big headache - everyone has an opinion of
how you should write code in Scala, so inevitably you spend a lot of time
debating features you should or shouldn't use in your teams (instead of
writing code. In Elixir, we never have to debate paradigms, we write code);
sbt is a sorry mess - no-one understands it and it's slow.

I still think it's a very well designed language, the choice of the JVM+Java
ecosystem as the target just has bogged it down with legacy crap like
everything else on that environment and the designers should start to make
some choices instead of offloading that on every single development team in
the world. I think that "single-paradigm" is one of the reason that simple
languages that get shit done, like Golang and Elixir, are so successful these
days.

Were I bound to the JVM, I'd still give it a good look (not sold on Clojure or
Kotlin yet and it _is_ nicer and less frustrating than Maven+Java if you keep
it simple); I'm just not married to the JVM so can freely consider other
options.

[1]
[http://www.artima.com/weblogs/viewpost.jsp?thread=260478](http://www.artima.com/weblogs/viewpost.jsp?thread=260478)

~~~
pethallow
I took a sip of Scala, and I found it very interesting. Other than LISP it was
my first functional language that was being used for something other than a
college course project. I liked having been made to think differently about
the code I wrote - fitting things into a functional construction.

That being said, I found that many of Scala's features can quickly become
drawbacks. I'm not a fan of JVM languages, but I've effectively programmed in
Java and there are many useful, well-written frameworks and tools built on top
of JVM languages. sbt is a pain in the ass, and I learned that fairly soon in
my Scala exploration. Our project also used many Java libraries and it was
jarring (no-pun) to switch between the "pure" Scala and the grafted-in Java.

The person or community you enter Scala through can also be very influential
on your experience. Though that's likely to happen with any language. The
developer leading our project was extremely opinionated and felt that no other
language was superior. He forced, oftentimes to the detriment of progress,
abstractions in the code that made it nearly inscrutable. He became tiresome
during discussions because his speech was mostly a stream of jargon. I could
never tell what he was trying to achieve by using all the more complex
features of Scala... other than job security.

------
sreque
As someone who is currently having to deal with a monolithic Java app built on
spring, hibernate, aspect weaving, code drenched in null checks, and other
questionable architecture choices, this article makes me want to switch to
Scala, and the reasons are mainly community, not programming language.

I think you could do a lot of the above In Java although the code would be a
little boiler-platey. But why do people care about boiler plate so much?
Hasn't GoLang shown us that boilerplate is not our greatest enemy?

~~~
dustingetz
It's not the boilerplate. When you take some of the best java developers on
the planet, after a couple years you end up with a
AbstractSingletonProxyFactoryBean, so what is a mere mortal supposed to end up
with? Evolve any Java codebase for N years and the result is the same.

[http://docs.spring.io/spring-
framework/docs/2.5.x/api/org/sp...](http://docs.spring.io/spring-
framework/docs/2.5.x/api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html)

You could also make a similar argument for Scala. Not boilerplate, but other
problems. There are some epic scala flamewars out there. A mortal could be
forgiven for looking at an "idiomatic" scala codebase and scratching their
head, looking at all this higher order "stuff" and wondering, "but where is
the actual code, that does the actual thing?" And I'm not sure there exists a
human on the planet who knows what idiomatic scala is. The whole point of the
language was to make some impossible compromises, and as such you can kind of
feel forces inside the language in tension with itself, not in alignment.
Perhaps FP and OOP are not meant to be unified.

~~~
pdpi
> Perhaps FP and OOP are not meant to be unified.

The only thing that keeps FP and OOP from integrating properly is the
"Everything is an Object" mentality. Pure-data structs aren't objects, and you
start making loads of weird compromises when you force them into an object-
shaped hole. Java (and, I guess, C++) kind of pushes classes as better
structs, and lots of bizarre problems come from there.

I find that, when I'm programming in the small, on the lower-level
implementation details, FP design principles serve me best. Inversely, when
thinking about the structure of my applications, OOP principles suit the
problem better.

This sort of design is what leads some people to say that Erlang is the most
OOP language out there — Erlang processes map very naturally to objects in
this sense, and it is, obviously, a functional language through-and-through.

~~~
mafribe

       The only thing that keeps FP and OOP from 
       integrating properly is the "Everything 
       is an Object" mentality. 
    

Actually ... in Scala everything _is_ an object.

Functions are special cases of objects. That's Scala's great insight and it
reverses what people used to think: everything is a function, and OOP is a
special case of FP (this is e.g. OCaml's idea). If you look at Scala's
foundations (DOT -- the dependent object calculus) this becomes pretty clear.

Could you be referring to the difference between pure programming and stateful
programming? Note that OO can be done in a pure way.

------
partycoder
What appeals to me about Scala is that is expressive and concise. It also
encourages some healthy patterns like such as making distinctions between
mutable and immutable containers, using futures/promises for asynchronous
functions, using option types to prevent null pointer exceptions and many many
others.

It influenced my programming style a lot and I try to prefer those patterns
when I use other languages as well.

Some people like more advanced aspects of Scala, and like to flirt with
category theory and hardcore functional stuff. Personally I find it hard to
express myself in terms of higher order kinds, monoids, functors, semigroups
and such. You can learn them but it's a bit like switching from qwerty to
dvorak... if you have to look at the keyboard each time it doesn't make things
simpler for you.

------
pents90
Scala appeals to those who love programming languages. Java and a few other
languages appeal to those who love making software, something that Scala is
terrible at.

~~~
nvarsj
Scala is a language of compromises. That's part of its success! I think it
appeals to people who want to try out many different types of language styles,
but the programming language purist in me hates it because it's not
opinionated and is such a mish mash.

~~~
camus2
> Scala is a language of compromises

Scala tries to be everything at once, it's hardly a language of compromises.
It was successful because when it was created Java sucked and now of course
people are stuck with Scala deployments as nobody can decipher all that code.
Java still sucks but less that it used to be. It needs type inference for like
yesterday. The biggest drawback of the language is the slow toolchain.

------
huula
I have used Scala to build the backend of [https://huu.la](https://huu.la) for
years, which is not a small codebase anymore, I love the language itself, it's
fast, typesafe, productive, and gives access to the rich Java ecosystem. The
only thing I dislike is the tooling, especially whenever I open eclipse, the
fan just screams to hell and it's still slow as a snail.

~~~
wrkronmiller
Have you tried using IntelliJ?

~~~
coding123
Totally agree, time and again, I see people use Eclipse (for pretty much
anything) would be ten times better off in IDEA.

------
mk89
Regarding json serialisation, at the time I was using scala, I found quite
"unusual" that the play library could not deserialize a json with more than 26
fields (or something like that). I hope they fixed it in the newer versions,
but still I don't get why to rewrite all the libs from scratch, when java has
good ones available.

~~~
diamondo25
As asked (and answered) here[0], it used to be a Scala case class limitation.
There are tricks to do it anyway, like manually mapping fields by writing your
own JsReads or JsWrites for your object.

[0] [http://stackoverflow.com/questions/20258417/how-to-get-
aroun...](http://stackoverflow.com/questions/20258417/how-to-get-around-the-
scala-case-class-limit-of-22-fields)

------
paulddraper
I wouldn't characterize Scala as a better Java any more than I would Python as
a better C.

Kotlin is a better Java.

Groovy is a scriptable Java.

Scala is a "worse Haskell" or an "extensible Swift", with close Java
interoperability (that last part leading to the warts).

~~~
bad_user
> _Scala as a better Java any more than I would Python as a better C_

The difference between Python and C is huge because C is not interpreted and
doesn't do _automatic memory management_ , which is actually the deal breaker
for many apps. Saying that such a difference exists between Scala and Java is
simply _wrong_. It's wrong starting from the fact that both are garbage
collected, running on top of the same VM, having the same performance and thus
targeting the same application profiles.

> _Scala is maybe a "worse Haskell", with extensive Java interoperability_

Haskell is a language I like and that I'm in the process of grokking, being a
continuous inspiration, but to tell you the truth, to the contrary I think
Haskell is a less practical Scala. Scala follows the pragmatism of the ML
family. OCaml is another pragmatic language. Clojure and Racket are too.

Empirically speaking, Haskell is good at being a trend setter in the FP
community, but besides really cool libraries and concepts, I don't see much in
the way of applications built by Haskell folks. Some big companies have built
complex systems on top of Scala, not to mention projects like Kafka and Spark,
which can also credit Java and the JVM. For OCaml, even with a much smaller
community than both Scala and Haskell, you have some really cool stuff like
MirageOS. What does Haskell have to show for, besides badly documented
libraries and compiler implementations?

Don't get me wrong, correlation does not imply causation, maybe Haskell simply
has a popularity problem, but the onus is on the Haskell community to prove
that Scala, OCaml and others are inferior alternatives to Haskell by showing
some results. Because at the end of the day it's the final artifacts that
really matter.

~~~
pinkythepig
Haskell has lots of large projects written in it.

Besides the ones others have mentioned, Haxl is probably one of the bigger
known industry uses of it. It is used at facebook as their spam filter:

[https://github.com/facebook/Haxl](https://github.com/facebook/Haxl)

If you scroll to the bottom of that github page, you can find several papers
and articles that go into detail about it.

~~~
saosebastiao
"Lots" is pretty relative. Haskell has lots compared to what? Arc[0]? It's not
in the same league as Scala, that's for sure. And that also means that it is
orders of magnitude away from the likes of C, C++, Java, Python, Perl, Ruby,
etc. Haskell is and always will be a niche language for more experimental or
research-y purposes that somewhat occasionally have real world uses.

That shouldn't be a bad thing. Haskell, like Prolog, SML, Simula, Smalltalk,
and Lisp, have influenced the world of programming far more than one could
ever expect if we only measured success by large project usage. I don't see
why Haskeller's need to defend their meager industry adoption so much. It has
some pretty good adoption compared to most research languages, but its
industry adoption is not that great for a general purpose language, and _it
doesn 't need to be_.

[0] [http://paulgraham.com/arc.html](http://paulgraham.com/arc.html)

------
kuschku
This post contains several wrong statements.

First, Java does support macros – you can use Annotation Processors normally
(as Butterknife, Dagger, and other projects do), or you can use Annotation
Processors to actually get the AST and modify it (not supported officially,
but used by projects like Lombok).

Second, Java has no type classes – this is technically true, but not exactly.
The mentioned example can also be handled with Java 8’s interfaces, as they
support default methods and private or protected methods.

Due to that, you can define a method instead of the writes() field, and then
use an interface-defined default method to handle actual serialization.

If combined with Annotation Processing, this allows easy, simple, compile-time
generation of JSON serialization (and yes, I’ve written stuff like this
before, so I know it’s actually usable, and not too complicated).

------
Fiahil
Yeah, Scala is not a better Java. And Scala is still a very young language.
With a lot of interesting features, yes, but also a _LOT_ of backward and
broken things.

Have you tried to serialize something to JSON ? Yes ? Which one of the
_TWELVE_ libraries did you use ? Need to compile something ? You can take a
coffee break. You defined a `unary_-` function ? I'm sorry you can't search
your code to locate the calls.

~~~
paulddraper
Scala grew up in a different time then Java.

Have you tried to serialize something to XML in Java? Which of the fifteen
libraries did you use?

------
keypusher
Kotlin is a better Java. Scala is just something else.

------
jankotek
It is also about tooling and libraries. I find Scala ecosystem to be behind
Java ecosystem couple of years (SBT versus Maven/Ant/Gradle, collection
libraries...).

And Kotlin makes this debate irrelevant anyway.

~~~
WaxProlix
That's completely not true because Kotlin has something near zero adoption. I
have a Kotlin fanatic coworker so I know all about the manifold benefits of
Kotlin -- it sounds awesome.

Never had a project OK'd to use it, probably never will. They obviously need a
PR and marketing department; otherwise they end up being the CouchDB to XYZ's
Mongo.

~~~
jankotek
I usually hava Scala/Java debate before new project (or refactoring) is
started. And here is Kotlin relevant.

Kotlin is bundled with Intellij Idea. And Kotlin has smaller adoption barrier.

~~~
WaxProlix
If you work with other teams, especially onprem or offshore teams, they use
netbeans or some other piece of shit IDE. It's just a fact. They know J7, can
be convinced to try J8, once read a blog that mentioned Scala, and don't know
what the fuck Kotlin is.

~~~
curun1r
On the other hand, if you decide to use Kotlin, you'll post a job listing, get
only a handful of candidates, and nearly all of them will be outstanding and
the type of curious, driven engineer that you'd normally have to sift through
a mountain of dime-a-dozen, uninspired Java hacks to find.

It's not until you've had to hire Java devs that the mystery of why so many
people feel the need to ask a question as facile as FizzBuzz becomes clear.

------
creyer
What "better java" means? It means I can build the same stuff but in a better
way. Easier to read, to maintain, and at least with the same performance.
Scala has a big plus on asynchronicity, but the article doesn't even try to go
there. Libraries like Akka, FS2, Monix, ScalaZ etc are not mentioned either.
In Scala I can use everything from Java and much more, and this is why is
better.

I'm sure by tomorrow someone with more time than I have will write an
extensive article explaining in more detail why is better.

~~~
eloisant
A "better Java" means keeping the same concepts and paradigms as Java, but
fixing some of the design issues. That's what Kotlin is.

Scala on the other hand is a completely different beast, but some people use
is as "a better Java" because it doesn't force you into its paradigms. You can
code in Scala without using case class, with var everywhere, etc.

It can be handy to fallback to "Java style" when you don't know how to do it
in idiomatic Scala, but at the end of the day if you don't want to embrace the
key paradigms of Scala it's better to use a different language.

------
yousry
My follow-up question would be: Is Scala still competitive to modern languages
like Swift and Rust?

I experienced several drawback according to library quality and code-safety.
There are too many small details that left me with an unpleasant feeling (I
would take ScalaNLP/Breeze for example).

But my central issue is the VM/GC dependency. In times of GPU computing,
native interface programming becomes a burden. The knowledge of object
ownership improves code readability. I feel uncomfortable leaving object
lifetime to a background process.

~~~
divanvisagie
It depends how you define "competitive". If you are trying to collect hipster
points then Scala is not going to help you but let's be real. Nobody is
writing big systems in either Rust or Swift, these are playgrounds for people
at the moment.

~~~
bontoJR
I am big fan of Swift and Scala... and, to be honest, for Swift there's a long
way ahead before a big system can be deployed... tooling and libs are not
there, also not considering that the lack of ABI stability makes the source
code necessary for any external dependency.

------
throwawayish
Not a myth: Kotlin is the better Java

Although Kotlin does have a lot of stuff that technically allows to write
weird code, most of that (eg. extensions) is around for better interfacing
with Java, and normally not used in pure K code.

------
preordained
So much Java hate in here. I understand most people think Java devs live in
caves, toiling away thinking Java and XML are the only technologies in the
world. Still, this Java dev has used Haskell, Prolog, Ruby, Python...etc. I
have left the cave. I've seen the world. It's nice, but Java still provides a
ton of support and tooling to get things done. People have done bad things in
the name of Java, and they have done fine work, too. Most of your practices
from the bad old days of 90s to early 2000s Java are in rapid decline.

It's not my favorite language (I heart Ruby), but a practical choice for many
projects. Don't kid yourself; once you leave "Hello World" land, and have to
deal with a variety of features, platforms, technologies, you can't hope to
roll your own salvation--no matter how expressive your favorite language. And
you don't want Johnny's 3 star github project solution, sorry. You want a
battle tested beast, with the scars to show for it. That's Java for you.

~~~
shados
The software engineering community is bottom heavy right now, driven by
improvement in accessibility of various platforms (eg Rails), and the
prevalence of the San Francisco tech startup bubbles (where tens of thousands
of developers have 10 jobs on their resume but never worked on one with more
than 20 developers). And then these people go on and get lucky, and you have
unicorn billion dollar companies built like if they were startups.

That creates a weird/interesting world, where the #1 priority is "how long
does it take to use this if I've never heard of it before, and how quickly can
I build an MVP with it"

That...changes priorities. A lot. Java is the other end of the spectrum, being
born long before that world existed, and probably went a little too far. Fact
remain, Java was born in a world very much opposite to what the majority knows
today. So it will get flack from people who don't understand (or worse: don't
remember, even though they were there!) why it is that way, and why it's
(sometimes! Not always!) valuable.

For a mature project, I don't give a damn how quick it is to learn or how fast
you can get your login form ready. The login form was written 10 years ago. I
want to see how quickly you can find, debug, diagnose and fix issues or how
quickly can a new module be added to the code base while being consistent with
the rest of the architecture.

The java ecosystem is actually pretty good at it. At this point I haven't done
Java in a very, very long time, but a large part of our stuff at work uses it,
and I can open one of our hundreds of repo, look at it, and I know what it
does and how I could extend it, even though I've never used the framework its
built on.

------
rco8786
Admittedly biased but can't help but think this article reads like something
stating that Scala is indeed a "better Java".

Well, perhaps not "a better Java" but at least "better than Java".

~~~
inlined
That seems to be the point. Proper or idiomatic scala code uses tools only
available to scala. I used scala for a while. It has some neat tricks that I
grew to like, but I think it ultimately had a problem I noticed in Ruby: there
are many "right" ways to do things and each team has its own culture. This
makes learning foreign codebase pretty hard--especially with how dense scala
code is.

------
hintingonwhoiam
Though correct this author makes a key assumption I dispute. "Scala as a
better Java" === "people code in the same way in Scala & Java". This
assumption leads to the focus on various Libraries and accepted standards.

But, at least to me, "Scala as a better Java" === "Scala with better syntax
and less boiler plate but access to Java libraries if you need them".

Java is a brilliant language. But nothing can survive without some assumptions
being voided over time. Despite that, many institutions relay on the good
parts of Java (which there are many). Scala is a middle ground which has that
backwards compat but with fixes to invalidated assumptions (syntax that has
gotten clunky over time, lack of functional constructs)

------
divanvisagie
Is The Scala Evangelism Task Force back in action? I'm game.

------
Zigurd
There are at least two things more important than Scala being a cleaner Java:

1\. The IDE 2\. Oracle's claims on Java IP

A good IDE is more important than Java being verbose, and the only way Scala
will displace Java is if Oracle win suits and makes Java expensive to use.

------
mwcampbell
I wonder if standard practices for Kotlin will diverge from Java in the same
way. I could guess either way. On the one hand, Kotlin maps between its
properties and Java's standard bean getters and setters, whereas Scala does
not. On the other hand, a desire to share code between the back-end and
statically optimizable JavaScript (and Android packages) will hopefully push
Kotlin libraries away from reflection and toward build-time code generation
(presumably based on annotation processors). Then again, the latter option is
also available to plain java (see Dagger 2), if only the broader Java
community would embrace it.

------
julian_1
Question - can I simply drop scala into an existing java based maven build?
Using something like the scala-compiler plugin
[https://mvnrepository.com/artifact/org.scala-lang/scala-
comp...](https://mvnrepository.com/artifact/org.scala-lang/scala-
compiler/2.12.1)

~~~
simsla
Scala is compiled against the jvm, so you're able to e.g. compile a scala jar
and call it directly from java.

A couple of caveats, though.

\- collections are different. You'll need to use helpers from JavaConversions,
etc. to e.g. turn a Scala list into a Java list. \- scala methods with default
arguments are irritating to call from java. \- avoid the more esoteric scala
features

------
inglor
> With compile-time DI, you make service classes accept lower level
> dependencies as constructor parameters. In Scala, constructor parameters are
> accessible from regular methods, so most of the time, these services could
> be completely stateless. This approach is also advocated by several Java
> (and .NET) experts, but it's by no means mainstream. Interestingly, Scala
> developers have an advantage over Java/C# users, because they can
> significantly simplify the implementation by combining a macro-based library
> with lazy definitions:

Asking for a dependency explicitly is service location not dependency
injection. Your code there does not solve anything better than a regular
service locator in a constructor would. The point of DI is that it's
abstracted from the user code and the user doesn't have to care about these
`wire` calls and can test it "as if dependencies were just passed regularly".

~~~
sreque
I don't think you're understanding what the author was saying. The author is
advocating for constructor-based dependency injection, which incidentally, I
also advocate for. There is a macro-based library in Scala, MacWire, that
helps write the constructor calls for you, essentially acting as an auto-wire-
like replacement to Spring and Guice, except that it does all its work at
compile time. This mean you catch errors much earlier in the build and deploy
process.

~~~
inglor
Where are the wire calls performed? Not in the constructor but in an
initialization file?

~~~
sreque
I'm not familiar with MacWire, but I believe it's powered by macros. You can
think of a macro as a function that runs at compile time. It's input is a
syntax tree representing some code, and it's output is an arbitrary syntax
tree representing code. The compiler, while processing source code, will
recognize places where a macro should be invoked on some syntax. It will call
the macro on that syntax, then replace the syntax with the output of the
macro.

In this sense, you can imagine a macro that takes in the source code for a
class that has wire calls, and rewrites the wire calls into object constructor
calls based on introspection of the syntax and types in the class.

If you're familiar with C macros, they are technically the same kind of thing,
although very basic, error prone, and unpleasant to work with. If you want to
learn more about macros, I would recommend starting with a simpler, more sane
macro system like one in Scheme, or, if you want something that looks more
like Java, Nemerle
([http://www.nemerle.org/About](http://www.nemerle.org/About)).

Scala's macro system has a bit of a bolt-on feel since the language wasn't
designed from the ground up for macros. That said, I applaud Scala's effort to
try to figure out how to integrate macros into their core language and hope
they are successful in the future with Scala Meta
([http://scalameta.org/](http://scalameta.org/))

------
merb

        Not surprisingly, this approach has become very popular in 
        recent years and made the Play team consider promoting it 
        as the default in the upcoming version of the framework. 
    

It's not really the default. It's just another reasonable choice without
adding guice as a dependency. Even the Starter templates include guice:
[https://github.com/playframework/play-scala-starter-
example/...](https://github.com/playframework/play-scala-starter-
example/blob/SNAPSHOT/build.sbt) Play! also does not enforce somebody to the
Scala Ecosystem, it doesn't come with many functional patterns (but they can
be used with it). The overall goal of the last versions was getting a DI
approach, so that the testability of an Applikation can be greatly improved
and also the testability of Play itself.

------
mring33621
I am a long time Java developer and, believe it or not, regularly write
important new product features in concise, performant Java 8.

I have looked at Scala time and time again and am not sure what to think. It
is currently a popular choice for big data munging -- I'm into Apache Flink
and most Flink jobs are way easier to read when written in Scala VS. Java.

But I also feel like Scala requires more decisions per line of code than Java,
which makes it a more demanding day-to-day language. Also, it seems to have
lots of dark corners. But these are really my impressions based on limited
experience, so I am likely wrong.

Also, my limited experience indicates that IDE support for Scala is quite
behind that of Java.

But I am still open to it.

To get to my point, actually my question: Where should I look to learn
quality, ideomatic Scala?

My preference would be to focus on small example programs that do one thing
well while demonstrating the correct, native use of Scala.

Thank you.

~~~
adamkl
I'm just starting to pick up Scala (and functional programming for that
matter) and I've been working my way through Functional Programming in
Scala[1].

So far, it does a good job of teaching functional programming by taking
stateful scala code, and refactoring it using pure functional approaches. The
result might be considered quality, ideomatic scala.

[1][https://www.manning.com/books/functional-programming-in-
scal...](https://www.manning.com/books/functional-programming-in-scala)

------
misja111
The very first example is about DI and advocates MacWire to do that in Scala:

lazy val userDao = wire[UserDao]

I come from Java and when I moved to Scala I wanted to use DI to mock
dependencies in my unit tests. The logical choice for DI seemed to be MacWire,
however it did not help me with the mocking at all.

In Java you have Mockito and annotations such as @InjectMocks that inject all
your mocks into your SUT automagically. In Scala, regardless if I used MacWire
or not, I had to override my SUT's implementation and its dependent fields by
myself, or use constructors that take all the dependencies as arguments so I
could override them in my tests. Luckily this is much easier in Scala than in
Java, but to me MacWire was a disappointment.

~~~
caoilte
Eventually you learn not to need mocks. It's a long road though. An important
first step is making your dependencies very very simple functions that are
trivial to define on the fly.

~~~
misja111
Yes I agree, in Scala mocks are not as useful as in Java and the Scala
language has some features that make it easier to work around them.

However what I don't understand is what is so great about MacWire. Maybe I'm
missing something but I always believed that the main advantage of a DI
framework was that it facilitated mocking. If this is not needed in Scala,
then what is so great about MacWire?

~~~
caoilte
You're right. The biggest thing that DI frameworks have historically done for
me is make mock injection easier.

There are other benefits, however. \- Manual wiring generally has quite a lot
of boiler plate (even in Scala, especially if you use free monads) \- DI
frameworks enforce a pattern of behaviour. This can be especially helpful when
navigating a project.

Having said that, whether these benefits are worth the cost of a DI framework
is debatable. My current weapon of choice is FreeK...

------
cygned
Even though Scala might not be the answer, I still think we need a replacement
for Java.

All the Java enterprise projects I know suffer from the same problems;
incredible complex project structures, a lot of "dead code" (e.g. empty Java
interfaces), XML, money being burned for engineers fighting with Tomcat or
Glassfish, slow database operations because of an ORM centric development and
so on.

I am not sure, what's going to be the solution but from my perspective Java as
a language needs to be replaced.

~~~
TeMPOraL
Java 8 is much better for programmer's sanity. If you could force people to
jump to that, and completely burn down some areas of the ecosystem (like XML
overuse), maybe Java could actually be saved.

Alas, I think backtracking on parts of the ecosystem is a hard thing, and I
don't see it happening soon.

~~~
TeMPOraL
Adding: I was messaged by someone who interpreted my comment as if I was
saying "Java 8 is better than Scala". That's not what I meant. I mean that
with Java 7 and 8, _Java_ the language is more bearable than it was in the
past, so Java the language is in less dire need of being replaced by something
else.

------
thepiwo
Scala quicky got my favourite language. I really like handling data using
functional and imutable concepts.

Great libraries for db access (slick) and json handling (sparay-json) were not
mentioned in the article, I wonder why slick is not even mentioned in the
comments, it is really nice!

Using scala with these and combined with akka and futures feels like a so
natural way of programming for me.

------
mcguire
" _With compile-time DI, you make service classes accept lower level
dependencies as constructor parameters. In Scala, constructor parameters are
accessible from regular methods, so most of the time, these services could be
completely stateless._ "

Um...the constructor parameters become invisible instance variables. It's not
stateless.

------
edem
You might want to try Kotlin which is basically just a Turbo Java without the
baroque fluff Scala brings to the table.

------
PaulHoule
It's not a better Java, it's a worse Java.

I like the late-time binding in Spring, it is a very complete answer to the
problem of "shipping a set of binary components" and "configuring those
components endlessly". Why is that a problem? Because your build is slow and
because it's dangerous to patch the source code every time you want to tweak
the configuration, ...

Trouble is: a lot of folks "learn" Spring working on a project somebody else
started by cutting and pasting and searching for answers on Google and
Stackoverflow.

You can learn some things that way, you cannot learn Spring that way. If you
read the manual a few times straight through you realize that it makes a lot
of sense.

------
fulafel
Did anyone switch to Clojure from Scala? Sounds like an attractive choice
given the complaints.

------
jwatte
The only data layer for Scala that matters is Spark and Data frame.

~~~
trengrj
To be pedantic in Spark 2.0 it is now Dataset. DataFrame is now an alias for
Dataset[Row].

------
stephen123
Nice examples!

------
balamaci
"STOP STOP, It's already dead"

