Jonas Bonér on real-world Scala
Jonas Bonér has posted an introduction to a series about how his company has used Scala for their product. I’m looking forward to reading the series. Worth noting is that he said his team picked up Scala quite quickly.
I’m very much looking forward to reading about the best practices and design choices they made. I’d also like to hear about how they dealt with their Java stack. Specifically, whether they put anything between the Java frameworks or called them directly from their Scala application.
Use git tags
I’m quite fond of Git. The home of Git projects on the web is GitHub. A lot of good projects, mostly Ruby and JavaScript related, but also others. It’s a popular home for dotfiles as well.
Unfortunately, the practice of tagging releases isn’t as common as it should be. Tags are pretty much just aliases for commits, though they can be annotated and even GPG signed (so, for example, no one can fake a Linux kernel tag by Linus). Part of that may be that Git doesn’t push tags by default.
But pushing a tag is easy, just add the –tags parameter to the push and it’ll push all your tags.
git push --tags origin master
Or, if you only want to push a single tag, you can push the tag directly.
git push origin mynewtag
Unlike Subversion tags, these won’t create whole new copies of the repository that can accidentally be committed to.
Tags are very useful when dealing with different releases of a project and you find yourself wondering what code was like in a previous version or a version past what you’re currently using. Being able to browse the source directly on a site like GitHub is very valuable, but having to look up the what commit has a comment like “bumping version” is annoying and time consuming. Not to mention that it’s more difficult to trust any old comment.
So please tag your releases. It doesn’t take a lot of effort and makes life easier for people using your project.
Scala/JRuby interoperability
This interesting post by Daniel Spiewak covers a bit of the current state of Scala/JRuby interoperability and suggests a couple ways to improve it. I think interoperability between JVM languages that aren’t Java are the next biggest improvement that should be focused on.
Groovy, JRuby, Scala and the others are generally good languages with good (or at least decent) interoperability with Java, but things get hairy when the various hacks start getting exposed to eachother. This is especially visible in the first example Spiewak shows, on calling the Scala + operator from JRuby.
Hopefully we’ll continue to see work being on this field. I’d love to see the same thing done for calling Scala from Groovy.
Why Scala?
This thread on the scala-debate mailing list (originally from scala-user) should prove an interesting discussion. It basically covers the two key elements for language adoption in the Java mindshare space: Tool support and stable backing.
Erik Engbrecht makes the good point that tool support is coming along and the people working on Scala are paid to do so.
The tool support is definitely still in active development. There’s a general feature race going on between the big three IDEs (Eclipse, NetBeans and IDEA) to support as many languages as possible. With all it’s static analysis, Scala has a lot of potential for IDE support. The key, however, is going to be getting past Java’s support. All the extra overhead static typing and analysis brings to the table requires the IDE to handle a lot of things developers can otherwise ignore with dynamic languages. For Scala to compete with Java, it’s going to need to equal Java on the stuff that’s similar, and provide a better view for developers on all the implicit stuff.
I don’t think a bunch of researchers working on the language is quite as solid an endorsement as corporate investment, but that doesn’t mean it’s not worth a lot. For a lot of people it’s going to stand up better as an argument than “the BDFL will not abandon this language, because it’s his baby.”
