2009 I sucked it up too.<p>"Hey Java is pretty much shit and here is this new better language called Scala, which you can use with your Java ecosystem!"<p>And I was hyped!<p>But, well then I saw the actual Java ecosystem...<p>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.<p>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.<p>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. :\
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]:<p>"Why Klein Cushion Grip screwdrivers are better than Wera Kraftform screwdrivers", or in this case "The myth of using Kraftform as a better screwdriver".<p>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.<p>[1] <a href="http://blog.cnccookbook.com/2015/08/19/8-brands-to-consider-for-the-worlds-best-screwdriver/" rel="nofollow">http://blog.cnccookbook.com/2015/08/19/8-brands-to-consider-...</a>
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.
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.
Kotlin 1.1 + Reactor (<a href="http://projectreactor.io/" rel="nofollow">http://projectreactor.io/</a>) has erlang style messaging passing paradigms, world class tooling and is gradually replaceable (class-by-class) for Java.<p>It's going to be interesting comparing the adoption curves of both these languages especially after Java 9 and most importantly Graal (<a href="http://openjdk.java.net/projects/graal/" rel="nofollow">http://openjdk.java.net/projects/graal/</a>) .
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.<p>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.<p>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.<p>[1] <a href="http://www.artima.com/weblogs/viewpost.jsp?thread=260478" rel="nofollow">http://www.artima.com/weblogs/viewpost.jsp?thread=260478</a>
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.<p>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?
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.<p>It influenced my programming style a lot and I try to prefer those patterns when I use other languages as well.<p>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.
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.
I have used Scala to build the backend of <a href="https://huu.la" rel="nofollow">https://huu.la</a> 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.
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.<p>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.
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.<p>I'm sure by tomorrow someone with more time than I have will write an extensive article explaining in more detail why is better.
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.
I wouldn't characterize Scala as a better Java any more than I would Python as a better C.<p>Kotlin is a better Java.<p>Groovy is a scriptable Java.<p>Scala is a "worse Haskell" or an "extensible Swift", with close Java interoperability (that last part leading to the warts).
This post contains several wrong statements.<p>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).<p>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.<p>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.<p>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).
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.<p>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.
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...).<p>And Kotlin makes this debate irrelevant anyway.
My follow-up question would be: Is Scala still competitive to modern languages like Swift and Rust?<p>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).<p>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.
Not a myth: Kotlin is the better Java<p>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.
Admittedly biased but can't help but think this article reads like something stating that Scala is indeed a "better Java".<p>Well, perhaps not "a better Java" but at least "better than Java".
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.<p>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".<p>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)
There are at least two things more important than Scala being a cleaner Java:<p>1. The IDE
2. Oracle's claims on Java IP<p>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.
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.
Scala quicky got my favourite language. I really like handling data using functional and imutable concepts.<p>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!<p>Using scala with these and combined with akka and futures feels like a so natural way of programming for me.
Question - can I simply drop scala into an existing java based maven build? Using something like the scala-compiler plugin <a href="https://mvnrepository.com/artifact/org.scala-lang/scala-compiler/2.12.1" rel="nofollow">https://mvnrepository.com/artifact/org.scala-lang/scala-comp...</a>
> 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:<p>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".
<p><pre><code> 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.
</code></pre>
It's not really the default. It's just another reasonable choice without adding guice as a dependency.
Even the Starter templates include guice: <a href="https://github.com/playframework/play-scala-starter-example/blob/SNAPSHOT/build.sbt" rel="nofollow">https://github.com/playframework/play-scala-starter-example/...</a>
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.
I am a long time Java developer and, believe it or not, regularly write important new product features in concise, performant Java 8.<p>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.<p>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.<p>Also, my limited experience indicates that IDE support for Scala is quite behind that of Java.<p>But I am still open to it.<p>To get to my point, actually my question: Where should I look to learn quality, ideomatic Scala?<p>My preference would be to focus on small example programs that do one thing well while demonstrating the correct, native use of Scala.<p>Thank you.
The very first example is about DI and advocates MacWire to do that in Scala:<p>lazy val userDao = wire[UserDao]<p>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.<p>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.
Even though Scala might not be the answer, I still think we need a replacement for Java.<p>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.<p>I am not sure, what's going to be the solution but from my perspective Java as a language needs to be replaced.
"<i>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.</i>"<p>Um...the constructor parameters become invisible instance variables. It's not stateless.
It's not a better Java, it's a worse Java.<p>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, ...<p>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.<p>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.