21 ms·

On Scala

111 points by yareally 13y ago

dkhenry 13y ago
Best line in the article """ If a grand unified theory of programming language existed, its implementation would be called Scala """
- laureny 13y ago
  I think Kotlin would be a better candidate for this. Scala's surface area is way too big for this purpose.
  - yareally 13y ago
    Kotlin is a promising language, but still pretty new, so it doesn't have as many libraries out there tailored for it yet or questions asked about weird corner cases you might encounter (so it can make it a bit harder to track down bugs). That has its positives if you want to be a pioneer in the language and start popping out some useful open source libraries though. I love what Jetbrains does though and actively read their blog as they keep improving it. Kotlin has a bright future (I think some of the developers of Groovy are working with Jetbrains on it), but still a language in its infancy.
    - vorg 13y ago
      Scala may be a safer solution because Kotlin is newer, but that doesn't stop Kotlin being a better choice than other older languages like Groovy. Today the Groovy P.M. announced they're adding statically-typed traits (http://groovy.329449.n5.nabble.com/Adding-Trait-to-Groovy-td5715831.html http://groovy.329449.n5.nabble.com/Adding-Trait-to-Groovy-td...) to Groovy, talking about them like they're an innovation. But they were already implemented by former Groovy++ developer Alex Tkachman (https://code.google.com/p/groovypptest/wiki/Traits https://code.google.com/p/groovypptest/wiki/Traits) 2 years ago. Groovy added static compilation into Groovy 1 year ago by copying it from Tkachman's Groovy++ codebase, then announced it to the world as "Groovy 2.0" without crediting him. Now they're trying the same trick again, laundering the Groovy++ Traits and passing it all off as "Groovy 2.2". Alex Tkachman is now one of the Kotlin developers (along with Groovy's creator James Strachan). So which codebase would you trust: one laundered without credit from someone else's implementation (Groovy), or a second try from the actual person who wrote the first attempt (Kotlin)?
  - Uchikoma 13y ago
    Kotlin looks(ed) promising. When I tried Kotlin some time ago they mixed plans, wishes and facts in the "documentation" which made it very hard to do some work, as many "features" in "examples" had not been implemented (And I thought to myself how stupid could I be to not get the examples working)
    - dodyg 13y ago
      Yes the official documentation is indeed out of date. I am working to fill the gap (http://goo.gl/TkgqR http://goo.gl/TkgqR - in progress) The potential growth for Kotlin usage will be on Android platform especially after the new Android Studio is based on IntelliJ 13. Kotlin fits nicely here and it's a relatively small language. Scala though is quite a pioneering language on the JVM. I think a lot of Kotlin features and design are influenced by Scala.
  - timclark 13y ago
    If you like Kotlin also look at Ceylon from RedHat. In some ways very similar to Kotlin with null-safety and improved generics.
    - yareally 13y ago
      Actually Kotlin has null safety as well[1]. Not sure how generics in Kotlin compare to Ceylon, but it also improved on Java's generic support[2] by eliminating wildcards, type projection, inferred types and some other features. Random question, but how far along is Ceylon's development compared to Kotlin's? I know they're both relatively new still, but just wondering how feature complete it is so far. [1] http://confluence.jetbrains.com/display/Kotlin/Null-safety http://confluence.jetbrains.com/display/Kotlin/Null-safety [2] http://confluence.jetbrains.com/display/Kotlin/Generics http://confluence.jetbrains.com/display/Kotlin/Generics
      - timclark 13y ago
        See here: http://ceylon-lang.org/documentation/1.0/roadmap/ http://ceylon-lang.org/documentation/1.0/roadmap/ I hate to say it because I like JetBrains and have given them lots of money over the years but I prefer Ceylon to Kotlin. They are very similar languages but I just like the Ceylon syntax more.
yareally 13y ago
Like the author, I've been using Scala more and more as of late (mostly after finding it to be a viable alternative to Java on Android). Perhaps the biggest thing that I've had to get over is the "feature freedom" of the language after being walled in by Java on Android. I know I'm not too far off in saying it, but it's like Martin Odersky created it in direct response to the nanny-like restrictiveness that Java has, but perhaps went too far in some areas (as the article describes a bit). He did write the current java compiler, so he's well familiar with how Java is. I just sometimes get the feeling someone pressed accept to every feature enhancement to the language at some point as just about any feature you can think of in a modern language has found its way into Scala. Generally, I find that to be a good thing, but I can see how it would be off-putting to some and makes Scala somewhat of a controversial language for both imperative and functional language advocates. If one is not careful and adhering to a formal style guide, it would easy to end up with an unreadable mess of inconsistent code. Anyone with some grounding in programming already at a professional level shouldn't have a problem, but someone that's relatively new to development might want to look into another language. For example, all of these are valid ways to create a class with some parameters/properties: https://gist.github.com/yareally/5811498 https://gist.github.com/yareally/5811498 After having to use Java on Android for the past three years, such freedom is both liberating and shocking at the same time. I use C#, JavaScript and Python pretty frequent as well, but it's just I'd say Scala is even more liberal than any of those feature wise. It's more like Perl (not quite, but close), but not quite in the area of a Lisp variant. Scala is definitely written from the viewpoint of the developer and not the intended users though. It's also nice to have access to features that are standard in languages like Python, Ruby, C# and functional languages. Seeing 13 lines of Java become 1 line of Scala[1] is a great feeling. I'd say if you have experience with Java, C#, Python, Ruby or any functional language you'll pick up on Scala pretty quick. If Java is your only language experience, it might be a bit rough at first, because of the expressiveness and freedom of the language, but don't let it detour you. If needed, you can mostly stick to the imperative side of Scala and slowly work in more functional features as well as some of the useful syntactical sugar stuff (like operator overloading) that Scala provides. [1] https://gist.github.com/yareally/5810767 https://gist.github.com/yareally/5810767
- mooreds 13y ago
saryant 13y ago
I started using Scala ~2.5 years ago for my undergrad thesis. At the time I didn't really know what I was doing and essentially wrote Java with map/reduce on collections. I've been working steadily in Scala since and currently do so professionally. I'm a fan, especially with the Akka actor framework. Lately I've been playing with Play, Akka and ReactiveMongo. For-comprehensions offer a terrific abstraction for dealing with asynchronous code. My current side project is "Street View for Flights" implemented in the above stack. Lots of calls to third-party REST APIs after checking if data has already been retrieved and inserted into Mongo. Code like the following allows for controllers to be asynchronous while staying readable: def byCode(airlineCode: String) = Action { Async { for { airline <- Airline.findByICAO(airlineCode) // returns Future[Option[Airline]] } yield airline map { a => views.html.airline(a) } getOrElse NotFound } } The advantage for me is that those futures could be redeemed either by finding the requested object in Mongo and on failure retrieving it from a third-party API while not blocking and keeping the code readable. Either way, the controller just gets a Future without blocking. Other parts of this project make heavy use of Akka actors to feed server-sent events (sort of a compromise between Comet and WebSockets). Development has been great fun because Scala really allows me to write code at a higher level. Asynchronous, typesafe, nullsafe code with the compiler as my safety net.
- yareally 13y ago
  Actors and the way Scala handles async is one of the reasons I wanted to get into using Scala on Android actually. The awkward way Android handles it is chock full of Java boilerplate and Scala's way is just much more elegant. Another feature that got my attention was the ability to have a SQL framework that handled things similar to LINQ. I haven't tried it much yet, but Squeryl[1] has looked promising for being a Scala equivalent. I may have to look into Akka more though as that will easily take care of async SQLite calls as well[2]. [1] http://squeryl.org/introduction.html http://squeryl.org/introduction.html [2] http://www.gamlor.info/wordpress/2012/05/async-sql-and-akka/ http://www.gamlor.info/wordpress/2012/05/async-sql-and-akka/
  - saryant 13y ago
tkw8 13y ago
Using Scala has been a breath of fresh air after 10+ years of (mostly) Java. Mountains of boilerplate (I'm looking at you getter/setter/constructor auto-generated code) become 2 or 3 lines, in some cases a 1 line class definition: class Foo(var x: Int, var y: Int, var name: String) (Thats equivalent to 6 method definitions and a constructor in Java. Also, the possibility that you forget to initialize one of the fields in your constructor [which happens from time to time in most Java code] is removed) It's not just about having to write less boilerplate, it's also about having to read less code and expressing ideas using functional concepts where it makes sense. Critics like to complain that having many features makes the language complex. In practice Scala code is fairly straightforward, the extra features just mean that library designers have to power to implement some pretty amazing interfaces for you using these features. Most Scala code is pretty sensible, and it's nice to know that the extra expressive power is there when you need it. This may sound like heresy but I find myself being more productive in Scala than in Ruby. Part of that comes for the self-documenting nature of static typing and clear interfaces (No more "what methods and fields does this Foo object that is being passed in to this obscure method have?"). This is a very useful property to have when reading other peoples' code. The tooling is surprisingly mature (IntelliJ). In hindsight picking Scala as a better Java should have been a no-brainer.
- habosa 13y ago
  Scala = scalable language. This is for all the reasons you said. Because the language allows so much, library designers can really extend the language itself and create whole new paradigms or do other powerful things you just can't do in any other language that's this stable and portable.
- lucian1900 13y ago
  There are much less complex but precisely as powerful languages out there (like Haskell). Scala's crazy amount of syntax is what makes me avoid it, not unlike C++.
  - trailfox 13y ago
    Does Haskell let me use the many Java libs that are used extensively internally in many organizations (including mine)?
anonymoushn 13y ago
There seem to be some problems in the examples. scala> def theSquareMullet(i:Int) = i * i theSquareMullet: (i: Int)Int scala> def theHoffSquareMullet({ mullet: => Int }) = mullet * mullet <console>:1: error: identifier expected but '{' found. def theHoffSquareMullet({ mullet: => Int }) = mullet * mullet ^ scala> def theHoffSquareMullet(mullet: => Int) = mullet * mullet theHoffSquareMullet: (mullet: => Int)Int scala> theSquareMullet(theHoffSquareMullet(10)) res0: Int = 10000
lmm 13y ago
Description of apply() is backwards or at least unclear; it's not that "new Song(name) goes to Song.apply(name)", rather, "Song(name)" -> "Song.apply(name)", which is commonly (and automatically, in the case of case classes) implemented as "new Song(name)". It's worth mentioning the positive side of more concise syntax for closures - as someone who previously used lamdbas heavily in python this is a real win. "Seq("1", "2", "foo").map({n => stoi(n)})" should just be "Seq("1", "2", "foo").map({stoi(_)})" - or, in this particular case, "Seq("1", "2", "foo").map(stoi)". Of course, the price is shown at the end as having more than one way to write the same thing - but the differences in those examples are (IMO) superficial and don't impair readability. The specific problem of infix/suffix methods should be solved with 2.10's compiler flags. They should also go some way towards improving source compatibility (features for which the syntax is expected to possibly change will stay behind flags), while 2.10 introduces a better binary compatibility policy. Still, most of the criticism is fair, and I'm pleased to see a comprehensive impression post like this.
TeeWEE 13y ago
What I dont like about scala is its "syntaxtic flexibility". Or how I would call it, non consistent syntax. Too much features: Scala has everything, it seems like the language designers coudn't make a choice about what is best. "Whoo this is cool, lets add it". One word: implicits, arrgh Also the fact that is built on top of java... When you design a good language, you should try to do it right, and leave all other out. However this is a design choice of Scala. And I think this choice makes the language a short term language, just as a stepping stone for java programmers to better languages. - end of rant -
- yareally 13y ago
  Why don't you like implicits? Even the more conservative language C# has them. It beats the heck out of having to do the following in Java: BigInteger x = new BigInteger(someBigNumString); BigInteger sum = x.add(new BigInteger("1000"); When you can do this in Scala (or similar in C#): BigInt x = BigInt(someBigNumString) BigInt sum = x + 1000 If you're going to say it can be abused, lots of things can be abused in any language. I prefer sanity in this case for implicits over risk of abuse. Having to use something like BigInteger in Java without implicits just makes my head hurt trying to read and write code using it.
  - pivo 13y ago
    I've done exactly one project in Scala, so I'm by no means a Scala expert. My objection to the implicit conversions is mostly when they're used with DSLs. Our project used several libraries that each implemented their own DSLs that of course made use of implicit conversions. There were two things struck me as questionable about the extensive DSL support in Scala. First, Scala source files that used one library's DSL ended up looking like they were written in a different language than Scala source files using another library's DSL. That, to me at least, makes it harder to read the source quickly and understand whats going on. This wasn't a horrible problem, but I found it somewhat burdensome to reorient myself when switching between DSLs, so I feel like it's an overall negative feature of the language. Sort of the opposite of the benefit that more consistant looking languages like Python and Go provide. It also means, at least for me, that and IDE is necessary in order to understand what's going on in source files using certain DSLs. I'm an Emacs user and this is the first time I've felt like I really should have been using an IDE, which was irritating. My second objection was that because of ambiguities between implicit conversions in different DSLs, source files that used more than one DSL had to fall back on explicit conversions and therefore not really use the DSLs. That made some source files using a given library look very different from other source files using the same library, since one was written using the DSL and the other wasn't. This is really my major objection to the language. In many other ways I really enjoyed Scala and wish I could use it more. Yet I wish DSLs and implicit conversions were used much more sparingly in Scala libraries.
JustinJ70s 13y ago
Starting adopting Scala about 18 months ago after much frustration with Java's copious boilerplate. It's like a breath of fresh air and feels in many ways like a dynamic language thanks to type inference. We still use many Java libraries but interfacing with Scala is a breeze. It's got more up-take than Kotlin or Ceylon and I'd say the only decent alternative on the JVM is Clojure but that's a different beast. If you're in a position where your after functional programming on the JVM then consider not waiting years for Java to catch up. Give Scala a go.
- trailfox 13y ago
  Same experience here.
milos_cohagen 13y ago
enjoyed the article very much! nice analysis.
eli_gottlieb 13y ago
I started out with Scala three years ago on a hobby project when I wanted an impure functional language compatible with a Java library I felt myself bound to use. Since then, it has become such a strong favorite that I have remodeled part of my own hobby programming language based on Scala.
Stranger2013 13y ago
Completely new to Scala but I think that "18 ways" code sample is a bit exaggerated. It is just a choice between C#-ish "a => a + 1" and Haskell-ish "_ + 1".
kclay 13y ago
I started using Scala last year with the Play! 2 framework (did a write up on it earlier this year on HN) and was a breathe of fresh air. I didn't have any prior functional programming skills so it was a bit of learning functional programming and the language as well, but it was a fun experience. When ever I have the chance to choose the tech stack for a new project whether personal or professionally, Scala and Play! is the first choice. I just finished a Scala lib for rethinkdb (will announce later).

111 points by yareally 13y ago

Best line in the article """ If a grand unified theory of programming language existed, its implementation would be called Scala """

laureny 13y ago
I think Kotlin would be a better candidate for this. Scala's surface area is way too big for this purpose.
- yareally 13y ago
  Kotlin is a promising language, but still pretty new, so it doesn't have as many libraries out there tailored for it yet or questions asked about weird corner cases you might encounter (so it can make it a bit harder to track down bugs). That has its positives if you want to be a pioneer in the language and start popping out some useful open source libraries though. I love what Jetbrains does though and actively read their blog as they keep improving it. Kotlin has a bright future (I think some of the developers of Groovy are working with Jetbrains on it), but still a language in its infancy.
  - vorg 13y ago
    Scala may be a safer solution because Kotlin is newer, but that doesn't stop Kotlin being a better choice than other older languages like Groovy. Today the Groovy P.M. announced they're adding statically-typed traits (http://groovy.329449.n5.nabble.com/Adding-Trait-to-Groovy-td5715831.html http://groovy.329449.n5.nabble.com/Adding-Trait-to-Groovy-td...) to Groovy, talking about them like they're an innovation. But they were already implemented by former Groovy++ developer Alex Tkachman (https://code.google.com/p/groovypptest/wiki/Traits https://code.google.com/p/groovypptest/wiki/Traits) 2 years ago. Groovy added static compilation into Groovy 1 year ago by copying it from Tkachman's Groovy++ codebase, then announced it to the world as "Groovy 2.0" without crediting him. Now they're trying the same trick again, laundering the Groovy++ Traits and passing it all off as "Groovy 2.2". Alex Tkachman is now one of the Kotlin developers (along with Groovy's creator James Strachan). So which codebase would you trust: one laundered without credit from someone else's implementation (Groovy), or a second try from the actual person who wrote the first attempt (Kotlin)?
- Uchikoma 13y ago
  Kotlin looks(ed) promising. When I tried Kotlin some time ago they mixed plans, wishes and facts in the "documentation" which made it very hard to do some work, as many "features" in "examples" had not been implemented (And I thought to myself how stupid could I be to not get the examples working)
  - dodyg 13y ago
    Yes the official documentation is indeed out of date. I am working to fill the gap (http://goo.gl/TkgqR http://goo.gl/TkgqR - in progress) The potential growth for Kotlin usage will be on Android platform especially after the new Android Studio is based on IntelliJ 13. Kotlin fits nicely here and it's a relatively small language. Scala though is quite a pioneering language on the JVM. I think a lot of Kotlin features and design are influenced by Scala.
- timclark 13y ago
  If you like Kotlin also look at Ceylon from RedHat. In some ways very similar to Kotlin with null-safety and improved generics.
  - yareally 13y ago
    Actually Kotlin has null safety as well[1]. Not sure how generics in Kotlin compare to Ceylon, but it also improved on Java's generic support[2] by eliminating wildcards, type projection, inferred types and some other features. Random question, but how far along is Ceylon's development compared to Kotlin's? I know they're both relatively new still, but just wondering how feature complete it is so far. [1] http://confluence.jetbrains.com/display/Kotlin/Null-safety http://confluence.jetbrains.com/display/Kotlin/Null-safety [2] http://confluence.jetbrains.com/display/Kotlin/Generics http://confluence.jetbrains.com/display/Kotlin/Generics
    - timclark 13y ago
      See here: http://ceylon-lang.org/documentation/1.0/roadmap/ http://ceylon-lang.org/documentation/1.0/roadmap/ I hate to say it because I like JetBrains and have given them lots of money over the years but I prefer Ceylon to Kotlin. They are very similar languages but I just like the Ceylon syntax more.

yareally 13y ago

Like the author, I've been using Scala more and more as of late (mostly after finding it to be a viable alternative to Java on Android). Perhaps the biggest thing that I've had to get over is the "feature freedom" of the language after being walled in by Java on Android. I know I'm not too far off in saying it, but it's like Martin Odersky created it in direct response to the nanny-like restrictiveness that Java has, but perhaps went too far in some areas (as the article describes a bit). He did write the current java compiler, so he's well familiar with how Java is. I just sometimes get the feeling someone pressed accept to every feature enhancement to the language at some point as just about any feature you can think of in a modern language has found its way into Scala. Generally, I find that to be a good thing, but I can see how it would be off-putting to some and makes Scala somewhat of a controversial language for both imperative and functional language advocates. If one is not careful and adhering to a formal style guide, it would easy to end up with an unreadable mess of inconsistent code. Anyone with some grounding in programming already at a professional level shouldn't have a problem, but someone that's relatively new to development might want to look into another language. For example, all of these are valid ways to create a class with some parameters/properties: https://gist.github.com/yareally/5811498 https://gist.github.com/yareally/5811498 After having to use Java on Android for the past three years, such freedom is both liberating and shocking at the same time. I use C#, JavaScript and Python pretty frequent as well, but it's just I'd say Scala is even more liberal than any of those feature wise. It's more like Perl (not quite, but close), but not quite in the area of a Lisp variant. Scala is definitely written from the viewpoint of the developer and not the intended users though. It's also nice to have access to features that are standard in languages like Python, Ruby, C# and functional languages. Seeing 13 lines of Java become 1 line of Scala[1] is a great feeling. I'd say if you have experience with Java, C#, Python, Ruby or any functional language you'll pick up on Scala pretty quick. If Java is your only language experience, it might be a bit rough at first, because of the expressiveness and freedom of the language, but don't let it detour you. If needed, you can mostly stick to the imperative side of Scala and slowly work in more functional features as well as some of the useful syntactical sugar stuff (like operator overloading) that Scala provides. [1] https://gist.github.com/yareally/5810767 https://gist.github.com/yareally/5810767

mooreds 13y ago

saryant 13y ago

I started using Scala ~2.5 years ago for my undergrad thesis. At the time I didn't really know what I was doing and essentially wrote Java with map/reduce on collections. I've been working steadily in Scala since and currently do so professionally. I'm a fan, especially with the Akka actor framework. Lately I've been playing with Play, Akka and ReactiveMongo. For-comprehensions offer a terrific abstraction for dealing with asynchronous code. My current side project is "Street View for Flights" implemented in the above stack. Lots of calls to third-party REST APIs after checking if data has already been retrieved and inserted into Mongo. Code like the following allows for controllers to be asynchronous while staying readable: def byCode(airlineCode: String) = Action { Async { for { airline <- Airline.findByICAO(airlineCode) // returns Future[Option[Airline]] } yield airline map { a => views.html.airline(a) } getOrElse NotFound } } The advantage for me is that those futures could be redeemed either by finding the requested object in Mongo and on failure retrieving it from a third-party API while not blocking and keeping the code readable. Either way, the controller just gets a Future without blocking. Other parts of this project make heavy use of Akka actors to feed server-sent events (sort of a compromise between Comet and WebSockets). Development has been great fun because Scala really allows me to write code at a higher level. Asynchronous, typesafe, nullsafe code with the compiler as my safety net.

yareally 13y ago
Actors and the way Scala handles async is one of the reasons I wanted to get into using Scala on Android actually. The awkward way Android handles it is chock full of Java boilerplate and Scala's way is just much more elegant. Another feature that got my attention was the ability to have a SQL framework that handled things similar to LINQ. I haven't tried it much yet, but Squeryl[1] has looked promising for being a Scala equivalent. I may have to look into Akka more though as that will easily take care of async SQLite calls as well[2]. [1] http://squeryl.org/introduction.html http://squeryl.org/introduction.html [2] http://www.gamlor.info/wordpress/2012/05/async-sql-and-akka/ http://www.gamlor.info/wordpress/2012/05/async-sql-and-akka/
- saryant 13y ago

tkw8 13y ago

Using Scala has been a breath of fresh air after 10+ years of (mostly) Java. Mountains of boilerplate (I'm looking at you getter/setter/constructor auto-generated code) become 2 or 3 lines, in some cases a 1 line class definition: class Foo(var x: Int, var y: Int, var name: String) (Thats equivalent to 6 method definitions and a constructor in Java. Also, the possibility that you forget to initialize one of the fields in your constructor [which happens from time to time in most Java code] is removed) It's not just about having to write less boilerplate, it's also about having to read less code and expressing ideas using functional concepts where it makes sense. Critics like to complain that having many features makes the language complex. In practice Scala code is fairly straightforward, the extra features just mean that library designers have to power to implement some pretty amazing interfaces for you using these features. Most Scala code is pretty sensible, and it's nice to know that the extra expressive power is there when you need it. This may sound like heresy but I find myself being more productive in Scala than in Ruby. Part of that comes for the self-documenting nature of static typing and clear interfaces (No more "what methods and fields does this Foo object that is being passed in to this obscure method have?"). This is a very useful property to have when reading other peoples' code. The tooling is surprisingly mature (IntelliJ). In hindsight picking Scala as a better Java should have been a no-brainer.

habosa 13y ago
Scala = scalable language. This is for all the reasons you said. Because the language allows so much, library designers can really extend the language itself and create whole new paradigms or do other powerful things you just can't do in any other language that's this stable and portable.
lucian1900 13y ago
There are much less complex but precisely as powerful languages out there (like Haskell). Scala's crazy amount of syntax is what makes me avoid it, not unlike C++.
- trailfox 13y ago
  Does Haskell let me use the many Java libs that are used extensively internally in many organizations (including mine)?

anonymoushn 13y ago

There seem to be some problems in the examples. scala> def theSquareMullet(i:Int) = i * i theSquareMullet: (i: Int)Int scala> def theHoffSquareMullet({ mullet: => Int }) = mullet * mullet <console>:1: error: identifier expected but '{' found. def theHoffSquareMullet({ mullet: => Int }) = mullet * mullet ^ scala> def theHoffSquareMullet(mullet: => Int) = mullet * mullet theHoffSquareMullet: (mullet: => Int)Int scala> theSquareMullet(theHoffSquareMullet(10)) res0: Int = 10000

lmm 13y ago

Description of apply() is backwards or at least unclear; it's not that "new Song(name) goes to Song.apply(name)", rather, "Song(name)" -> "Song.apply(name)", which is commonly (and automatically, in the case of case classes) implemented as "new Song(name)". It's worth mentioning the positive side of more concise syntax for closures - as someone who previously used lamdbas heavily in python this is a real win. "Seq("1", "2", "foo").map({n => stoi(n)})" should just be "Seq("1", "2", "foo").map({stoi(_)})" - or, in this particular case, "Seq("1", "2", "foo").map(stoi)". Of course, the price is shown at the end as having more than one way to write the same thing - but the differences in those examples are (IMO) superficial and don't impair readability. The specific problem of infix/suffix methods should be solved with 2.10's compiler flags. They should also go some way towards improving source compatibility (features for which the syntax is expected to possibly change will stay behind flags), while 2.10 introduces a better binary compatibility policy. Still, most of the criticism is fair, and I'm pleased to see a comprehensive impression post like this.

TeeWEE 13y ago

What I dont like about scala is its "syntaxtic flexibility". Or how I would call it, non consistent syntax. Too much features: Scala has everything, it seems like the language designers coudn't make a choice about what is best. "Whoo this is cool, lets add it". One word: implicits, arrgh Also the fact that is built on top of java... When you design a good language, you should try to do it right, and leave all other out. However this is a design choice of Scala. And I think this choice makes the language a short term language, just as a stepping stone for java programmers to better languages. - end of rant -

yareally 13y ago
Why don't you like implicits? Even the more conservative language C# has them. It beats the heck out of having to do the following in Java: BigInteger x = new BigInteger(someBigNumString); BigInteger sum = x.add(new BigInteger("1000"); When you can do this in Scala (or similar in C#): BigInt x = BigInt(someBigNumString) BigInt sum = x + 1000 If you're going to say it can be abused, lots of things can be abused in any language. I prefer sanity in this case for implicits over risk of abuse. Having to use something like BigInteger in Java without implicits just makes my head hurt trying to read and write code using it.
- pivo 13y ago
  I've done exactly one project in Scala, so I'm by no means a Scala expert. My objection to the implicit conversions is mostly when they're used with DSLs. Our project used several libraries that each implemented their own DSLs that of course made use of implicit conversions. There were two things struck me as questionable about the extensive DSL support in Scala. First, Scala source files that used one library's DSL ended up looking like they were written in a different language than Scala source files using another library's DSL. That, to me at least, makes it harder to read the source quickly and understand whats going on. This wasn't a horrible problem, but I found it somewhat burdensome to reorient myself when switching between DSLs, so I feel like it's an overall negative feature of the language. Sort of the opposite of the benefit that more consistant looking languages like Python and Go provide. It also means, at least for me, that and IDE is necessary in order to understand what's going on in source files using certain DSLs. I'm an Emacs user and this is the first time I've felt like I really should have been using an IDE, which was irritating. My second objection was that because of ambiguities between implicit conversions in different DSLs, source files that used more than one DSL had to fall back on explicit conversions and therefore not really use the DSLs. That made some source files using a given library look very different from other source files using the same library, since one was written using the DSL and the other wasn't. This is really my major objection to the language. In many other ways I really enjoyed Scala and wish I could use it more. Yet I wish DSLs and implicit conversions were used much more sparingly in Scala libraries.

JustinJ70s 13y ago

Starting adopting Scala about 18 months ago after much frustration with Java's copious boilerplate. It's like a breath of fresh air and feels in many ways like a dynamic language thanks to type inference. We still use many Java libraries but interfacing with Scala is a breeze. It's got more up-take than Kotlin or Ceylon and I'd say the only decent alternative on the JVM is Clojure but that's a different beast. If you're in a position where your after functional programming on the JVM then consider not waiting years for Java to catch up. Give Scala a go.

trailfox 13y ago
Same experience here.

milos_cohagen 13y ago

enjoyed the article very much! nice analysis.

eli_gottlieb 13y ago

I started out with Scala three years ago on a hobby project when I wanted an impure functional language compatible with a Java library I felt myself bound to use. Since then, it has become such a strong favorite that I have remodeled part of my own hobby programming language based on Scala.

Stranger2013 13y ago

Completely new to Scala but I think that "18 ways" code sample is a bit exaggerated. It is just a choice between C#-ish "a => a + 1" and Haskell-ish "_ + 1".

kclay 13y ago

I started using Scala last year with the Play! 2 framework (did a write up on it earlier this year on HN) and was a breathe of fresh air. I didn't have any prior functional programming skills so it was a bit of learning functional programming and the language as well, but it was a fun experience. When ever I have the chance to choose the tech stack for a new project whether personal or professionally, Scala and Play! is the first choice. I just finished a Scala lib for rethinkdb (will announce later).