> A language without higher-kinded types or type-classes cannot be the language that "Scala should be". And these aren't things that can be easily added later. In other words I don't think it will ever happen.

I mentioned higher-kinded types; last I knew they were an experimental feature. I thought Ceylon offered some way to do "open interfaces" (the vital part of typeclasses IMO)? If not then that's definitely an issue.

> And what can you do in Ceylon about this? Or our we talking about a dream?

In Ceylon you have arity abstraction over tuples built in, so you can do HList-style operations by default. Scala will supposedly add this in Don Giovanni but in the meantime you have to use Shapeless with its implicit macros and it's slightly less nice (e.g. the error messages are less clear).

>Scala.js is reusing the Scala compiler in what happens to be the cleanest transition I've seen. Care to explain?

I think it's fair to call Scala.js "retrofitted", and I think the article is right that a language that was designed from the ground up to be JVM-independent will inevitably be better at it.

My whole point was that these are minor rough edges to Scala that aren't really that important, so I'm not sure why you're being so defensive.

Sorry, I sound defensive only because I'm in a bad mood, nothing to do with the subject at hand.

Thanks for the clarifications.

> but software is about trust and I do not trust somebody like Gavin King for delivering a good language after Hibernate :)

Perhaps it's just a joke, but if it's not: sure you're entitled to dislike Hibernate and prefer other ways to talk to a DB, but it's still one of the most widely used ORM on the JVM so it may not be perfect but it is also a huge success.

> A language without higher-kinded types or type-classes cannot be the language that "Scala should be"

You don't really get to say what other people think Scala should be. You like higher kinds, so do I, I'm glad they are in Scala but most people have never even heard the term and to them, they would much rather have a language with fewer features than one with more.

That's the goal that Ceylon and Kotlin are trying to achieve.

Scalajs is reasonably good, but it is retrofitted; it's a javascript backend for a language that wasn't specifically designed for a javascript backent. Ceylon was designed to compile to javascript. I haven't used either so I can't comment as to whether it actually makes a difference.

One place where it makes quite a big difference is in the standard library. In scala the standard library is very often just a thin shim on top of the JVM equivalent... which means that scala.js needs to shim the JVM library. It's not a huge deal in that most everyday things pretty much work out of the box, but if you're using a lot of time/date manipulation (via Joda-Time or the JDK8 java.time package) you'll have to use something else on the JS side.

So, that's a good example: ceylon.time is implemented in pure Ceylon, and is totally cross-platform.

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.

> Why is reinventing the wheel considered a good thing?

It's not. There just is no shim for java.time currently! Even worse, there could be licensing issues[1].

EDIT: That, and some of us are unfortunately still on JDK7 until the next Ubuntu LTS. Not that that's scala.js's fault, but it's a practical issue.

EDIT: ... and of course having a duplicate implementation of java.time (JDK + the shim-which-is-basically-a-reimplementation-in-JS) could be considered "reinventing the wheel"! :) If you have to reinvent the wheel, then doing it such that it at least behaves completely consistently across all backend platforms is preferable, IMO.

[1] https://github.com/scala-js/scala-js/issues/1618

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.)

Right, but the JS and JVM runtimes have quite different behavior. And I'm willing to bet that implementing something as non-trivial as java.time again in Scala(.js) will end up causing quite a few bugs because they aren't identical.

That's why I'd rather have a single implementation for anything non-trivial and just retarget that to each backend using more low-level primitives. After all you're using a different language -- using a different date/time API shouldn't be much of a problem.

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.

I'm not sure why you're being sarcastic.

I'm not saying it'll be bug-free. My point is that it'll have exactly the same bugs on either platform. This may be preferable to having different bugs on different platforms.

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.

That's a good point. As a (shim) library developer I think I might agree -- because it would perhaps be easier to find bugs in my library -- as an application developer I wouldn't because I would have to find different workarounds for different bugs.