1. [...] Can you compare the two languages, tell us about the advantages of each in your perspective?
Barry's full question: I am Barry Burd, I am a professor at Drew University in Madison, New Jersey and I am interviewing Chris Richardson at QCon New York. Chris is a developer and architect, he is a Java champion, a JavaOne rock star and the author of “POJOs in Action” which describes how to build enterprise Java applications with frameworks such as Spring and Hibernate. He was also a founder of the original cloudfoundry.com, an early Java PaaS for EC2. He is the creator of microservices.io and he is working on his third start up, a platform for developing reactive microservices. Chris, welcome to QCon. Let’s talk about Java for a bit. Your focus is on Java, but you also are most recently focusing on Scala. Can you compare the two languages, tell us about the advantages of each in your perspective?
Oh yes. I have been using Java for practically as long as I can remember. I think from pretty much the very early days of Java in 1996, I guess. So, I am a big fan of the Java ecosystem, I think the JVM is a wonderful piece of engineering, it is a great platform and what is exciting about it in a way is that it supports the diversity of languages. So, when I was developing the first version of Cloud Foundry, the core of that was actually written in Groovy, because I just loved Groovy’s expressiveness compared to how Java was back at that time. But after a while, I ended up becoming dissatisfied with the dynamic typing in Groovy because it allowed a lot of typos and other kind of errors to slip through and that is when I discovered Scala. That was around 2009. I started dabbling with Scala because not only is it expressive, but it also gives you the safety net of static typing. So over the years, I have just been doing more and more with Scala.
2. For you, in what ways is Scala as expressive and maybe more expressive than Java?
Certainly when you compare it with Java 7 the differences are very, very clear-cut, right? A classic example is that if you want to do collection processing, in Java that means writing for loops. So, simple operations like transforming a collection, filtering or combining the elements of a collection, require a for loop with several lines of code, whereas in Scala, with its functional approach, you have a functional paradigm and so you can map over a collection with a Lambda or filter it and reduce it and so on. So, compared with Java 7, it is very concise in a lot of clear and obvious ways. But with Java 8, the introduction of Lambdas into Java was a great step forward because particularly with the stream API collection processing is comparatively concise, but I still think that if you start digging into the differences between Java 8 and Scala, you will still find that Scala is a much richer, more concise language. For instance, there is pattern matching. It is like a switch statement on steroids times 10. So, you can pattern match against a data structure with various case clauses and match and dispatch on that. Then case classes themselves, you know, with one line of code, you can define a class and with fields and a constructor and a copy method on all of that, whereas if you were to rewrite that case class in Java, that expands into a page of code, by the time you defined the fields, the constructor, the getter methods and so on. So, Scala is still ways ahead of Java 8 in terms of expressiveness.
Barry: But there is still a backbone of Java in Scala.
Oh, absolutely. A lot of power in Scala comes from the fact that you can easily leverage the vast number of mature libraries that exist inside the Java ecosystem
Yes, it is an interesting mixture. I think some of the Scala folks would argue that the core of Scala is actually quite small, but you have all these features that can combine in interesting ways to give the appearance of complexity. But having said that, I do think there is a long learning curve and I remember that for quite a while I have been using Scala for a few years and I was still learning methods in the collection interface. Every week I would discover a new useful method, because it is actually quite a rich API. But, I think there is this interesting phenomenon in the software industry that we have developed this expectation that all of our tools should be easily learnable. Like: “Oh, that is too complicated. I would actually have to spend time to figure out how to use it!” In other professions, you are actually expected to learn. I guess, say, if you wanted to become a doctor, you would actually have to memorize anatomy, which is like “Gee. I could just Google that. Why do I actually have to remember it?” But there is a belief that that actually makes you a better doctor. I think we have lost that in the software community. I think that we should actually expect to learn, right? A lot of the systems we build today are actually quite complex and we should have powerful tools with which to build those systems, right?
Another analogy: you want to do math. Math requires a lot of learning. I mean there is many, many layers of abstraction and you have calculus. But those are useful, powerful tools and I think we should apply that same way of thinking to our programming languages as well.
That is an interesting argument. I would argue that if you actually have very well designed abstractions, which you could say that is what a language is a made of, then you have these powerful building blocks with which you build your code out of. So if you have well designed abstractions, then that is a good thing, versus badly designed abstractions and sort of a weird, unnecessary complexity, then yes, I would agree with you that that is undesirable.
Barry: In other words, it is not the complexity, it is the naturalness of the complexity, it is the workability of the complexity.
Yes. One argument is “Gee, I do not understand how garbage collectors work. Therefore I am better off using malloc and free” I do not know if that is an accurate phrasing of your argument, but conceptually malloc and free are really simple, whereas in garbage collectors - there is a lot of complexity there. But in reality, it turns out that in a wide range of applications, it is so much better to program in a language with a garbage collector than it is to do manual memory management.
Barry: And that is in fact the trend in languages now. It has been for many years, I believe.
You know, it is funny. In a former life, I used to be a Lisp programmer. I actually built Lisp systems and so back in ‘88 – ’89, the team I was running built a pretty sophisticated, generational garbage collector that was running on Sun workstations with 8MB of memory and actually gave you really good performance. After that I went to C++ and it was like totally turning to the dark side having to do reference counting, with smart copy constructors or whatever the paradigm was used. Then Java came out but then it took Java a number of years to actually have a state of the art garbage collector. So, for the most part, there is this trend towards having garbage collection which is such a good thing. It is such a big step forward. Interestingly, there is a language Rust that is getting some attention and that has some other paradigms for managing memory based on who owns the object and passing it around. That seems interesting for a narrow class of applications for which garbage collectors are not applicable. But I think that for a vast majority of applications, garbage collection is a good thing.
Well, I am very excited about Lambdas. Once again, Lambdas are an incredibly old concept. I suppose the original Lisp had them back in 1958 and so it is good that they are finally being accepted as s useful thing to have in a language. So, yes, definitely. I think it is just incredibly good that Java 8 has them. I mean it really increases the expressivity of the language.
Oh, you know, it’s funny. I look at it like there are two sides to Lambdas. There is the place where you use a Lambda in place of a functional interface – that seems kind of natural. But then, from the perspective of the code that has been called, where there has been passed a Lambda, that code is being written obviously in terms of a functional interface and coming from a Java perspective it is a little unnatural. It is like I am passing in a function, but what you get is something else. On one hand it is kind of nice because it cleanly integrates in with how Java works today and it has the benefit that you can use a Lambda whenever you need a Runnable or a Callable or any of the standard interfaces that have been part of Java for many years. But when I pass in a predicate, what does that have? A test method? I mean I really can’t quite remember the details off the top of my head. That seems unnatural because compared with Scala, in which if someone passes you a function, you get a function that you can treat as a function and just call it. So, that is both good and bad.
Yes. In Oakland we have this Scala study group. So, we have been getting together once or twice a month and we learn about and discuss some aspects of Scala. Recently we started studying Haskell.
Barry: Tell me about it.
I don’t know quite how to explain or how to put it.
Barry: Purely functional.
Yes. We get this sort of an unusual situation where HelloWorld, which is sort of the basic thing you would want to write to get going, rely on advanced features in Haskell, because it is this pure functional language. It's all in terms of the IO monad. So, it is a little daunting, but on the other hand I am actually kind of excited about it in the sense that some of the code that I have written in Haskell ends up being a lot cleaner than the code that you write in Scala. So, part of me – I mean this is not an entirely serious suggestion in a way – but it is like if you are going to go hardcore functional, use Haskell instead of trying to emulate it in Scala. Though, of course, there is business issues around that, right? It would be brave to actually build a commercial system in Haskell because of the lack of Haskell developers, but it is actually something that I want to spend a chunk of time really digging into. And if nothing else, I think it would help to actually go and read the papers that have been written by the people who worked on Haskell which will actually explain a lot about why you are doing what you are doing if you are programming in a functional style in Scala.
Oh, yes. So briefly, event sourcing is a way of both structuring your business logic and persisting your business entities in an event centric way. So, rather than storing the current state of the entity in the database – like for a bank account, it would be an account table with a balance column – instead what you need to do is to store the sequence of state changing events for that entity – like the account was opened with a particular balance, credited by a certain amount of money, debited by another amount of money, and then to actually construct or reconstruct the current state, you load the events from the database and replay them.
That idea has been around for quite a long time and I have always been curious about it. But then I started doing a bunch of work with microservices where you architect a microservices system, you end up with a database per service, but then you have a problem because you want to implement a business transaction that needs to update data in multiple databases - like transfer money between accounts – and if you have a functionally decomposed and a sharded database, then that might actually involve three different databases, but you cannot use two-phase commit these days because that is unfashionable and has issues around the CAP theorem and modern infrastructure technologies, NoSQL databases and message brokers and the like do not support it. That has just got me interested in event-driven architectures in general and event sourcing in particular.
You actually write your business logic in a way such that whenever state changes, you publish an event and then that can trigger the next step in this workflow that updates the next database which triggers an event that ultimately triggers an update in another database. So, in my talk, I had an example of transferring money between bank accounts and it was this eventually consistent event-driven workflow and event sourcing is kind of a good way of writing business logic that emits events because any state change is represented by an event.
Yes, it is definitely a hot topic and it is shooting up the Gartner hype cycle towards the peak of inflated expectations, I think. But having said that, I do think that if you are building a complex system or a large system, then you should seriously consider adopting a microservice architecture. It is a way of tacking the complexity and enabling you to be agile in your development process and in your delivery process.
Barry: To conclude, I want to get back to the topic of Java because you are a Java champion, a JavaOne rock star and I want to find out from you what, in your opinion, is the entire life cycle of Java, from its start in the ‘90s
Way back, right?
Barry: Well depending on when you want to start - to, if you have a crystal ball, its eventual demise. Can you describe that, understanding of course that your crystal ball is only as good as…?
It was funny. I must admit that when Java first came out – it was in ’95 – I looked at it and said “Hmm, that is strange!” for a couple of reasons. Number one: I was kind of looking it at it from a Lisp background, specifically from a Common Lisp background, and it was like “Well, this is a simple little language. It has garbage collection, but it does not have multiple inheritance”. Then I was looking at it from a C++ perspective where it does not have templates or what you now call generics. So, initially I was not taken with it, but after a while I really was. I look at Java as being a huge step forward. I think that it is fairly under-appreciated today, especially if you are a relatively young developer and you actually cannot remember what it was like before Java. So, it actually brought modern techniques which had been around in ivory-tower languages, such as garbage collection, into the mainstream.
I mean it got us away from C for many things, it moved us away from the horror of C++ into a safe, garbage collected or managed run time environment and that was a huge step forward and it has constantly improved over the years and I think that a humongous amount of money has been spent on engineering the JVM to be this high-performance runtime. And you look at other languages and – I do not want to name any – but their runtimes are not so good. The JVM is pretty solid. So it was doing really well for a while, but for a long time it was like there was Java and there was .NET and they are like two clear camps. I forgot when it was – I think it was 2005 – there was like a Cambrian explosion. Suddenly there were these other languages starting to emerge like Ruby on Rails came out, then there was Groovy and then there was this and that and the other and then Java started to look a little dated in a sense. You know, a lot of that was due to the lack of Lambdas and some of the things around that. And then actually for a while I was kind of worried about Java in the sense that it was almost like it was kind of static for a number of years and even some of the people who were driving the language were saying “We might be done. This is kind of where it should be. It is in a good place” So I am actually excited now that particularly with Java 8 it is like “No, we are going to keep making it better”
Barry: And moving forward?
Moving forward, I actually do not know what is coming down the pipe.
Barry: No guesses?
No, I have not really been looking at roadmap stuff, I must admit.
Barry: I am not talking about road maps, I am talking about wild guesses. How long have we got with Java?
Well, I mean, when did COBOL die off?
Barry: I know, but still.
No, in terms of its future, there is sort of two parts to your perception of things. Number 1: even though we are software engineers, the software community is very fad-driven, there is fashions, right? And at some level, Java is un-cool, unfashionable and it so you would have to be programming in Node and apparently that is not so hot anymore. Now it is Go, right? So, it is a pop-culture style of technology selection - what technology is hot and what technology is cold, rather than actually going “what technology is useful”. But despite the other languages that are perhaps getting a lot more discussion, I still think that there is a humongous number of people who are still building Java applications and even if they are not building Java applications, they are building applications that run on the JVM. So, I think Java is going to evolve, the JVM is going to be the place where people are going to create powerful, new languages and so I think it has a fairly healthy future or a very healthy future.
Barry: Chris Richardson, thank you so much for the interview.
Thank you.