13 ms·

Why we love Scala at Coursera

• bleh_ 13y ago
  I didn't know ascii architect was a job.
• fiatmoney 13y ago
  This is a thing about Scala which gives me pause: it looks like gazing into the guts of the compiler puts one on a course towards a nervous breakdown. http://www.youtube.com/watch?v=TS1lpKBMkgg http://www.youtube.com/watch?v=TS1lpKBMkgg
  • noelwelsh 13y ago
    I asked someone in the know, and apparently Paul Phillips is always like that. He has an interesting background -- was a pro poker player for a while.
    • wyuenho 13y ago
      Also happened to be the guy who wrote the most Scala code on the planet, and he quit Typesafe last year.
      • virtualwhys 13y ago
        Well, so what? Simon Marlow, Haskell's lead compiler developer in recent years, quit, leaving arguably a much larger gap than @paulp leaving Tyepsafe since SPJ is wrapped up in leading some English education initiative. Anyway, shit happens, gaps are filled. Languages, once established, are larger than any one developer, no matter how brilliant the individual may be. It's worth noting that @paulp is as active as ever in Scala, working on his new collections library and contributing to Scala now from the outside -- he may have left Typesafe but has not in anyway left Scala. As he says, he has a "sickness" for language perfection, and fortunately for we Scala users, Scala is the target of his illness ;-)
        • nousernamesleft 13y ago
          >Simon Marlow, Haskell's lead compiler developer in recent years, quit, leaving arguably a much larger gap than @paulp leaving Tyepsafe Quit what? He is still a ghc developer. He quit his job at Microsoft Research to go work at Facebook, but that doesn't seem quite comparable to quitting a job working at the official scala company on the official scala compiler.
          • virtualwhys 13y ago
            Marlow is _full-time_ at Facebook, bye bye. There's a difference between being a ghc developer and THE ghc developer. He's more of an advisor now than a committer, look at his ghc commit history, lots of comments, few commits. Not saying he's joined the dark side like Erik Meijer, but he's also not actively _working_ on the compiler as he did before; that's for the new guy(s).
            • nousernamesleft 13y ago
              >Marlow is _full-time_ at Facebook And? Before that he was full time at Microsoft. He was never an employee of any sort of official ghc company working on ghc full time. >Not saying he's joined the dark side like Erik Meijer What dark side and what is wrong with Erik?
      • singingcheese 13y ago
        > Also happened to be the guy who wrote the most Scala code on the planet I love the way he assumes that. I think he may be surprised to learn the sheer scale of some production Scala systems which aren't part of the Scala class library or compiler. Besides, he put together a list of obscure corner cases that no practicing Scala developer actually seems to care about.
        • kasey_junk 13y ago
          I think the Paul Philips stuff is both overblown by people outside of the Scala community and dismissed too freely by those inside of it. Paul has a very pessimistic world view, a very high standard of perfection and he's spent tons of time in the guts of an extremely complicated system. Listening to some of his talks it is easy to make the assumption that he thinks Scala should be nuked from orbit. On the other hand, while the ParSeqViewLike example is a bit of an inside joke (I think). It doesn't take a whole lot of doing to push the Scala collections library into weird and terrifying behaviour. I'm a practising Scala developer and I do it at least monthly. For people with experience with other better designed collections systems the Scala collections library feels heinous to use, and if you ever have to dig into the code, good luck. If the Java stream api is implemented well and has a high take up rate, I expect lots of people to come to Paul's point of view with regards to the terribleness of the standard Scala library.
          • singingcheese 13y ago
            > It doesn't take a whole lot of doing to push the Scala collections library into weird and terrifying behaviour I'm genuinely curious to see examples you've seen in production code. I've used the collections for years coding full-time and haven't encountered anything like that.
            • kasey_junk 13y ago
              An example I use a lot because it is terse: From MapLike.scala def apply(key: A): B = get(key) match { case None => default(key) case Some(value) => value } From HashMap.scala def get(key: A): Option[B] = { val e = findEntry(key) if (e eq null) None else Some(e.value) } That is to say that the default behaviour of a Scala hash map is to create a new object for every access (notice I say access, not for every insert) even when I ask it to pretty please give me the one that doesn't have the null safe Option code involved.
  • psuter 13y ago
    Please don't miss the larger point of this talk (and others by the same speaker); programming languages in general are not what they should be according to this speaker. If anything, though, he seems to agree that Scala is a good choice compared to the plausible alternatives: "At the very least, I can endorse Scala relative to the set of existing alternatives pretty strongly." "I judge things compared to what could be, and not what is. [...] It's not good enough to be the strongest of the little kids brawling when you could be the big kid next door."
    • coolsunglasses 13y ago
      Actually Haskell is quite nice and does a better job. Practical too.
      • yan 13y ago
        I'm curious, what languages do you consider impractical?
        • coolsunglasses 13y ago
          Assuming practical is some kind of bar for "I'd use this at a company where I'd be deploying the project into some kind of online production" - there are a number of experimental/research languages that are better for offline research/analysis and don't have the ecosystem Haskell has. I'm not going to mention them by name because if you don't know of them, then it doesn't matter and I don't want to slur them.
      • polymatter 13y ago
        I am a great fan of Haskell. But the tooling and libraries of the JVM is a significant real-world practical benefit. Scala can get away with a lot of nasties for that. (In fairness Scala is very well designed, nastiness is normally all to do with Java compatibility) Plus it allows Java programmers to start writing code almost immediately.
        • 13y ago
  • grey-area 13y ago
    Thanks for the link; if you can ignore the somewhat hysterical delivery, that talk is really fascinating. It's more about what a programming language should be (in his opinion) than what Scala is not. He quotes my favourite aphorism from Wittgenstein as well: The limits of my language define the limits of my world
  • wyuenho 13y ago
    Here are the slides if anyone is interested. I love the ParSeqViewLike trait on the 3rd slide. There are tons and tons of these Scala WTFs throughout the talk. It's really interesting. http://www.slideshare.net/extempore/a-scala-corrections-library http://www.slideshare.net/extempore/a-scala-corrections-libr...
  • Patient0 13y ago
    Wow that talk is an eye-opener. Thanks for the link.
  • deleted 13y ago
    [deleted]
• namelezz 13y ago
  Anyone knows when Functional Programming and Reactive Programming classes are reopen?
  • nkvoll 13y ago
    No, they haven't released any new information about them yet.
• noelwelsh 13y ago
  I think this is a nicely balanced article. Good to the see the pros and cons clearly laid out.
• hawkharris 13y ago
  My favorite quote from the article: "Python probably takes the cake for being regular. PHP gets cake in the face… Scala is somewhere in-between."
  • ChikkaChiChi 13y ago
    If you have complete control over your programmatic infrastructure and you are getting PHP 'cake in the face' you shouldn't blame PHP. You're just a shitty programmer.
    • hawkharris 13y ago
      I helped develop a PHP application used by about 30,000,000 people. It consisted of well-organized objects that followed proper design patterns. Our API was easy to use and understand. Although PHP was an effective, decent language, it wasn't the best tool for our project. It lacked certain functional features, brevity and syntactic sugar that one might find in Python. The Web is full of emotional, profanity-laden debates pitting one language against another. I don't think those are interesting or useful. But it is productive to critique the languages' relative strengths and weakness based on how they can be applied to a business problem. Like the engineer from Coursera, I determined that PHP was, indeed, a "cake in the face," considering my needs and circumstances at the time.
    • nousernamesleft 13y ago
      Yeah, for example: PHP's accidental broken support for octal numbers is definitely the fault of all the people who use PHP, not a problem with the language.
• courtf 13y ago
  All of the praise here for scala can be applied, verbatim, to Java itself. Some of the concerns are no different than Java (UTF-8), or are actually not a problem there (intellij IDE vs eclipse). While the comparison to dynamic languages is valid, this is a rather shallow discussion of scala itself.
  • hythloday 13y ago
    "Combining for-comprehensions with composable futures makes asynchronous concurrency look like straightforward synchronous code." I would really enjoy seeing this in Java.
    • courtf 13y ago
      Fair enough, the syntax is rather pleasing.
      • agumonkey 13y ago
        more than syntax, immutable functional idioms are pretty good defaults, shorter both syntactic and semantic wise
    • RyanZAG 13y ago
      Just curious, but have you used Java8 much? Or barring that, something like quasar? Qasar in particular is about writing async code as if it were sync code...
      • lmm 13y ago
        Java's future API is inadequate - you can only block on a future or poll it, not ask to be notified when it completes, so you end up needing a thread for each future which loses a lot of the benefits. I haven't used Qasar specifically but I did use other java extensions that add some scala features for a while (Lombok and the Checkers Framework). The thing is, once you're using those you're effectively using a different language ("extended java") with its own bugs - and the community for that language is much smaller than that for scala.
• sramsay 13y ago
  What is the point of articles like this? I'm not trying to be snarky; I really am trying to understand why a company would go out of its way to advertise the technology its using. Sometimes we see blog posts from devs at companies (often pretty senior) who write things like "We went with Clojure, and we've been really happy." That's clearly a geek-to-geek thing. But what is this? I mean, it's also geek-to-geek, but it's more "official." Users don't care -- they might have no idea what's even being discussed. Honestly, it's hard not to read this kind of thing as, "We had a whole bunch of meetings where we debated what language/technology/platform to use. There was bitter, acrimonious warfare, but we don't want to be a company that is about warfare, so we're writing this post that makes the case for why the people on the side of the angels won the argument."
  • NickPollard 13y ago
    For one, it's a good way to attract hires. As they mentioned, Scala developers are not as common as say, Java developers, so a post like this is a way to announce to Scala developers looking for work that Coursera is a potential employer - many people would view being able to use a language they like as a positive about a job.
    • sramsay 13y ago
      Ah, of course. And of course to crb200 below as well.
    • quicksilver03 13y ago
      I see it also as a good way to repel people hating Scala. For example, after reading this article I'm sure that I won't even try to apply for a job at Coursera: zero time wasted for both me and them.
  • mbesto 13y ago
    > I really am trying to understand why a company would go out of its way to advertise the technology its using Simple - hiring.
  • crb002 13y ago
• flurdy 13y ago
  The quote "I trust my team with this power, but can you?” resonates well with me and also why I similarly insist on removing restrictions and permissions on most tools etc. I trust my team. They are smart and reasonable people (whom are allowed to f-up sometimes). There is an unrestricted handbrake in every car, that doesn't mean people pull it unless necessary.
• ocfx 13y ago
  Isn't there ways to do lightweight concurrent programming with python still? I don't see why they chose scala over python.
• abalone 13y ago
  Weird, why say all that about how it's better than Python/PHP/etc but then not say why they chose it over Java?
  • Cless 13y ago
    They probably didn't even consider it. At least, I hope not.
  • lmm 13y ago
    I suspect most of their target audience has a dim view of Java. Also, scala's official website has the advantages over Java. (If you're asking what Scala's advantages over Java are: less verbose to read (general lack of syntactic noise, case classes, UAP), covariance/contravariance for generics, code that's much more explicit about mutability (thanks to val/var), pattern matching, more flexible syntax (particularly for/yield as used with e.g. futures), more powerful/flexible type system (e.g. the typeclass pattern))
    • abalone 13y ago
      But one of the Scala drawbacks they cite is "arcane syntax". Another one is all the "advanced features" than can "weave a tangled web of code undecipherable to even its authors". That's very much against the usual alleged benefits of Scala vs. Java that you've listed. That's why I was very interested in the article, a "real world" take on Scala that really felt doctrine-free.. but found it odd that they didn't mention anything about Java. Java would seem at first blush to solve all of the concerns they listed: compile time, arcane syntax, counterproductive advanced features, primitive IDE support, training needs. While at the same time preserving most of the benefits: type safety, concurrency with Play/Akka, JVM ecosystem. So it was just a little weird to not mention the elephant in the room.
• deleted 13y ago
  [deleted]
• mentaat 13y ago
  the whole "live reload" capability of play is a gimmick because in real life making a code change in a medium to large project is like watching grass grow - every change you make takes minutes to compile and reload.
  • atto 13y ago
    How large? We have well over 100k lines of code (Scala), and it's not a serious issue. The sbt 0.13 incremental compiler is much better than 0.12's. Also, using sbt multi-projects helps quite a bit (even when running all at once).
    • Cless 13y ago
      I hope you're right. I really do.
    • mentaat 13y ago
      much smaller - around 25k+. i gave up after becoming frustrated by the atrociously compile times. haven't used sbt .13 though but i don't expect it to solve miracles given how inherently complex the scala compiler code is. according to paul phillips, core scala committer, there are large portions of the compiler code that nobody touches because nobody understands it. and as per him this along with bunch of other limitations guarantees that you won't see huge gains in compile times unless they rewrite the whole compiler...
      • frowaway001 13y ago
        > there are large portions of the compiler code that nobody touches because nobody understands it Could you link to one of those "large portions"? > and as per him this along with bunch of other limitations guarantees that you won't see huge gains in compile times unless they rewrite the whole compiler... You mean like https://groups.google.com/forum/#!topic/scala-internals/6HL6lVLI3bQ https://groups.google.com/forum/#!topic/scala-internals/6HL6... ?
        • virtualwhys 13y ago
• mjt0229 13y ago
  It's good to see Scala getting some love after all those "i hate scala" rants (many of which seemed to be written by people who haven't spent much time with the language). We're using it at work for essentially all new development. Although I have complaints, I can't think of another language or environment that I've used that's been so satisfying and free from overall irritation. In practice, we don't get code that's unreadable, we don't wait ages for compilation, and we gain all the functional and typesafe goodness.
  • thescrewdriver 13y ago
    We've had the same experience with Scala. It's the most enjoyable language I've ever coded in. We switched away from Java for most new development a while back already. The anti-Scala rants are just confusing to us. Most of the people complaining just seem to be random non-Scala developers recycling other peoples' criticisms.
    • etrain 13y ago
      I hear Java people say "I love scala" a lot. I do not hear people coming from other environments saying this.
      • kasey_junk 13y ago
        I've come from lots of environments, and you're correct, I won't say "I love Scala". What I will say, is right now, if you are targeting the JVM there aren't any better alternatives (I believe in strong typing). Maybe someday Kotlin or Ceylon or Java 9 will be better but for now Scala is the best choice.
      • GFischer 13y ago
        It certainly does sound like a step up from Java, while retaining most (all?) of the good things. Being a "better" alternative to Java (edit: as kasey says, targeting the JVM) doesn't sound like a bad place to be :) . It's on my "to-try" list but the little development I do nowadays is on the .NET platform. Which other environments do you think would benefit from trying Scala, or are bashing Scala? C / C++ ? Node? Edit2: it seems Ruby or Python people wouldn't like Scala. Me, I like static typing.
• wilsonfiifi 13y ago
  It would be interesting to read a similar article from a company that uses python as their core programming language (Dropbox for instance) to contrast it with this one. Python might not be as popular as Java but I was under the impression that it offered a rich enough platform/ecosystem to accommodate for a wide spectrum of software projects. Concerning the issue of type checking, I understand that it's great to have a compiler that can take care of that for you but I'm pretty sure unit-tests and a bit more care also goes a long way when using a scripting language like Python; besides how hard can it be to sprinkle a bit of "type(<object>) is" in your code where type checking is required? (smile) I wonder if vert.x was also considered. I don't see any mention of it in the article.
  • lgieron 13y ago
    I'd say having automatic compile-time checks and vs having to be "extra careful" + necessity for more umit tests is a world of difference. AFAIK, Google doesn't use dynamic-typed languages for any of its projects (except where their hand was forced - they inherited the codebase in an acquisition) and they sure as hell are experienced in large-scale software development (for small to medium projects, the drawbacks of python etc. aren't as apparent).
    • okaram 13y ago
      I'm not sure what you consider google 'projects'; from what I heard, a lot of their 'sysadmin' type of scripting is in python (probably moving to go now)
      • lgieron 13y ago
        By "projects" I mean code delivering actual software products (like for example the search, gmail etc.), not some auxiliary admin scripts.
  • CmonDev 13y ago
    "pretty sure unit-tests and a bit more care" - it's better to focus on unit-testing behaviour and care about things that need human's input though. "where type checking is required" - it's better to single out cases where it is not required, this is how it's done in C# for example - quite useful for integration with other ecosystems.
• _pmf_ 13y ago
  > Scala’s compiler is very sophisticated–it runs over 25 phases Sophisticated is not the first term that comes to mind.
• CmonDev 13y ago
  "Refactoring a statically typed language is easier than refactoring an interpreted one ... even Python is a difficult chore that engineers shy away from because modifications are likely to create more bugs than they fix." Well said, I think refactoring being "fun" is more important then coding being "fun" for projects that are not a piece of throw-away code (unlike data analysis for example).
• markbao 13y ago
  From an experience standpoint, isn't the fact that you'd have to teach people a new language coming in the door detrimental to the use of that language? Comparing a company that takes in people that have been coding Ruby/Python/Java/whatever for 5+ years, versus one that takes in people that don't have Scala experience but teaches them on the job, wouldn't the former move faster and generally have more experience, making it better to hire from a large pool of experienced people (in a popular language) than a small pool (in a more niche language)? This, of course, assumes (rightfully, I think) that the "carryover" effects of programming experience aren't substantial enough to claim that 1 month of Scala experience is better than 3 years of Ruby experience, and nor is the "advantage" that Scala gives over these more popular languages (real or imagined). I love Coursera and all, but I'm curious what people think about this.
  • tieTYT 13y ago
    I think you're right in the short term, but long term you may be more productive with Scala. -Devil's Advocate.
    • markbao 13y ago
      I agree and disagree. The inherent qualities of a more recent language (especially one like Scala which seems to be built upon a good foundation) may make a team more productive in the long term despite the initial cost. However, what also counts in the long term is the structure of the codebase, and I'd argue that people with more experience in a language are better suited to build more long-term-viable codebases with less technical debt just because they know the language better. But perhaps that's simplistic.
  • NickPollard 13y ago
    Teaching someone a programming language (e.g. Scala) is not equivalent to teaching someone to program. If you take someone who has 5 years Ruby/Python/Java experience, and then spend a month teaching them Scala, they don't miraculously forget everything they know about functions, algorithms, data structures, encapsulation, interfaces, problem-solving, maths, etc. I started my current job (at a Financial Institution where I write 99% Scala) with no Scala knowledge, but good programming fundamentals and experience with functional programming. A month later, I was a competent Scala programmer. This isn't unique to Scala - if you have a language you like, which you think offers advantages over the competition, then it is worth training people to use it and then using it.
• brown9-2 13y ago
  The quote about refactoring ease in Scala is interesting, since I imagine the experience would be the same in plain old Java - refactoring in any statically typed language is much easier when you are comparing to PHP, Python and Javascript.
  • kasey_junk 13y ago
    In fact it is a little dishonest. Refactoring in Scala is considerably worse than refactoring in Java due to the complexity of the language.
    • brown9-2 13y ago
      True, I'm curious what (if any) IDE the quote-author is using for refactoring. Or perhaps they are just referring to the simplicity of something like being able to rename/edit a method signature and have the compiler catch all the references to the old name immediately.
• enjo 13y ago
  "Refactoring a statically typed language is easier than refactoring an interpreted one; modifying existing PHP, and even Python, is a difficult chore that engineers shy away from because modifications are likely to create more bugs than they fix." Over the years I've worked pretty deeply with both static (C++/Java/Scala) and dynamic languages (Python/Ruby). I simply don't agree. The biggest thing that contributes to refactorability has nothing to do with type safety. Instead unit test coverage, by a mile, is the thing that makes code easy to refactor. In my experience issues of type safety are rare. The same types of bugs are going to crop up in Scala, Python, Java, or even Fortran unless you have tests to help you discover those issues. I've long felt that type safety is largely a solution to a problem that doesn't really exist. Not in a hugely meaningful way at least. Logic errors are generally independent of type issues, and as such it is code quality and unit test coverage, more than any specific language feature, that lead to highly flexible (and therefore refactorable) code.
  • NickPollard 13y ago
    > The biggest thing that contributes to refactorability has nothing to do with type safety. Instead unit test coverage, by a mile, is the thing that makes code easy to refactor Type Safety is Unit Test Coverage. Typing is a statically checked test of correctness of your program. Languages like C give static typing a bad name. Types are not things like 'float', 'int', 'double'. Types are 'degrees', or 'radians'. Types are 'buy', or 'sell', 'price' or 'yield'. Types guarantee that your code executes as you expect, and prevent you from writing incorrect code in the first place. Is it 100% effective? No. But there's a reason that high level statically typed languages (Scala, Haskell, OCaml) usually work correctly after they compile.
    • brandonbloom 13y ago
      > usually work correctly after they compile I still don't buy in to this trope. Q: What is true of every single bug in production? A: It passed both your type checker and your tests.
      • NickPollard 13y ago
• ChikkaChiChi 13y ago
  I enjoyed this article because it stated without a whole lot of bias why Scala was the right tool for the job. Python could have fulfilled some of the requirements such as the lighter concurrency; however it would have come at the expense of the ease of deployment. I disagree with type safety being integral to refactoring, but each team has their own culture and this seems to fit theirs well.
• donjigweed 13y ago
  Good to see some love for Scala after all the recent rants. Unfortunately, I think it's going to be short lived. Most shops where Scala would be an option will soon have a production release of JDK8 available to them, at which point Scala's tradeoffs really only become acceptable to those who already have significant investment in the language or who think category theory is a reasonable companion to an industrial language.
  • singingcheese 13y ago
    Java 8 would make a very poor Scala substitute, and only offers a small subset of what is provided by Scala.
  • kasey_junk 13y ago
    JDK8 is a very nice release and I hope it will bring Java a few years ahead, but there are so many things still missing from Java that every time I shriek. From big things like no type class support to tiny things like 1 file per interface/class the Java experience continues to be frustrating in the extreme.
    • donjigweed 13y ago
      Which is why I said "Scala's tradeoffs" would become unacceptable. Java 8 is basically "close enough" to "The Good Parts" of Scala that most people probably won't be willing to tolerate all of Scala's warts.
      • frowaway001 13y ago
        > Java 8 is basically "close enough" to "The Good Parts" of Scala Ehh ... not really. And I honestly don't see the gap between Java and Scala closing. It's widening at a frightening rate. Java's warts are far worse than Scala's warts. So I'm not seeing why that should be a point either.
• dmunoz 13y ago
  I enjoyed reading this article, but does anyone who doesn't already understand what they're saying understand after reading something like: "Play's reactive core and asynchronous libraries (e.g. WS) integrate seamlessly with other powerful concurrency primitives in the ecosystem such as Akka’s actors. Combining for-comprehensions with composable futures makes asynchronous concurrency look like straightforward synchronous code." I get the gist, but I had to go and search for what for-comprehensions were. According to [0], they're a syntactic sugar over map. Then, if I search for composable futures (I know those words separately, but can only guess about them used together) I seem to only get results for Akka 2.0. The first result I click on is for a 167 page book for $23 USD. Maybe that is my fault, as the first result is actually to Akka documentation, but when I click there there is no mention of the word composable. The next two links are to slides of a presentation by the author of the first link I mentioned, and then to a video of the presentation. The fourth is to an early access of the same book, the next a blogspam to the video presentation. I gave up here. For an article that is arguing for scala in comparison to PHP, Python, and Go, I didn't walk away with anything more than "sounds nice, but is it really?" Code example would've helped. [0] http://tataryn.net/2011/10/whats-in-a-scala-for-comprehension/ http://tataryn.net/2011/10/whats-in-a-scala-for-comprehensio... Edit: Calling it "an article that is arguing for scala in comparison to PHP, Python, and Go" is a misrepresentation. It's really just about why they like scala, but they do do plenty of hand-wavy comparisons with other languages. Edit 2: Okay, I see the Akka documentation does have a section "Composing Futures" that I missed.
  • singingcheese 13y ago
    It made perfect sense to me, perhaps because I code in Scala for a living (even though I don't use either Akka or Play (yet)). It reminds me of the old comment about how unreadable French is because it looks nothing like English.
    • Sharlin 13y ago
      I don't think the target audience of the blog post was experienced Scala developers (that would just be preaching to the choir!) so the use of unexplained jargon should be kept at minimum to actually reach the audience.
• nnq 13y ago
  > Refactoring a statically typed language is easier than refactoring an interpreted one Compiled vs interpreted is very different than dynamically typed vs statically type! Yes, I can't name any statically typed language that is interpreted (or that has an interpreter actually used in production, to be more exact), but we're still talking about different things. I guess this is some kind o "semantic typo", but... really? Am I supposed to trust the opinion of whoever wrote this?!
• jsmith0295 13y ago
  I think they really love it because they have plenty of time to take courses online while they wait for their Scala code to build.
• hit8run 13y ago
  I've used them all: PHP, Ruby, Java, Scala, Node and Python. I'll stick to Python because the syntax is awesome and it's easy to read. Scala looks so weird to me. If I was really dependent on the JVM (which is indeed a great environment) I would honestly just stick to Java and enjoy the superior IDE support compared to scala.