EN
DE
Ben Dale interviews Johnny from Bitbot Technology. They talk about the use of Kotlin in various companies and the frameworks used. They also compare Kotlin to other languages like Scala and discuss its benefits, including simplicity, readability and ease of adoption.
Front end engineers are showing interest in Kotlin due to its aspects of functional programming and strong typing. This is bridging the gap between front end and back-end languages, with some engineers transitioning to full stack or back-end development using Kotlin.
Ben:
When do you first start working with Kotlin commercially?
Johnny:
2017, it’s been a few years now.
Ben:
And what frameworks have you used across the companies where you've used it?
Johnny:
For most of the clients, it's typically spring boot as it solves 90% of the use cases very well, and it's got very wide adoption where we've had scenarios or non-functional requirements for very fast startup times we have looked to Spring Native / Grail VM to solve that use case. Spring Boot is the most common back-end JVM framework I’ve seen used, I have also seen Micronaut in action and heard of Ktor but predominantly it's Spring Boot.
Ben:
Were you quite heavily involved in the decision-making around framework selection?
Johnny:
Yes, Where clients or projects hadn't used Kotlin before I ended up recommending its use and adoption. It was always journey to attain buy-in, and needed to be the right time and place.
Ben:
Why did you decide to start working with Kotlin and implement them in those companies specifically?
Johnny:
Kotlin is how we wanted Java to be, It reduced boilerplate code so you ended up writing less code, and the code tended to be more highly readable and understandable, generally more of a joy to work with than for example, Java at the time.
Productivity gains were quite high, for the adoption of Kotlin. And people really enjoyed working with it.
Typically, when engineers did work with Kotlin, they wouldn't want to go back to Java. It was pretty much, from what I've observed across my clients, 100% adoption and not going back on it.
Ben:
When you first started working with Kotlin across your clients, did you consider any other languages at all?
Johnny:
There was of course Java. Scala was another option. However, Scala had issues of complexity and readability in terms of how it was used as a language because it allowed you to do so many different things in different ways, tended to become more complex to understand as a language. It was not favorable as an end state.
Ben:
Are there any other benefits that you saw to using Kotlin specifically over Scala?
Johnny:
Compared to Scala, the biggest difference with Kotlin is it's simpler, it's just simpler to understand.
Scala allows you to do more in its framework of language. That ultimately means that the way it tends to get used is that you end up with more difficult-to-understand code.
Scala is very powerful, however, Kotlin just made was simpler, I think for Java engineers and the wider community to sort of understand, and comprehend in terms of its end-state code that gets produced.
Ben:
Java to Kotlin is the main transition that we've seen, but we are seeing more and more companies move from other programming languages now to Kotlin, like completely non-JVM-based languages, which is quite interesting.
Johnny:
Yeah, I'd imagine there might be a few, for example, Node JS applications. We've seen front-end engineers show great interest in Kotlin because it's got aspects of functional programming that they like, but also it's got strong typing, which they also like. And they feel that's a gap in many of the front-end languages today. So we are seeing a transition of certain front-end engineers moving into either full stack or in some cases moving on to the back end on Kotlin as well.
Ben:
That's interesting. So companies can benefit from adopting Kotlin, not just for hiring back-end engineers, but also to help get front-end engineers in writing more back-end code?
Johnny:
I think so because it's a language that is simple enough in terms of its readability. It's got a crossover with many front-end engineers enjoying functional-style programming, and that's possible to do in Kotlin. It’s bridging the gap there in terms of the desire and needs for languages where with previous versions of Java there was quite a bit of resistance to learning it as a FE engineer.
The stability that the JVM provides on the back end makes it an interesting choice for server-side development. If you're thinking about Node JS applications, then, sure, it's an option for engineers that are using Node JS to move to a JVM back end because the familiarity with that sort of functional style is ticked. There is a learning curve however, with any backend engineering to consider that might be new for pure FE developers like threading models, IO / compute and security considerations that they may not have come across before so that needs to be taken into consideration. However, you've got a vast framework, very strong and stable framework for back-end development.
Ben:
What type of applications have you been using Kotlin to build?
Johnny:
From the back-end perspective, it tends to be cloud platforms comprised of microservices.
These have varied from real-time data monitoring, and data science insight platforms to financial platforms.
Ben:
Roughly how much of the company's code base would you say has been written in Kotlin?
Johnny:
I'm seeing probably somewhere adoption of around between 20 and 100% for the server side depending on the client. If we look at a company in terms of just the server-side languages, it varies from like 20% to 100%.
20% where they're probably using Java from a legacy perspective, perhaps they've got Scala or using other languages.
A number of companies are moving 100% to do Kotlin on the back-end as well, across all the disciplines that might vary.
If you're looking at the front-end and data science, then it might vary between 10 to say 80%.
Ben:
Have you seen any real barriers to adopting Kotlin to wider organizations and anyway you've overcome them?
Johnny:
I think it comes down to buy-in, and buy-in ultimately comes down to knowledge and taking the clients on a journey to understand the benefits of Kotlin, highlighting the advantages of the language allows the client to take a decision to adopt.
I think ultimately that the greatest barrier is really the exposure of the language across other technology leaders. But I'm seeing that become less and less of a hurdle to overcome. So how we've overcome it is generally taking them on the journey and that's proven successful as an approach.
Ben:
Are there particular nuances in terms of how you would influence different stakeholders?
Johnny:
Yeah, I think it's important to ensure to everyone that there's visibility of what we're doing. For example, that might be VPs or whether it's CTOs, depending on the size of the company or heads of engineering, it comes down to sharing the aspiration or the intention to open up and discuss options of technology and the benefits. But then it comes to the ground up.
I found that going bottom up is very powerful because it lets the engineers see and explore the language and therefore fall in love with it and then want to adopt it. Then the question really comes down to when the appropriate time to do that is if that makes any sense, and ensuring that the right people are a part of that decision.
Ben:
And just going back to benefits and advantages slightly, is there any data that you've tracked to demonstrate the advantages of using Kotlin to help influence stakeholders?
Johnny:
I've got a PowerPoint which has the benefits listed out. And typically, that can be a part of the whole discussion around it and framing around it that we do, but even before a brown bag. So, yeah, we can list them out.
Ben:
In the clients that you've consulted on, do you know roughly in each of those how many Kotlin developers now work in those companies?
Johnny:
It's difficult to say across the entire client. Typically I can speak for the projects I've worked on, and that might be by slightly because of the consultant aspects, but anywhere between 70% to 30% freelance to permanent.
Ben:
And what locations has it all been in the UK or not?
Johnny:
Seeing engineering teams across the US, London, and Europe, but typically what I'm seeing is clients are looking at hubs where there's centered around cities, where there's the ability to commute because I'm seeing predominantly remote but also face-to-face meetings are also being encouraged within companies, whether it's one or two days a week.
Companies are tending to offer remote. Obviously always by exception, there's people that work remote 100%. But I think there's an encouragement to also do a mix and certain engineers also enjoy that too.
Ben:
What challenges have you faced hiring Kotlin engineers?
Johnny:
Not many. We tend to take on engineers with JVM knowledge, and knowledge of the frameworks that we use tend to really go for the quality of the engineer versus just the knowledge of the language. Because Kotlin is easy to pick up, we found it straightforward to hire.
Ben:
Any context on how straightforward it is to pick up, what sort of timelines?
Johnny:
Any really good engineer picking up a language like Kotlin, I would say within hours they'll be running code.
Once you translate the semantics of the language, usually most engineers would know more than one language anyway. You'll be writing code within hours. Within days, you'll feel fairly comfortable enough to be locking out parts of an application, typically within two weeks.
You'd consider yourself well versed on the language enough to be able to get through most deliveries of most of the things you think you need to as part of your day-to-day job. That's the sort of time frame I'm seeing. So very low barrier to entry in terms of the language. If you've got familiarity with Java or Scala.
Ben:
What about if you didn't, and were coming from a completely different language?
Johnny:
If JVM is new to you, then that might take longer. Let's say you're coming in from typescript again. You'd be knocking out code within hours, I think. Then at that point, the proficiency is more about understanding the JVM, how that works, and the actual frameworks like Spring, how to wire those together.
That would take longer, and it might depend on the depend per engineer you could see it taking probably, I'd imagine it's twice to three times as long, depending on what type of programming you're doing.
If there are aspects on the server side, there are additional aspects that sometimes need to be considered, like threading that some front-end engineers may not have experience with or need to think about.
Thank you Johnny for your time and insight into Kotlin as a programming language at Bitbot Technology.