justthistime_

    So what, in the above "wall of text", is wrong about 
    Scala or Kotlin?

Maybe just check the responses from the last fifteen dozen times? It's not that hard.

    You're not telling what was incorrect, just that the 
    author is _always_ incorrect, which strikes me as 
    hyperbole.

I'm not telling anything. The Scala and Ceylon designers did. They probably know better than me, or him.

In what sense is it closer to Scala? It's more like a slightly nicer Java: All Kotlin code can be translated back to Java (with some boilerplate), but almost no Scala code could be expressed gracefully in Kotlin (or Java).

Extremely poor cost/benefit ratio.

Sorry, but I don't plan on reading your confused ramblings.

This is what we call FUD.

- extension methods

- property syntax + magic identifier

- reified

- immutable wrappers around mutable collections

- const

- multiple redundant ways of defining generic upper bounds

- companion objects + syntax

- operator/infix rules

- constantly changing nullability rules

There is still a huge chunk that does.

> Rust itself isn't particularly influenced by Scala

Agree! Sadly, they didn't use all the lessons Scala could offer them when designing their own language. :-(

Painful to watch as they introduce stuff where Scala developers already know that it's completely broken.

Same bugs on different platforms are extremely hard to find.

Different bugs on different platforms are like an early Christmas present:

You don't even need to write tests which include your "expectations" of the result anymore.

Just call the code with randomized inputs for both platforms, and if there is a difference, you found a bug.

Well, I don't think what you say is based on reality if you look at all the broken, half-designed stuff they are trying to ship. (Not understanding (yet) why some design decisions are bad, doesn't mean they aren't bad.)

It feels like they are digging through Scala's graveyard of discarded ideas without even realizing it. Most of what they try to do differently has already been considered in the past and has been rejected by the Scala developers for good reasons – years ago.

Kotlin's struggles are a good example that knowing how to build IDE support for existing languages doesn't give you the skills to design a programming language from scratch.

    The Kotlin designers specifically call out Scala's
    mistakes when discussing why they do things differently.

Yes, I have to give them that. They (and their "fans") excel at PR, marketing and FUD.

Yeah, inventing an API and implementation of a date/time/calendar library from scratch without an existing spec, implementation, tests or experience will surely be totally bug-free.

> but still manages to enhance them via compiler magic and extensions

The thing is that Scala tried to do that for years, and after years of battling subtle, leaky abstractions, they picked a different design.

It feels like Kotlin designers are completely unaware of what other languages tried and keep repeating all the mistakes ...

Please get some help with your mental health issues.

As mentioned in the ticket, the original implementation is BSD.

Your last point is not the only thing that matters though. If the runtime already ships with packages X, there is no point in shipping your own implementation.

(Which is exactly what Scala/Scala.js does with math stuff: it reuses BigInteger from the runtime on the JVM, but ships its own implementation with Scala.js.)

Why is reinventing the wheel considered a good thing?

javax.time is considered by some to be one of the best, most well-designed general and versatile libraries for date and time related matters out there, regardless in any language.

How would things be improved by throwing that away, and inventing something different? I think keeping the API and providing an implementation for Scala.js is a much more reasonable approach.

Designing a date/time requires very rare skills and knowledge that most people lack. A re-implementation of javax.time means all the documentation, tests and existing code can be re-used and allow correctness checks against the existing implementation.

He did the same uninformed rants about other languages for a long time already. It's unlikely that he will do his homework any time soon.

Hopefully this will also happen at lower levels.

The "I'm the smartest person in the world, because I work at Google" attitude is a reason I don't interact with/communicate with/contribute to Google-related projects. Their hugely inflated egos are just off-putting.

I'd use Jackson.

> "But, but ... we play both kinds of music, Country and Western!"

Yeah, but somehow it's only one group of people who seems to call the shots: Those with a disdain for the poor, the weak, the ill, the black and women.

The US is not known for applying laws to rich people.

Wow, more of this "free market" non-sense.

a) It's not a free market. Especially in cases with life-threatening diseases a person can't just "walk away from a deal", that would be suicide for that person.

b) Entities banding together to negotiate a better price? Boohoohoo how unfair. Welcome to capitalism. Oh wait, if the entity were for-profit companies all would be fine, right? It's only bad when citizens band together.

Is it so hard to accept that in all other civilized countries health care works better and at a more reasonable cost?

Get your shit together, Americans.

They own more of your government than any other industry, which is incidentally how they managed to create their hyper-inflated prices in the first place.

Their chance of success doesn't depend on R&D.

God, some Americans are really cringe-worthy. Is it really necessary to get defensive just because other governments are more interested in representing the interests of their people?

Yeah, because the price people are paying is related to the actual costs of researching and producing it.

Hint: No, it's not.

Don't bother with him. He seems to be the successor of Cedric Beust.

If you consider these things huge, you never looked over the rim of Kotlin's tea cup.

You would be surprised what's out there.

Yes, as long as you never use any third-party library and place all your code into a single module, GHC doesn't completely fail on its promises.

My concern is that this PhD-style development suffices for most Haskell users, but is not practical for any non-small project in the real world with more than one developer.

> It's a strong guarantee that boosts the robustness and usability of type classes significantly.

If there was a compiler which would enforce these rules.

If you care about coherence, you should be very dissatisfied with GHC anyway.

I meant in terms of being obsoleted by their "base" language (JavaScript).

Language rarely matters, but Scala is were the action is today and probably in the future.

Both languages could be considered "add-ons" on top of their runtime, so you have to think about how likely it is that the "base" language gets good enough to slow down adoption significantly.

In Scala's case it's quite unlikely that Java will ever be able to even decrease the gap let alone closing it.

Elixir feels a lot like CoffeeScript in that regard.