[adriaanm]

(Scala tech lead here). We're doing everything within our means to improve tooling -- we agree it's crucial. Which changes would you like to see that aren't happening?

One engineer on the Scala team (Grzegorz Kossakowski) spent all of last year on a much better algorithm for incremental compilation (name hashing), sbt 0.13 was a giant leap in usability IMO, and both IDE plugins have made enormous progress over the last years (again, IMO).

[bkeroack]

I'm just starting with Scala and I find the IntelliJ Scala plugin immensely non-intuitive (and I'm a big JetBrains fan normally).

Why do I have three different, apparently non-equivalent ways to create a new project (Java->Scala, SBT, Scala Module)?

The tooling and documentation seems to assume familiarity with the Java ecosystem. I'm not a Java developer (nor do I want to be), I'm a Python guy. Am I really expected to learn Java first just so I can learn Scala?

[dragosiulian]

You might want to give the Eclipse Scala IDE a go. It's pretty easy to get started even if you're unfamiliar with Eclipse (watch the getting started video): http://scala-ide.org/download/current.html

Disclaimer: I'm the tech lead of the Scala IDE for Eclipse project

[eweise]

Choose File/New Project/Scala (sbt) and it should create an sbt project for you. Most of the scala open source projects and examples you will find on the web, use SBT so try to learn that instead of using maven or letting your IDE manage its own project.

[ssmoot]

After over a year of working with Scala and IntelliJ I don't know how to create a project from scratch through the IDE.

I just create a build.sbt, project/build.properties, and then open my SBT project in IntelliJ. Since they added SBT import support a few months ago that works really well for me.

[tormeh]

My advice would be to just drop the IDE and go for editor+compiler. IDEs are always confusing.

[kclay]

I always wondered how that worked with scala. Giving how complex some libraries could be with use of implicits and not explicitly defining the return time I always thought it would be a bit troublesome to try to program without any use of intellisense. Then again I guess the same would apply to dynamic languages such as javascript and python so maybe my concerns are not really concerns.

[ssmoot]

As a counterpoint to this popular meme: Most developers I know are VIM converts (from TextMate).

I've never seen their choice of editor improve their coding speed. Haven't seen it on videos online. The idea that being fluent in VIM makes you an all around faster/better coder and the IDE is a crutch just isn't supported by evidence IME.

I use IntelliJ. The startup is a bit slower. And the minute or so pause if I change up dependencies can be annoying (though that's rare). On the other hand I always have method signatures at my fingertips, depend a lot less on the web version (of the same documentation), can jump into compiled libraries for exploring interfaces, and instead of a fuzzy "ack-like" symbol search, I have true jump-to-definition/open-class, etc. I have access to the FSC which provides continuous feedback as well. Ensime is a pale shadow of IntelliJ IME.

Maybe those things aren't important to some people. I find it makes me very productive though, and I haven't met a VIM user who can outpace me yet (though I did see some true VS.NET/RAD-tooling masters back in the day that could put me to shame).

All this just to say: Use what works for you. If that's IntelliJ, cool. If it's VIM, great. But there's a lot of anti-IDE sentiment out there. It's just another tool. Use it if it makes sense. Judge it on it's own merits. You are not less (or more) of a coder for using IntelliJ.

As long as you stay away from Eclipse at least. I think we can all agree on that. ;-) (Seriously Eclipse... It's 2014, and you still can't easily theme your IDE with a couple clicks?)

[tormeh]

Well, I haven't tried Intellij, but in my experience the best coding environment is: 1. Visual Studio 2. gEdit

Visual Studio has incredibly good fuzzy code completion and gEdit has a total lack of features to be confused by and good font rendering. I just look at all the menus and buttons in Eclipse and I can't stand it. All this stuff can't possibly be necessary.

Since VS is not available for neither Scala nor Linux I'm left with gEdit.

[ssmoot]

IntelliJ keeps most of it's buttons hidden (in v13 at least). Might be worth a shot. I'm not entirely sure what you mean by "fuzzy code completion", but IntelliJ supports case-insensitive-in-order-partial-symbol matching.

For example, "jsfmt" with match "jsonFormat", and display the matches as I type so I can arrow-down and hit ENTER if I see what I want (or just keep typing until the list filters down to the one I want).

Implicit invocations get underlined by default as well. Which is nice since I'm rarely at loss for understanding what the compiler is doing to make this code work.

[jfb]

With ensime [1], I use my editor (Emacs) and get much more sophisticated tools than you might think possible. It's not perfect, but it provides pretty nice inspection tooling.

[1] https://github.com/ensime

[seanmcdirmid]

Making scalac aggressively incremental was a problem solved long ago. I'm presenting a paper about the continuation of that work at this year's onward.

[jondot]

Hi, thanks for taking the time to reply. My personal opinion of SBT is one that represent almost every developer I've discussed it with. Jumping to the bottom line - an experience like: rubygems, npm, lein (clojure), and that kind of build and package family is much preferred - one example is Buildr.

It's hard to pinpoint a developer 'instinct', but I think a build/dependency tool like rubygems or npm is one of the first things a developer bumps into, and becomes a central part of the experience _very early_, even before the experience of the language. With that in mind, SBT present a cryptic (some times even non-scala) like feel to it.

[bad_user]

Speaking of rubygems and npm, SBT also solves issues that neither of them are solving.

Actually npm doesn't even solve the issue of dependency management well for client-side dependencies - people apparently use Bower for that - and then just wait until you get the idea of building mixed apps. And then building stuff may not be so required for one-off JS scripts, but if you want to run a linter over your code, or to package dependencies in a single binary based on Common.js or AMD and maybe to do minification for distribution, then you're in for a world of hurt. And in case you think it's unfair to compare the clusterfuck that is Javascript's ecosystem against SBT/Scala, you may be interested to know that Scala.js (the Scala to Javascript compiler) is a pleasure to work with, one reason being that it just works with SBT.

The Ruby ecosystem is somewhat close to sane, but beginners still have to deal with gemspec versus bundler, rubygems versus Rails, rvm vs rbenv, plus the issue of native dependencies (for Scala/SBT, the only native dependency is the JVM itself and until 2016 at least Java SE 6 is all you need). And Python for example - is another example of a clusterfuck.

It's easy to forget as experienced developers that we did experience pain when we started with our current platform. Lets face it - when it comes to dependency management and build systems, we should be ashamed of ourselves. And now after having worked with other environments, SBT may suck (it does, it really does), but to me it sucks less than everything else I tried, because at least it solves most of my needs out of the box and for the edge cases there's usually a plugin available.

[ssmoot]

As a former Ruby developer: Please for the love of all that is holy do not make SBT more "Ruby-ish". Rubygems, Bundler, RVM and friends don't do anything SBT doesn't already do. And SBT does it with less set up and ceremony, fewer tools, more reliability, and less DSL "magic".

Rake is a cancer. SBT Tasks are far from straightforward, but they're certainly no more complex once you start throwing in dependencies. Tasks could use some work. But dependencies, project definitions, build settings, cross compilation, all light years ahead of anything in Ruby-land.