Why Learn Scala in 2013?(blog.typesafe.com)
blog.typesafe.com
Why Learn Scala in 2013?
http://blog.typesafe.com/why-learn-scala
74 comments
I like Scala and didn't personally find it that hard to start using it but I'm not optimistic about its future as a mainstream alternative to Java. It's just too big and complex and (apparently) too GC heavy to be useful on what is quickly becoming one of the most important Java environments (Android).
My money is on Jetbrains' Kotlin as a significant but manageable step forward from Java. Given its pedigree I expect it to have tooling support that no other JVM language can match.
http://kotlin.jetbrains.org/
My money is on Jetbrains' Kotlin as a significant but manageable step forward from Java. Given its pedigree I expect it to have tooling support that no other JVM language can match.
http://kotlin.jetbrains.org/
Part of Kotlin's pedigree are some ex-developers of Groovy, i.e. James Strachan (Groovy's creator) and Alex Tkachman (creator of Groovy++, the inspiration for Groovy's static type-checking). They bring a deep knowledge of implementation pitfalls that can only be gained from doing it wrong the first time.
Of course, Scala creator Martin Odersky completely rewrote Scala after version 1.0, and even in version 2.x, has considered fixing stuff between point releases to be more important than backwards compatibility, so Scala similarly ought to be quite polished by now (version 2.10), in both feature set and implementation.
Of course, Scala creator Martin Odersky completely rewrote Scala after version 1.0, and even in version 2.x, has considered fixing stuff between point releases to be more important than backwards compatibility, so Scala similarly ought to be quite polished by now (version 2.10), in both feature set and implementation.
I didn't know that the Groovy folks were involved in Kotlin. That's great to hear. I think this team has exactly the right experience to build a potential Java killer.
Wow I never heard of Kotlin. There was a presentation about it at Devoxx but since I didnt visit it.
Looks like a simple yet powerfull language. While still remaining type safety. Going to look into it!
Looks like a simple yet powerfull language. While still remaining type safety. Going to look into it!
my little worry about scala is that it _keeps getting_ bigger and more complex.
2.9 manage to not change the language much, AFAIR, but now 2.10 gets macros[0], string interpolation, implicit classes, value classes, and a whole new concurrency framework.
All cool stuff, but the nonchalance in adding more and more things makes me uncomfortable.
[0] yes, I know, "experimental"
2.9 manage to not change the language much, AFAIR, but now 2.10 gets macros[0], string interpolation, implicit classes, value classes, and a whole new concurrency framework.
All cool stuff, but the nonchalance in adding more and more things makes me uncomfortable.
[0] yes, I know, "experimental"
I think it's true that Haskell is better for playing around with the stuff published in ICFP and related conferences. The reason, however, is a bit more subtle. Haskell is the dominant language for programming language research. So publications tend to use it, and Haskell is better adapted at being Haskell than Scala :) There is also more stuff being published in Haskell for this reason.
However it is not correct to say that Haskell is more expressive than Scala. It is in some ways but Scala is more expressive in others. There is a paper that discusses type classes in Scala and show they have some advantages over Haskell's implementation. As more people use Scala and discover neat things you do in it, this is feeding back into other languages. For example, here's the mighty Oleg implementing the cake pattern from Scala in Haskell: http://okmij.org/ftp/Haskell/ScalaCake.hs
However it is not correct to say that Haskell is more expressive than Scala. It is in some ways but Scala is more expressive in others. There is a paper that discusses type classes in Scala and show they have some advantages over Haskell's implementation. As more people use Scala and discover neat things you do in it, this is feeding back into other languages. For example, here's the mighty Oleg implementing the cake pattern from Scala in Haskell: http://okmij.org/ftp/Haskell/ScalaCake.hs
> Haskell is the dominant language for programming language research. ..... There is also more stuff being published in Haskell for this reason.
No. Even if you just mean the FP (functional programming) community this isn't true, and it's definitely not true for the whole of SIGPLAN.
No. Even if you just mean the FP (functional programming) community this isn't true, and it's definitely not true for the whole of SIGPLAN.
Thank you for the link. The cake example was exactly what I was thinking of when I said that things may be changing (though I couldn't recall the specific example). It's also quite likely that as the Scala community grows, and people stop trying to make it be "like <language> but more <quality>", we will see more innovation in this space.
Still, I think Scala is first and foremost a practical language. Straying too far from that as a primary goal would probably be harmful in the long run (i.e. driving a Ferrari might be fun, but you're not going to buy one for the daily commute).
Still, I think Scala is first and foremost a practical language. Straying too far from that as a primary goal would probably be harmful in the long run (i.e. driving a Ferrari might be fun, but you're not going to buy one for the daily commute).
Haskell might be a bit of a bad example considering how far ahead it is compared to other languages in terms of PL features (like type-level programming). When compared to other imperative languages, Scala is very feature complete, and Scala also has pretty much all the features of ML-type functional languages.
It's definitely at a good intersection of "useful" (all the JVM stuff) and "nice" (you can be functional or imperative, writing DSLs are super easy, etc).
It's definitely at a good intersection of "useful" (all the JVM stuff) and "nice" (you can be functional or imperative, writing DSLs are super easy, etc).
I really like Scala. But i have some thoughts on this article:
- Its not objective: It's from Typesafe. Logically they are not going to mention the negative sides of Scala
I used Scala myself and I think it is a very good approach to combining functional, imperative, object oriented and type safety in one language.
But the big downside is complexity: Scala is utterly complex, its has all the features of java. But it simplifies the object model (everything is an object), that's a good thing. But the type system? Really complex. Making compile time errors very difficult to understand.
A shift to functional style programming is happening more and more. But I think, and hope, there will be a complete paradigma shift from imperative to completely functional. This should start with universities starting with lambda calculus and functional languages to 1st year CS students.
Functional programming has the simplest execution model, is one of the best to reason about, and works very well with current multicore systems. That's why i'm spending more time on learning Clojure than learning Scala. In the end a language like lisp is much simpler but the paradigma shift is what makes it a bit difficult for those imperative programmers like me.
- Its not objective: It's from Typesafe. Logically they are not going to mention the negative sides of Scala
I used Scala myself and I think it is a very good approach to combining functional, imperative, object oriented and type safety in one language.
But the big downside is complexity: Scala is utterly complex, its has all the features of java. But it simplifies the object model (everything is an object), that's a good thing. But the type system? Really complex. Making compile time errors very difficult to understand.
A shift to functional style programming is happening more and more. But I think, and hope, there will be a complete paradigma shift from imperative to completely functional. This should start with universities starting with lambda calculus and functional languages to 1st year CS students.
Functional programming has the simplest execution model, is one of the best to reason about, and works very well with current multicore systems. That's why i'm spending more time on learning Clojure than learning Scala. In the end a language like lisp is much simpler but the paradigma shift is what makes it a bit difficult for those imperative programmers like me.
I'm not disagreeing about the complexity, but you can choose to use a sane subset of the language and do away with all the other stuff. Map, filter, anonymous functions and type inference already puts it way ahead of Java in terms of productivity. You can absolutely choose to ignore the rest of the language.
In the end a language like lisp is much simpler but the paradigma shift is what makes it a bit difficult for those imperative programmers like me.
It's not very fair to compare Scala with Clojure - static typing might not be everyone's cup of tea, but over time, I have come to appreciate it's power when dealing with certain classes of problems.
In the end a language like lisp is much simpler but the paradigma shift is what makes it a bit difficult for those imperative programmers like me.
It's not very fair to compare Scala with Clojure - static typing might not be everyone's cup of tea, but over time, I have come to appreciate it's power when dealing with certain classes of problems.
I'm not disagreeing about the complexity, but you can choose
to use a sane subset of the language and do away with all
the other stuff.
While I don't think _this_ article presents any compelling reasons to learn scala, you still should. If I had to list my reasons they would be
0. Of all the "new" languages Scala has the best selection of libraries and I think is the easiest to become instantly productive in. Languages like Rust and even to some extent Go are also really exciting and let you do great things, but the native library support isn't as robust as it is for Scala, and Rust in particular is still under heavy development and isn't really ready yet. From a stability standpoint you should be OK with Go, but even it will be baking in more stuff and changing more then you will see Scala change.
1. The Productivity Boost Effect. You will find you can solve complex problems with a few lines of code and a little thinking. I have ported 1K+ lines of C++ to 10 or 20 lines of Scala
2. Personal Growth. If you are coming from C++ or Java and have done Imperative programming your whole career then Scala is a _gentle_ introduction to functional programming. As you start to use the language you might start by using it as java and only typing half the character ( no type signatures ,semi-colons , or in some places parentheses ) as you do more things and look for elegant solutions the function patterns will become obvious in their usefulness and you will start seeing their value first hand.
3. Awesome Libraries you get access to. I think immediatly of things like Akka, Twitter Storm , Play2 , and my personal favorite Spark[1]. Not that there aren't great libraries in other languages and most if not all of those expose themselves to Java and other languages, but its great using the native language they were designed for. you can do some great stuff.
4. Finally its better then spending all day reading and commenting on Hacker News. :-)
0. Of all the "new" languages Scala has the best selection of libraries and I think is the easiest to become instantly productive in. Languages like Rust and even to some extent Go are also really exciting and let you do great things, but the native library support isn't as robust as it is for Scala, and Rust in particular is still under heavy development and isn't really ready yet. From a stability standpoint you should be OK with Go, but even it will be baking in more stuff and changing more then you will see Scala change.
1. The Productivity Boost Effect. You will find you can solve complex problems with a few lines of code and a little thinking. I have ported 1K+ lines of C++ to 10 or 20 lines of Scala
2. Personal Growth. If you are coming from C++ or Java and have done Imperative programming your whole career then Scala is a _gentle_ introduction to functional programming. As you start to use the language you might start by using it as java and only typing half the character ( no type signatures ,semi-colons , or in some places parentheses ) as you do more things and look for elegant solutions the function patterns will become obvious in their usefulness and you will start seeing their value first hand.
3. Awesome Libraries you get access to. I think immediatly of things like Akka, Twitter Storm , Play2 , and my personal favorite Spark[1]. Not that there aren't great libraries in other languages and most if not all of those expose themselves to Java and other languages, but its great using the native language they were designed for. you can do some great stuff.
4. Finally its better then spending all day reading and commenting on Hacker News. :-)
> I have ported 1K+ lines of C++ to 10 or 20
> lines of Scala
a) Rewrites are usually more succinct simply because you've done the legwork before; a second solution is almost bound to be more to the point.
b) One wasn't using the initial language properly.
Sure, going from C to Haskell may lead to insanely compressed code, but C++ in conjunction with its mature standard library, Boost, and the multitude of libraries available is such an advanced and excessively paradigm-spanning language that a reduction by not one but two orders of magnitude suggests a less than perfect first draft.
It was a combination of reasons. Firstly I wrote it better the second time. I think almost any time you rewrite something even in the same language you can do it in less lines. Secondly even with boost and the STL its really hard to do some things in c++ in a few lines of code. My case was incorporating ASIO the framework to get it up and running and get its event loop working as well as the cod to parse the data that was being received. In Scala with Akka it was an actor with the IOManager and then simple text manipulation and I had replicated the functionality.
I've looked at Scala. I think it's really neat. I think it is Perl. And that's what scares me. You can solve the problem in many ways, each one getting more functional and abstract. Eventual so abstract that you can't really tell what going on.
Another issue is the fact that it interacts with the JVM. Short answer, it seems nice, but if you're functional, you can't really use the 3rd party libs because you can't be sure they will play well in the functional world. Long answer is here. http://talesfromannoyance.blogspot.com/2012/05/why-im-lookin....
I'll probably double back to Scala at some point, but I think a language off the JVM is a better option. Or at lease one that is so odd to the JVM that most people will only look for libs written in that language. For that I assume Clojure is a better choice.
Another issue is the fact that it interacts with the JVM. Short answer, it seems nice, but if you're functional, you can't really use the 3rd party libs because you can't be sure they will play well in the functional world. Long answer is here. http://talesfromannoyance.blogspot.com/2012/05/why-im-lookin....
I'll probably double back to Scala at some point, but I think a language off the JVM is a better option. Or at lease one that is so odd to the JVM that most people will only look for libs written in that language. For that I assume Clojure is a better choice.
"I've looked at Scala. I think it's really neat. I think it is Perl."
Or C++. Brilliant programmers will undoubtedly do brilliant things with it, but for a lot of folks, the word "multiparadigm" might as well read "radioactive." It's true (as someone above noted) that you can use a useful subset of the language and discard the rest, but weak programmers seldom choose correctly, and so we're left with steaming piles of spaghetti everywhere.
Ten years ago, I would have been thrilled reading Odersky's book. Nowadays, I die a little inside every time I see the phrases "language feature" and "syntactic sugar" in a language manual.
Or C++. Brilliant programmers will undoubtedly do brilliant things with it, but for a lot of folks, the word "multiparadigm" might as well read "radioactive." It's true (as someone above noted) that you can use a useful subset of the language and discard the rest, but weak programmers seldom choose correctly, and so we're left with steaming piles of spaghetti everywhere.
Ten years ago, I would have been thrilled reading Odersky's book. Nowadays, I die a little inside every time I see the phrases "language feature" and "syntactic sugar" in a language manual.
There's no limitation: you can use any 3rd party Java library from Scala. We do it in production for years, works perfectly.
It's true that Scala DSL is scary. As far I know soon (version 2.10?) you will have to add a compiler flag to enable some scary stuff. They are useful for library developers, but not too great for everyday apps.
Also you don't have to use the functional part. I saw plenty of code that looked like a nicer Java. You get less boilerplate and better performance - see http://news.ycombinator.com/item?id=2615096
Edit: The article you linked says: "... one call to some open source project that didn't worry enough about threading to even warn the user that the object is not thread safe." This would fail in any language, including Java.
It's true that Scala DSL is scary. As far I know soon (version 2.10?) you will have to add a compiler flag to enable some scary stuff. They are useful for library developers, but not too great for everyday apps.
Also you don't have to use the functional part. I saw plenty of code that looked like a nicer Java. You get less boilerplate and better performance - see http://news.ycombinator.com/item?id=2615096
Edit: The article you linked says: "... one call to some open source project that didn't worry enough about threading to even warn the user that the object is not thread safe." This would fail in any language, including Java.
You're right. But functional adds a whole new layer of "safety". The functional developer will think, "My code is functional, share nothing, messaging passing goodness. I'm fine." As but some new developer, keen on Scala, but not thinking about the older 3rd parties, adds a call from his functional goodness to the non safe, side effecting code. This will introduce a subtle, hard to trace bug. As a result, I'm not a big fan of the "it's compatible with Java" hype around these VM languages.
> I'm not a big fan of the "it's compatible with Java" hype around these VM languages.
The fact is Java interop is a fundamental feature providing great pragmatic utility as well as an absolute prerequisite for any kind of adoption of these languages. It's basically the opposite of "hype."
The fact is Java interop is a fundamental feature providing great pragmatic utility as well as an absolute prerequisite for any kind of adoption of these languages. It's basically the opposite of "hype."
I don't agree. I think that interopt should be at a higher level, like services. Putting the ability to integrate code not written for your paradigm is problematic. Pragmatic, but still problematic.
It's a lot like Node.js. Why Javascript? Because it is so self contained that it is impossible to use code that violates the paradigm because its too new. When the designer of Node looked at using straight C or another language, the legacy threat put him off. Same thing here.
It's a lot like Node.js. Why Javascript? Because it is so self contained that it is impossible to use code that violates the paradigm because its too new. When the designer of Node looked at using straight C or another language, the legacy threat put him off. Same thing here.
> I don't agree. I think that interopt should be at a higher level, like services. Putting the ability to integrate code not written for your paradigm is problematic. Pragmatic, but still problematic.
I think if you look at just about any common example of idiomatic Clojure code you'll find Java interop sprinkled all over the place. People aren't going to reimplement all those libraries in Clojure, Scala, or whatever other JVM lang you're targeting. Seamless interop is a prerequisite. I think most Clojurians feel it yields far more benefit than any problems it might introduce.
I think if you look at just about any common example of idiomatic Clojure code you'll find Java interop sprinkled all over the place. People aren't going to reimplement all those libraries in Clojure, Scala, or whatever other JVM lang you're targeting. Seamless interop is a prerequisite. I think most Clojurians feel it yields far more benefit than any problems it might introduce.
One of the major reasons why I went with Scala was the seamless Java interop.
There are 1000s of great and well tested components available. Apache, IBM, Yahoo etc. invested years in these, most of the time it just works.
There might be some libraries with issues, but so far I had only good experience with everything from security (bouncycastle) to PDF processing or geocoding.
There are 1000s of great and well tested components available. Apache, IBM, Yahoo etc. invested years in these, most of the time it just works.
There might be some libraries with issues, but so far I had only good experience with everything from security (bouncycastle) to PDF processing or geocoding.
I had a job where we needed Java interop but wanted to do functional programming. The whole team ran on Scala, of course.
I hate to speak the Word of Curse, but this was why we used monads. They gave us something of an effect-typing system in which to wrap calls to side-effecting third-party libraries.
I hate to speak the Word of Curse, but this was why we used monads. They gave us something of an effect-typing system in which to wrap calls to side-effecting third-party libraries.
Funny, I had already planned on this as a 2013 goal of mine - this blog post only reinforced it!
Coursera has a Scala course from Odersky that's worth giving a shot: https://www.coursera.org/course/progfun
Coursera has a Scala course from Odersky that's worth giving a shot: https://www.coursera.org/course/progfun
Can anyone recommend a good book on Scala? Or should the documentation be enough?
Bruce Eckel is releasing a book this year on Scala, Atomic Scala: http://www.atomicscala.com/
Eckel's Thinking in Java was a classic, I suspect he will this one out of the bag too.
The Odersky book is good as a reference, but not a great teaching tool, its too big. I watched the video lectures, they're quite good if a little dry and occasionally quite abstract especially if you're trying to apply Scala to real world problems.
Be warned though interop isn't perfect between Java and Scala, sometimes you have to resort to tricks to make things work, Hadoop APIs being a good example.
Eckel's Thinking in Java was a classic, I suspect he will this one out of the bag too.
The Odersky book is good as a reference, but not a great teaching tool, its too big. I watched the video lectures, they're quite good if a little dry and occasionally quite abstract especially if you're trying to apply Scala to real world problems.
Be warned though interop isn't perfect between Java and Scala, sometimes you have to resort to tricks to make things work, Hadoop APIs being a good example.
I recommend Programming in Scala: A Comprehensive Step-by-Step Guide http://www.amazon.com/gp/product/0981531644/ref=as_li_ss_tl?...
Clear and well written.
Programming in Scala - http://www.artima.com/shop/programming_in_scala_2ed
For more links, visit http://typesafe.com/resources
For more links, visit http://typesafe.com/resources
besides staircase book (the one from Artima.com:
the other good starter book: http://horstmann.com/scala/
detailed looks, all angles: http://www.manning.com/suereth/
the other good starter book: http://horstmann.com/scala/
detailed looks, all angles: http://www.manning.com/suereth/
There's also Scala for the impatient by Cay Horstmann.
You can get it for free from Typesafe: http://typesafe.com/resources/book/scala-for-the-impatient
You can get it for free from Typesafe: http://typesafe.com/resources/book/scala-for-the-impatient
Talks, videos, other resources: https://www.assembla.com/spaces/liftweb/wiki/Resources
Can anyone explain in less than ten words why one should learn Scala in 2013?
Foursquare, Twitter, LinkedIn, Netflix, Box.com, Nest.com, CloudPhysics, Quora, Simple, Klout
More than 10: http://www.quora.com/Startups/What-startups-or-tech-companie...
More than 10: http://www.quora.com/Startups/What-startups-or-tech-companie...
Tumblr too.
Are you suggesting that the metric of how powerful a programming language is is the quantity of companies using it?
He was asking: why should he learn Scala?
Getting hired by any of these companies can be a good enough reason for some.
Getting hired by any of these companies can be a good enough reason for some.
If you ask for an explanation in 10 words, you shouldn't complain when it doesn't address all your concerns.
You're the only person in this thread who said the word 'powerful'.
Powerful? Perhaps. Useful? Definitely.
My take on "Should I care about Scala?" question:
- If you're average or below average developer: the language does not matter. Focus on algorithms and read other people's code a lot.
- If you are using anything other than Java: consider testing Scala ( * ). You might learn great new ways of writing code, especially if you never used Functional Programming before.
- If you're above average developer programming in Java: you have to learn Scala now! Soon having "Java" on your resume without "Scala" will suggest "this person's skills are outdated" or "this is a junior developer".
( * ) I just put together a small starter project, no dependencies: https://github.com/csoma/Scala-starter
- If you're average or below average developer: the language does not matter. Focus on algorithms and read other people's code a lot.
- If you are using anything other than Java: consider testing Scala ( * ). You might learn great new ways of writing code, especially if you never used Functional Programming before.
- If you're above average developer programming in Java: you have to learn Scala now! Soon having "Java" on your resume without "Scala" will suggest "this person's skills are outdated" or "this is a junior developer".
( * ) I just put together a small starter project, no dependencies: https://github.com/csoma/Scala-starter
So my colleage recommended we look into spark, which looks pretty neat, but said a caveat would be that we would need to learn scala. My first impression of your bare minimum is "holy crap that's a lot of boilerplate for a bare minimum project". While I expected there to be some code necessary to get thing up and running, my mind spun at that 400loc build script. What the heck is that for if you are not actually doing anything? Also, I have some experience with lisp as a functional language...What are all this crazy symbols doing in your main scala file? :Unit=\n ?? I hate to be critical, but what on earth is going on here? It's not exactly welcoming, by any means.
You don't have to use the sbt script provided here.
It's just for convenience: it will automatically install Java, Scala and dependencies. Run it and you don't have to hunt down anything from the web.
If you have SBT already installed (with homebrew, MSI, apt-get etc), you don't need that file at all.
Main.scala is a "println", Build.scala sets some compiler flags and project name - this is all.
About "Unit": Scala is strongly typed. In exchange you will not have run-time type errors and also you don't need type checking unit tests.
It's just for convenience: it will automatically install Java, Scala and dependencies. Run it and you don't have to hunt down anything from the web.
If you have SBT already installed (with homebrew, MSI, apt-get etc), you don't need that file at all.
Main.scala is a "println", Build.scala sets some compiler flags and project name - this is all.
About "Unit": Scala is strongly typed. In exchange you will not have run-time type errors and also you don't need type checking unit tests.
Thanks for the response. Given it's going to the JVM I should have been more prepared for verbosity. I did a bit more reading and with your suggestions it seems my initial reaction is mostly just shock of a change from what I'm used to. I'll do some more research and will probably mellow out a bit :) Any suggestions on ebooks or otherwise to get started? Cheers!
I updated the README with some additional info.
Java and Scala have essentially the same bytecode output as both compilers were written by Martin Odersky.
There are many links below: free books, PDFs, articles, videos, tutorials.
Or just Google "The busy Java developer's guide to Scala" (article), "Scala for the impatient" (PDF), "A Tour of Scala", "An Introduction to Scala for Java Developers" (about REPL) etc.
Java and Scala have essentially the same bytecode output as both compilers were written by Martin Odersky.
There are many links below: free books, PDFs, articles, videos, tutorials.
Or just Google "The busy Java developer's guide to Scala" (article), "Scala for the impatient" (PDF), "A Tour of Scala", "An Introduction to Scala for Java Developers" (about REPL) etc.
All your wildest dreams will come true.
Does it have macros?
Yes, as of Scala 2.10 which is staged and set to be released within days.
I haven't looked at Scala lately. Has the compile speed of Scala improved? Is it comparable to Javac now?
The new SBT is a lot smarter now, my incremental builds are pretty fast.
Speed-up is part of the roadmap: http://blog.typesafe.com/getting-down-to-work
Speed-up is part of the roadmap: http://blog.typesafe.com/getting-down-to-work
It's too bad sbt isn't actually simple and is generally a disaster.
I did scala in IntelliJ. The lack of tooling reduces the value a lot. I almost prefer plain java over the sheer simplicity it has comparatively...
I did scala in IntelliJ. The lack of tooling reduces the value a lot. I almost prefer plain java over the sheer simplicity it has comparatively...
Why do you feel that sbt isn't simple/a disaster? I actually think it is the nicest of the build tools on JVM. I can set up basic projects with no configuration. Also, its triggered build feature[1] combined with its interactive console is a killer feature set that I think all build tools should have.
[1] http://www.scala-sbt.org/release/docs/Howto/triggered.html
[1] http://www.scala-sbt.org/release/docs/Howto/triggered.html
It is extremely inconsistent. The config file is a list of Scala expressions, however it is not a valid Scala code as a whole. And when you want subprojects, then suddenly the config file is not able to do that, you need to setup another directory with a totally different style of config to do that. On the other hand the interactive console is a killer feature, agreed.
I don't really think it is inconsistent. Sbt has two methods for configuring your projects. You can use a limited configuration file that has less boiler plate but also doesn't allow you to configure as much. The alternative is that you can use the full configuration that has more boilerplate but lets you configure everything. The reason I don't think this is inconsistent because the full configuration is a strict superset of of the limited configuration, both syntactically and semantically (with the exception that expressions need to be added to sequences instead of separated by blank lines).
Question, doesn't the full configuration require you to put your config stuff in multiple files? A lot of files?
The sbt 'directory of configuration' was always a bummer for me. The single pom.xml is a nice mechanism. Also maven has good CI compatibility.
The way I think of it is that maven has a good way of specifying a build. The mvn command is the slow, but complete, way of building. The normal development lifecycle is to load your maven model into an IDE then go from there, using IntelliJ's incremental build support, etc.
SBT in other words, solves a problem I don't have.
The other major problem is last year, SBT was a fucking train wreck between 0.7, 0.8, 0.9 and 0.10. Now that we are a YEAR out from that yeah sure maybe it's a lot better. I'd give it another year before I'd seriously try it again.
In the mean time, I am more interested in kotlin for sane static typed JVM languages, and clojure for real functional sauce. Scala is too slow for me :-/
The sbt 'directory of configuration' was always a bummer for me. The single pom.xml is a nice mechanism. Also maven has good CI compatibility.
The way I think of it is that maven has a good way of specifying a build. The mvn command is the slow, but complete, way of building. The normal development lifecycle is to load your maven model into an IDE then go from there, using IntelliJ's incremental build support, etc.
SBT in other words, solves a problem I don't have.
The other major problem is last year, SBT was a fucking train wreck between 0.7, 0.8, 0.9 and 0.10. Now that we are a YEAR out from that yeah sure maybe it's a lot better. I'd give it another year before I'd seriously try it again.
In the mean time, I am more interested in kotlin for sane static typed JVM languages, and clojure for real functional sauce. Scala is too slow for me :-/
SBT actually only requires 2 configuration files (even for multi-project builds). One for SBT plugins and one for everything else. You can use more files for organizational purposes but they are not necessary.
I actually like 'directory of configuration'. The SBT build configuration is actually an SBT project itself. So you can use a lot of the same tools to trouble shoot the build configuration that you would use to troubleshoot the build itself. Also, this means that in some cases (such as multi-project builds) you can use much fewer files.
I'm not sure about CI compatibility. I know that Jenkins/Hudson have SBT support but I have never tried to use it.
I actually think that way that most IDEs interact with maven builds is less complete than what you have with SBT. For example, frequently you need specify your build configuration again if you want your IDE to do incremental compilation or to run individual tests. This can be very painful if your build contains anything out of the ordinary. With SBT you just attach a remote debugger to a long running SBT process and then let SBT due all of the building and running. It takes care of the automatic incremental compilation and lets you run individual tests (which, unlike most IDEs, it can be configured to run tests automatically and it can probably run them much faster).
I can certainly understand if the previous 0.7 to 0.10 jump made you nervous about SBT. However, I think that SBT has matured a lot in the year and a half since then. I think it has finally reached a stability point where it is ready for general use. In particular I think the 0.12.x series is where this finally occurred. It has now has a steady release process and has fixed issues that SBT (along with Scala the language) had, in the past, with binary compatibility.
EDIT: lost a bunch of text in the submit, had to retype
I actually like 'directory of configuration'. The SBT build configuration is actually an SBT project itself. So you can use a lot of the same tools to trouble shoot the build configuration that you would use to troubleshoot the build itself. Also, this means that in some cases (such as multi-project builds) you can use much fewer files.
I'm not sure about CI compatibility. I know that Jenkins/Hudson have SBT support but I have never tried to use it.
I actually think that way that most IDEs interact with maven builds is less complete than what you have with SBT. For example, frequently you need specify your build configuration again if you want your IDE to do incremental compilation or to run individual tests. This can be very painful if your build contains anything out of the ordinary. With SBT you just attach a remote debugger to a long running SBT process and then let SBT due all of the building and running. It takes care of the automatic incremental compilation and lets you run individual tests (which, unlike most IDEs, it can be configured to run tests automatically and it can probably run them much faster).
I can certainly understand if the previous 0.7 to 0.10 jump made you nervous about SBT. However, I think that SBT has matured a lot in the year and a half since then. I think it has finally reached a stability point where it is ready for general use. In particular I think the 0.12.x series is where this finally occurred. It has now has a steady release process and has fixed issues that SBT (along with Scala the language) had, in the past, with binary compatibility.
EDIT: lost a bunch of text in the submit, had to retype
A bit late to this discussion, but just want to add a simple clarification that really helped me grok sbt, for posterity:
There are three types of sbt config files: .properties, .sbt, .scala.
* .properties: pure key-value text file
* .sbt: SBT DSL
* .scala: full valid Scala code
I found this little nugget buried deep in the old SBt Github wiki. Now that SBT has its own website, its partially explained in the first few lines:
http://www.scala-sbt.org/
...
* .sbt build definition uses a Scala-based "domain-specific language" (DSL)
* More advanced .scala build definitions and extensions use the full flexibility of unrestricted Scala code
...
There are three types of sbt config files: .properties, .sbt, .scala.
* .properties: pure key-value text file
* .sbt: SBT DSL
* .scala: full valid Scala code
I found this little nugget buried deep in the old SBt Github wiki. Now that SBT has its own website, its partially explained in the first few lines:
http://www.scala-sbt.org/
...
* .sbt build definition uses a Scala-based "domain-specific language" (DSL)
* More advanced .scala build definitions and extensions use the full flexibility of unrestricted Scala code
...
I prefer Gradle for all polyglot programming, and their recent release upped the Scala support in it
I tried IntelliJ, but the Scala plugin had a lot of bugs. Eclipse on the other hand is pretty good now: http://scala-ide.org/
Personally I find the SBT Scala file much simpler than a Maven XML.
Personally I find the SBT Scala file much simpler than a Maven XML.
As an former Eclipse user I had to switch to IntelliJ for the last 4 months and use it on a daily basis. I was very surprised how well the Scala plugin works. Excellent code completion, code search and refactoring options. I tried also Scala IDE in the Coursera Course and think the overall development experience of IntelliJ (with Java and Scala) is much better.
Is there some support for Maven, like generating Idea project from a pom file?
You can use the pom.xml as the IntelliJ project file, no need to process it into something else.
you can edit the pom.xml file, and have your project adjusted immediately. intellij will download and add the new jar to the classpath... BAM
intellij is really a much better experience in developing than eclipse. Lots of fit and finish things, also intellij is very keyboard-centric, so whereas eclipse had lots of graphical widgety things, intellij has all your normal day to day stuff fully keyboard accessible. It's the closest to emacs in an IDE I've ever seen.
intellij is really a much better experience in developing than eclipse. Lots of fit and finish things, also intellij is very keyboard-centric, so whereas eclipse had lots of graphical widgety things, intellij has all your normal day to day stuff fully keyboard accessible. It's the closest to emacs in an IDE I've ever seen.
I'd recommend using zinc instead if (like me) you aren't too crazy about using sbt. Zinc is basically the incremental compiler part of sbt stripped out, plus nailgun support. Large projects can still take some time to rebuild if critical dependencies were touched by a change.
i really just want intellij compatability. sbt doesnt offer that. it's incremental compiling is not useful because I do my java dev in intellij. So SBT offered me nothing that maven didnt already have, minus a few weirdo things (like putting the scala version in the name/version of a scala library).
To me, I had to give up scala due to lack of tool support. Maybe if you are used to an emacs/gcc paradigm, but I've gotten quite productive in intellij, as much or more than any C++-styled development. Why have another window with compiler output when you could have it inline with the code and using the typographic features?
I could go either way, but with Java, intellij I have 'develop and run anywhere' going on. Sure there are some super edge causes at the highest performance profiles, but that is always hardware specific, and unless you are developing on the same server class boxes you wont find it.
To me, I had to give up scala due to lack of tool support. Maybe if you are used to an emacs/gcc paradigm, but I've gotten quite productive in intellij, as much or more than any C++-styled development. Why have another window with compiler output when you could have it inline with the code and using the typographic features?
I could go either way, but with Java, intellij I have 'develop and run anywhere' going on. Sure there are some super edge causes at the highest performance profiles, but that is always hardware specific, and unless you are developing on the same server class boxes you wont find it.
Have you tried the sbt-idea plugin: https://github.com/mpeltonen/sbt-idea
I find that it works pretty good (although obviously not as good as the built in maven support).
I find that it works pretty good (although obviously not as good as the built in maven support).
No, it's very slow. If you use a SSD, it's manageable.
One thing I've found helps a LOT is encapsulation and return type annotation.
If you change a public method, SBT will recompile all users of that class even if they don't use that method. If you change a private method, it's smart enough to recompile only the one file.
Annotating your return types both saves the compiler the effort of figuring out what you meant, and also prevents you from accidentally changing the return type and forcing recompilation of a bunch of client code.
If you change a public method, SBT will recompile all users of that class even if they don't use that method. If you change a private method, it's smart enough to recompile only the one file.
Annotating your return types both saves the compiler the effort of figuring out what you meant, and also prevents you from accidentally changing the return type and forcing recompilation of a bunch of client code.
Anybody have any knowledge of how job prospects compare between Scala, Clojure and Haskell?
The article seems to imply Scala jobs are taking off (19 pages). Are Scala jobs really outpacing Clojure and Haskell?
The article seems to imply Scala jobs are taking off (19 pages). Are Scala jobs really outpacing Clojure and Haskell?
Scala seem to have much more job results on every site than Clojure and Haskell: http://www.simplyhired.com/a/jobs/list/q-scala+developer. See also Dice.com. To see startup jobs, check Startuply or Angel.co: http://www.startuply.com/#/scala%20developer/1
(To get more accurate results, you should search in-title or by tagged skill.)
(To get more accurate results, you should search in-title or by tagged skill.)
Java 8 (coming out in 2013) is going to be sprinkled with functional programming features....
...with emphasis on the sprinkled. No partial function application, for example.
Its Scala or Go in 2013 for me...
However, if you are happy with your current working language and are, instead, looking for a language that will let you grow as a programmer...well, for that sort of approach I'm not so sure Scala is the best you can do. This is just anecdotal, but I've noticed a trend where someone does something cool in Haskell, and then says "oh yeah, and with a few adjustments and given a couple of caveats, you can do it in Scala like so...". In other words, it seems to me that more of the innovation is happening in other languages and then its being brought back into Scala as almost an afterthought.
I have seen some hints that this is changing, and so I definitely won't write-off Scala. At the same time, there are an awful lot of interesting languages out there if you're looking to grow as a programmer...