Hacker News Reader

SBT is probably the best example of the total immaturity of the Scala community in terms of real-world engineering. Hey, we're building for the JVM, we've got Maven, it's arguably the best solution in any language for a very difficult problem that has stopped entire language ecosystems in their tracks. Let's rewrite it, from scratch, using unproven concepts! And put 'simple' in the title!

Afterwards, we'll call XML ugly and claim to be more 'functional', without even noticing that Maven's pom format is actually a nested s-expression structure that happens to use angle brackets.

> we've got Maven, it's arguably the best solution in any language for a very difficult problem that has stopped entire language ecosystems in their tracks

Wait wut? Are you drunk? :-)

My experience is that SBT works great, while Maven tries to fight you at every step. SBT developers try to help you get you work done, while questions in the Maven community are usually answered with bullshit responses.

Maven (like Eclipse) are a great example of what's wrong in the Java community.

Not yet. You wanna show me the better solution than Maven? Something that manages multi-module projects, with various versions of dependencies, and packaging as war/jar/tgz/whatever?

I've probably spent way more time cursing Maven than praising it, but that's the nature of a build/packaging/dependency tool, it's like a sysadmin, you're either not noticing it's there or cursing its parental lineage.

What's SBT offer over maven? Lack of XML, with more trendy markup and new bugs? Like I said, immature.

> What's SBT offer over maven? Lack of XML, with more trendy markup and new bugs? Like I said, immature.

Maybe you should do some research and figure out the answer for yourself, then you wouldn't jump to weird conclusions.

If you're motivated to wade this far down the thread, but can't be bothered to explain one concrete benefit in one sentence, I've gotta assume it's pretty difficult to come up with one.

It's pretty easy to come up with multiple ones.

Just one, to not prevent you from doing your own research:

Type-checked build definitions.

I lost days to debugging broken Maven setups were some tags were misspelled or placed at the wrong position, and Maven just gave a shit about it.

SBT immediately tells you what's the issue.

Another one: It's completely painless to introduce new settings/keys/commands/tasks. Want to have a deployment step which moves some files to the right place after compilation? 3 lines of code. 3 lines, not a god damn Maven plugin.

Well, we seem to disagree on the usefulness of those items and the quality of SBT's solutions vs the pain of rebuilding an entire new build/deployment stack and fighting through all the bugs you've created.

We'll just have to see how history unfolds. IMO sbt already hit the high-water mark and is receding, lots of shops using scala today advocate using mvn.

EDIT: You inspired me to do some research. Apparently, senior engineers from typesafe do hour-long presentations named "Effective SBT" at Scala Dayz conferences. Truly the simplest of build tools.

> IMO sbt already hit the high-water mark and is receding, lots of shops using scala today advocate using mvn.

I haven't seen that at all in practice. I think that's just a bit of noise on the internet.

SBT keeps getting better, and many shops which originally opted to stay with Maven are now moving to SBT, because it's just so much better than Maven.

Not sure what your problem is. Even back in the 0.7 days, SBT was better than Maven. I'll change profession before I ever move back to Maven.

Oh, let's have a look what that "senior Typesafe" guy has to say about SBT vs. Maven:

  Well, coming from first contributing to the maven-scala-
  plugin, then eclipse, then sbt itself, I can tell you that
  some of the things we do in sbt just fundamentally won't 
  work in Maven, otherwise I'd have tried them.
  If you'd like my branch list of broken experiments, I can 
  share them, but be assured that I personally was an sbt 
  hater before learning the tool.

  All of the complaints of syntax and documentation DO 
  represent a younger project vs. a more mature one.  
  However, architecturally, I'm placing my money on sbt over 
  maven.  THat's not to say sbt is perfect, but I think most 
  of these complaints are adressible.

In the previous project I worked in, we switched to Dropwizard for a lot of services that now run in production. We were already using Jersey, Guava, etc., but Dropwizard gives some nice extra glue and standardized our configuration and gave us a standardized way to instrument services (via metrics). It can really recommend it for RESTful services.

Also, there is a nice Maven plugin that creates Ubuntu packages from Dropwizard projects:

https://github.com/reines/dropwizard-debpkg-maven-plugin

Your experience around the performance of SBT (and possibly, by extension, Play compilation) runs very much counter to my experience. I have found SBT to be much faster than Maven (thanks largely to the console). There may be something wrong with your project that is causing it to build so slowly. Are you seeing the compilation go very slowly or is it more issues with artifact resolution?

I've used SBT with and without Play 2, and it was a pain every time. On a standalone app, resolving dependencies was the big time consuming part, but compilation was slow too. I'm not talking like 3x slower than Maven, but it feels slower.

We've had around 7 different projects using SBT at one point (most are now using Maven), and it was always that painful for us. We've mitigated the issue with resolution by using our Nexus server as a proxy, it helped a bit.

But other than performance, over the year we've had a lot of random issues with caching. Things like a dependency not found in the ivy cache which required us to completely remove the cache for that artifact. A "test" run which found no tests to run, which required us to remove the target directory for some reason.

Play 2 was just the icing on the cake: it has a lot of dependencies, and the routes in Scala takes what feels like forever to compile, not joking it feels like that single route file takes as much time to compile as 30 java files.

I'm sure it's not the experience of everyone, seeing how many people enjoy using Play 2/SBT but for our organization it wasn't a good choice.

Yeah, historically the artifact resolution has been kind of slow if you have several sub projects. However, there was just a new release of SBT that added a bunch of improvements for this[1].

[1] http://typesafe.com/blog/improved-dependency-management-with...

Play 2 really is a different framework than Play 1, which was what brought Play its fame. If you like Play 1, try the Ninja Framework. It has a cheesy name but it has the super fast development cycle that Play 1 used to have.