Clojure in Oslo: Telenor Digital
Communicating with Clojure
This post is part of our Clojure In series, taking an in-depth look at companies across Europe who have adopted Clojure. In this article we look at Telenor Digital, a company within Telenor; Telenor is a communications giant with headquarters in Oslo.
The overall effect Clojure has had on me is that I've been rejuvenated
A communications giant
Telenor is a telecommunications company providing services in 13 different countries serving over 200 million customers worldwide. The company has over 35K employees and uses a wealth of different technologies including Clojure.
Jon: So what do you three do at Telenor?
Joel: We work for Telenor Digital providing a global back-end and digital services for telcos in the Telenor Group. We have about 300 engineers and provide services such as CONNECT Payment and CONNECT ID - payment and login solutions.
Jon: What's it like to work at Telenor Digital?
Joel: It's a super international company; it's a Norwegian company but less than 50% of the employees are Norwegian.
Erik: It feels like a new angle on diversity. There are no 'foreigners' here, everyone speaks English. It's a really cool experience.
Joel: Our in-house development teams have a real start-up culture, for instance we sometimes start new services such as appear.in.
Jon: Cool, you guys built appear.in? (We were using appear.in to facilitate this interview).
Erik: Yes. appear.in was invented here and not made to order. It was launched without asking for permission which showcases some of the spirit inside of Telenor digital.
Joel: In our team - the Data Insights team - we report on how all our various products are performing. Everything we build now uses Clojure and maybe ClojureScript.
We're a team of 12 in Digital Global Services of Telenor Digital. The other teams here mostly use Java, but there are a few using different languages such as Go and Node.js. We're the only ones using Clojure.
The Clojure journey
Jon: How did the Clojure journey start at Telenor?
Joel: It started with some consultants here being interested in using Clojure and they got the go ahead. It started like how it does at so many other places; using it for small independent pieces; small utilities such as data import/processing jobs.
It has increased since then; when new services or rewrites happen we use Clojure. By now our team has only one Java left service in production; everything else is written in Clojure.
Jon: When did you yourselves start using it?
Joel: I joined Telenor Digital because of Clojure. I did search for Clojure on Stackoverflow jobs and I found this job.
Jon: What got you originally into Clojure?
Joel: I've been interested in programming languages for a long time having tried everything from Ruby, OCaml, Standard ML, Common Lisp, C and C++, Java, and eventually Clojure.
I wanted to get back to Lisp but Common Lisp felt stagnant, with no leadership or clear path to improve the situation (for example, by standardizing on a single syntax for hash-maps), and there wasn't an awesome story on how to manage projects and dependencies, although this has improved since. I also wanted a language with a good story for multi-threading, which wasn't possible to do in a portable way across implementations and operating systems.
Clojure gets that for free through the JVM, and the persistent data structures brought something new with just the right amount of additional syntax for my liking.
Jon: How do other teams perceive your teams' use of Clojure?
Joel: Most of the teams in our division are 100% Java - they like Java and are a little bit sceptical of Clojure. Some are interested and some are curious - we are collaborating with another team and they are starting to make contributions. One person needed some help with the IDEs etc but he is making changes on his own.
I hope to spread to Clojure within the company. We're doing lots of hiring and recruitment, inviting people if we have workshops and training and so on.
Jon: What are the actual advantages of Clojure that you see?
Joel: So much shorter time to write code. In our team - Data Insights - there is lots of data processing. It's very useful to have immutability baked in and being able to parallelise code very easily.
The functional mindset is a requirement for the data processing frameworks we use such as Spark and Flink where you use functional operations frequently; map, reduce etc. There is also laziness; not executing computations until they are absolutely required. Developers need to be comfortable with laziness to use these frameworks.
Erik: The overall effect Clojure has had on me is that I've been rejuvenated. I look forward to work each day; looking forward to working on code - playing with it and making it beautiful which is not possible in Java the way it is in Clojure.
Jon: How do you go about upskilling developers to learn Clojure?
I read the Joy of Clojure and found it really interesting. I was sceptical at first - all the parens and the syntax. The first week I felt like: 'why should I use this thing?' I wanted to continue using Angular.js, but Joel convinced me to use ClojureScript.
Joel: I thought I gave you the choice.
Paul: In a week or two weeks I was loving it; Clojure is a lot of fun to write. Namespaces make applications really modular, making the code really easy to maintain.
Joel: It helps that ClojureScript is structured as a real program.
Paul: Yes, with Clojure and ClojureScript it's like working on the same thing. It was crazy - in a couple of weeks I felt completely fluent, where as before I'd hated the parens.
Erik: When you onboard people you need to teach them to use the REPL fluently. They need to understand the way of working in the REPL to reap the benefits of code becoming easier to play with which ultimately leads to better code. This isn't immediately evident for people new to Clojure.
Jon: How do you go about hiring?
Joel: We look for good developers, not necessarily Clojure developers. We look for people with experience of functional programming and an interest in learning languages, as opposed to people that just want to continue with the tools they know.
Erik: As Joel said: he joined this company because of Clojure.
Jon: What IDE do you use?
Joel: We have two Emacs lovers, one Emacs novice, and four developers using Cursive.
Paul: I tried Emacs but it was too much work to learn both Emacs and Clojure at same time. I switched to Intellij and Cursive and it was amazing. For people that don't want to learn Emacs, try Cursive - they will love it.
Erik: For each new person that joins we let them learn Clojure first. If they want to learn Emacs also then fine, but it's harsh to put them on Emacs and Clojure directly.
I would recommend Emacs though. I've been using Emacs for 26 years and I love it; I started using it in 1990.
Jon: What do you guys use for the front-end?
Joel: We use Om for our front-end. If I could do over I'd look into Reagent. But Om is nice, it's worked well for us.
State of Clojure?
Jon: What's the state of Clojure in Norway?
Joel: - At the last EuroClojure I went to, I met a lot of people from Oslo. There's a stable community, although it's a bit non-visible.
There's a functional programming meetup in Oslo and a lot of people are interested in Clojure.
Jon: What's your opinion on the overall state of Clojure?.
Joel: I appreciate the backwards compatibility of Clojure, especially when compared to Scala which breaks binary compatibility all the time.
Erik: I enjoy the work that Alex Miller does - he's the face of Clojure for the community. He has a difficult job; there's a lot of people with strong opinions and he manages them really well.
What really excites me about Clojure is that it is not very exciting. It's rock solid and let's you do your job.
Joel: I would said it is exciting but not surprising.
Jon: Any recent developments in the Clojure language or ecosystem that interest you? Please don't say Spec because everyone does!
Jon: Any frustrations with Clojure?
Joel: We could use better error messages. There is room for more batteries included pre-packaged frameworks, recommended libraries etc.
I've noticed that what you read in books doesn't always match current best practices. For example what are the best practices for logging? We have things like Chestnut and Luminus, but more official/central recommendations on best practices and endorsed libraries would be appreciated.
Jon: What technologies would you like to give a shout-out to?
Jon: What do you think of Mount? I haven't heard of it being used that often.
Joel: It so easy to get started with and just works. You don't need to deal with protocols etc. We're very happy with it; Mount feels more Clojure-ry than Component.
Sign up to the JUXT newsletter