interestingemu

It was once routine for me and others I know to be prescribed hydrocodone for conditions like painful seized muscles, root canals or severe strep throat. We were apparently all in the ~80%+ who used it as intended and stopped. It worked great!

I think this is exactly the kind of drug abuse people want to get away from. Some people also used heroin or meth and managed to stop. This doesn't mean it's OK to abuse opiates for things like "seized muscles, root canals or strep throat" ... WTH? Opiates are used to manage severe pain, not this I've-torn-my-nail-a-bit-I-need-opiates-now.

Pain is a part of life, stop being a princess and deal with it.

I believe systemd-resolved, however, is one of those components that is entirely optional, and which nothing explicitly depends on...

Yet. Wouldn't be the first time some "optional" component became mandatory.

GP is clearly right. What's the point of going "that's just your opinion" on every fact he mentions?

Scala developers can do whatever they want or need at compile-time.

The systemd network stack is entirely optional and intended for scenario where you can't afford/don't need the 'fatness' of NetworkManager, just because it's there, doesn't mean you have to use it.

Currently.

Jesus, it took me way too long to realize this was about online classes, not virtual classes in languages. :-)

Yes, exactly, which makes the claim even more baffling.

Sure, they can just reimplement all their Java dependencies, but if they have to implement e.g. collections anyway, they could just have designed a better API in the first place, instead of being stuck with Java collections on platforms that don't even run Java.

Isn't pure Kotlin a much more unlikely scenario than pure Scala? Kotlin devs certainly take pride at every opportunity of how much Kotlin piggybacks on Java, cf. collections.

I think you can't have it both ways, having a worse abstraction for handling errors while claiming that it works better with Java code and then claiming that "pure Kotlin code" is where the more interesting case is.

I have seen plenty of libraries using null to indicate an error. If this wasn't the case, as you allege, then why do Kotlin devs act like it's such a big deal? Why add a language feature for something that isn't even considered an issue instead of e.g. improving how Kotlin handles checked exceptions?

I think this comment shows a very fundamental lack of understanding how different languages handle errors.

In Java (and Kotlin) -- ignoring the topic of exceptions as an alternative -- errors like "missing value" are communicated with null.

So in Java you first have an error handling problem, you deal with it by returning null ... now you have a null handling problem!

Kotlin tries to put some band-aid around nulls by making them more typed than in Java.

In Scala, errors are handled with bog-standard library types like Option, Either, Try, Validation, not some special language built-in. These types are not facilities to handle null (shown by the fact that all these types happily accept null as a valid value), they are facilities to handle errors.

They handle errors better than Java or Kotlin, because these types allow developers to choose the appropriate type for a specific error case and retain the structure of a computation. To expand on the second point: Nullable types cannot be nested, Scala's types can and regularly are.

This allows Scala to compose operations while carrying errors up to the point where they can be handled easily.

If you have an operation returning an Option[T], and want to run an option on the value returning an Either[S, T] then simply looking at the resulting value will tell you if things succeeded or where exactly things went wrong.

    None               --> First operation did not result in a value
    Some(Left(fail))   --> Second operation failed with cause "fail"
    Some(Right(value)) --> All operations succeeded with result "value"

TL;DR: Kotlin tries to put some band-aid around Java's broken approach of handling errors with null, Scala deals with errors correctly in the first place.