Moving to Kotlin taught me to appreciate the underlying fundamentals in the JVM and the patterns present in Java.
I’d rather not use Java today, though. Kotlin is basically Java but with the best practices enabled by default and the bad parts made impossible at a language level.
Besides what other people said, one example is classes being closed by default (you need to explicitly set a keyword to make them open to extension). That was done to prevent inheriting from classes that weren’t designed to be inherited, and forcing you to use composition instead.
Yeah, they’re probably talking about nulls. In Java, object references (simplified pointers, really) can be null, pointing nowhere and throwing an exception if you try to access them, which is fine when you don’t have a value for that reference (for example, you asked for a thing that doesn’t exist, or you haven’t made the thing yet), but it means that every time you interact with an object, if it turns out to have been null, a null pointer exception is getting thrown and likely crashing your program. You can check first if you think a value might be null, but if you miss one, it explodes.
Kotlin has nulls too, but the type system helps track where they could be. If a variable can be null, it’ll have a type like String?, and if not, the type is String. With that distinction, a function can explicitly say “I need a non-null value here” and if your value could be null, the type system will make you check first before you can use it.
Kotlin also has some nice quality of life improvements over Java; it’s less verbose (not a hard task), doesn’t force everything to belong to a class, supports data classes which are automatically immutable and behave more like primitive values than objects, and other improvements.
Moving to Kotlin taught me to appreciate the underlying fundamentals in the JVM and the patterns present in Java.
I’d rather not use Java today, though. Kotlin is basically Java but with the best practices enabled by default and the bad parts made impossible at a language level.
I need to know more. What are the bad parts that are disabled? Which best parties are enabled at the language level?
Besides what other people said, one example is classes being closed by default (you need to explicitly set a keyword to make them open to extension). That was done to prevent inheriting from classes that weren’t designed to be inherited, and forcing you to use composition instead.
Yeah, they’re probably talking about nulls. In Java, object references (simplified pointers, really) can be
null, pointing nowhere and throwing an exception if you try to access them, which is fine when you don’t have a value for that reference (for example, you asked for a thing that doesn’t exist, or you haven’t made the thing yet), but it means that every time you interact with an object, if it turns out to have been null, a null pointer exception is getting thrown and likely crashing your program. You can check first if you think a value might be null, but if you miss one, it explodes.Kotlin has nulls too, but the type system helps track where they could be. If a variable can be null, it’ll have a type like
String?, and if not, the type isString. With that distinction, a function can explicitly say “I need a non-null value here” and if your value could be null, the type system will make you check first before you can use it.Kotlin also has some nice quality of life improvements over Java; it’s less verbose (not a hard task), doesn’t force everything to belong to a class, supports data classes which are automatically immutable and behave more like primitive values than objects, and other improvements.
null safety, to my understanding
For one thing, the file and class name must be the same. While it is good practice, making it mandatory requirement limits flexibility.