Kotlin truly shines when it comes to avoiding excessive bureaucracy of classical Type-Driven approaches to optionality.
Let’s see how does its native approach to null-safety compare to java.util.Optional.
Playing with multidimensional arrays and method references can be tricky sometimes.
Java 8 got many things right and some not – apart from commonly recognized Java 8 caveats, there are a few which feel especially wrong.
Kotlin takes Type-Inference to the next level (at least in comparison to Java) which is great, but there’re scenarios, in which it can backfire on us.
In this article, we continue where we left off and focus solely on error detection for Hamming codes.
Hamming Error Correction with Kotlin – part 1
Hamming code is one of the Computer Science/Telecommunication classics.
In this article, we’ll revisit the topic and implement a stateless Hamming encoder using Kotlin. Continue reading
Handling checked exceptions in lambda expressions can be often frustrating. Luckily, there is a type inference rule that we can exploit… Continue reading
The tricky thing about working with PriorityQueues is that, ironically, they don’t always behave according to the PriorityQueue semantics. Continue reading
In this short article, we’ll have a look at how we can bypass Kotlin’s native null-safety with sun.misc.Unsafe, and see why it can be dangerous even if we aren’t messing up with it directly. Continue reading
The peek() method from the Java Stream API is often misunderstood. Let’s try to clarify how it works and when should be used.
Stream<T> peek(Consumer<? super T> action)