Hacker News Reader

Comment by lmm | Hacker News Reader

It would be nice to have more substantive criticisms. While I dislike SBT[1], scalaz and spray are a large part of why I enjoy scala so much. While akka was so difficult to use that it almost soured me on the whole thing, and shapeless' monstrous compile times made it practically unusable. So don't think this post represents some kind of consensus.

[1] The notion of configuring your build tool in a full programming language is alluring but ultimately a bad idea IMO; builds should be simpler and more declarative than that.

View on HN

Agreed, I would like to hear more specifics on why spray was so maligned.

Scalaz is a library that I wish I grokked better, but in all I think it has hurt as much readability as it ever hoped to help. That is, learning the concepts I fully want to do. Using the opaque names, not so much. I'd rather have that level of understanding on my target domain, not category theory. (Were I only smart enough to do both...)

I also agree regarding Akka. I want to like it, but I also feel it purposefully makes things complicated. It was hilarious to read the quote from Torvalds saying that "distributed algorithms are really hard" in context of why microkernels are hard to do, and then see Akka basically say that they make it so that all algorithms are written in a distributed way. Or sad. Not sure which.

I have found Akka and the actor model to be pretty straight forward, easy to use and understand. I think it makes writing distributed algorithms a breeze (first hand experience). Can you give more details about what you found complicated in it?

Agreed. We run an Akka cluster with 5-6 nodes as our backend, clocking in at 15Kloc. It's been running for months now with no problems. If we need to add capacity, we just provision a new EC2 instance with Vagrant/Chef and it auto-joins the cluster. Once we're done, we can remove it gracefully and the rest of the cluster just deals with it.

Distributed algorithms, in general. :)

Don't get me wrong, if what you are doing is already a distributed algorithm, then it doesn't hurt. But turning all algorithms into distributed algorithms just seems crazy. Unless, I suppose, you don't care about such things as speed and memory consumption.

Don't use the wrong tool for the job, it's as simple as that.

On Akka home page, in bold "Build powerful concurrent & distributed applications more easily."

Maven always had a number of issues -- SBT came along and solved none of them and introduced a few new ones.

I know that I'm in the vast minority, but I don't see what people find difficult about SBT. For the most part, it seems to keep itself out of the way. I would say I've found it only slightly more cumbersome than Rake, and a breath of fresh air when compared to the JVM alternatives (although I haven't had first-hand experience with Leiningen).

If used with discipline it's fine. But it ends up encouraging people to put complex logic in their build files. I prefer the rigidity of maven, where it's simply impossible to do e.g. conditional dependencies.

I can't understand that. Maven is the absolutely worst cluster fuck in terms of a build system I have ever seen.

I can't deal with Maven's position of "Oh, you want to have some tiny bit of intelligence in your build? Guess what, a) fuck you, b) write a crappy plugin for it." anymore after seeing that simple things can be indeed simple and straightforward with SBT.

> If used with discipline it's fine.

I think this is actually an astute criticism of Scala as a language, and not just the SBT library; it holds true for many of its more unconventional features.

Scala is probably not a good language choice if you/your team are prone to shooting themselves in the foot.

I am with you brother, I like SBT. Plain and simple.

The last time I used SBT, which was well over 3 years ago, the SBT file wasn't really valid scala - this may not be the case now.

sbt != scala

(eq leiningen clojure)

and I like it that way

You can choose to use the DSL (build.sbt) or a full-blown build file written in Scala (Build.scala).

We use the latter but we have a very complex build—multi-JVM testing, half-dozen subprojects.

Reply on news.ycombinator.com