A Kotlin long-term update: calm, peaceful, and productive


It’s kind of hard to believe, but we’ve been writing Kotlin at Basecamp for 20 months now! And with the first ever KotlinConf starting tomorrow, it felt like a good time to reflect on my time with Kotlin.

When I first started off with Kotlin, I was a bit…excitable. I was blown away by all the incredible things it could do. Compared to Java, it made my life so much easier and I was just much happier working with it. I was so excited to be learning this shiny new tech that I would tell anyone that would listen about all its wonders.

Now, almost two years in, things are different — in a good way.

The big thing is that I’m (mostly) past the initial “holy shit this is awesome” moments of discovery when you first come over from Java — finding out about all those crazy things you can’t do in Java, all the fantastic niceties that become your favorites, and all the little things that save you tons of time. Of course I’m still learning new stuff regularly, but for the most part I’m not running into any huge surprises day to day.

And so from that perspective Kotlin has become, well…uneventful. Wonderfully, lovably uneventful!

At its best Kotlin is extraordinarily reliable, unfussy, and pragmatic.

And while those words might not generate feelings of uncontainable excitement like I experienced at first, they paint an important picture of how awesome Kotlin is, deep down. They’re the things that really matter in a calm (and consequently a productive) work environment.

It’s awesome that the language is rock solid stable after upgrades. It’s awesome that every feature has been thoughtfully considered and prioritized against practical, real-world uses. It’s awesome that JetBrains dedicated 5+ years to get to a incredibly stable 1.0.

And it’s awesome that once you get the hang of it, Kotlin simply gets out of your way so you can get shit done, fast.

At this point in my Kotlin journey, my daily workflow is calm, peaceful, and productive because it’s uneventful. I may not be shout-from-the-rooftops excited about every little Kotlin feature anymore, but that’s OK. What really matters most to me is that Kotlin is a rock solid, stable foundation for my work now and in the future. And that’s worth a lot when shipping good work is the one true reliable measure of success.

Past and present aside, the future is bright too. The language is progressing at a fast clip (coroutines!), and the tooling around it is getting better every day. And perhaps most importantly, community involvement — blog posts, conference talks, Stack Overflow answers, and libraries — continues to expand rapidly too. These are exciting times!

I’ve had so much fun over the past couple of years building Android apps, and Kotlin’s been a big part of that. The progression from initial excitement to calm productivity to looking ahead at its bright future has been an absolute blast. I cannot wait to see what’s in store for us at KotlinConf and beyond!


If you enjoyed this post, please do hit the 👏 button below. Thanks!

We’re hard at work making the Basecamp 3 Android app better every day (in Kotlin, of course). Check it out!

Programming languages aren’t a zero sum game


Stop me if you’ve heard these before when people get to talking about programming languages…

“These features are copied this from <superior language>.”

“Nothing new here. <superior language> has done this for years.”

“This language has nothing on <superior language>, but nobody realizes it.”

<superior language> does the same thing, but better.”

I bring it up because I’ve been reading and writing a lot about Kotlin lately. And invariably someone posts a snarky comment like one those above, carrying with it a clear innuendo: my preferred programming language is better than yours.

And every time I see those I leave with the same reaction. Who gives a shit?

Now I’m not talking about people who are having constructive conversations or even just poking fun. Hell, I may have been known to take a jab at Java every once in a while. 👊

I’m talking about a subset of programmers who treat languages like it’s a zero sum game — that for one language to succeed, another (or all others) must fail. It’s like they’re on some strange crusade to prove how they were first and best at everything.

But why does it matter if a language takes the best ideas from another language and implements them? Why does it matter if another language had some feature for years and your favorite just got it? What the hell does “better” even mean when everyone has different preferences and styles?

To me programming languages are simply about doing good work, building success, and if you’re lucky, finding happiness. Many people have achieved those with Ruby, Swift, Javascript, Java, C#, Python, Go, and dozens of other languages.

I’ve been lucky enough to find that with Kotlin. It makes my work genuinely enjoyable. I find it fun and exciting to work with, and that makes me happy. But I’m no programming linguist — for all I know, every other programming language is technically “superior” to Kotlin.

But who cares? There can be many different languages that make many different people happy in many different ways. If I’m happy and having fun with a language, why do others feel the need to shit on it? Are we so insecure and unhappy that we need to tear down another language to make our favorite look better? It’s a negative, petty stance to take that has a disheartening effect on others.

Just because a language doesn’t do something brand new conceptually doesn’t mean it shouldn’t exist. If a language takes ideas and inspiration from another language, that’s a wonderful compliment to the earlier architects. And if your favorite language is “better” than mine, believe it or not, I’m super happy for you — it’s awesome that you’ve found something great!

Programming can be hard. Finding joy in work can be hard. If people can achieve success and find joy in any programming language, that’s a wonderful thing. Why not celebrate every language that can help people achieve great things (especially their own happiness!) instead of making everything a showdown?

If you really believe in your favorite programming language, focus on its merits, not the demerits of others. Avoid the temptation to make snarky comments or tear down another language. Instead, keep it positive. Spread the word on why your language is awesome. Compare and contrast fairly. Have strong opinions and challenge each other respectfully.

Trust me, there’s plenty of room for all our favorite programming languages — even Java. 😜


If this article was helpful to you, please do hit the 💚 button below. Thanks!

We’re hard at work making the Basecamp 3 Android app better every day (in Kotlin, of course). Please check it out!

Kotlin: It’s the little things

Kotlin has a bunch of amazing features, and certain ones tend to grab the headlines — things like extension functions, higher order functions, and null safety among them. And rightfully so — those are all incredibly powerful, fundamental features of the language upon which everything else builds on.


And while I love those features, there are a handful of small things you don’t hear much about that I really appreciate on a day-to-day basis.

These are simple, small niceties — the little things you do hundreds of times a day but nothing you’d consider “advanced”. They’re common sense language features that, when compared to Java, end up saving you a bunch of cognitive overhead, keystrokes, and time.

Take this simple, albeit highly contrived, example:

// Java
1 | View view = getLayoutInflater().inflate(layoutResource, group);
2 | view.setVisibility(View.GONE)
3 | System.out.println(“View " + view + " has visibility " + view.getVisibility() + ".");

// Kotlin
1 | val view = layoutInflater.inflate(layoutResource, group)
2 | view.visibility = View.GONE
3 | println(“View $view has visibility ${view.visibility}.")

At first glance the Kotlin version may look similar, as the differences are subtle. But there’s some great stuff to unpack that’ll make your life much better in the long run.

Given that example, let’s take a look at five things from Java that you’ll never need to do in Kotlin.

(Note: For clarity in the code snippets, Java is always shown first and Kotlin second. Contextual code is truncated and the diffs are bolded.)

1. Declare variable types

View view
vs.
val view

Instead of explicitly declaring a variable type (in this case a View) Kotlin simply infers it from whatever is assigned to it. You just write val or var, assign it, and get on with your day. One less thing to think about.

2. Concatenate Strings into an unreadable mess

“View " + view + " has visibility " + view.getVisibility() + "."
vs.
“View $view has visibility ${view.visibility}."

Kotlin provides String interpolation. It’s such a stupid simple feature to have that makes working with Strings much easier and more readable. It’s particularly useful for logging.

3. Call getters/setters

getLayoutInflater().inflate();
view.setVisibility(View.GONE);
view.getVisibility();
vs.
layoutInflater.inflate()
view.visibility = View.GONE
view.visibility

Kotlin provides accessors for existing Java getters and setters so that they can be used just like properties. The resulting conciseness (fewer parenthesis and get / set prefixes) improves readability considerably.

(Occasionally the Kotlin compiler can’t reconcile the getters/setters for a class and this won’t work, but that’s relatively rare.)

4. Call painfully long boilerplate methods

System.out.println();
vs.
println()

Kotlin provides you with concise convenience methods that wrap many painfully long Java calls. println is the most basic (though admittedly not the most practical) example, but Kotlin’s standard library has a boatload of useful tools that cut down on Java’s inherent verbosity.

5. Write semicolons

;
;
vs.

Need I say more?

🏅Honorable mention: Not shown, but you never have to write the new keyword ever again either!


Look, I know these aren’t mind-blowing features. But these little things, in aggregate over many months and tens of thousands of lines of code, can make a big difference in your work. It really is one of those things you have to experience to appreciate.

Put all these little things together with Kotlin’s headline features and you’re in for a real treat. 🍩


If this article was helpful to you, please do hit the 💚 button below. Thanks!

We’re hard at work making the Basecamp 3 Android app better every day (in Kotlin, of course). Please check it out!

Kotlin makes me a happier (better) programmer

What’s Kotlin’s best feature? Creating programmer happiness.


There’s been a lot of action around Kotlin lately. So one question you’ll often hear is “What’s your favorite Kotlin feature?”

And while there are many wonderful things about the language, for me it isn’t about any single technical feature.

My answer? It makes me happy.

Writing code that’s concise, clear, and expressive makes me happy. Focusing on creative solutions to business problems, not boilerplate and ceremony, makes me happy. Feeling an intense motivation to learn, which was missing in the Java days, makes me happy.

And that’s super important. Because being happy isn’t just good for the soul. It’s great for your programming skills too.

As DHH astutely pointed out many years ago in Getting Real:

Would you truly be happy working in this environment eight hours a day? This is especially important for choosing a programming language.

Happiness has a cascading effect. Happy programmers do the right thing. They write simple, readable code. They take clean, expressive, readable, elegant approaches. They have fun.

Imagine extrapolating that feeling over an extended period of time.

The more capable and friendly your language is, the happier you are. The happier you are, the better code choices you make. The better code choices you make, the better habits you build. And the better habits you build, the better programmer you become!

This is exactly what’s happened with Kotlin and me over the past year. And I’m a better programmer because of it.

DHH continues:

We found programming bliss in the language Ruby and passed it on to other developers with our framework Rails. Both share a mission statement to optimize for humans and their happiness.

In summary, your team needs to work with tools they love. Choose the fuse that gets people excited. You’ll generate excitement and motivation and a better product as a result.

This is absolutely true for Kotlin— it fits my brain and optimizes for my happiness. Working with it is just flat out fun, exciting, and motivating. It makes the quality of my work better and it makes me better.

I’ve never been a happier (or better) programmer. 😍


If this article was helpful to you, please do hit the 💚 button below. Thanks!

And if you’ve caught the Kotlin bug, you might like our other posts:

Using Kotlin to make Android APIs fun again

Kotlin announcement at Google I/O 2017

If you haven’t heard, Kotlin is now a first class citizen on Android and we couldn’t be more thrilled at Basecamp. We’ve been using Kotlin since it hit 1.0 last year and we recently got to 100% Kotlin in the Basecamp 3 Android app.

One of my favorite features in Kotlin is extension functions. They let you extend functionality in classes without inheriting from them. We make great use of extension functions at Basecamp to simplify and add clarity to Android APIs that are verbose (or that we just don’t like). Below are a few example of ways that we leverage extension functions to make Android development easier on a day-to-day basis.

Set a View height

Setting the height on a View programmatically in Android is annoying (and I’m being nice). With a Kotlin extension, you can pretend that Android makes it easy for you:

fun View.setHeight(height: Int) {
val params = layoutParams
params.height = height
layoutParams = params
}

Now when you want to set a height for your view instance, you just need to call view.setHeight(newHeight). Super easy!

Set View visibility

To make a view visible or gone by writing view.visibility = View.VISIBLE or view.visibility = View.GONE over and over is tedious. Never again! We have extension functions to make that nicer:

fun View.visible() {
visibility = View.VISIBLE
}
fun View.gone() {
visibility = View.GONE
}

Now we can just write view.visible() and view.gone() and… that’s it.

Read an Asset file into a String

Quick, how do you read one of your packaged asset file resources into a String? The answer is verbose input stream code. No thanks! We wrote an extension function:

fun AssetManager.fileAsString(subdirectory: String, filename: String): String {
return open("$subdirectory/$filename").use {
it.readBytes().toString(Charset.defaultCharset())
}
}

To retrieve the String, now we can write :

val json = context.assets.fileAsString("json", "config.json")

Retrieving a Color resource across API levels

Up until API 23, the way to retrieve a color resource was context.getColor(R.color.my_color). But starting at API 23, the signature added a new parameter for a theme resource. If you don’t need to specify a theme resource, you can make this easier on yourself so the same code can work on all API levels:

fun Context.color(@ColorRes id: Int) = when {
isAtLeastMarshmallow() -> resources.getColor(id, null)
else -> resources.getColor(id)
}

Now call context.color(R.color.my_color) anywhere you like and you have a clean wrapper. You could even make the theme resource an optional parameter with a default, since Kotlin supports this.

Inflate a Layout

Wish it was easier to inflate a new layout?

fun Context.inflate(res: Int, parent: ViewGroup? = null) : View {
return LayoutInflater.from(this).inflate(res, parent, false)
}

We can now write context.inflate(R.layout.my_layout) and avoid the mandatory parameters that Java required. (If you needed to attach your new view to the parent, you’d need account for that above.)

Use the Anko Library from JetBrains

JetBrains has already done a lot of work to make Android development easier. They’ve created many extension functions in their Anko library that you can use without writing any custom extension functions yourself.

For example, obtaining a System Service involves verbose syntax and error-prone type casting. With Anko it’s a lot easier:

val manager = context.notificationManager

That’s it. Under the hood, their extension property looks like this:

val Context.notificationManager: NotificationManager
get() = getSystemService(Context.NOTIFICATION_SERVICE) as NotificationManager

(Note that this is an extension property not an extension function — another great tool in Kotlin that you should explore.)


Android has many rich and powerful APIs, but they often cater to its legacy and limitations in Java. With Kotlin, you now have the power to shape the APIs you use most often. Imagine how nice it would be to be free of the API annoyances you’ve been living with for years!

I’d love to hear — what are some of your favorite extension functions that you’ve written for Android? Please share!


We’re hard at work making the Basecamp 3 Android app better every day (in Kotlin, of course). Please check it out!

How we made Basecamp 3’s Android app 100% Kotlin

Our best advice based on a year of real-world shipping.

Made with ❤️ in Chicago.

We started our Kotlin journey a year ago based on two hunches: that it would 1) make a huge difference in programmer happiness and 2) wildly improve our work quality and speed.

I’m happy to report that our hunches were right! As of this week, Basecamp 3’s Android app is written in 100% Kotlin. 🎉

That puts us in a unique position to share tips from the experience of going from all Java to all Kotlin. How do you get started? What should you look out for? What are the best ways to keep learning Kotlin?

Read on!

🤓 Wrap your head around the basics

First thing’s first — take some time to get acclimated with the the language. There are free resources galore, but here are a few I’d recommend:

  • Jake Wharton’s talk about Kotlin for Android. This was the lightbulb moment for me. After two watches, I really started to get it.
  • Some of my favorite Kotlin features. I wrote this a few months after we started with Kotlin. I specifically wrote it to be basic and straightforward so it’d be easy for beginners (which I was at the time!)
  • The Kotlin docs. When people tell me to read the docs, I often wince. But the Kotlin docs are legit, and are an excellent way to get acclimated.

🐢 Start slow but make it real

Writing your first bit of Kotlin is usually the hardest part of getting started.

To alleviate the pressure, people will often suggest you start with tests or perhaps a Gradle plugin. And while that’s extremely sound advice, it doesn’t work for me. It’s too boring and obscure to get excited about.

I propose something different — write real production code.

This is important because 1) it’s something you can see working in your app right away and 2) it’s more fun! That feeling of accomplishment and seeing something work shouldn’t be discounted — it builds your confidence and keeps you motivated.

Of course I don’t recommend converting a giant class all at once on your first go. Instead try converting a utility or helper method. Take a single method from one of your util classes and rewrite it in Kotlin.

Done! You now have your first bit of production ready Kotlin.

😵 Don’t try to learn the whole language at once

Kotlin has a lot of great stuff in it — so much that you might be tempted to use it all right away.

And while that can work, I wouldn’t recommend it. Instead find a few key concepts that click in your brain (not what others tell you are the best parts of the language), and practice using those to their fullest.

When I got started, three areas clicked for me: flow control (when/if/for), extension functions (add functionality to any class you want), and null safety (in particular the use of let). Focusing on just those few concepts helped me get started without feeling overwhelmed.

Don’t be afraid to start small. You need space in your brain not only to pick up new things, but to let them stick. You’re already going to be dealing with basic syntactical differences — if you try to cram all the goodness all at once, something is bound to get overwritten in your brain.

🔀 Learn from the auto converter

JetBrains has done a solid job with their Kotlin plugin and its ability to auto convert Java to Kotlin. It can get your class 60–70% of the way there, leaving you with some tuning and idiomatic/stylistic things to take care of.

There are two great ways to learn from this:

  1. Auto convert the class, but keep the Java class handy. Put them side by side, and see how the Kotlin compares. You’ll pick up a ton by just seeing how the auto converter chose to implement the Java in Kotlin.
  2. Auto convert the class, but don’t leave it in that state — while the 60% version will run, that last 40% is what makes the difference between OK code and great code. Attack everything for clarity and conciseness and look for ways to follow Kotlin idioms that the auto converter couldn’t figure out.

🤔 Question all your Java habits

As you begin writing Kotlin, the sad reality is that you’ll probably have some bad Java habits you’ll need to break.

I found myself writing terrible if/else blocks in cases where a when would be so much better. I was writing null checks around objects when a simple object?.let{} would’ve been better. And much more.

You may also have built up some strong ¯\_(ツ)_/¯ attitudes toward ugly code blocks. Because Java is so verbose, over time you may have begun to accept an occasional ugly code block as “well, that’s Java”.

Writing in Kotlin will help you see through those, but you will need to let go of the idea that ugly code is OK. Sure there will be times when ugly code may be situationally necessary, but you won’t be able to blame Java’s ceremony any more.

So regularly question whether you are doing something the “Kotlin way”. When you see code that feels long or complicated, pause and take another look at it. Over time you’ll develop new, better habits that will overwrite your Java ones.

🏕️💨 Leave the campsite cleaner than you found it (no new Java ever)

A good way to keep your code heading in the right direction is to tidy up small bits of Java as you pass by. As the saying goes, leave the campsite cleaner than you found it.

A lot of times when building something new, you’ll incidentally need to make a small change to an existing Java class — add an attribute, change a type, etc. These are often small classes like a model or utility class.

Convert them! Don’t be lazy and leave them be. This incremental, slow approach over time will save you and your team much frustration in the long run.

❄️ Use cool downs for Kotlin

A great time to work on Kotlin conversions is when you’re cooling down off a big release.

Often we’ll do our normal two week cycle, release a big feature, and then take a few days to watch for stability and customer issues.

Those couple days aren’t going to be enough time to get into something big, so it’s a great time to convert some classes to Kotlin. Over time you’ll get faster at this and be able to knock out a few classes per day.

👴🏻 Curb your enthusiasm

When you start to feel comfortable with Kotlin, you might get a little…excited. That’s a good thing! That energy and enthusiasm keeps you motivated and learning.

But it’s also easy to go overboard. I certainly did.

I‘d collapse whatever I could into single-expression functions to save lines, only to realize I was giving up clarity. I’d use too many when blocks, even in cases where a simple if/else would’ve been sufficient and clearer. I’d write extension functions galore, then realize I was creating more cognitive overhead than I was saving.

It’s wonderful to be enthusiastic and use all the tools that Kotlin gives you. But try to keep your cool (unlike me) and make sure you’re using language features for the right reasons.

💸 Don’t forget about your customers

While seeing more and more Kotlin makes your life much better, you need to keep one very important (obvious?) thing in mind: your customers don’t care.

I fully support the argument that programmer happiness leads to great code and ultimately a better product. It’s crucially important.

But as with all good things, you need to find the right balance. Converting all your Java to Kotlin might be a fun goal for you, but meanwhile your customers might be struggling with a nagging bug.

The great thing is that those two things aren’t mutually exclusive. Grab those bugs and squash them with Kotlin — it’s a win-win! (If we’re being honest, Java probably caused the bug in the first place anyway).

👯 Don’t go it alone

Depending on your company makeup, this might be easier said than done. But if you can, find a Kotlin buddy!

There is no question that I’m more proficient at Kotlin because of my buddy Jay. We regularly share ideas, review each other’s Kotlin, and poke fun at Jamie, our designer.

Sometimes that stuff happens in informal chats, but the by far the most valuable place to learn is in pull requests. You can let your code speak for itself, and the feedback can do the same. When it comes to learning Kotlin (or any new language really), this is absolutely crucial.


Alright, you made it! I know that’s quite a bit to chew on — maybe some obvious, maybe some not. But I hope it helps get you on the right path to joining us in Kotlinland!

If this article was helpful to you, please do hit the 💚 button below. Thanks!

We’re hard at work making the Basecamp 3 Android app better every day (in Kotlin, of course). Please check it out!

Some of my favorite Kotlin features (that we use a lot in Basecamp)


Team Android at Basecamp recently passed a fairly big milestone — over 25% of the Basecamp 3 Android app code base now runs on Kotlin! 🎉

Github statistics for the Basecamp 3 Android app as of 5/27/16.

We’ve found that Kotlin not only makes our code much better, but massively increases programmer happiness. All of this ensures we’re making the best app we can for the tens of thousands of Android users we support.

Given our new experiences with the language, I thought it’d be worth sharing some specifics that make the language so wonderful to work with.


Unlike most articles that introduce you to a language, I’m going to avoid using too much programming lingo. Instead, I’ll try using plain English in the hopes that it’s more accessible to beginners. 🤗

Some notes about the code examples:

  • I am by no stretch an expert in Kotlin. Read, consider, and discuss!
  • They look better on a desktop browser. You can get by on the mobile app in landscape mode, but I’d recommend breaking out your laptop to read them.
  • They’re brief and simple on purpose. Long-winded examples tend to cause confusion. Take these simple examples and extrapolate them into your own potential uses, and you’ll see a lot more power.

Let’s get started with seven of my current favorites!


1. Replacing simple if/else if/else blocks with when

One of my absolute favorites.

// Java
if (firstName.equals("Dan")) {
person.setTeam(programmers);
} else if (lastName.equals("Dihiansan")) {
person.setTeam(designers);
} else {
person.setTeam(others);
}
// Kotlin
when {
firstName == "Dan" -> person.team = programmers
lastName == "Dihiansan" -> person.team = designers
else -> person.team = others
}

when blocks are effectively the same as a simple if block, but look how much more readable that is!

There’s a similar convention when only one argument is being checked. Typically this would be a long, ugly switch/case statement in Java.

// Java
switch (firstName) {
case "Dan": person.setTeam(programmers)
break;
case "Jay": person.setTeam(programmers)
break;
case "Jamie": person.setTeam(designers)
break;
default:
person.setTeam(others)
}
// Kotlin
when (firstName) {
"Dan", "Jay" -> person.team = programmers
"Jamie" -> person.team = designers
else -> person.team = others
}

I swear, this alone is worth writing Kotlin.

2. Beautifying even the ugliest click handlers

Using Anko, a library built for Kotlin, click listeners are ridiculously easy.

I hate writing these in Java so much that I could barely bring myself to write an example here. But I soldiered on. 😭

// Java
view.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
System.out.println("This is horrible");
}
});
// Kotlin
view.onClick {
println("WAT")
}

3. No more view binding

By using the Kotlin Android Extensions, you no longer need to bind views to objects to start working with them. You can access them directly without any binding. Zero. None.

// Java
EditText composer = findViewById(R.id.composer);
composer.setText("Allo!");
// Kotlin 
view.composer.text = "Allo!"

That might not look like a big deal in isolation, but think about how much of your Activity/Controller code is the ceremony of binding a view to an object before you can start to work with that object. Kotlin bypasses all of that.

4. Functions in one line

One line functions can technically be written in Java, but you’d be going against generally accepted styles.

Kotlin’s inherent brevity makes one-liners (officially called single-expression functions) quite common, and they look great. No extra lines and no braces required.

// Java
public String fullName() {
return getFirstName() + " " + getLastName();
}
// Kotlin
fun fullName() = "${firstName} ${lastName}"

Bonus: the return object type is implied, so Kotlin will automatically know the method is returning a String without ever having to write “String” anywhere.

You may have also noticed in this example 1) no need for public and 2) string interpolation.

5. Convenience methods built on top of familiar objects

Kotlin has extended objects you’re familiar with and made them even better and packaged them into the Kotlin Standard Library.

Take String comparisons for example:

// Java
if (name.toLowerCase().contains(firstName.toLowerCase())) {
...
}
// Kotlin
if (name.contains(firstName, true)) { ... }

Not a huge difference, but enough to improve readability in many places. The standard library has tons of these kinds of tweaks. Perfect!

6. Reducing the need for`if (whatever != null)`

Null checking is so painfully common in Java that `if (whatever != null)` is probably in your recurring nightmares.

Kotlin has a number of impressive null safety features built in, and let is just one of those ways to achieve more readable code.

// Java
if (message != null) {
System.out.println(message)
}
// Kotlin
message?.let { println(it) }

Here if message is not null, Kotlin will let the block (what’s inside the braces) run. If it’s null, it just skips it.

There’s one other bit of awesomeness — notice the println(it) statement? The it keyword allows you to reference the object the let began from.

7. The Elvis operator

I mostly love this operator because of its name. It looks like this:

?: // Turn your head to the left, you may see someone familiar

Fun name aside, the real reason this is great is because it handles the common scenario of “if something is null, I want to give it a value, but otherwise just leave it alone”.

// Java
if (people == null) {
people = new ArrayList();
}
return people;
// Kotlin
return people ?: emptyArrayList()

Here if people isn’t null, it returns. If it is, it returns whatever is to the right of the Elvis operator.


So that’s just a brief look at some things that make my life better every day working with Kotlin.

If you’re interested in getting started with Kotlin, their documentation is very good, and you can poke around the interactive Kotlin Koans. I tend to struggle with things like koans (feels too much like school work!), so if you’re like me, I’d encourage you to try building something real.


We’re working really hard to make the all-new Basecamp 3 and its companion Android app as great as they can be. Check ’em out!

If this was helpful to you, please do hit the heart button below or let me know on Twitter and we’ll keep adding to this Kotlin series.

How I fell in love with a programming language

After a month with Kotlin, I finally understand what the hell DHH has been saying about Ruby all these years!

Basecamp 💖 Kotlin! (Illustration by Nate Otto)

If you know only one thing about DHH, it’s that he adores the Ruby programming language. He doesn’t just like it. He genuinely loves it. There’s zero debate about this.

I’ve always highly respected his viewpoint. But I can’t say I’ve necessarily been able to fully relate to it.

Don’t get me wrong. His rationale and explanations make perfect sense. I don’t write a lot of Ruby, but I understand why people like it a lot. It’s very pretty, expressive, and clear. It has a ton of great features. Those are the facts.

But when David talks about Ruby, he doesn’t hammer on facts. Rather, he exudes emotion. Emotion is what really cuts deep and inspires people.

Sure, he also mentions some language features, but it’s far more interesting when he excitedly talks about Ruby’s beauty, how it makes him genuinely happy, and how its transformed his life. His deep passion and enthusiasm trumps any facts or features. You can tell Ruby is, to him, something special and profound. He loves it.

And it’s usually at this point when I ask myself, “What the hell is DHH talking about?”😕


The reason I could never fully relate to David’s visceral, emotionally charged stance on Ruby is because <gulp> I’ve been a Java guy for 15+ years.

I know it’s not a particularly cool thing to say, but for all its warts, Java has served me well. And as Android’s native language, it’s been a true blessing in disguise. Who knew all those years of writing shitty webapps would turn into such an awesome mobile opportunity?

But I’ve never had strong feelings about Java itself. I liked some things about it, and I hated others. Whatever…it did the job. It was fine.

For many years my perspective was simple — I didn’t have to love Java (or whatever programming language) to do my work well.

Me and my Java.

That all changed a few months ago.

At the suggestion of my Android partner in crime, Jay, we started to look more seriously at Kotlin. It had been in the back of our minds for a while, but when it hit 1.0, we took a more serious look.

Jay jumped in first with some experiments and I played around, but I didn’t think too much more about it. I continued with my 100% Fine Artisanal Java™ features.

Then about a month ago I wrote my first Kotlin class.

It was a popup adapter in just 86 lines (17 of which were package and import statements), and I couldn’t get over how concise and readable it was. I could barely comprehend how little I wrote to get something to work.

It took me a few passes, but all of a sudden, I sensed the difference. This wasn’t just about language features or what the FAQ said the language was capable of.

This was about how I felt.

It was genuinely fun. I found myself smiling. I found myself saying “holy shit” more than a few times. I’d read code over and over and couldn’t believe how much I was accomplishing in so few lines. I couldn’t believe the clarity of the writing.

Over the next few days, I wrote more and more Kotlin. I wrote my first extension. Then I converted an existing helper class and instantly cut 94 lines. I wanted to write more!

With just a few hours of effort, I cut 94 lines without breaking a sweat.

I was amazed, excited, and having a ton of fun. I was also slightly freaked out by this weird new experience brought on by a programming language.

Then it finally dawned on me. Oh my God, this is it. This is what loving a programming language is like.

Over the next couple of weeks, that warm fuzzy feeling just grew and grew.

Whenever I’d have to work with Java, it was painful. I’d find myself rushing through it and making stupid mistakes because I had more important Kotlin files to attend to.

But when I opened the Kotlin files, I felt at home, relaxed. The code was beautiful and expressive. It was concise but powerful. I kept finding new ways to write more clearly, more directly. And I was happy!

In short, I was feeling what David had felt about Ruby for all those years. I finally understood what the hell he was talking about!


And so that’s where we’re at in the love story. It’s still really early, and who knows if this is just infatuation or true love. For all I know it’ll all come crumbling down.

But no matter how it turns out, I learned this very valuable lesson (and it only took me 15+ years)…

Nobody can truly decipher a programming language‘s greatness for you. No amount of explanation will help you feel a great language at your fingertips. They may try, but it won’t fully click. You have to experience it for yourself.

If you’re programming now, but don’t love the language you’re writing, I’d encourage you to try one that has a reputation for positive vibes: Ruby, Kotlin, Swift, or Coffeescript. And don’t just read the docs and do tutorials — pick one and try building something real.

Just remember…


Good luck. I hope you find love on your journey.


We’ve been working really hard to make the all-new Basecamp 3 and its Android app as great as they can be. Check ’em out, we hope you love them. 😀

If you have any feedback, I’d love to hear it! Email me or hit me up on Twitter and let’s chat.