[acjohnson55]

I'm going to opine that I think IDE support can (and probably eventually will) be a lot better. I don't think Scala support in IntelliJ or Eclipse is where Java support was in Eclipse 10 years ago. When I first used Eclipse with Java, it was like the IDE new the entire language it was masterful at providing me all the docs and refactorings I might want. Granted, Java then had a much bigger audience than Scala now, and Scala's a much bigger language for and IDE to fully understand. But I'm finding IntelliJ improves visibly on pretty much a biweekly basis.

SBT to me is damn near disastrous, though. It's like they created this obtuse DSL for describing transformations to the immutable project settings, when they could have just used mutable features Scala already has, and obviated the need to learn a gnarly layer on top, with its weird rules and quasi-Scala syntax. The other thing that annoys the hell out of me is how difficult it is understand what keys exists in what scopes, what order tasks run in, and all the arbitrary translations between identifiers in the SBT shell versus the files themselves.

I read the entire 40+ page Getting Started guide, and I still find it incredibly frustrating when I need to do nontrivial modifications to my build process. I really hope SBT is up for a complete overhaul. I don't think it is though, because I think it provides people who invest the time to learn all the magic incantations that warm fuzzy feeling of superiority, because only they can peer through the layers of inscrutable DSL-syntax and see the elegance far beneath.

...Now that I've got that out of my system, I agree that Scala is on the rise, and we'll see these aspects improve as more people start to realize just how powerful the language is building large systems -- the horizontal and vertical scaling benefits Odersky always talks about.

[eeperson]

Have you tried SBT 0.13? I think it addresses some of your issues with SBT syntax. The DSL usage has been greatly simplified (many fewer operators to remember). Also, the identifiers are now the same in both the config files and the shell.

In older versions of SBT (SBT 0.7 and earlier) the configuration was done using immutable settings. In SBT 0.10 there was a switch to the current model. I believe this was done to make the configuration more declarative. A side of affect of this is that builds can now be easily parallelized without becoming nondeterministic. It also means that, in general, you shouldn't care what order tasks a re run in.

As far determining what keys are available in which scopes, I have always found this pretty easy to determine by using the 'inspect' command in the SBT repl. Although, perhaps I am not entirely under standing your issue here.

SBT does have a problem for specific cases when you do need tasks to run in a particular order. However, this is something that is currently intended to be addressed[1] in the SBT 1.0 release, which is scheduled for the end of this year.

[1] https://github.com/sbt/sbt/issues/1001

[acjohnson55]

I'm on 0.13.5, and I honestly don't notice much of a difference. Maybe once projects and docs fully bring themselves up to date, it will be better, but I still see some keys and scopes that have hyphens in their names in the console. Looking up cryptic operators is also a huge pain. Since `<<=` is no longer emphasized, I couldn't find it anywhere within the current manual, and yet many StackOverflow answers and readmes recommend using it to add a dependency to an existing task.

It's easy to inspect a single setting with `inspect`, but it's very unwieldy to try to examine the entire dependency tree this way.

The very un-Scala-esque syntactic rules in build.sbt files also are a huge pain for anybody who just needs to dabble. Clearly, writing Build.scala files was a major drag, but it really feels to me that the answer should have been a better pure Scala API, rather than a DSL. It's a really leaky abstraction.

View an example of my pain here: http://stackoverflow.com/questions/24286551/get-assets-to-co...

[eeperson]

The old versions of the keys and scopes with the hyphens are still present for backwards compatibility. However, you don't need to use those.

Yeah, I can certainly understand your frustration about finding info for the '<<=' operator. This is an unfortunate side effect of cleaning up the API. All of the old examples uses it but now the documentation doesn't explain it up front.

It sounds like your problem with examining the dependency tree might be solved by one of the 'inspect' sub commands (tree|uses|definitions). Running 'inspect tree <command>' will give you the entire dependency tree for '<command>'.

I'm not sure I understand your last point. What do you mean by 'better pure Scala API, rather than DSL'? Do you mean that the SBT API is not very good? Do you mean that the '.sbt' files are annoying to use? I'm a little confused since the DSL is a Scala API.

[kasey_junk]

In general, I completely agree with you. SBT has been a disaster. It was a mistake from the very beginning and a time sink the entire community simply did not need.

That said, later versions are starting to at least move in the right direction with the removal/de-emphasizing of the cryptic symbols and the consolidation of the core concepts.

I was only able to get over my hatred of sbt when I came to realize that it isn't a build tool. It is a hugely powerful task system with declarative, type safe syntax. That you can use it to build scala projects is just a side effect. Whether anyone needs a hugely powerful task system is another question...

[DCKing]

I admit that I have not taken SBT anywhere near its limits. For simple projects, later versions do present a very easy to read build system in my experience, though.