If you’ve ever used a nightly build of Scala or Play 2 plugins, then you probably know that mixed feeling of being on the edge and using the features none of your colleagues is even aware of yet, but at the same time expecting your entire environment to crash at any moment.
Well, we sort of took care of that second part by opening of Scala and Play 2 plugins EAP. With this EAP we intent to give you a much safer way to evaluate the upcoming features and influence development. EAP cycle includes new builds every two to three weeks, so you will have plenty of time to try it and provide feedback.
To start using EAP builds just add a corresponding repository URL via Settings → Plugins → Browse repositories… → Manage repositories (just like with the nightly builds.) After that your IDE will automatically inform you about updates and install them for you. And, of course, you can always get the latest updates from Scala and Play 2 plugins EAP page and install them manually.
As some of you may know, this June the whole Scala plugin team took a break and went to Berlin to enjoy Scala Days 2014, and of course to meet IntelliJ IDEA users! Alexander Podkhalyuzin, a lead developer of the Scala plugin, used this chance to catch Jason Zaugg, a Scala rockstar and developer at Typesafe, and talk about Scala Compiler, Dotty and IntelliJ IDEA. Enjoy the interview!
Alexander: How did you first hear about Scala?
Jason: A colleague of mine saw Martin Odersky present Scala at a conference in 2008. He shared his impressions of the language at our team’s weekly tech talk, and my interest was piqued. I had already been drawn to functional programming from the perspective of a Java programmer who disliked code duplication. I’d used Ruby and Groovy on small projects, but was never happy with the compromises in type safety and performance. Scala seemed to offer the best of both worlds.
Alexander: You’ve helped the IntelliJ IDEA team a lot to improve the Scala plugin. What are your impressions about developing for IntelliJ Platform?
Jason: My contributions to the plugin were largely “scratching an itch”. Back in 2009, it was hard to sell Scala to a Java programmer who appreciated a powerful IDE. I knew a tiny bit about the IDE plugin architecture as I had built a plugin a few years earlier, and wondered how hard it would be to dive in and fix a few bugs. I learnt a lot about Scala in the process, and started to get a taste for the unique and rewarding challenge of working on programming language tooling.
I really liked the refactoring-friendly AST that underpins the IDEA architecture, together with the infrastructure for handling big code bases (indices, PSI stubs). I also liked the approach to unit testing taken in the Scala Plugin.
The downside of course is that is makes it hard to reuse the parser and typechecker from the language.
The Scala community knows that the place to be on June 16th – 18th is Scala Days 2014 conference. So, the entire team behind the IntelliJ Scala plugin went to Berlin to embrace the awesomeness of this event.
Besides attending the talks (I wish I had enough time to hear them all), we delivered our own presentation Good to Great: IntelliJ IDEA and Scala (hosted by Alexander).
We also had a booth with amazing giveaways that included IntelliJ IDEA Yo-Yos (and stickers):
Even though the distribution of Yo-Yos was, undoubtedly, our main goal, we were very happy to meet IntelliJ Scala plugin users in person. What can I say? Sometimes we had a feeling of being rockstars (thanks for all the praise, folks!), sometimes, well, we could only humbly promise to fix this or that bug…
Meeting real Scala rockstars like Martin, Jason, Josh, just to name a few, was a real pleasure.
Thanks to everyone who took care to answer our questionnaire. You’ve been very helpful, and here’s just a few stats we’ve collected: Continue reading →
We are extremely happy to let you know that the latest version of the Scala plugin (0.29.479) for the upcoming IntelliJ IDEA 13.0.2 has no false error highlighting for our own source base anymore. Moreover, a number of corresponding tests have been added to our TeamCity server, so we don’t expect to see a regression further.
The next step will be using source base of an external popular open-source project as a test for spotting false errors highlighting. That’s why we ask you for suggestions on such projects.