Scala devs: Doing the R&D so Java people don’t have to
First established in 2013 as a way of nailing down a set of core principles for modern application infrastructure, the first Reactive Manifesto has been the catalyst for much healthy debate among developers. Like any first release however, the Manifesto proved to be wanting in certain areas. This September, Jonas Boner announced on the Typesafe blog that a second version was in the works, moving away from the original pillars of Event-Driven, Scalable, Resilient and Responsive to Responsive, Resilient, Message-Driven and Elastic, which can be considered “more accurately reflect the core value of Reactive design.” Voxxed recently met with fellow Typesafer Jamie Allen for the full story on the revision of Reactive, as well as the latest news from the Scala enterprise ship.
Voxxed: The Reactive Manifesto has been successful in generating a lot of debate in the industry. What are the key reasons for the update?
Looking at what Martin Thompson has said with regards to revising reactive, it seems like the objective is to make it less-academic, more accessible – and shorter. The words are clearer, there are no more drawn-out explanations, trying to make clear a word that wasn’t – and that ‘wordsmithing’ and the involvement of everybody in the community helping us refined it. It is on GitHub, it can have pull requests, and it invites people to contribute opinions, even if they don’t contribute verbiage. So, the downsizing of it and the higher clarity, certainly makes it a more valuable document than it was to begin with.
Simultaneously, whilst you’re ‘de-academising’ the manifesto, Martin Thompson has said he wants to up the geek levels.
It’s true. It’s so easy to get caught up in technology – I don’t want to use the word ‘lust’ – but…the desire to play with something that’s new and exciting, that’s teaching you things…And it’s great for a developer to experience that, but at the same time, you need to put stuff into production, and you need to do it quickly, so using technology that aren’t proving, technologies that are actually hindering your ability to do that quickly because you’ve got to ramp up and learn, etc. On the other hand, a little bit of hipsterism isn’t a bad idea, because you do need to have your eyes open to when there’s a new way to better solve a problem.
You’re clearly a Scala guy – what impact do you think Java 8 will have (or indeed has had) on the growth of the language?
I don’t know, there are a lot of people who, once they experience Scala, don’t ever want to go back to Java. Either it’s the lambdas, or the defender methods, or the optional…those are all wonderful things. But, I often joke, and this is a joke, but it’s sort of true, that if Oracle really had a desire to get rid of Scala, what they would have gone after are case classes, where we synthesise a lot of information about data, so you don’t have to write all that yourself – which you still have to do in Java. Since they didn’t go after that, I didn’t feel like they were going after Scala so much as evolving their own language to do the things that people wanted to be able to do. So I don’t believe that most Scala developers will go, “Oh great, I can go back to Java.”
And there is a certain amount of, it’s almost like we did the R&D for them. In terms of market penetration, and whether or not certain things could be adopted into Java, because one of the great design principles of Java is that we do this, and that’s what we do, and we try not to get into all the stuff that makes things hairy. I think what Scala did show was that people can do that – in mass, and that emboldened the Java guys to do things that maybe they wanted to do before, but weren’t sure if it would work.
And obviously it helps that Scala is developed with this huge community pushing it forward in leaps and bounds, unlike Java, which has to go a little slower…
Yeah, and actually, we’re seeing the exact same thing happening in the Scala community now, where Scala is all focused on being enterprise ready at this point, and we’re hardening the compiler, and all the decisions we’re making going forward at this point at are all about enterprise and having a language that isn’t so much about trying new things, as doing what we do now, as best as possible. And there are people in the Scala community who are frustrated by that, saying well, I want these things.
So breaking off into things like Dotty…
Yeah, and the Typelevel group, for example. They have very specific ideas about what they want to do…and that kind of innovation can’t be downplayed. As a matter of fact, the Typelevel group were something like fork number 750 of the language, and it really wasn’t news to Typesafe that a fork had happened.
At the same time, having them focus on the things they want, and contribute that in a compiler implementation that is merge compatible with our Typesafe compiler for Scala, is great, because they can innovate, and they can find new ways to do incredible things – and we strongly encourage them to ‘carry on forking’ while we do the dirty work of the enterprise, and keep everybody happy in that domain. We can’t have large corporations who want to adopt Scala afraid that it’ll blow up on them because of some fancy new things that are being added. They’ve got to be battle tested.
What’s you opinion on Ceylon? In some respects, in filling that modularity gap, it’s doing some of that JVM-Java hole filling that Scala used to do with lambdas.
I don’t know a lot about Ceylon. I’ve looked at the language specification, but I don’t hear much about it. I don’t hear any adoption stories, and not to downplay what the people at Red Hat have tried to do with the language, but it didn’t advance the conversation. Kotlin tried to advance the conversation, believe it or not, but there have been times when people from Typesafe have had conversations with them to try to figure out ways to do what they want to do. But, at the same time, the original specification that they said they wanted for Kotlin, and what was being pushed out, were two different beasts.
As long as there’s advancement happening, instead of people saying, I don’t want to advance, I want to coalesce around these core features, that doesn’t tend to drive people to your language. Especially if there’s already one on that platform that does those things, just because there’s the cognitive overhead of having to learn that language to do something I can already do.
Finally, you’re co-writing a book on Reactive Patterns. What’s the inspiration for this?
There have been guiding design principles in software for a very long time, and people look for them and how they’re supposed to develop systems. For object oriented systems, everybody looks to the gang of four book called ‘Design Patterns’. In some respects those patterns are now dated by approaches that are more functional, as opposed to object oriented, and they are no longer necessarily relevant. Some of the terms are relevant for things you do in functional programming – you can call that sort of like a command pattern or a decorator, but nobody does. What we’re seeing with reactive that, while the manifesto is out, and the concepts are defined, there are still a lot of questions about what is the best way to test a reactive system? What is the best way to think about elasticity? And it’s interesting because as the reactive manifesto has changed, Roland and I have had to make sure that the book has reflected those changes as well.