Why you might want to choose Ceylon (opens in new tab)

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.

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.

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.

The biggest downsides I've encountered are around the deeper-magic Java interop, with stuff like Dropwizard's HK2 dependency injection system getting a little messy--especially around non-nullable parameters--but that stuff is, all things considered, a small part of the application.

I do wish Kotlin had more pattern matching semantics but that's just me being picky, it's a really nice language.

Maybe, or maybe not all language designers have the goal of making their language as popular as possible. A language can be popular enough, such that it has a good community and good set of libraries, without trying to get everyone to switch.

In fact, depending on what you're looking for, a language can become too popular. In this case, you start getting people in the community that detract from it, rather than contribute to it.

The study sounds interesting, though there are obvious risks to trusting self-reports, but I think you're taking a broader meaning of "familiarity" than they're using - I read the result as "programmers are likely to use a language that they know when starting a project" and I don't think you can generalize to "programmers are more likely to use a new language that's similar to a language they know" (apologies if there's something in the video that's not in the text, can't watch videos here). Certainly past a certain point the library ecosystem and pool of familiar programmers become self-sustaining, and I can well believe that such things would be the biggest factors in any given project's choice - but that can't possibly explain how a language gets to that point in the first place.

For many of us the distinguishing characteristic of Java was that it was heavily marketed, often to managers; in the early days it felt like a lot of Java users were doing so under orders. (With 1.5 and the introduction of generics the language became a lot more programmer-friendly and I think at that point it developed a lot more grassroots popularity). Being less cynical I think Java did offer something unique in the form of crossplatform multithreading with a well-defined memory model - it's easy to forget how valuable that seemed, particularly as the world moves away from conventional threading. Possibly the combination of memory-safety and claims of C-like performance was new as well? I'm speculating here as I'm not so familiar with the less popular alternatives, but I think it's not simply a case of Java being less weird or more blue-collar than Self or Modula. The popularity of Python (with weird syntax and modula-like modules) and Javascript (with a Self-like inheritance model) show that that level of weirdness is no barrier if a language has a compelling advantage.

(Likewise Go, I think - it's taking programmers largely from Python/Ruby land where it can claim a USP in the form of performance (while retaining good async support and some level of conciseness). And again, marketing seems to be somewhat involved - so often when I ask "Why did you choose Go over OCaml?" the answer is "What's OCaml?".)

I think the clearest strike against the blue-collar approach is Perl. Perl took an extremely "pragmatic" attitude to language design, adopting many "most bang-for-the-buck features" (deemphasising consistency or underlying coherence), and put a lot of emphasis on tooling and libraries with CPAN, PerlUnit and the like. And for a time it was very successful - but ultimately it became a language that was very hard to evolve, whereas other languages (in particular Python and Ruby) were able to catch up on the tooling side and their coherence gave them an advantage in the long-term. I think Kotlin is making the same... mistake would be too strong a word, Perl is a success story by many measures, but I think Kotlin is taking a very short-term strategy; it feels like every time someone figures out a clever thing you can do with implicits in Scala it gets added to Kotlin as a language feature. Everything about it feels very ad-hoc, particularly in comparison to Ceylon. So I think that while Kotlin may be a very effective language for the short term it's going to be a very brittle one that will struggle to adapt in the future.

I guess that's the closest thing to a counterexample to my original claim - a lot of people did move from Perl to Python with no USP beyond being clearer and smoother. FWIW I think the issues with Perl were deeper than those with Scala; there is some ad-hoc junk in the language (structural types should never have been added, nor should Dynamic, async/await aren't worth it...) but it feels quite peripheral, I think the core still fits together nicely. But hey, if those issues do end up forming enough of a toehold for Ceylon to take over, I'm fine with that too.

I mean, examples of things that are cross-platform in Ceylon: collections, localization, promises, regexes, HTML construction, logging, testing, dates/times.

Examples of things that are platform specific: I/O, database access, filesystem access, distributed transactions, the HTTP server.

That's pretty reasonable and natural, isn't it?

- an elegant and powerful representation of tuple and function types -- Okay, Kotlin could do with this

- reified generics -- This is apparently expensive on the JVM: http://blog.jetbrains.com/kotlin/2014/12/m10-is-out/

- the cleanest solution to the problem of null -- I think saying that `String? x = "abc"` is cleaner than `var b: String? = "abc"` is subjective. -- Does Ceylon have Safe Casts? https://kotlinlang.org/docs/reference/null-safety.html

- awesome modularity -- Something I'll need to look into

- a language module [that] completely abstracts the underlying runtime, and offers a set of elegant APIs that vastly improve on those available natively -- I guess the improvement in abstraction comes from the Reified Generics -- Have you got any examples of where the API is superior to that of the Kotlin one? For example, with Kotlin's extension functions Java File object has been extended with a readLines() function that returns all of the lines of a File as a List. I was impressed when I saw that. Underneath it is doing the usual BufferedReader and InputStream boiler plate work that you would normally write in Java.

- a language specification -- https://kotlinlang.org/docs/reference/

The article was an overly verbose 2000 word wall of text.

but, I dont know if thats really the case though (I dont know ceylon). I think that fat arrow line would just become a no op instead, creating a lambda and throwing it away immediately ("name" being the param name in the lambda and nothing more).