Nushell has the in operator to check if a value is an element of list. With the same in operator you can check if a string is a substring of another string. And finally you can use the in operator to check if a key is in a record. When you use the operator the value you want to check is defined before the operator and the list, other string or record is defined after the operator.
The not-in operator is the opposite of the in operator and checks if a value is not in list or other string or key in a record.
It is also possible to use the has and not-has operators to do the same checks, but the value you want to check is set after the operator. The list, other string or record is set before the operator.

Operator overloading is one of Kotlin’s most beloved features. It lets you give familiar syntax to custom types, and you’re probably already using it without even noticing it. Take the Map interface, for example: the indexed access operator ([]) is used to read and write entries:

The same syntax works for arrays, lists, and any type that declares an operator fun get or operator fun set. Did you know that you can overload the indexed access operator with multiple indices?

Considering a move to Kotlin? Coming from a Java background? In this short series of blog posts, I’ll take a look at familiar, straightforward Java concepts and demonstrate how you can approach them in Kotlin. While many of these points have already been discussed in earlier posts by colleagues, my focus is simple: how you used to do it in Java, and how you do it in Kotlin.

Case 12: In this post, we explore how to model a finite set of types in Java — the “old way” with enums or class hierarchies, the “new way” with Java SE 17+ sealed classes — and then see how Kotlin handles them elegantly with sealed classes.

Considering a move to Kotlin? Coming from a Java background? In this short series of blog posts, I’ll take a look at familiar, straightforward Java concepts and demonstrate how you can approach them in Kotlin. While many of these points have already been discussed in earlier posts by colleagues, my focus is simple: how you used to do it in Java, and how you do it in Kotlin.

Case 11: You want to construct an object.

With many parameters. Some optional. Readable. Preferably without a constructor that looks like a password.

Within the JVM community, once in a while somebody jokes about getting old and therefore needing to start learning COBOL. Usually, someone responds that there are indeed some “precious older people” who wrote COBOL, or dare I say it, still write COBOL today. For me, COBOL has always sounded like a relic of the past. Something you read about, not something you seriously consider learning. But lately, I have been hearing rumours about companies starting to recruit new employees specifically to fill COBOL vacancies. That triggered me hard enough to start wondering. Can I actually run COBOL on my own laptop today, and if so, can I have a reasonably nice developer experience while doing so?

Considering a move to Kotlin? Coming from a Java background? In this short series of blog posts, I’ll take a look at familiar, straightforward Java concepts and demonstrate how you can approach them in Kotlin. While many of these points have already been discussed in earlier posts by colleagues, my focus is simple: how you used to do it in Java, and how you do it in Kotlin.

Case 10: You need to do many things at once. Mostly waiting. Sometimes working.

Considering a move to Kotlin? Coming from a Java background? In this short series of blog posts, I’ll take a look at familiar, straightforward Java concepts and demonstrate how you can approach them in Kotlin. While many of these points have already been discussed in earlier posts by colleagues, my focus is simple: how you used to do it in Java, and how you do it in Kotlin.

Case 9: You need something that belongs to the class. Not to an instance.

Considering a move to Kotlin? Coming from a Java background? In this short series of blog posts, I’ll take a look at familiar, straightforward Java concepts and demonstrate how you can approach them in Kotlin. While many of these points have already been discussed in earlier posts by colleagues, my focus is simple: how you used to do it in Java, and how you do it in Kotlin.

Case 8: You want a sensible default.

If something is missing. Or null. Or both.

Considering a move to Kotlin? Coming from a Java background? In this short series of blog posts, I’ll take a look at familiar, straightforward Java concepts and demonstrate how you can approach them in Kotlin. While many of these points have already been discussed in earlier posts by colleagues, my focus is simple: how you used to do it in Java, and how you do it in Kotlin.

Case 7: Nulls exist.

Ignoring them doesn’t make them go away.

Considering a move to Kotlin? Coming from a Java background? In this short series of blog posts, I’ll take a look at familiar, straightforward Java concepts and demonstrate how you can approach them in Kotlin. While many of these points have already been discussed in earlier posts by colleagues, my focus is simple: how you used to do it in Java, and how you do it in Kotlin.

Case 6: Passing functions around sounds scary.

Until you try it.

Considering a move to Kotlin? Coming from a Java background? In this short series of blog posts, I’ll take a look at familiar, straightforward Java concepts and demonstrate how you can approach them in Kotlin. While many of these points have already been discussed in earlier posts by colleagues, my focus is simple: how you used to do it in Java, and how you do it in Kotlin.

Case 5: Java has switch. Kotlin has when.