Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Learn Scala in 2013?

blog.typesafe.com

Post reply on HN
Print view View original

61–70 of 75 posts

Re: Why Learn Scala in 2013?

#61

Post by eeperson »

pkolaczk wrote: post #53
eeperson wrote: post #20

Earlier quoted context omitted.

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

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).

Re: Why Learn Scala in 2013?

#62

Post by vorg »

cageface wrote: post #15
jballanc wrote: post #8

When I first encountered Scala, my impression was that this would be Java 2.0. Two plus years later, that's still my impression. What this means to me is that if you are looking for a new work-a-day language (i.e. the language that you use to pay the bills; the ones that appear in the Tiobe top 25), then Scala is probably worth a look. However, if you are happy with your current working language and are, instead, loo…

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…

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.

Re: Why Learn Scala in 2013?

#64

Post by virmundi »

donjigweed wrote: post #52
virmundi wrote: post #45

Earlier quoted context omitted.

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 b…

> 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."

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.

Re: Why Learn Scala in 2013?

#65

Post by cageface »

vorg wrote: post #62
cageface wrote: post #15

Earlier quoted context omitted.

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…

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 c…

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.

Re: Why Learn Scala in 2013?

#66

Post by arikrak »

charlieflowers wrote: post #58

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?

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.)

Re: Why Learn Scala in 2013?

#67

Post by ryanpers »

rbehrends wrote: post #38
ryanpers wrote: post #17

Earlier quoted context omitted.

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'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.

Re: Why Learn Scala in 2013?

#68

Post by ryanpers »

Flow wrote: post #46
lgieron wrote: post #44

Earlier quoted context omitted.

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.

Re: Why Learn Scala in 2013?

#69

Post by ryanpers »

eeperson wrote: post #61
pkolaczk wrote: post #53

Earlier quoted context omitted.

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 su…

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 :-/

Re: Why Learn Scala in 2013?

#70

Post by eeperson »

ryanpers wrote: post #69
eeperson wrote: post #61

Earlier quoted context omitted.

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 su…

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 lifecyc…

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

Post reply on HN