Comment by kev009 | Hacker News Reader

Comment by kev009 | Hacker News Reader

I used it exclusively on top of the Playframework for web development from 2011-2014 full time, and occasionally thereafter (job switch). I find it a very sturdy way to build web applications, and the time penalty of initial development is quickly paid off during refactor and extension.

If you are a one language trick, you might have a bad time, but if you have been exposed to multiple languages (like a typical CS education) it shouldn't be too hard to be productive and even fairly idiomatic code in a couple months.

Overwhelming pros:

* Type system is awesome, massive time saver once a project is underway

* Operator overloading very well done. Infix, postfix, prefix operators can allow for very readable, concise DSLs. Apache Spark being a great example but also many DB libs.

* Excellent frameworks like Playframework, Apache Spark to build on top of

* Being stacked on the JVM - you have access to tons of production worthy libs for just about anything

* ScalaJS.. really awesome if still young project to unify web development in a much more reliable way than weak JS and $backend.

Overwhelming cons:

* Compile time is quite bad

* Operator overloading can cause some really bizarre syntaxes like SBT. SBT is probably better than the mainstream Java build systems, but it's often a head scratcher.

* Being stacked on the JVM - you soon desire native Scala libs for everything

In 2016 I would also heavily consider Java 8 for the same team usage vs when I started using Scala in 2011. I think Java 8 really slowed the adoption of Scala down which may be worrisome for long term market share.

Thanks. God, I HATE operator overloading.

I didn't even realize Scala had it, until a few months ago when somebody was doing a demo that involved some SBT. It was quite frightening. (Did we learn NOTHING from the C++ debacle???)

Come to think of it, I've come to dislike "operators" in general (as opposed to function calls). Memorize these operator precedence rules? No thanks, just do the inside parens first, now you're trained.

C might be a good step up from assembler (though it, and its spawn need to go away as app dev languages), but I think Lisp got this aspect (no special, jacked up, operator syntax) right, in a "less is more" kind of way.

I've used a Scala S3 library that overloaded + to mean upload.

Scala doesn't have operator overloading technically. It had two orthogonal language features that give rise to operators:

1. Methods can use symbols

2. Single-arg methods can be called infix

Scala doesn't have operator precedence rules. All operators (infix methods really) are left associative unless they end in a colon in which case they are right associative. Examples

2 + 1

Is

2.+(1)

2 :: 1 :: Nil

Is

Nil.::(1).::(2)

The colon thing is the sort of thing that on paper seems hacky but in practice Just Works and is seldom used. But when you do use it it really helps a lot.

> Scala doesn't have operator precedence rules.

That's not true. The operator precedence is determined by the first character of the operator:

  (all letters)
  |
  ^
  &
  < >
  = !
  :
  + -
  * / %
  (all other special characters)

Precedence is different than associativity.

As long as I'm being cranky, let's talk about Scala/Java build tools, as well.

Curse the fool who invented "Ant", rather than figuring out how to parse a Makefile and provide a few rules or pre-set-variables to support DOS/Windows, Java compilation and such (e.g. - in a Java program to interpret a Makefile and avoid running external processes for steps that were defined as doable in the JVM). Now we have a generation raised on XML who thinks that extending a build requires creation of "Ant tasks", "Maven plugins" or similar rigor-morale.

I'm in more or less complete agreement, but you have to acknowledge that ant was a product of its era. I wrote Java code in the pre-ant era, and Makefiles sucked. Unfortunately Maven also sucks, just in different ways. Nobody has yet solved the build problem very well, not even Gradle. The build situation is even worse in the JS and Ruby worlds.

This is an area ripe for "disruption". No idea if there's any money in it though.

> In 2016 I would also heavily consider Java 8 for the same team usage vs when I started using Scala in 2011.

Out of curiosity, would Clojure be up for consideration? Why? Why not?

From my personal experience, no. I like Clojure. I like the fact that everything is map or list or set. I like that with Specter Clojure becomes really useable.

What I don't like is that tooling is either missing, terrible at battery life on Mac or incredibly complex to learn. Intellij sucks battery because it locks the high performance graphics card on. Counterclockwise is nice, but it's got a background task that spins every minute or so. That drains the battery too. Atom drains the battery because it's Chrome-based. Emacs is...Emacs. Could be nice, but holy crap the learning curve. Finally, there doesn't appear to be a great DI library like Spring. Component works, but its naming and interaction flows are confusing.

I do like Clojure. I've got a few project for Clojure around ArangoDB.

After all of this, I'm switching back to Eclipse (Spring STS), Java 1.8 and Spring. For all the language issues, I can knock the project out in a few months. I can probably train my wife quickly in it too.

Clojure is great, beautiful and simple, but it requires either good discipline and lots of tests, or good discipline and something like Clojure.typed, Schematic, or Clojure.spec. Otherwise there's just too many silly type errors at runtime.

The good thing is that "runtime" doesn't have to be production - you can experiment with live data in a REPL and flush out most of the bugs, which of course doesn't diminish the need for good tests.

I wouldn't recommend it for teams consisting only of junior developers and/or large codebases, where it can be hard to maintain good hygiene in the long run.

Reply on news.ycombinator.com