Why Learn Scala in 2013? • Hacker News Board

Re: Why Learn Scala in 2013?

#71

Post by eeperson » Sun, Dec 30, 2012, 10:33 PM UTC

ryanpers wrote: post #67

rbehrends wrote: post #38

Earlier quoted context omitted.

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

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

Re: Why Learn Scala in 2013?

#72

Post by donjigweed » Mon, Dec 31, 2012, 5:40 AM UTC

virmundi wrote: post #64

donjigweed wrote: post #52

Earlier quoted context omitted.

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

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

Re: Why Learn Scala in 2013?

#73

Post by dkhenry » Mon, Dec 31, 2012, 6:31 PM UTC

apl wrote: post #49

dkhenry wrote: post #35

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

> I have ported 1K+ lines of C++ to 10 or 20 > lines of Scala I'm not doubting your claim, but as a general rule that sounds awfully steep. Maybe you got lucky (because whatever you wanted to do was a brilliant match for some standard library function or happened to be tailored to a uniquely "Scala-y" feature). In most cases of drastic code reductions upon language switch, however, it's one of two phenomena: a) Rewri…

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.

Re: Why Learn Scala in 2013?

#74

Post by CCs » Mon, Dec 31, 2012, 9:51 PM UTC

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

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.

Re: Why Learn Scala in 2013?

#75

Post by SkyMarshal » Thu, Jan 10, 2013, 10:49 PM UTC

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.

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

...