Ask HN: Has anyone here programmed in Kotlin? What do you think about it?

We C++ veterans know that implicit conversions are one of the worst ideas to put in a language. They start simple enough and then they get clever, which is where trouble starts.

> i.e. if you know what you're doing have at it; otherwise keep to a strict subset

There are few things about programming language design we know, because getting empirical data is so hard. One of the few things we do know (from C++ in the nineties, of course) is that this kind of design doesn't work. The average codebase lifespan is about a decade, during which time people move around and team leads change. Everyone has their own discipline, and by year 5 (usually earlier), the codebase is unmaintainable.

Of course, now that C++ has been re-branded and re-purposed as a specialized language for close-to-hardware software, and is used by specialists, it is doing quite well. I certainly wouldn't mind Scala marketing itself -- like C++ and Haskell do -- as a language for specialists (although even specialists would be better off opting for the excellent OCaml implementation on the JVM, or even Frege if Haskell is your cup of tea).

There is absolutely no reason to be as multi-paradigm as Scala is on the most polyglot platform around, which brings me to:

> that power... is what draws dsl authors to Scala.

One of the great things about the JVM is its relatively easy inter-language interop. I would use a meta-language made for DSLs (like Clojure, MPS or Xtext) for my DSL, while I'll write the infrastructure in Java/Kotlin. Learning Java and Clojure, or Kotlin and MPS, is easier than learning Scala alone (well enough for DSLs), and the results are cleaner, produce more maintainable code and better error messages (well, I wouldn't say Clojure excels at error messages, but at least the DSL writer has full control over them, and can make them quite good with an extra bit of effort).

Also, I'd like to see what those DSL codebases look like after five years of heavy usage (not to mention the error messages Scala spits out, which are completely unparsable to anyone who does not understand how the DSL is constructed).

I don't think that's selling it short. Accurately describing your product only prevents people who aren't really your target -- like me -- from being disappointed and telling the world about it, while it helps attract precisely those people who would be most excited about it.

Also, I think Typesafe realize now that there is not much money to be made in developing and supporting a programming language (ironically, there is some to be made -- though not too much -- supporting specialist languages; see Ada and Matlab). That's why they want to change their name, right?

> no users = no dice; doubt either will grab much mindshare in the near-term.

That's splitting hairs a bit; Scala doesn't exactly have mass appeal either. We're talking about the difference between tiny and small.

> I doubt Kotlin will be able to deliver the same guarantees, but if it can, watch out Oracle.

I know they're trying to. Also, I know Oracle actively encourages alternative JVM languages. Their product is the Java platform, which currently -- to be honest -- is not too far from being the same as Java the language (all alternative JVM languages combined don't amount to 10%, or possibly even 5% of the JVM ecosystem). But they wouldn't mind if that changes. Their research team working on Graal, HotSpot's next-gen JIT, coming to OpenJDK in Java 9, spends as much time on making sure it runs Ruby, R, C, Python, and JavaScript well as it does on making sure it runs Java well. I know Oracle's Java team isn't all too happy about it, but I also know that that's what Oracle wants.

Oracle would probably never have started to experiment with value types and specialized generics, if Scala didn't take the plunge and implemented, tested and shipped it years ago already.

Of course there are restrictions... but the choice was basically either never getting value types and generics, or accepting some restrictions until Scala drags Java into the 1990ies.

It's the same with extension methods. If the only thing you ever knew where extension methods, they would look pretty exciting. But after being aware of the full range of approaches, extension methods are "meh" ... they only implement the least useful part of implicits.

If I had to decide between extension methods and nothing, I'd pick nothing. Extension methods are just not pulling their weight.

Scala does a lot of things in a certain way, because the have > 10 years of experience experimenting with various approaches.

I suggest that you try to understand _why_ Scala does things this way, instead of assuming Scala devs are stupid. It's pretty likely that everything Kotlin does has been considered by Scala developers 5 years ago already–and discarded because better designs were discovered.