Brief Story of Kotlin @ Domo: - First championed b...
# utah
Brief Story of Kotlin @ Domo: - First championed by a handful of enthusiasts about 2-3 years ago as a better alternative to Java for our server-side development - Adopted by a couple of teams as our preferred server-side language - Several new Spring-based services implemented 100% in Kotlin - Currently used by ~10 developers on 3 teams (that I know of). - Adoption has not been free of impediments - a couple of key Kotlin developers and advocates have departed, and broader adoption within the company remains a real challenge. There also exist some detractors who do not want to see any change to accepted Java code and design patterns. - All things considered, Kotlin has made a significant difference in improving the readability and maintainability of code in our Kotlin services, and has eliminated a lot of Java boilerplate. Wherever we rewrite existing Java code with Kotlin, we consistently eliminate about 2/3 of the overall number of lines that were previously required.
🔥 2
💯 1
I'm curious about the reasons the java devs give for digging in their heels. Can you expand on that? Thanks for the post, btw, it has been quiet in here...
A couple of reasons why I see Kotlin not being adopted more widely at Domo yet: 1. Many other teams don't overlap with our existing Kotlin projects, and simply don't have anyone on their side championing the benefits of Kotlin adoption. I think some are receptive, if they were given the right opportunity. 2. On my team and adjacent teams that have started to use Kotlin, we haven't yet won over the development manager one level up. We have written several projects with Kotlin, but he has stated he does not want any further new projects to use Kotlin at this time
To be fair, he is an excellent manager who gets things delivered quickly. However, we are also delivering software that regularly suffers from known pitfalls and code smells common in OOP Java. It is verbose, imperative, unreadable, prone to NPE and difficult to maintain.
any use of functional and declarative style code gets a negative response from him. Lambdas are discouraged. Expressive Kotlin features that don't exist in java are frowned upon (e.g. idiomatic when(), if/else, try, etc)
our java code is full of 100-500 line methods (or longer), has if/else and other control flow statements nested to an unreasonable / unreadable depth in many cases. The usual. I can't believe I have to make a case for Kotlin's readability, given what the code base currently looks like, but I do.
Main Reasons given for not using kotlin are: • It is unreadable and takes a lot of time for java developers to learn kotlin • The average hiree coming straight from college will not be able to understand kotlin and be able to pick it up in a reasonable amount of time