
Making the move from Scala to Go - maloga
https://movio.co/blog/migrate-Scala-to-Go/
======
lkrubner
Since they cite me (and my essay from 2014) as part of their decision making
process, I want to throw in 2 cents here. They ended up deciding on Go,
whereas I have ended up preferring Clojure, yet I agree with a lot of what
they say, so I'll try to clarify why I ended up with a different decision than
what they made.

I understand what they mean when they write:

 _I think the first time I appreciated the positive aspects of having a strong
type system was with Scala. Personally, coming from a myriad of PHP silent
errors and whimsical behavior, it felt quite empowering to have the confidence
that, supported by type-checking and a few well-thought-out tests, my code was
doing what it was meant to._

There are times when I appreciate the strict type-checking that happens in
Java. I do get what they mean. But there are also a lot of times when I hate
strict type-checking (in particular, when dealing with anything outside of the
control of my code, such as whimsical, changing 3rd party APIs that I have to
consume (for some business reason), or even 1st party APIs that feel like 3rd
party APIs because they are developed by another team (within the same
company) or for some reason we can not fix the broken aspects of some old API
that was developed in-house 6 years ago.) Because of this, I have become a
proponent of gradual typing. If I am facing a problem that I have never faced
before, I like to start off without any types in my code, and then, as I
understand the problem more, I like to add in more contract-enforcement. This
is what I attempted to communicate in my essay "How ignorant am I, and how do
I formally specify that in my code?" [1]

I think everyone who works with Clojure sometimes misses strict type-checking.
Because of this, there have been several efforts to offer interesting hybrid
approaches that attempt to offer the best of all worlds. There is Typed
Clojure for those who want gradual typing, and there is more recently Spec.
Given what I've written, you might think I am a huge fan of Typed Clojure, but
I've actually never used it for anything serious. The annotations are a little
bit heavy. I might use it in the future, but for now, I am most excited about
Spec, which I think introduces some new ideas that are both exciting for
Clojure, and which I think will eventually influence other languages as well.

Do watch the video "Agility & Robustness: Clojure spec" by Stuart Halloway.
[2]

I also sort of understand what they mean when they write this:

 _No map, no flatMap, no fold, no generics, no inheritance… Do we miss them?_

There are times when we all crave simple code. Many times I have had to re-
write someone else's code, and this can be a very painful experience. There
are many ways that other programmers (everyone who is not us, and who doesn't
do things exactly like we do) can go wrong, from style issues such as bad
variable names to deeper coding issues such as overuse of Patterns or using
complex algorithms when a simple one would do. I get that.

All the same, I want to be productive. And to be productive in 2017 means
relying on other people's code. And, in particular, it means being able to
reliably rely on other people's code -- using other people's code should not
be a painful experience. Therefore, for me, in 2017, one of the most important
issues in programming is composability. How easy is it for me to compose your
code with my code? That is a complex issue, but in general, those languages
that allow for high levels of meta programming allow for high levels of
composability. Both Ruby and Javascript and Clojure do well in this regard,
though Ruby and Javascript both have some gotchas that I'd rather avoid. In
all 3 languages, I find myself relying on lots of 3rd party libraries. I use
mountains of other people's code. Most of the time, this is fairly painless.
But there are some occasionally painful situations. With Ruby I run the risk
that someone's monkeypatching will sabotage my work in ways so mysterious that
it can take me a week to find the problem. And Javascript sometimes has the
same problem when 3rd parties add things to prototype, perhaps using a name
that I am also using. I so far have had an almost miraculous time using
Clojure libraries without facing any problems from them. It's this issue of
composability that makes me wary of Go. While I sometimes crave a language
that simple, I can't bring myself to give up so much of modern languages best
features.

[1] [http://www.smashcompany.com/technology/how-ignorant-am-i-
and...](http://www.smashcompany.com/technology/how-ignorant-am-i-and-how-do-i-
specify-that)

[2] [https://www.youtube.com/watch?v=VNTQ-
M_uSo8](https://www.youtube.com/watch?v=VNTQ-M_uSo8)

~~~
pka
> If I am facing a problem that I have never faced before, I like to start off
> without any types in my code, and then, as I understand the problem more, I
> like to add in more contract-enforcement.

This seems to be a widespread sentiment.

In practice, I've found that prototyping anything remotely complex without
types is so painful that I'd rather settle for an inferior design than trying
to come up with the best possible abstraction.

In Haskell, I come up with a coherent skeleton without having to implement
mundane details, hit a wall in the design space because of some case I didn't
think of, come up with a better idea and then go back to the code and refactor
with confidence. The type system always guarantees that my prototype is
coherent as a whole. And I can do that dozens of times.

In Clojure, even with spec, I'd have to implement all my functions fully
before being even able to test the design as a whole (sure, testing individual
functions works fine in the REPL.) And after hitting a wall, having to
reimplement everything every time is just too much work.

~~~
abc_lisper
> In practice, I've found that prototyping anything remotely complex without
> types is so painful

Just to offer a counter-point, I have a Clojure project here with 3k LOC,
without using spec/schema. All I have is 700 LOC tests. The tests enforce
semantic meaning, along with (some) contracts. I miss types from time to time,
but it is no where near as bad as you mention. Against me is the fact is that
my app is mostly self-contained, and written all by me. I am fairly certain
the project would be atleast 30k LOC if I wrote it in Java.

I think value of types only comes into being when there are many people
working on a single code base. Repl/tests/integration tests will take one a
long way before it reaches its limits.

I don't buy the argument that types are useful for large codebases, because
1\. Types don't enforce meaning. Meaning is far complex than type. Haskell
style types only work as far as they enforce meaning. 2\. Types have limits
too. More accurately, humans have limits. Working with large codebases where
there are 1000s of types is hard; which it shouldn't be because that was type
systems selling point all along.

Cleaner abstractions of code, separated by strongly enforced protocols(types)
is the way to go, I think.

~~~
kazinator
Today I caught a bug in a macro-expanding code walker, where it was expanding
the wrong form. The syntax being walked is (foo-special-operator x y z .
rest). x and z are ordinary forms that need to be expanded; y is a
destructuring pattern (irrelevant here). The walker was expanding z in the
place of x: that is to say, expanding z twice, and using that as the expansion
of both x and of z. That's simply due to a typo referring to the wrong
variable.

The type system would be of donkey all use here, because everything has the
correct type, with or without the mistake. The code referred to the wrong
thing of exactly the right type.

A lot of code works with numerous variables or object elements that are all of
the same type, and can be mixed up without a diagnostic.

~~~
neilparikh
So the issue you faced was that you used z twice, and x not at all? In that
case, linear types ([http://edsko.net/2017/01/08/linearity-in-
haskell/](http://edsko.net/2017/01/08/linearity-in-haskell/)) may have caught
that.

~~~
kazinator
x not being used at all can be caught by a simple unused variable warning.

In this situation, the variable's value was used somewhere, so that didn't go
off.

------
stcredzero
_As it turned out, more flexibility led to devs writing code that others
actually struggled to understand._

This is what happens in almost every language. Niftyness and the prospect of
impressing your coworkers distorts the cost-benefit calculation. This is in
addition to the true costs appearing months or years after the code is
written, involving the interaction of complex factors, like increased cost of
debugging.

"Clever" should be regarded as a limited resource. Also, the shop should
encourage a culture where "clever" with regards to making code easier to
understand should be valued above all else.

~~~
lacampbell
I'd much rather deal with concise, clever code that has a sane interface and
works, rather than sprawling long winded code where everything is void and the
same low level constructs are used everywhere.

And honestly, sometimes I don't know if code is too "clever" or the reader is
just too "dumb".

~~~
nemothekid
>And honestly, sometimes I don't know if code is too "clever" or the reader is
just too "dumb".

IMO, the answer is people vastly underestimate the cognitive cost of reading
code. "Code" rarely exists in a vacuum, the reader has a universe of inputs,
outputs, problems, solutions, failures and goals. The cognitive cost of trying
to read someone's code is something that must be paid multiple times per day
and at one point do you have to wonder - is the gain in expressiveness for a
single programmer worth the cognitive cost of the multiple programmers who
have to parse that code.

I'd imagine the answer is no - especially for companies that spend more time
iterating and patching based on customer feedback than actually designing and
architecting systems. My belief is that expressive languages have their place
but companies are far more likely to build their software in a "patch-test-
iterate" environment which favors less expressive languages.

~~~
runT1ME
I'll keep repeating myself: the cognitive cost of "code" is dwarfed by the
cost of understanding an _application_. If a couple esoteric languagn features
take an extra few hours to learn but reduce LOC tenfold, it's a price I'd pay
every time.

Not everyone feels this way, the investment to learn these features may not
pay off right away, and if you come from a "move fast and break things"
language (python/php/js) it can feel like a waste of time.

~~~
dualogy
> _If a couple esoteric languagn features take an extra few hours to learn but
> reduce LOC tenfold, it 's a price I'd pay every time._

Issue is that a beginner pre-conditioned long enough on "verboser,
imperativer" models/languages, when reading/comprehending such a codebase, has
to literally mentally expand every 1 line into 10 upon reading, for quite a
while .. some weeks, some months, as more intuitive grasp sets in slowly over
time. Probably what happened at OP's quoted company and with the different
speeds in comprehending what "clever" (compact) code some of their coders came
up with, what they flippantly called "code that was harder to understand by
others"..

------
ludicast
Scala is the latest whipping boy(1). It's a great language with tons of warts,
but it actually acknowledges the warts.

Case in point, when (2)Paul Phillips went after Scala (mentioned in the
article), Odersky took some of that criticism to heart for the next
iteration/rewrite of the Scala compiler. In an industry where everyone doubles
down, that's extremely refreshing.

Scala's cognitive footprint can lead to misbehaving programmers, but clean
Scala has its own elegance if the cuteness is avoided. The slowness I'll give
you though :(.

1) I'm old enough to remember this language CoffeeScript that "really really
sucked". And then all of a sudden, people were using ES6/TS with parameter
destructuring, classes, lambdas, but yeah, CS was the bad guy.

2) Despite his bellyaching, Paul Phillips never really left Scala the language
(check his commit log), just the compiler team & lightbend.

~~~
Daishiman
Well Coffeescript was refreshing in being very terse and introducing a lot of
niceties that were missing in JS. It was also trivial to introduce footguns
given its whitespace rules and some pretty radical syntax rules.

New Javascript has basically taken the best that CS had and wrapped it in the
necessary turd that is backwards compatibility in a hastily designed language,
but the results speak for themselves and modern JS is just much more
pleasurable.

~~~
jiaweihli
Yes, the frustrating thing was that people previously praised the language
_despite_ its obvious footguns. A language where 'dropping parentheses where
you can' is idiomatic is a disaster waiting to happen.

I don't know about you, but I never want to be holding a footgun, ever.

~~~
dagw
Coffeescript worked pretty great when using it on solo projects, because I
could use the bits I liked (which where very nice) and ignore all the footguns
that I didn't like. The problem as such was that any coffeescript I wrote
turned out not be all that idiomatic.

------
justinhj
Some experience to share: I studied Scala and FP on the side before jumping to
a team that was using it in production. Most of the engineers on the team have
an enthusiasm to learn about and use fp.

Bi-weekly we have a book club where we take turns presenting a topic from
functional programming in Scala, functional reactive domain modelling and
others.

We program as simply as possible but when a new technique is discovered we go
ahead and use it after it's been presented to the team and everyone is
comfortable with it.

all code is reviewed and unreadable code does not pass

Compile times haven't been an issue. As an example a 100k line Scala program
with around 900 files takes around 2 minutes to rebuild whilst incremental
changes are immeasurably fast. Reloading code while a local server is running
is easy by default in IntelliJ.

Using worksheets for playing is often useful.

we don't use actors where streams would make more sense and vice versa, know
the purpose of your tools

I've had bad experiences with Go. I know that for the application I'm working
on it would not scale to 10 programmers working and constant refactoring due
to business goals changing.

~~~
alexbanks
What magical place do you work that allows for this level of engineering
quality?

> all code is reviewed and unreadable code does not pass

Sounds quite nice.

~~~
lewapkon
Thorough code review is a great process that should be used in every company.

~~~
alexbanks
Keyword: _Should_

------
imh
Looking through the really abstract scala code they linked brings up a problem
that really frustrates me in haskell. Why doesn't anybody document their
really abstract code? You _know_ it's going to be confusing, so why not help
out? If I have a type like

    
    
        def foreignKey[P, PU, TT <: AbstractTable[_], U] ...
    

It's not sufficient to document the function's arguments. You also need to
document the type variables! Likewise in haskell with code like

    
    
        f . g x . (h (i x) $ j y z) . k $ aNamedVariable
    

It really isnt' so hard to refactor that into

    
    
        let descriptivelyNamedFunction = (h (i x) $ j y z)
            anotherDescriptivelyNamedVariable = descriptivelyNamedFunction . k $ aNamedVariable
         in f . g x $ anotherDescriptivelyNamedVariable
    

It's much larger, but in certain places it prevents so many headaches. It's
great that you can put stuff inline, but both communities seem super lax about
accepting code that is the opposite of self-documenting.

 _edited for clarity, i hope_

~~~
tel
I mostly agree with you, but I also think a bit part of what Haskell-like FP
shows is how often your code is invariant to so many things that the variables
no longer have any sense to them whatsoever.

That doesn't really excuse badly named variables when that doesn't hold. It's
more that it's something sort of novel to a lot of Haskell-like programmers
and so we all get excited about it and probably overdo it somewhat. But on the
other hand, I think it's very well-justified often enough.

For instance, with

    
    
        class Functor f where
          fmap :: (a -> b) -> (f a -> f b)
    

there are many words you _could_ give to f, a, and b but they're essentially
all misleading.

With another example from the article, Strong Syntax, the "Syntax" bit is
basically a convention in scalaz that ought to be immediately obvious if
you're familiar with the scalaz library. The "Strong" bit has to do with a
subtype of "Profunctor" structures, "Strong Profunctors".

Profunctors are generalizations of functions that show up all over the place.
Strong profunctors are profunctors which can "distribute over a tuple".

Giving names to these types is an exercise in futility. At least with a
function `a -> b` might be named `in -> out`, but with a Profunctor there
isn't even that intuition. It's just too general. Subsequently, it shows up
all over the place.

~~~
aninhumer
> At least with a function `a -> b` might be named `in -> out`, but with a
> Profunctor there isn't even that intuition.

What about:

    
    
      dimap :: (newIn -> in) -> (out -> newOut) -> p in out -> p newIn newOut

~~~
tel
With profunctors there's not necessarily anything going in or out and
especially not necessarily and notion that the thing going in produces a thing
going out.

That's all roughly true with one kind of profunctor, a function arrow, but not
true in general.

For instance,

    
    
        data Counterexample a b = Cx (Set a) b
    

is (very, very, very nearly [0]) a profunctor, but a isn't necessarily "going
in" and b isn't necesssarily "coming out".

[0] It's a profunctor if a is finite. You can handle the infinite form by
writing it as `data Cx a b = Cx (a -> Bool) b` which is equivalent to what I
wrote when `a` is finite... but it also makes it a little easier to pretend
that a is "going in" even if that's a bad intuition.

~~~
aninhumer
I'm not sure I see how the intuition is bad here? What would the lmap
implementation for your (Set a) example be if not equivalent to the (a ->
Bool) case? And how is that not an example of data "going in"?

More generally even if there are Profunctors for which this analogy isn't
perfect, I feel like the intuitive type names are still more useful than
random letters. Especially for a relatively advanced concept like Profunctors,
for which I expect pretty much all users to be comfortable with the idea that
a type variable does not necessarily imply that concrete values of that type
will exist.

~~~
tel
It is equivalent to the (a -> Bool) case. In Haskell at least, all "negative
type parameters" are ultimately generated by the left side of a function—but
this is more a concern for how ideas are modeled (perhaps partially) in
Haskell then a fundamental one. If you're writing code that's

    
    
        forall p . Profunctor p => ...
    

then `in` and `out` aren't generally valid.

I definitely hear the argument that ergonomically it might be a good idea to
use a sort-of-appropriate model to drive better terminology... but at the same
time I think there are drawbacks. I think it helps the early part of a
learning curve but then hinders the latter part. An expert doesn't care what
they're called since they're just mentally erasing the names as appropriate
anyway. A non-expert will try to carry the metaphor further than it can go and
gets stuck.

This is why there's endless debate about calling Monoid "Appendable" or
something like that. For the commonest cases that's the right idea... but the
first time someone questions why there's an Appendable instance for Bool (two,
actually!) you're fighting with your own inappropriate metaphor.

"Oh, Appendable actually means Monoid but we didn't want to say that straight
up."

------
coconut_crab
My company also have a lot of problems with Scala, both technical and non
technical ones, but so far we have managed to control it:

\- As for slow compilation times, incremental building helps a lot.

\- Intellij works most of the time, and if it doesn't a few type annotation
will fix it.

\- It's very hard to find people with Scala experience. We have given up on
finding those and decide to train people from the beginning for 2 months. I
myself studied mechanical engineering in university and I can code just fine
after a few months.

\- The language itself is very complex, so we let more experienced programmers
write the backbone/framework/library/common parts and the less experienced one
do the code glueing-job. That way we can have Scala type safety and
expressiveness without scaring the juniors. IIRC one company used Haskell also
do the same and they said it is very hard to introduce runtime bugs because
almost everything were caught during compile time, "If it compiles, it works".

You may ask why going through so much trouble just to use Scala. There are
many reasons (speed, type safety etc..), one of them is that we can be
immensely productive _when needed_ , the conciseness of the language combine
with a powerful type system let us implement complicated features rapidly
without very few bugs. IMHO Scala strives to combine both FP and OOP on top of
JVM so a lot of tradeoffs had to be made. The developers have to learn a lot
of concepts and have good self discipline, but in exchange we can write fast,
robust systems and even enjoy it.

(Edited for better formatting, this is my first time posting here.)

~~~
gazarullz
+1 for "If it compiles, it works" .... been there done that ... multiple times
!!! And yes in the beginning the feeling of "it works on the first run" was
just strange and it get me some time getting used to it

------
adriaanm
[Scala team lead at Lightbend here]

I'm always eager to learn how we can improve Scala, especially as we kick of
the Scala 2.13 cycle (hard at work on compiler performance and standard
library improvements). Email is 'adriaan.at("lightbend.com")

Regarding Scala's growth, I will leave you with
[https://www.indeed.com/jobtrends/q-scala.html](https://www.indeed.com/jobtrends/q-scala.html).

~~~
koevet
For completeness:

[https://www.indeed.com/jobtrends/q-scala-q-
golang.html](https://www.indeed.com/jobtrends/q-scala-q-golang.html)

~~~
rubenv
Or for those who don't call it "golang":

[https://www.indeed.com/jobtrends/q-scala-q-golang-q-
go.html](https://www.indeed.com/jobtrends/q-scala-q-golang-q-go.html)

~~~
furrydog
"Go" the language is tricky to search for as just the word "go", so I wouldn't
read much into that. Many job ads contain the word go, but have nothing to do
with go the language. e.g. "...go to our website..." "...go above and
beyond..." etc.

------
bad_user
Some notes:

\- the actor model, along with the Akka implementation, has nothing to do with
functional programming; and it isn't orthogonal either, since an actor's
mailbox interactions are definitely not pure, with actors being stateful and
at the same time non-deterministic; in general if you place those in the same
article, there's a high probability that you never did functional programming;
and if you did actual _functional programming_ (as in programming with
mathematical functions), then you wouldn't want to go back to a language that
makes that impossible ;-)

\- Akka actors are not the only game in town for processing data, you can also
use Finagle, FS2, my own Monix and even Akka Streams; And yes, concurrency
often requires multiple solutions because there's no silver bullet and Go's
channels suck compared with what you can do with a well grown streaming
solution

\- Scala's Future are not meant for "hiding threads" and 1:1 multi-threading
is actually simpler to reason about, because if that fancy M:N runtime starts
being unsuitable (because lets be honest, most M:N platforms are broken in one
way or another), then you can't fix it by choosing a more appropriate solution
without changing the platform completely

\- Your devs are maybe lazy or maybe they don't give a fuck, but given that
you're supposedly dealing with concurrency in your software, if those
developers struggle with a programming language, then it's time to invest in
their education or hire new developers, because the programming language is
the least of your problems

\- Paul Phillips still works with Scala and he most likely hates languages
like Go, so when you mention him or his presentation, it definitely cannot be
in support of Go

~~~
extempore
Paul Phillips here. I searched my tweet archive for my tweets about Go. Draw
your own conclusions.

\- Kill me before I look at go.

\- Nobody shot me first so I looked at go. Sigh. After maybe an hour of go I
was ahead of where I was after a week with rust.

\- The first audible WTF with go: cuddled else is mandatory. Parse error
otherwise.

\- go is a terrible, terrible language, yet still a major productivity boost.
Amdahl's law in another context.

\- You often see languages which are fighting the last war. Go is fighting the
War of 1812.

\- If someone had made up Go within a work of fiction, they'd have been
laughed out of the room.

\- I had thought Blub was a rhetorical device, but Go is more Blub than Blub.

\- reduce: what you will do with your expectations after you start with Go

\- Did they miss any chance to introduce an ad hoc inadequate non-solution?
Tool directives in comments! What could go wrong!

\- Comical levels of confirmation bias in proglangs. Guy doesn't get it, poor
impl, isn't useful, "see?" Examples: scala, python, go.

\- Some specifics are enumerations in scala, closures in python, and anything
devised since 1980 in go.

\- Go: compiler directives in comments is "an elegant design".
[https://t.co/DjCO1UxgC2](https://t.co/DjCO1UxgC2)
[http://t.co/BR3kFxRZvc](http://t.co/BR3kFxRZvc)

\- Rust and Scala drown you in complexity. Go drowns you in simplicity.

\- This comment sums up Go pretty well.
[https://t.co/Td9Q3wOW43](https://t.co/Td9Q3wOW43)

\- go logging package lets you set the global Writer, but not query it. So you
can't save/restore it. Nice job.

\- This year's gold medalists in type safety's missing-the-point olympics: Go!
[https://t.co/ktrlBUEwP9](https://t.co/ktrlBUEwP9)

\- Turns out Go is the result of a bar bet between Rob Pike and Robert
Heinlein. Everybody lost.

\- It’s incredible how far Go has lowered my estimation of the vaunted Google
engineer. What an institutional failure.

\- Go is what you might come up with if your definition of programming was
“shuffling electrons”.

\- A Go discussion thread is “how to build a space station with crayons” up to
homotopy.

\- A supposed selling point of Go is that you can learn it in a day. Think of
what that tells you about what it can do.

\- The existence of Go leads me to realize the infamous Google technical
interview is designed to _weed out_ out-of-the-box thinking.

\- I added a second file to [https://t.co/ktrlBUEwP9](https://t.co/ktrlBUEwP9)
further explaining how go's casting requirements are broken by design.

\- But little did I know, I’m just a “lesser” programmer because I enjoy Go’s
simplicity" says a commenter. Well, yeah.

\- The Go string type can't be passed as a fmt.Stringer. You apparently have
to accept interface{} and type match. Amazing.

\- An example of go upside: "go get ...gocov" and code coverage instantly
worked. In scala it has always been painful/fragile at best.

\- Any go code which has error in parameter position which tests err against
nil will silently miss a bunch of errors.

\- Hostility to abstraction: the Go story

\- Sad that google waited this long to put a deep mind on go.

~~~
extempore
I missed a couple which didn't mention go:

\- Rob Pike is like Henry Ford, except when people said “faster horses” he
said “that is the best idea I’ve ever heard.”

\- Rob Pike is the Antonin Scalia of programming language design - an
Originalist. Except 1970s not 1770s.

~~~
easuter
Enjoy your horse then; I'll just speed off into the sunset with the latest
model Generics Motors has to offer. :)

------
unoti
I have a simple question. In the article they mentioned they had a concurrency
issue with a timed buffer that they later neatly solved with go channels and
goroutines. They said that they solved the problem in Scala by moving to the
actor model, but that required importing Akka into their project and training
everyone how to use Akka.

My simple question is: couldn't they have achieved the heart and soul of the
actor model by just making an object on its own thread, and talking to that
object on a simple synchronized message queue? It's a handful of easy to
understand lines of code, and nobody needs to delve into the sea of madness
that is learning and configuring Akka and its actor model.

In more general terms, it's possible to use Scala as Java that plays well with
immutability and functional programming techniques without turning your
codebase into an overly complex difficult-to-understand mess. But for some
reason people just can't stop themselves.

For what it's worth, Elixir hits a real sweet spot of functional goodness,
combined with awesome concurrency without getting too deep into bizarre
complexity.

~~~
digitalzombie
Actors should be in a process no? If it's in a thread then it'll take the main
process down with it.

Erlang's BEAM VM every actor is in it's own process. So if something goes bad
then it can be restarted via supervisor.

Scala is on JVM and JVM isn't built with concurrency in mind and I think
Erlang's BEAM is too good at this. Akka is gimped too, you have to write actor
a certain way iirc other wise it takes over the scheduler. BEAM is preemptive,
it doesn't matter if you have a for(1) loop, your process/actor can only take
some much of the cpu time.

I think hands down Erlang is a really really beautiful language for
concurrency. It's syntax is ugly but it's such a small language that does
everything you need for concurrency. Scala is just big and there are so many
way to shoot yourself in the foot and tons of compromises. I also think
implicit type is too magical and shot myself in the foot many time using
libraries that use implicit type.

~~~
dalailambda
Erlang's processes are green threads, they're just called "processes". Neither
Erlang, nor Akka run 1 thread or process per actor, they just schedule
multiple actors over N native threads inside the single process (ignoring
multi-node situations).

~~~
sbalea
Two notable differences: Akka Actors concurrency is done at library level and
an actor can block a JVM thread if not coded carefully. Erlang processes
concurrency is support at VM level and there's no way an Erlang process can
block a VM scheduler (native code aside, but with native code all bets are
off)

------
_Codemonkeyism
Maintaining a Scala code base for some years, I've learned a lot. I would not
go back to a language that does not support Option/Maybe and map/flatMap.
These really changed my coding style.

My largest problems [1] are all still there after years, developers only payed
lip service and that killed Scala I think.

The largest bad design decision was to support inheritance which leads to it's
own problems with type inference. Sad that after Java devs already recognized
how bad inheritance is that Scala also got inheritance.

The sticking out problems is how very very very slow Scala compiles. This
makes web development (even with Play) and unit testing a huge pain (and the
complicated syntax + implicits + type inference makes IntellJ as an IDE very
very slow on detecting problems in your code)

Concerning the article I do think Futures are a more powerful (and higher)
concept compared to coroutines. They are easier to combine IMHO [2]

Now trying Kotlin for the faster IDE and compilation speed, sadly the Kotlin
developers think Option is only about nullable Types (it's not and something
differen!) and don't embrace it.

[1] [http://codemonkeyism.com/scala-unfit-
development/](http://codemonkeyism.com/scala-unfit-development/)

[2] [http://codemonkeyism.com/a-little-guide-on-using-futures-
for...](http://codemonkeyism.com/a-little-guide-on-using-futures-for-web-
developers/)

~~~
adriaanm
The only thing on your list on your blog [1] that's still true is that we care
about PL research. Since 2.10, we've worked really hard on improving the
migration between major versions, and the feedback has been very positive.
We'll keep working on finding the right balance between ease of migration and
fixing issues in the libraries. Scala 2.13 will be a library release, with
further modularisation of the library (towards a core that we can evolve much
more slowly, and modules that can move more quickly, but where you can opt to
stay with older versions as you prefer).

We've also invested heavily in incremental compilation in sbt. Sbt is meant
for use as a shell, and it's super powerful when used like that. When I'm
hacking the compiler in IntelliJ, recompiles of some of the biggest source
files in the compiler (Typers.scala, say) take just a few seconds. I rarely
have time for office chair sword fights anymore.

With Scala 2.13, half of my team at Lightbend is dedicated to compiler
performance. We'll have some graphs to show you soon, but our internal
benchmarking shows our performance has steadily improved since 2.10.

~~~
_Codemonkeyism
I still have the problem of upgrading because not all of the libraries are
cross compile or do work. At the end of last year we've upgraded one library
which cost us many days.

Next is upgrading Lift to 3.0 which will be a nightmare (again).

"We've also invested heavily in incremental compilation in sbt."

Yes, I read this over and over again, and I see micro benchmarks posted.

Using SBT with continuous unit testing I can't feel a difference - or it is so
slow with a major code base that it's still much to slow and I judge it having
no progress. Either way, after years it is still too slow (newest Scala +
newest SBT).

"I rarely have time for office chair sword fights anymore."

Today I expect Kotlins practically instant compilation. 10 seconds for
compiling some changed files is already to much for rapid development with
TDD/Web, it breaks my flow, but YMMV.

"We'll have some graphs to show you soon,"

See above, I've seen dozens of micro benchmarks that claim improvements, in
the end it doesn't show up in my real projects - at least in mine and the
person who migrated to Go in the linked article. And all the other blog post
authors that moved away from Scala towards something faster (Kotlin, Java 8,
Go, ...)

But as I've said, I've moved on to Kotlin for new projects because for me
Scala is a lost course.

------
richardwhiuk
So _four_ developers moved from Scala to Go.

'As you can see, we largely came from the stateful procedural world.'

No, you come from the 'my first languages' world....

~~~
cafebabbe
Ah, the GORILLAS.BAS world...

------
Avshalom
Making the move from Go to X, and why we're not going back (2018)

~~~
clishem
[https://mobile.twitter.com/HackerNewsOnion/status/7587710913...](https://mobile.twitter.com/HackerNewsOnion/status/758771091363856384)

------
joneholland
Sounds more like moving away from a big jvm monolith is how they gained their
speed.

Our Scala based microservices build in seconds.

Anyway, no idea who movio is, but cool they like go. Not sure why they needed
to write Scala FUD in the process.

~~~
Daishiman
I think that if you _have_ to move to microservices just to avoid atrocious
compilation times that means there's something horribly wrong in the language
stack. Microservices should be used to solve architecture problems, not a
workaround for compiler slowness.

~~~
scalatohaskell
just cyclic dependencies between project's generated source codes of exposed
interfaces/contracts. ez.

It's not hard to fuck up ur sw eng. practices and blame language.

------
unscaled
This mentions weak IDE support as one of Scala's pain points, but Go has very
much the same problem, and the language is vastly less complex.

The two best IDEs for Go right now IMO are VS Code and the EAP Gogland, but
both of them are not yet on par what you get with Java. VS Code has only
support for very rudimentary refactoring (renames) and relies on a rather slow
horde of external CLI linters (executed on save) to provide code analysis.
Gogland has pretty nice refactoring, but its built-in code analysis is still
too shallow.

Both will get better, but I can't take the claim that you'd move to Go from
another language due to "lack of a good IDE". If you want the best IDE move to
Java (or Kotlin, or C#) and never look back.

~~~
geodel
Go can be written without good IDE. I just use Sublime with Go plugin it works
great. Also Gogland gives sub-par experience to many experienced Go users.
E.g. it does not use `gofmt` but their own formatter which they use for all
IDEs. Not sure about their refactoring tool but `gorename` seems to me fine
refactoring tool.

~~~
unscaled
Gogland's non-standard formatting is one of my pain points. But the standard
go* tooling doesn't offer any proper refactoring.

Unless if by refactoring you mean "Jus' renaming my functions and variables
and nothing else, and only when all my packages compile correctly, with 80%
guranteed success" then Gorename is a good tool, I guess. YMMV.

This is what I have in mind when I talk about good refactoring (Resharper on
Visual Studio being the gold standard IMHO):
[https://es137custom.files.wordpress.com/2012/12/resharperref...](https://es137custom.files.wordpress.com/2012/12/resharperrefactoring.png)

It's a huge productivity boost for me, enough that I'm willing to live with
the subpar experience of IDE Vim Plugins.

Again, you can argue that _YOU_ don't need this IDE fanciness, but OP claimed
this is a major reason for them wanting to ditch Scala.

------
cjauvin
_Having this smartness disparity between devs is really bad for team dynamics,
and complexity leads invariably to this._

More and more I believe this to be a profound truth.

~~~
dasmoth
This seems like an argument for the lowest common denominator.

What should programmers who enjoy working with more powerful abstractions do?

~~~
blacksmythe

      >> What should programmers who enjoy working with more powerful abstractions do?
    

Work on teams where the lowest common denominator is higher.

------
mark242
Obligatory "did you try running sbt ~ compile before you started complaining
about the compile times" post.

It's amazing how the tools for faster turnaround times exist-- the one thing
the Scala community needs to do a better job of is clear, opinionated
documentation.

Also -- [https://github.com/scala-native/scala-
native](https://github.com/scala-native/scala-native) \-- watch that space.

~~~
tylerpachal
Could you explain this a little bit? I am just getting into Scala, usually I
use `sbt run` and `sbt test` while I am working, then `sbt dist` to package my
production app. What does `sbt ~ compile` do ?

~~~
joshlemer
If you run `~` before any command, sbt watches the directory for any source
changes, and on detecting source changes, redoes the command. So `sbt
~compile` will re-compile any new sources as soon as they are saved.

~~~
jpliska
The use of the ~ here illustrates the problem in the scala world: a lot of
surprising bells and whistles. Why not call it watch instead of ~?

~~~
justinhj
Or just use IntelliJ and you can reload classes while your program is running
if you want. Sbt is a very powerful tool but it's not written with readability
for new users in mind.

------
misja111
In my experience, the larger your codebase, the more you appreciate these
features:

\- a strong type system

\- a pure functional language so you have referential transparity

\- an IDE that helps you with refactoring

If your project is small than you can do without all of those, actually they
might even slow you down.

When I read the article, I get the feeling that this particular team was
working on a small codebase.

~~~
stymaar
The author also complains about the sub-optimal IDE experience with Scala and
then says he moved to a langage that has none …

------
kev009
I would consider Scala a far better language from a safety, syntax and design
perspective. Go is compelling due to the low GC pause times, and to some
extent the community for some types of software. I would imagine switching
between these to be quite rare. I would expect more movement from Scala to
Swift or perhaps Rust.

------
DrBazza
Stroustrup is right, there are languages that people complain about, and
languages that no-one uses. Go is now firmly in the former camp. Even if the
complaints are always generics and error handling.

------
s1gs3gv
All this whinging about compile speed ~LOL~

I remember when software development was a gentleman's game and we looked
forward to sharing a half hour together in somebody's office or around the
railing or coffee pot to exchange ideas and news while the build finished.

Scala is good. Its not perfect, its not appropriate for every situation, but
its worth learning and using.

Go has an anachronistic feel about it that is just, well, ugly.

------
noelwelsh
I think this team was doomed from the start.

If you come from an imperative programming background, as this team did,
(typed) FP is a new way of thinking. It takes a long time to adjust to this
new mindset, _particularly_ if you've been programming in imperative languages
for a long time. Go, on the other hand, is more of the same. It doesn't seem
that anyone on the team had a background in typed FP, and it doesn't seem that
they had any support from the organisation to make this shift. I'm not
surprised it took them a long time and didn't end well.

Learning new things is hard and until universities and other training
providers start teaching FP these kinds of stories will continue. (The
alternative, to have companies investing in training and mentoring [plug: my
company provides these services for Scala] doesn't appear to be likely en-
masse, even though it would be radically cheaper than throwing away code.)

~~~
tapirl
They just want a language more efficient to do develop/test/deploy loops. Yes,
Go does much better than JVM based langauges from this point.

------
bsaul
Wonder where they'll go once their codebase becomes crippled with interface{}
type and nil pointers check, and they stop using chanel to return to mutex for
performance reasons, or more control.

Note : sounds snarky, but it's an honest question i find asking to myself
after having tried many server side techs and feeling limited with go.

~~~
Sphax
Probably nowhere because 1) never happens 2) is a non-issue and 3) too
probably 99% of the time.

~~~
stymaar
1) I have a totally different experience ! When your are writting code which
must have a certain degree of genericity you end up having a ton of
interface{} …

2) wat ? How having a null pointer a non issue ?! Empirically it causes fewer
bugs than in Java or JavaScript, but it's still a really common source of bugs
in Go.

3) I've never run into this kind of problem myself since I dont use Go for
performance-heavy code.

------
overcast
X = the current disliked language of the month on Hacker News

Z = latest, most discussed language on Hacker News

Making the move from X to Z, and why this is just a marketing campaign from a
marketing group.

~~~
argonaut
I've been on HN for years. Scala has been widely criticized with these exact
same criticisms for years. These are all legitimate issues people have, even
if you don't think they're valid.

------
runT1ME

        It took some of us six months including some after hours MOOCs, to be able to get relatively comfortable with Scala
    
    

Huh. Yeah, sounds like Go is a really good choice for you guys! For some
reason our team is able to onboard new engineers and have them be productive
in less than a month...

~~~
lazzlazzlazz
You're either being a little unfair, or have a very low standard for
"productive".

~~~
kod
No, there's a huge difference in quality of programmers. I've led a team that
was productive (by which I mean shipping code that met business goals) within
weeks of starting with scala. I've been on other teams where some of the guys
still couldn't understand closures after 6 months.

~~~
geoka9
> I've led a team that was productive (by which I mean shipping code that met
> business goals) within weeks of starting with scala.

Personally, I like to measure things like that by how fast a team/developer
can get up to speed on maintaining an already existing non-trivial codebase in
the language. Shipping greenfield projects is often easier than adding
features to an existing one, particularly in languages like Scala.

~~~
runT1ME

         Shipping greenfield projects is often easier than adding features to an existing one, particularly in languages like Scala.
    
     

I don't agree. I work on an incredibly large Scala team and a powerful type
system gives you a _lot_ more confidence to make everything from minor bug
fixes to sweeping refactors.

The price paid for having to learn the complexities and power of Scala (which
I'll admit is much harder than other languages) pays off in that it lowers the
overall application complexity by reducing the need for a plethora of
frameworks/libraries.

If you write Scala like you'd write a java/python/Go application, you'll have
better type inference and a worse IDE, along with slower compile times. Not a
great proposition. If you write Scala like a pure functional language that
allows you to create powerful libraries and DSLs that make it possible to hack
together very reliable applications, you'll be amazed.

------
jorblumesea
Scala is an excellent language from a safety and design perspective. It's
biggest flaw is the lack of a corporate sponsor and higher barrier of entry.
Map, FlatMap, Options are all really great but hard to grok at first.

~~~
adriaanm
Thanks, glad you like it! We at Lightbend (my employer) don't think of
ourselves as very corporate, but we definitely sponsor Scala development. My
team is hard at work on Scala 2.13 (well, except the part of it that's
commenting on HN stories).

------
AzzieElbab
wrt to programming languages, going from scala to go is like going from
english professor to honey boo boo. go is basically new php with lots of ftm
features baked in. scala, for all it's flows stays true to it's goal - it is a
scalable language. use as mush of it as you are comfortable with and keep
growing. here is btw one of the "coolest" features of go in scala
[http://storm-enroute.com/coroutines/docs/0.6/101/](http://storm-
enroute.com/coroutines/docs/0.6/101/)

------
eklavya
I don't know, types help me think. I get lost real soon without them and the
reason why I could never pick up any Lisps. In Scala/Haskell I can come up
with a solution incrementally and types are the biggest reason why. I always
have that feeling that I am missing out on the trumpeted awesomeness of Lisps
but I can never justify using them. Maybe there is a personal angle to
language selection but I just can't help but feel types are the future and a
real advancement of technology.

------
hocuspocus
Some points might be valid it's really hard not to dismiss the whole article
when you write things like this:

> The funny part is that, because dependency hell is so ubiquitous in Scala-
> land (which includes Java-land), we ended up using some of the projects that
> we deemed too complex for our codebase (e.g scalaz) via transitive
> dependencies.

First, I've just checked, there are 237 dependencies in my classpath, and it
never caused me any issue. Dependency management is a complex problem, but the
JVM ecosystem does a pretty good job at it. Binary incompatibilities that are
specific to Scala are pretty much non-existent today outside of very specific
cases.

Secondly, why use stuff that you deem too complex and then complain that it
is? Transitive dependencies are just that, transitive. I have Cats and
Shapeless in my classpath and I haven't found yet the need to use them in my
own code.

~~~
cdegroot
It is too bad though that e.g. IntelliJ cannot tell the difference, will offer
you the transitive dependency's stuff in code completion, and now you are tied
to it. Of course, the thing _you_ used went away in the newer version that the
newer version of your direct dependency uses, and now you're spending time
figuring out dependencies instead of writing code. Which, in my experience,
happens pretty much all the time in Java/Scala land. (and I won't start about
the sorry state of build tools for the JVM; seen them all, nothing is as nice
as what I'm using now (Elixir/Mix)).

------
rodrigosetti
Nice write-up. I wonder if you guys have tried using Scala as a functional
programming (_no_ vars, returns, partial functions, exceptions, mutable data
structures, etc.) - or just used it like in the stateful procedural world.

~~~
cdegroot
I think the problem here is that Scala doesn't make any choices for you. Now
you're busy having to do a ton of code reviews to make sure that everyone
stays within the chosen paradigm, stuff will of course slip through and bite
you, and there you are with one big nice mess. Plus, it's too simple to just
pull in a Java library which doesn't mesh well paradigm-wise with what you
have (or a Scala library for that matter). I've done a ton of Scala and I've
been left with the same conclusion as I had waaaay back with C++ - too many
potential solutions, too many pitfalls and ways to make a mess. I guess I'm a
person that wants to make the language make the paradigm choice for me and
then I'll happily stick with that. One reason I like a language like Elixir so
much - the language made the choices, it matches the problem set I work on
pretty well, all the libraries look the same, life is simple, I can just write
code (instead of trying to understand a moderately complex build.sbt file
which basically comes with a paradigm of its own).

------
didibus
Worked with a principle engineer once who used language as a litmus test. If
you could not understand functional programming like Lisp or MLs, he'd just
know not to get you on his team.

Obviously, most of the software could be written by monkeys, and only need to
produce trivial functionality, in those cases, please switch to Go or at least
stick to Java or C#. I say that because in the hands of someone who doesn't
know, more expressive languages can cause havoc, and turn really messy.
Especially the hybrid languages like Scala.

~~~
unoti
Leading teams to victory and accomplishing business objectives is an even more
important litmus test, in my book. But different strokes for different folks I
guess!

~~~
didibus
But the best thing you can do to improve the team's chances of accomplishing
business objectives is to choose its members more carefully.

~~~
unoti
I agree. But personally I'd be concerned about a team lead who thinks the make
or break thing is whether a candidate engineer loves fondling their monads all
day.

~~~
didibus
Ya, it's a little draconian, but in practice it was more nuanced. If you just
didn't know those things, it was fine, but if you couldn't learn and
eventually understand them...

------
diminish
"..it felt quite empowering to have the confidence that, supported by type-
checking and a few well-thought-out tests, my code was doing what it was meant
to. "

Does this mean that on what software is "meant to do" type checking covers
most test cases and only few additional is needed to ensure iy does what it's
meant to do?

~~~
maloga
That's not what I meant to emphasise, but kind of. I was contrasting the Scala
programming experience to this: [https://eev.ee/blog/2012/04/09/php-a-fractal-
of-bad-design/](https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/)
which seems to be pretty much the point expressed by the Coursera people in
the blogpost I quoted from them.

------
eternalban
You know, this really needs to be said:

Does this company have 'adult' technical supervision or what?

------
jksmith
"Part of my frustration with Scala (and Java) was the feeling that I was never
able to get the full context on a given problem domain, due to its
complexity."

This. Same with any other kitchen sink language.

------
eternalban
And they could have just used Java from the beginning.

~~~
geodel
And how do you propose to offset the benefit of smaller image size and lower
memory usage?

~~~
eternalban
I see. Smaller image size and lower memory usage was the critical factor
informing the decsion to use Scala and not Java?

If we're talking server provisiong cost bread ($) I think factoring in the
costs of stack switch, code rewrites and salaries should be on the table too!

p.s. Have been writing Go code since the day it was released. My comment has
nothing to do with their decision du jour.

------
gbersac
If I had too move away from scala I would rather consider swift. Could anyone
help me compare those two languages ?

~~~
drhurdle
[http://hyperpolyglot.org/rust](http://hyperpolyglot.org/rust)

Here is a pretty good comparison between Rust/Swift/Scala

------
taylodl
Felix looks like an awesome programmer! :)

------
andrewvijay
Really well written. We have a similar story where we re wrote parts of our
Java code in go and the build time has reduced from 15m to 3.6m! Coffee break
to reading a small medium article.

~~~
namelezz
> the build time has reduced from 15m to 3.6m.

Is 3.6m the build time of the remained Java code, the rewritten Go code, or
both remained Java and rewritten Go code together?

~~~
andrewvijay
java ~ 3.4 mins, go - 3-4 secs :D

------
filips_rajesh
First Yammer, then LinkedIn, then Twitter, and now movio.co.

The exodus away from Scala continues.

~~~
Cyph0n
Regarding LinkedIn, they are not moving away from Scala AFAIK. And Yammer was
a long time ago. Note that Scala has improved quite a bit since then,
especially with the release of 2.12.0 (Java 8 support).

I don't understand why, but there seems to be a lot of negativity aimed
towards Scala. It's a solid language backed by the JVM, has great Java
interop, and beautifully combines OOP and FP in a way I've never seen in any
other language. Also, ScalaJS[1] is absolutely amazing.

Yet every few weeks, you get a blog post detailing why Scala is a failure and
how it will be dead in a few years. Seriously, what gives?

[1]: [https://www.scala-js.org/](https://www.scala-js.org/)

~~~
mdasen
I don't care much for language battles, but maybe I can shed some light on
this.

The former VP of Platform Eng at Twitter said in 2015, "What I would have done
differently four years ago is use Java and not used Scala as part of this
rewrite. [...] it would take an engineer two months before they're fully
productive and writing Scala code." The VP of Platform Eng at Twitter
expressed regret for the choice of Scala.

LinkedIn's SVP of Eng Kevin Scott said, "We are not getting rid of Scala at
LinkedIn. We've recently made the decision to minimize our dependence on Scala
in our next generation front end infrastructure which is rolling out this
year. We've also made a decision to focus our development infrastructure
efforts on Java 8, Javascript, Objective-C, Swift, C++, and Python given the
nature of things that we are building right now and will be building in the
foreseeable future. That said, we have a ton of Scala code running in
production, and will continue to provide basic support for Scala and those
Scala systems for the foreseeable future."

And Coda's Yammer letter is around for those to Google.

Companies don't ditch languages that they have a huge investment in. It's just
not worth it when you reach a certain level. It's not just the code to run
your services, but the huge investment in performance, tooling, and monitoring
- not to mention the bugs that come up from code that's just a little
different. Twitter is past the scale where it can ditch a language. So is
LinkedIn. But they can regret choices or decide to concentrate future
development in a different direction.

I think that Java 8 has dulled some people's enthusiasm for Scala. Java 8
comes with a lot of nice features that people _really_ missed in Java and
might choose Scala because it did have them.

But I think more generally, there's been a movement away from being enamored
with features, cleverness, and terse syntax in a language. Scala is a language
of features, cleverness, and terse syntax. I was at a presentation by Rob Pike
(one of the Go folk) and he argued that there are many things you can add to a
language that feel clever and satisfying to write, but obscure what's actually
going on and ultimately the things that are annoying, that are time sinks, and
that cause problems aren't that you had to use a loop rather than something
more clever. It was a long time ago so this is potentially more what I took
away from the presentation than Pike's sentiment.

If we look at Go, Go is boring as hell. I mean, it has one cool thing in it -
the goroutines (with cool being defined as something generally not found in
all programming languages). It doesn't even have a lot of the cool things Java
has. Java has annotations, inheritance, generics, a cool lambda syntax,
"final" immutable references, advanced codegen. . . Go doesn't even have a way
for me to declare an immutable variable. But it's so easy to pick up because
there's basically nothing unfamiliar to someone who has experience with a
mainstream, imperative language. Really, the syntax might be a bit different
and it will always take a bit to adjust to a new language, but goroutines is
really the only feature of the language that should be "new" to users (maybe
multiple return vars, but that's stretching it). It generally emphasizes the
ease of understanding and debugging over terseness of code. People seem to be
enjoying that (at least some people). Part of it might just be that when a new
philosophy comes onto the block, a lot more is written about it than gets
written about old philosophies. For example, DHH just argued that Rails' all-
in-one package is still a huge value add today, even though it doesn't get
written about as much as it did a decade ago ([https://www.quora.com/What-
makes-Rails-a-framework-worth-lea...](https://www.quora.com/What-makes-Rails-
a-framework-worth-learning-in-2017/answer/David-Heinemeier-Hansson?srid=tfS)).
It's possible that Scala's value add is as good as it once was, but the people
who found that value add useful have long since stopped blogging about it.

I haven't used Scala that much. I like that it has a repl, I like immutability
(which should be nice with Shenandoah GC), I like the fact that I can make a
basic POJO (case class) without writing a novel of private fields, getters,
setters, hash code, and equals. Scala definitely has some great parts that I
wish Java had. Scala also has some hell that can make it harder to reason
about (gratuitous operator overloading, implicits [http://yz.mit.edu/wp/true-
scala-complexity/](http://yz.mit.edu/wp/true-scala-complexity/)).

Scala also came onto the scene at a time when Java didn't look so hot. Java
5/6 era Java (2004 & 2006) just didn't support the cool FP stuff that Scala
did. Java 7 didn't come out until 2011 and still didn't have lambdas. It was
2014 before Java got a lambda. So Scala was this new language that ran on the
JVM that had features! But maybe people didn't want all the features, but
really only wanted a few of them like lambdas, streams, and the ability to
make simple POJOs/case classes (which is still missing in Java, though things
like [http://immutables.github.io/](http://immutables.github.io/) can help).
I'm sure that there are many other reasons to use Scala. I'm not trying to
argue anyone away from a language they enjoy using. The point I'm trying to
make is that for many people, they might have chosen Scala for some of these
simpler features that now mostly exist in Java. Other people might have been
enamored with how productive that Scala made them at first and later decided
that they were creating things that were harder to debug or for others to read
and understand. Still others might not have realized that everything is
terrible and there's no amazing new technology that's going to make them 100x
happier than they used to be when they actually write real programs. Don't
underestimate that last bit. Scala's been around and has plenty of people who
have used it and not created anything in a shorter amount of time or more
reliably than they had in Java, Python, or whatnot. . .but don't yet realize
that everything is terrible. I'm not saying that languages don't matter. I
think they do. Still, it's hard to find something that doesn't have huge
terrible portions that will drive you nuts on occasion.

Scala isn't as shiny and new as it once was. A new language is always awesome
before you have to debug what you write in it. Java 8 has implemented a lot of
what people thought was missing from Java. People have dulled on "magic"
(really just harder to follow code) that might be hard to discover how it
works rather than easy-to-follow code. That doesn't mean Scala is terrible or
anything, but it's advantage over Java is probably smaller for people who want
some basic FP and the zeitgeist seems to be moving against languages that are
more implicit or dynamic (regardless of whether that's happening in terms of
LOC).

~~~
pacala
Not following Java very closely and using Scala as a better Java. Is there
hope to get case-class POJOs in Java itself?

~~~
gazarullz
Project Lombok already does that, you should check it out:
[https://projectlombok.org/](https://projectlombok.org/)

