When I started programming in Scala I was naturally looking for a suitable IDE. Due to former experience and preference, I disregarded Eclipse and tried Netbeans with its Scala plugin but could not get it running properly. I had more luck with IntelliJ IDEA, that is it worked. But it is performing sluggishly and has a lot of bugs. In particular, many compiler errors are not found by IDEA, and some things it marks as errors are none. Scala’s complex type system is not all well implemented, so syntax completion is no help, either. That the Scala compiler itself runs at turtle speed was merely the last drop in my barrel of discomfort. As it was, working productively was impossible. Therefore, I decided to switch to a regular editor and simple-build-tool, something I saw mentioned everywhere people asked for good Scala IDEs.
First, I had to enable my favorite editor geany to recognise and highlight Scala code. Geany is a decent editor with a couple of IDE-esque features such as symbol tables, task lists and compiler control. It appears to be rather inflexible under the hood, so I was not able to integrate sbt completely with it in any sense (and did not really try). I did, however, create a Scala filetype definition that performs reasonable well. I have yet to discover some missing highlighting; Scala’s simple syntax certainly helps. Find the file and what geany devs make of it on sourceforge. Maybe it will be included in future releases. As of now, you have to copy it to ~/.config/geany/filedefs/ and add the line Scala=*.scala; to file /usr/share/geany/filetype_extensions.conf (paths for Ubuntu 10.10).
simple-build-tool is a real gem, I never want to code without it again. First, it is obviously a build tool, replacing make, Ant and consorts. Since it is tailored to (and written in) Scala, you do not have to bother with nasty configuration files. The few things you need to configure are coded in a convenient Scala DSL. The standard folder hierarchy is reasonable and usable. sbt handles dependencies on popular Scala libraries automatically, using scala-tools.org, and supports the most popular test frameworks. There are two major design decisions that make sbt more than just a build tool: is runs in an interactive shell and can automatically repeat any command you issue whenever you change files this command depends on. Compilation of small changes is done cleverly so you get results orders of magnitude faster than if you waited for scalac. In essence, you get new compilation or test results only a few seconds after you hit CTRL+S — and I do that a lot. If you are not convinced yet, see sbt in action.
The combination of sbt and an editor is comfortable to use, at least in a multi screen and desktop environment. On one desktop I have editor and shell with sbt maximised on one screen each. To the left, I have a browser for web research. To the right, I have a browser with APIs on one and an interactive Scala shell on the other screen. I have prints of the Scala collection overview and type hierarchy schematic (source) lying on my physical desk. That puts everything I need in comfortable distance to where the actual coding happens.
The only things I do not get in this setup are more advanced IDE features, such as syntax completion, inline documentation or refactoring. As long as major IDEs fail to do these things properly for Scala, you do not lose anything but save yourself the hassles and resource hogging that come with any of the big IDEs. If they perform better one day, I might consider switching. But I have the feeling that the rather rapid development of Scala with a history of breaking source backwards compatibility, its complex type system and implicit mechanisms as well as compiler plugins might prevent IDE developers from supporting it perfectly ever. And even if: coding without completion forces you to learn things by heart, improving your coding speed. Lacking complex refactoring forces you to think first, code after; when refactoring happens, though, you are obviously in real pain.