24 ms·

The myth of using Scala as a better Java

• rco8786 10y ago
  Admittedly biased but can't help but think this article reads like something stating that Scala is indeed a "better Java". Well, perhaps not "a better Java" but at least "better than Java".
  • inlined 10y ago
    That seems to be the point. Proper or idiomatic scala code uses tools only available to scala. I used scala for a while. It has some neat tricks that I grew to like, but I think it ultimately had a problem I noticed in Ruby: there are many "right" ways to do things and each team has its own culture. This makes learning foreign codebase pretty hard--especially with how dense scala code is.
• deleted 10y ago
  [deleted]
• sandGorgon 10y ago
  Kotlin 1.1 + Reactor (http://projectreactor.io/ http://projectreactor.io/) has erlang style messaging passing paradigms, world class tooling and is gradually replaceable (class-by-class) for Java. It's going to be interesting comparing the adoption curves of both these languages especially after Java 9 and most importantly Graal (http://openjdk.java.net/projects/graal/ http://openjdk.java.net/projects/graal/) .
  • pmarreck 10y ago
    > erlang style messaging passing paradigms Or you could, you know, go directly to the source while experiencing a pretty nice language on its own http://elixir-lang.org/ http://elixir-lang.org/
    • hnbroseph 10y ago
      elixir is for rubyists, really. dynamnic typing.
      • pmarreck 10y ago
        Guards, pattern-matching (even down to the structural level) and typespecs cover a lot of the ground that static typing would, without forcing the type rigidity. Although Haskell seems to have admittedly cornered the static typing market
  • gregpardo 10y ago
    Wow this is cool. I always preferred Kotlin to Scala and have used it for Android dev. It was extremely easy to get it working compared to writing an app in Scala and the language was more similar with a modern syntax. This project looks neat and if you had to use JVM tools but wanted some of the benefits of Erlang style development I could see it being a perfect fit.
• scalatohaskell 10y ago
  Ive used Scala as both "better java" and as "worse-haskell" in two different teams. Both times it was much more pleasant than doing Java.
  • godmodus 10y ago
    Here here. Im new to scala and I love it. Also sbt > maven!
    • xxs 10y ago
      it's "hear, hear". The expression Comes from the English Parliament back in the 17th century.
      • m3talridl3y 10y ago
        Now the really puzzling question is: How would someone learn about this particular saying without seeing it in writing? Are there actually people still using "hear hear" in everyday speech?
        • blowski 10y ago
          The British Parliament still uses it frequently, as does my Grandad. It means "Hear Him!" as in "Listen to this guy, because he's right".
          • broodbucket 10y ago
            It's used in Australian parliament too.
        • gozur88 10y ago
          I've heard it in everyday speech, yes. I always assumed people pick it up from reading it, though.
        • godmodus 10y ago
          Ironically, I've have an English bachelors degree,and I've never seen it in writing before, till now! Language is active learning. There's no real way to avoiding these pitfalls, besides reading and engaging with others. I'm OK with it aslong as those offering corrections do it kindly. I've learned German, too. German is 'difficult', not because of its grammar, but because how mistakes are handled. Which is often with harsh commentary, ridicule or confusion. Not sure why that is the case, but English speakers are often kinder when offering corrections!
• jwatte 10y ago
  The only data layer for Scala that matters is Spark and Data frame.
  • trengrj 10y ago
    To be pedantic in Spark 2.0 it is now Dataset. DataFrame is now an alias for Dataset[Row].
• partycoder 10y ago
  What appeals to me about Scala is that is expressive and concise. It also encourages some healthy patterns like such as making distinctions between mutable and immutable containers, using futures/promises for asynchronous functions, using option types to prevent null pointer exceptions and many many others. It influenced my programming style a lot and I try to prefer those patterns when I use other languages as well. Some people like more advanced aspects of Scala, and like to flirt with category theory and hardcore functional stuff. Personally I find it hard to express myself in terms of higher order kinds, monoids, functors, semigroups and such. You can learn them but it's a bit like switching from qwerty to dvorak... if you have to look at the keyboard each time it doesn't make things simpler for you.
• divanvisagie 10y ago
  Is The Scala Evangelism Task Force back in action? I'm game.
• jankotek 10y ago
  It is also about tooling and libraries. I find Scala ecosystem to be behind Java ecosystem couple of years (SBT versus Maven/Ant/Gradle, collection libraries...). And Kotlin makes this debate irrelevant anyway.
  • WaxProlix 10y ago
    That's completely not true because Kotlin has something near zero adoption. I have a Kotlin fanatic coworker so I know all about the manifold benefits of Kotlin -- it sounds awesome. Never had a project OK'd to use it, probably never will. They obviously need a PR and marketing department; otherwise they end up being the CouchDB to XYZ's Mongo.
    • jankotek 10y ago
      I usually hava Scala/Java debate before new project (or refactoring) is started. And here is Kotlin relevant. Kotlin is bundled with Intellij Idea. And Kotlin has smaller adoption barrier.
      • WaxProlix 10y ago
        If you work with other teams, especially onprem or offshore teams, they use netbeans or some other piece of shit IDE. It's just a fact. They know J7, can be convinced to try J8, once read a blog that mentioned Scala, and don't know what the fuck Kotlin is.
        • curun1r 10y ago
          On the other hand, if you decide to use Kotlin, you'll post a job listing, get only a handful of candidates, and nearly all of them will be outstanding and the type of curious, driven engineer that you'd normally have to sift through a mountain of dime-a-dozen, uninspired Java hacks to find. It's not until you've had to hire Java devs that the mystery of why so many people feel the need to ask a question as facile as FizzBuzz becomes clear.
      • 10y ago
• stephen123 10y ago
  Nice examples!
• itaysk 10y ago
  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.
  • lcw 10y ago
    I agree it doesn't have strong opinions and every developer has a different flavor of writing it making it difficult to code review without a ton of personal opinion type comments. That said it is a fun language because of how flexible it is too. It just, at times, does not seem practical for projects that have a ton of hands on them compared to other more opinionated languages.
  • gozur88 10y ago
    That was exactly my experience. Great hobby language. Not what I want to use on a professional team with a mix of capabilities.
  • jshmrsn 10y ago
    As others have mentioned in top-level comments, definitely give Kotlin a try, as it is specifically designed in response to your conclusion about Scala. I've been using Kotlin full-time for over a year, and I've really enjoyed it.
  • TeMPOraL 10y ago
    My impressions after a month spending working in it were somewhat similar. But it's not that there's much to learn (a necessary thing in a powerful tool) - it's that after that month, the language still felt like a totally inconsistent mix of every feature they could find in other languages (beside maybe sane macros, conditions and call/cc). I suppose, though, that after spending enough time immersed in a language, even such inconsistency stops being a real obstacle to anything.
    • oelang 10y ago
• manis404 10y ago
  wow the author is retarded. Scala is definitely a better Java
• keypusher 10y ago
  Kotlin is a better Java. Scala is just something else.
• yousry 10y ago
  My follow-up question would be: Is Scala still competitive to modern languages like Swift and Rust? I experienced several drawback according to library quality and code-safety. There are too many small details that left me with an unpleasant feeling (I would take ScalaNLP/Breeze for example). But my central issue is the VM/GC dependency. In times of GPU computing, native interface programming becomes a burden. The knowledge of object ownership improves code readability. I feel uncomfortable leaving object lifetime to a background process.
  • nvarsj 10y ago
    > Is Scala still competitive to modern languages like Swift and Rust? Of course it is... swift is a mobile PL, and Rust is barely used non-academically (and also takes a long time to be productive in). Scala let's java devs immediately hit the ground running, for better or worse, and it's hugely popular in the real world.
  • divanvisagie 10y ago
    It depends how you define "competitive". If you are trying to collect hipster points then Scala is not going to help you but let's be real. Nobody is writing big systems in either Rust or Swift, these are playgrounds for people at the moment.
    • bontoJR 10y ago
      I am big fan of Swift and Scala... and, to be honest, for Swift there's a long way ahead before a big system can be deployed... tooling and libs are not there, also not considering that the lack of ABI stability makes the source code necessary for any external dependency.
  • yellowapple 10y ago
    I don't think Scala's really comparable to Swift, and it certainly is not to Rust. Use the right tool for the right job.
• laichzeit0 10y ago
  After doing this shit professionally for more years than I could care for anymore, when I see programming language or framework comparisons I immediately think of something like[1]: "Why Klein Cushion Grip screwdrivers are better than Wera Kraftform screwdrivers", or in this case "The myth of using Kraftform as a better screwdriver". And then I imagine myself going back to using my shitty old Phillips screwdriver set to screw in a few screws in a non-optimal fashion and someone might say "Wow, thanks for hanging my door!" and I imagine the surprise on my face as I realize that people want functioning doors and are not too bothered about which brand of screwdriver was used to achieve that. [1] http://blog.cnccookbook.com/2015/08/19/8-brands-to-consider-for-the-worlds-best-screwdriver/ http://blog.cnccookbook.com/2015/08/19/8-brands-to-consider-...
  • lumpypua 10y ago
    To counter with an alternative tool comparison: drills and impact drivers look very similar. I'd bet that most of my friends don't really know the difference. But for some situations, an impact driver is an entirely more capable tool. If you use a drill all day, professionally, you'd be a fool not to take a serious look at an impact driver and see if it makes your life easier.
    • timc3 10y ago
      I don’t think using different tools (which a drill and impact driver really is) is what the OP mean’t. He was more along the lines that must people don’t care whether you picked a Bosch impact driver or a DeWalt impact driver to fix their problem. And if you explain to someone the difference, they usually get it. Even my daughter when she was five could understand why I had two similar looking things when I was working with them..
      • azernik 10y ago
        But, again - if you're the person using those tools, you care about the difference. The difference in reliability, usability, power, whatever.
      • 10y ago
• huula 10y ago
  I have used Scala to build the backend of https://huu.la https://huu.la for years, which is not a small codebase anymore, I love the language itself, it's fast, typesafe, productive, and gives access to the rich Java ecosystem. The only thing I dislike is the tooling, especially whenever I open eclipse, the fan just screams to hell and it's still slow as a snail.
  • wrkronmiller 10y ago
    Have you tried using IntelliJ?
    • coding123 10y ago
      Totally agree, time and again, I see people use Eclipse (for pretty much anything) would be ten times better off in IDEA.
  • deleted 10y ago
    [deleted]
  • tutanchamun 10y ago
    You should definitely give Jetbrains free community edition of Intellij Idea together with the scala plugin a try. [0] It feels much better to use than Eclipse. [0] https://www.jetbrains.com/idea/features/editions_comparison_matrix.html https://www.jetbrains.com/idea/features/editions_comparison_...
• mk89 10y ago
  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.
  • bontoJR 10y ago
    It was 22 fields and the problem was not serializing/deserializing, but it was a problem with the Scala functions and tuples system not supporting case classes with more than 21 fields. This limitation has been removed since Scala 2.11.
  • diamondo25 10y ago
    As asked (and answered) here[0], it used to be a Scala case class limitation. There are tricks to do it anyway, like manually mapping fields by writing your own JsReads or JsWrites for your object. [0] http://stackoverflow.com/questions/20258417/how-to-get-around-the-scala-case-class-limit-of-22-fields http://stackoverflow.com/questions/20258417/how-to-get-aroun...
• pents90 10y ago
  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.
  • pierrehenrit 10y ago
    Actually not true. If you love making software you will probably use Scala without its esoteric features (for the better, imho) and you have a powerful and useful tool, yet very pleasant to work with.
    • watwut 10y ago
      If you are writing code alone, yes. If you are trying to decipher a lot of code somebody else created, not so much.
      • pierrehenrit 10y ago
        The point I was trying to make is that it does not have to be cryptic at all! I worked on a play app where it was really easy to go around and even JS front-end developers made small contributions. Maybe some teams need to set up rules, or do more code reviews idk.
        • watwut 10y ago
          Every teams ends up with different subset of features through. When you take over after different team with different culture, the deciphering problem gets back. Also, through I did not seen it in Scala but in different language, the part of coding I personally enjoy the least was the prolonged fight over which features are going to be used with code reviews being primary tool to force other team members into submission. Seriously, I like following team standards, but new rules suddenly appearing during code review were pretty annoying - giving me a choice between not meeting deadline and following other dude random opinions whether I agree with them or not.
  • nvarsj 10y ago
• balamaci 10y ago
  "STOP STOP, It's already dead"
• misja111 10y ago
  The very first example is about DI and advocates MacWire to do that in Scala: lazy val userDao = wire[UserDao] I come from Java and when I moved to Scala I wanted to use DI to mock dependencies in my unit tests. The logical choice for DI seemed to be MacWire, however it did not help me with the mocking at all. In Java you have Mockito and annotations such as @InjectMocks that inject all your mocks into your SUT automagically. In Scala, regardless if I used MacWire or not, I had to override my SUT's implementation and its dependent fields by myself, or use constructors that take all the dependencies as arguments so I could override them in my tests. Luckily this is much easier in Scala than in Java, but to me MacWire was a disappointment.
  • tutanchamun 10y ago
    You could also just use Google Guice (but you would loose compile time safety) like playframework. Maybe you like that better than MacWire?
  • caoilte 10y ago
    Eventually you learn not to need mocks. It's a long road though. An important first step is making your dependencies very very simple functions that are trivial to define on the fly.
    • misja111 10y ago
      Yes I agree, in Scala mocks are not as useful as in Java and the Scala language has some features that make it easier to work around them. However what I don't understand is what is so great about MacWire. Maybe I'm missing something but I always believed that the main advantage of a DI framework was that it facilitated mocking. If this is not needed in Scala, then what is so great about MacWire?
      • caoilte 10y ago
        You're right. The biggest thing that DI frameworks have historically done for me is make mock injection easier. There are other benefits, however. - Manual wiring generally has quite a lot of boiler plate (even in Scala, especially if you use free monads) - DI frameworks enforce a pattern of behaviour. This can be especially helpful when navigating a project. Having said that, whether these benefits are worth the cost of a DI framework is debatable. My current weapon of choice is FreeK...
• Zigurd 10y ago
  There are at least two things more important than Scala being a cleaner Java: 1. The IDE 2. Oracle's claims on Java IP A good IDE is more important than Java being verbose, and the only way Scala will displace Java is if Oracle win suits and makes Java expensive to use.
• julian_1 10y ago
  Question - can I simply drop scala into an existing java based maven build? Using something like the scala-compiler plugin https://mvnrepository.com/artifact/org.scala-lang/scala-compiler/2.12.1 https://mvnrepository.com/artifact/org.scala-lang/scala-comp...
  • simsla 10y ago
    Scala is compiled against the jvm, so you're able to e.g. compile a scala jar and call it directly from java. A couple of caveats, though. - collections are different. You'll need to use helpers from JavaConversions, etc. to e.g. turn a Scala list into a Java list. - scala methods with default arguments are irritating to call from java. - avoid the more esoteric scala features
• edem 10y ago
  You might want to try Kotlin which is basically just a Turbo Java without the baroque fluff Scala brings to the table.
• creyer 10y ago
  What "better java" means? It means I can build the same stuff but in a better way. Easier to read, to maintain, and at least with the same performance. Scala has a big plus on asynchronicity, but the article doesn't even try to go there. Libraries like Akka, FS2, Monix, ScalaZ etc are not mentioned either. In Scala I can use everything from Java and much more, and this is why is better. I'm sure by tomorrow someone with more time than I have will write an extensive article explaining in more detail why is better.
  • hocuspocus 10y ago
    > In Scala I can use everything from Java and much more, and this is why is better. You can use everything but it's not always very nice. For instance one of my biggest source of frustration is dealing with XML and SOAP (yes I know...) Scalaxb is good but limited, and using Java libraries means dealing with Java POJOs. I can definitely see Kotlin's potential in the "perfect Java interop" space. That said, I agree with you, and I enjoy those high-level libraries too much to switch back to a less powerful language.
  • eloisant 10y ago
    A "better Java" means keeping the same concepts and paradigms as Java, but fixing some of the design issues. That's what Kotlin is. Scala on the other hand is a completely different beast, but some people use is as "a better Java" because it doesn't force you into its paradigms. You can code in Scala without using case class, with var everywhere, etc. It can be handy to fallback to "Java style" when you don't know how to do it in idiomatic Scala, but at the end of the day if you don't want to embrace the key paradigms of Scala it's better to use a different language.
• cygned 10y ago
  Even though Scala might not be the answer, I still think we need a replacement for Java. All the Java enterprise projects I know suffer from the same problems; incredible complex project structures, a lot of "dead code" (e.g. empty Java interfaces), XML, money being burned for engineers fighting with Tomcat or Glassfish, slow database operations because of an ORM centric development and so on. I am not sure, what's going to be the solution but from my perspective Java as a language needs to be replaced.
  • TeMPOraL 10y ago
    Java 8 is much better for programmer's sanity. If you could force people to jump to that, and completely burn down some areas of the ecosystem (like XML overuse), maybe Java could actually be saved. Alas, I think backtracking on parts of the ecosystem is a hard thing, and I don't see it happening soon.
    • cygned 10y ago
      I'd say, in the end it comes down to two problems; Java's verbosity and the fact, that a lot of frameworks do "magic", things happen without explcitely asking for it (the JPA is a nice example for that).
    • TeMPOraL 10y ago
      Adding: I was messaged by someone who interpreted my comment as if I was saying "Java 8 is better than Scala". That's not what I meant. I mean that with Java 7 and 8, Java the language is more bearable than it was in the past, so Java the language is in less dire need of being replaced by something else.
  • allengeorge 10y ago
    I thought Go was the replacement for Java.
    • hnbroseph 10y ago
      did you write a bunch of go?
• merb 10y ago
  Not surprisingly, this approach has become very popular in recent years and made the Play team consider promoting it as the default in the upcoming version of the framework. It's not really the default. It's just another reasonable choice without adding guice as a dependency. Even the Starter templates include guice: https://github.com/playframework/play-scala-starter-example/blob/SNAPSHOT/build.sbt https://github.com/playframework/play-scala-starter-example/... 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.
• throwawayish 10y ago
  Not a myth: Kotlin is the better Java Although Kotlin does have a lot of stuff that technically allows to write weird code, most of that (eg. extensions) is around for better interfacing with Java, and normally not used in pure K code.
• kuschku 10y ago
  This post contains several wrong statements. First, Java does support macros – you can use Annotation Processors normally (as Butterknife, Dagger, and other projects do), or you can use Annotation Processors to actually get the AST and modify it (not supported officially, but used by projects like Lombok). Second, Java has no type classes – this is technically true, but not exactly. The mentioned example can also be handled with Java 8’s interfaces, as they support default methods and private or protected methods. Due to that, you can define a method instead of the writes() field, and then use an interface-defined default method to handle actual serialization. If combined with Annotation Processing, this allows easy, simple, compile-time generation of JSON serialization (and yes, I’ve written stuff like this before, so I know it’s actually usable, and not too complicated).
• k__ 10y ago
  2009 I sucked it up too. "Hey Java is pretty much shit and here is this new better language called Scala, which you can use with your Java ecosystem!" And I was hyped! But, well then I saw the actual Java ecosystem... Java itself is a pretty clunky language, especially for people like me, who did scripting language programming all the time and are probably not considered Real-Developers-TM to the Java folk. So the ideas of Scala resonated with me pretty much. Anyway, after trying to configure stuff like Kafka, Zookeeper and Maven and setting up a SOAP API, I saw that the problem with Java isn't the language. Yes it's ugly, but JavaScript is ugly too, well even Python has its ugly parts. The problem also isn't performance, like so many C devs cry about daily. The problem seems to be that Java devs like to create things more complex than they need to be. Conglomerates of XML files, layers on layers on layers... I just don't know anymore. I didn't use Scala for long and it wasn't because it failed me, it did, it brought its own complexity with implicit conversions and overloaded operators etc. but that wasn't the reason, it was the ecosystem which usage Scala enabled, the ecosystem that felt like it was still stuck in pre 2000. :\
  • nolok 10y ago
    Thinking of it, SOAP is the most Java-like thing taken to the extreme that I can think off. Needlessly complex, dozens of imbricated layers that no one knows why they even exist, cult of "the library and server will do it for you, you don't need to know how that works", and when the library invariably fail on some obvious stuff you're left hanging with inscrutable XML files and no decent way to debug the exact layer that fails, with every thread mentioning that issue on the web being met by a variation of "you shouldn't be doing that" or "add this additionnal middleware layer to solve it" All of that to send two ints and get one back.
    • k__ 10y ago
      Hehe, yes. I had to write a SOAP endpoint last week, because the dev in the other company didn't like REST. It was just one endpoint, that took a set of values. Took me a few days to get the WSDL right, because no good examples or tutorials were to be found... In the end it took me 80% of the time to figure out that I had a wrong XMLSchema version used to define my types. Only some heavy XML IDE found this bug, all validators just told me that I didn't define any types, haha... well at least I learned something in the process :)
• Fiahil 10y ago
  Yeah, Scala is not a better Java. And Scala is still a very young language. With a lot of interesting features, yes, but also a _LOT_ of backward and broken things. Have you tried to serialize something to JSON ? Yes ? Which one of the _TWELVE_ libraries did you use ? Need to compile something ? You can take a coffee break. You defined a `unary_-` function ? I'm sorry you can't search your code to locate the calls.
  • paulddraper 10y ago
    Scala grew up in a different time then Java. Have you tried to serialize something to XML in Java? Which of the fifteen libraries did you use?
• paulddraper 10y ago
  I wouldn't characterize Scala as a better Java any more than I would Python as a better C. Kotlin is a better Java. Groovy is a scriptable Java. Scala is a "worse Haskell" or an "extensible Swift", with close Java interoperability (that last part leading to the warts).
  • bad_user 10y ago
    > Scala as a better Java any more than I would Python as a better C The difference between Python and C is huge because C is not interpreted and doesn't do automatic memory management, which is actually the deal breaker for many apps. Saying that such a difference exists between Scala and Java is simply wrong. It's wrong starting from the fact that both are garbage collected, running on top of the same VM, having the same performance and thus targeting the same application profiles. > Scala is maybe a "worse Haskell", with extensive Java interoperability Haskell is a language I like and that I'm in the process of grokking, being a continuous inspiration, but to tell you the truth, to the contrary I think Haskell is a less practical Scala. Scala follows the pragmatism of the ML family. OCaml is another pragmatic language. Clojure and Racket are too. Empirically speaking, Haskell is good at being a trend setter in the FP community, but besides really cool libraries and concepts, I don't see much in the way of applications built by Haskell folks. Some big companies have built complex systems on top of Scala, not to mention projects like Kafka and Spark, which can also credit Java and the JVM. For OCaml, even with a much smaller community than both Scala and Haskell, you have some really cool stuff like MirageOS. What does Haskell have to show for, besides badly documented libraries and compiler implementations? Don't get me wrong, correlation does not imply causation, maybe Haskell simply has a popularity problem, but the onus is on the Haskell community to prove that Scala, OCaml and others are inferior alternatives to Haskell by showing some results. Because at the end of the day it's the final artifacts that really matter.
    • myth_drannon 10y ago
      Elm compiler is written in Haskell.
    • pmilot 10y ago
• sreque 10y ago
  As someone who is currently having to deal with a monolithic Java app built on spring, hibernate, aspect weaving, code drenched in null checks, and other questionable architecture choices, this article makes me want to switch to Scala, and the reasons are mainly community, not programming language. I think you could do a lot of the above In Java although the code would be a little boiler-platey. But why do people care about boiler plate so much? Hasn't GoLang shown us that boilerplate is not our greatest enemy?
  • paulddraper 10y ago
    The nice thing is that you can choose the language and "community" independently. Scala with Spring or Java with Play. You can usually mix and match Java and Scala source code easily. Kind of like C and C++.
    • dsacco 10y ago
      This has not been my experience in practice, but it has been my experience that people say this can be done theoretically. I worked at a company where most of the backend was in Java and Scala. There was this platonic ideal of Scala for the usually stated reasons, but what actually happened was weird, half-implemented Scala with Java that was necessary to take it the rest of the way on pretty much every microservice. It never really felt like Scala stood on its own weight without requiring 20% of the solution in Java. That bifurcation ended up making the maintenance sort of a pain. I don't currently work with Scala (sometimes Java), but I would be interested in hearing some tips from you on how to make Scala more of a first class citizen and stand on its own weight.
      • paulddraper 10y ago
        Well, my practical experience is that writing in Scala is so much more enjoyable, it eventually becomes 100% Scala.
  • dustingetz 10y ago
    It's not the boilerplate. When you take some of the best java developers on the planet, after a couple years you end up with a AbstractSingletonProxyFactoryBean, so what is a mere mortal supposed to end up with? Evolve any Java codebase for N years and the result is the same. http://docs.spring.io/spring-framework/docs/2.5.x/api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html http://docs.spring.io/spring-framework/docs/2.5.x/api/org/sp... You could also make a similar argument for Scala. Not boilerplate, but other problems. There are some epic scala flamewars out there. A mortal could be forgiven for looking at an "idiomatic" scala codebase and scratching their head, looking at all this higher order "stuff" and wondering, "but where is the actual code, that does the actual thing?" And I'm not sure there exists a human on the planet who knows what idiomatic scala is. The whole point of the language was to make some impossible compromises, and as such you can kind of feel forces inside the language in tension with itself, not in alignment. Perhaps FP and OOP are not meant to be unified.
• cdegroot 10y ago
  I once drank the Scala cool-aid as well. Even wrote an enthusiastic article about it [1]. Since then, my enthusiasm has been replaced by disappointment: the JVM interop is a lie, as Java libraries often are a bad fit, people won't have time to write the extensive wrapper code needed to hide it, and as a result ugliness starts permeating your codebase - yes, bad, but that's how teams under time pressure work; the multi-paradigm-and-widening (back in 2009, Scala was a smaller language) is one big headache - everyone has an opinion of how you should write code in Scala, so inevitably you spend a lot of time debating features you should or shouldn't use in your teams (instead of writing code. In Elixir, we never have to debate paradigms, we write code); sbt is a sorry mess - no-one understands it and it's slow. I still think it's a very well designed language, the choice of the JVM+Java ecosystem as the target just has bogged it down with legacy crap like everything else on that environment and the designers should start to make some choices instead of offloading that on every single development team in the world. I think that "single-paradigm" is one of the reason that simple languages that get shit done, like Golang and Elixir, are so successful these days. Were I bound to the JVM, I'd still give it a good look (not sold on Clojure or Kotlin yet and it _is_ nicer and less frustrating than Maven+Java if you keep it simple); I'm just not married to the JVM so can freely consider other options. [1] http://www.artima.com/weblogs/viewpost.jsp?thread=260478 http://www.artima.com/weblogs/viewpost.jsp?thread=260478
  • pethallow 10y ago
    I took a sip of Scala, and I found it very interesting. Other than LISP it was my first functional language that was being used for something other than a college course project. I liked having been made to think differently about the code I wrote - fitting things into a functional construction. That being said, I found that many of Scala's features can quickly become drawbacks. I'm not a fan of JVM languages, but I've effectively programmed in Java and there are many useful, well-written frameworks and tools built on top of JVM languages. sbt is a pain in the ass, and I learned that fairly soon in my Scala exploration. Our project also used many Java libraries and it was jarring (no-pun) to switch between the "pure" Scala and the grafted-in Java. The person or community you enter Scala through can also be very influential on your experience. Though that's likely to happen with any language. The developer leading our project was extremely opinionated and felt that no other language was superior. He forced, oftentimes to the detriment of progress, abstractions in the code that made it nearly inscrutable. He became tiresome during discussions because his speech was mostly a stream of jargon. I could never tell what he was trying to achieve by using all the more complex features of Scala... other than job security.
• inglor 10y ago
  > With compile-time DI, you make service classes accept lower level dependencies as constructor parameters. In Scala, constructor parameters are accessible from regular methods, so most of the time, these services could be completely stateless. This approach is also advocated by several Java (and .NET) experts, but it's by no means mainstream. Interestingly, Scala developers have an advantage over Java/C# users, because they can significantly simplify the implementation by combining a macro-based library with lazy definitions: Asking for a dependency explicitly is service location not dependency injection. Your code there does not solve anything better than a regular service locator in a constructor would. The point of DI is that it's abstracted from the user code and the user doesn't have to care about these `wire` calls and can test it "as if dependencies were just passed regularly".
  • sreque 10y ago
    I don't think you're understanding what the author was saying. The author is advocating for constructor-based dependency injection, which incidentally, I also advocate for. There is a macro-based library in Scala, MacWire, that helps write the constructor calls for you, essentially acting as an auto-wire-like replacement to Spring and Guice, except that it does all its work at compile time. This mean you catch errors much earlier in the build and deploy process.
    • inglor 10y ago
      Where are the wire calls performed? Not in the constructor but in an initialization file?
      • sreque 10y ago
        I'm not familiar with MacWire, but I believe it's powered by macros. You can think of a macro as a function that runs at compile time. It's input is a syntax tree representing some code, and it's output is an arbitrary syntax tree representing code. The compiler, while processing source code, will recognize places where a macro should be invoked on some syntax. It will call the macro on that syntax, then replace the syntax with the output of the macro. In this sense, you can imagine a macro that takes in the source code for a class that has wire calls, and rewrites the wire calls into object constructor calls based on introspection of the syntax and types in the class. If you're familiar with C macros, they are technically the same kind of thing, although very basic, error prone, and unpleasant to work with. If you want to learn more about macros, I would recommend starting with a simpler, more sane macro system like one in Scheme, or, if you want something that looks more like Java, Nemerle (http://www.nemerle.org/About http://www.nemerle.org/About). Scala's macro system has a bit of a bolt-on feel since the language wasn't designed from the ground up for macros. That said, I applaud Scala's effort to try to figure out how to integrate macros into their core language and hope they are successful in the future with Scala Meta (http://scalameta.org/ http://scalameta.org/)
• mwcampbell 10y ago
  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.
• mcguire 10y ago
  "With compile-time DI, you make service classes accept lower level dependencies as constructor parameters. In Scala, constructor parameters are accessible from regular methods, so most of the time, these services could be completely stateless." Um...the constructor parameters become invisible instance variables. It's not stateless.
• hintingonwhoiam 10y ago
  Though correct this author makes a key assumption I dispute. "Scala as a better Java" === "people code in the same way in Scala & Java". This assumption leads to the focus on various Libraries and accepted standards. But, at least to me, "Scala as a better Java" === "Scala with better syntax and less boiler plate but access to Java libraries if you need them". Java is a brilliant language. But nothing can survive without some assumptions being voided over time. Despite that, many institutions relay on the good parts of Java (which there are many). Scala is a middle ground which has that backwards compat but with fixes to invalidated assumptions (syntax that has gotten clunky over time, lack of functional constructs)
• PaulHoule 10y ago
  It's not a better Java, it's a worse Java. I like the late-time binding in Spring, it is a very complete answer to the problem of "shipping a set of binary components" and "configuring those components endlessly". Why is that a problem? Because your build is slow and because it's dangerous to patch the source code every time you want to tweak the configuration, ... Trouble is: a lot of folks "learn" Spring working on a project somebody else started by cutting and pasting and searching for answers on Google and Stackoverflow. You can learn some things that way, you cannot learn Spring that way. If you read the manual a few times straight through you realize that it makes a lot of sense.
• mring33621 10y ago
  I am a long time Java developer and, believe it or not, regularly write important new product features in concise, performant Java 8. I have looked at Scala time and time again and am not sure what to think. It is currently a popular choice for big data munging -- I'm into Apache Flink and most Flink jobs are way easier to read when written in Scala VS. Java. But I also feel like Scala requires more decisions per line of code than Java, which makes it a more demanding day-to-day language. Also, it seems to have lots of dark corners. But these are really my impressions based on limited experience, so I am likely wrong. Also, my limited experience indicates that IDE support for Scala is quite behind that of Java. But I am still open to it. To get to my point, actually my question: Where should I look to learn quality, ideomatic Scala? My preference would be to focus on small example programs that do one thing well while demonstrating the correct, native use of Scala. Thank you.
  • adamkl 10y ago
    I'm just starting to pick up Scala (and functional programming for that matter) and I've been working my way through Functional Programming in Scala[1]. So far, it does a good job of teaching functional programming by taking stateful scala code, and refactoring it using pure functional approaches. The result might be considered quality, ideomatic scala. [1]https://www.manning.com/books/functional-programming-in-scala https://www.manning.com/books/functional-programming-in-scal...
• fulafel 10y ago
  Did anyone switch to Clojure from Scala? Sounds like an attractive choice given the complaints.
• thepiwo 10y ago
  Scala quicky got my favourite language. I really like handling data using functional and imutable concepts. Great libraries for db access (slick) and json handling (sparay-json) were not mentioned in the article, I wonder why slick is not even mentioned in the comments, it is really nice! Using scala with these and combined with akka and futures feels like a so natural way of programming for me.
• preordained 10y ago
  So much Java hate in here. I understand most people think Java devs live in caves, toiling away thinking Java and XML are the only technologies in the world. Still, this Java dev has used Haskell, Prolog, Ruby, Python...etc. I have left the cave. I've seen the world. It's nice, but Java still provides a ton of support and tooling to get things done. People have done bad things in the name of Java, and they have done fine work, too. Most of your practices from the bad old days of 90s to early 2000s Java are in rapid decline. It's not my favorite language (I heart Ruby), but a practical choice for many projects. Don't kid yourself; once you leave "Hello World" land, and have to deal with a variety of features, platforms, technologies, you can't hope to roll your own salvation--no matter how expressive your favorite language. And you don't want Johnny's 3 star github project solution, sorry. You want a battle tested beast, with the scars to show for it. That's Java for you.
  • shados 10y ago
    The software engineering community is bottom heavy right now, driven by improvement in accessibility of various platforms (eg Rails), and the prevalence of the San Francisco tech startup bubbles (where tens of thousands of developers have 10 jobs on their resume but never worked on one with more than 20 developers). And then these people go on and get lucky, and you have unicorn billion dollar companies built like if they were startups. That creates a weird/interesting world, where the #1 priority is "how long does it take to use this if I've never heard of it before, and how quickly can I build an MVP with it" That...changes priorities. A lot. Java is the other end of the spectrum, being born long before that world existed, and probably went a little too far. Fact remain, Java was born in a world very much opposite to what the majority knows today. So it will get flack from people who don't understand (or worse: don't remember, even though they were there!) why it is that way, and why it's (sometimes! Not always!) valuable. For a mature project, I don't give a damn how quick it is to learn or how fast you can get your login form ready. The login form was written 10 years ago. I want to see how quickly you can find, debug, diagnose and fix issues or how quickly can a new module be added to the code base while being consistent with the rest of the architecture. The java ecosystem is actually pretty good at it. At this point I haven't done Java in a very, very long time, but a large part of our stuff at work uses it, and I can open one of our hundreds of repo, look at it, and I know what it does and how I could extend it, even though I've never used the framework its built on.