5 ms·
The IDE story has vastly improved in Scala, certainly nowhere near that of Java but decent nonetheless. The best way to shoot yourself in the foot is to have au
by virtualwhys 12y ago
The IDE story has vastly improved in Scala, certainly nowhere near that of Java but decent nonetheless. The best way to shoot yourself in the foot is to have automatic build turned on in your IDE and to run SBT in a separate terminal; with that approach you get dog slow compilations, blocked UI, and other hair pulling madness. When SBT is boss (i.e. IDE auto build turned off and compile target shared between the two) then you'll have a far saner development experience.
The OP hasn't been using Scala for long so many of his gripes boil down to lack of experience. You have to learn the ropes, the (myriad) corner cases, etc. of the language before things start to click.
It's like starting out in Haskell, where on earth do you even begin to understand this utterly new paradigm, much less go into production with large scala projects in it? The answer is: you don't, you learn, learn, learn until you're well grounded in the language and its frameworks; then you bet the bank on it because you're sold on its clear-as-day powers.
I'll go out on a limb and say that the only viable type safe alternatives to Scala and its ecosystem are C#/F# on .NET, and Haskell. In other words, yes, Scala has its warts, but overall is pretty much unmatched in terms of expressivity, power, and performance.
- the_af 12y agoI like Scala, but it gets me that the official IDE, Scala IDE, is so utterly broken. If you let the IDE handle the build, you'll constantly get spurious compilation errors, which in a statically typed language are unacceptable. Letting SBT do the build may work, but come on. This is the official IDE! Is there any acknowledgement in scala-ide.org that you should let SBT to do the build? Do Odersky and the guys at Typesafe use that setup, or do they suffer their IDE silently? I haven't had much luck with IntelliJ either.
- virtualwhys 12y agoCouple things to keep in mind: Java IDEs have had millions of man hours put into them; there's a reason they're rock solid reliable; that and Scala's power is a double edged sword: tooling becomes a more difficult proposition with greater language complexity. As Scala users we're basically guinea pigs in the IDE department. Having suffered from the relative stone ages of 2010 era Scala tooling I can honestly say that if you're considering picking up the language, you've come at a great time ;-) re: sbt running the show, not sure about IntelliJ but the core Scala IDE devs will drop that bit of knowledge when a user moans on the mailing lists about blocked UI, spurious syntax errors, and other bundles of joy.
- Roboprog 12y agoI would never let any IDE run my build. Builds are always scripted with explicit settings, which anyone can run, with the same results, regardless of what editor and preference settings they use. (so long as needed compilers are installed on server/workstation)
- the_af 12y agoI think we're not using the word "build" in the same sense. I meant when writing code with your IDE, not when building the deployable artifact. In Eclipse this would be in Project -> Build Automatically; I forget the setting in IntelliJ. Incremental compilation in the IDE is useful because you see errors as you type. This is an entirely separate issue from reproducible builds, etc.
- Roboprog 12y agoOK, so you are talking about the ability of the IDE to scan (and parse where needed) the code and libraries to generate a symbol table for validation, auto-completion and definition / usage look-up.
- the_af 12y agoYes, but note that for this the IDE needs compilation, which is why I used the word "build" (perhaps confusingly). Eclipse for Java does this perfectly, and I assume many other IDEs do so too. Scala IDE, which is built on top of Eclipse, does a terrible job at this. For a statically typed language such as Scala, it's aggravating when your tools report spurious compilation errors.
- CmonDev 12y agoYes, when thinking about a modern managed multi-paradigm, multi-typed, multi-platform language the choice is pretty much limited to Scala, C# and F#.