Kotlin 1.1: What’s coming in the standard library

"initialising an entire message queue broker, an entire relational database and an entire web server" is just abstract words. Initialization of an entire web server is creating a socket and binding it to 80 port, that's what should be done, but what else happens? Initializing a relational database is something like opening a file. May be read journal, rollback unfinished transaction, but those things could be done after initialization.

I use Java and I'm always trying to improve startup time. Last time I used undertow for tiny project, with jdbc to access remote database. Project started in mere milliseconds and it was much easier to iterate. But every time I enable something monstrous like servlets, hibernate, spring or, save god, java ee, it's always 30+ seconds start time. And I always wondered, why that's happens? I can serve millions of customers in those 30 seconds, I can read gigabytes of data from my HDD and parse millions of XMLs.

You're more optimistic than I am. And honestly proper TCO doesn't seem to be all that important to "regular" java programmers[1], it's just that it's crucial for $ALT_LANGUAGE implementers. (Where ALT_LANGUAGE has a functional flavor.)

[1] I'm guessing that this is the reason that it hasn't been prioritized... but who knows what complexity would rear its ugly head if one were to actually try to implement TCO on the JVM... I'd hazard a guess that it's 'highly non-trivial'.

Scala supports local tail call optimization for a single function. A lot of FP languages support mutually recursive tail call optimizations, where two functions recursively call each other (common in FP). Scala (and no JVM language to my knowledge) cannot optimize this and so programmers have to resort to workarounds like Trampolines.

In contrast, LLVM IR and .NET CLR support it, allowing language compilers to use it. F# supports it and there's plans for C# to support it. It might be supported in the LLVM Scala target (Scala native) at some point in the future.

You've fallen for the trap of mistaking Gradle to be Apache Groovy, perhaps because those 10-line build scripts for Gradle are the only encounter most programmers have with Groovy. Your comment should read "Gradle is adding support for Kotlin alongside Groovy, and comments by the Kotlin designers. The big difference of course is that Groovy is dynamically typed by default."

But the right way to represent absence - whether you call it null or option or something else - is clearly with a normal type that follows the normal rules of the language, not a special language-builtin type with special language-builtin rules. Some light syntactic sugar for commonly-used types makes sense (like Ceylon's "?"), but what it desugars to should always be something you could write a normal library type for. Indeed if your language doesn't let you implement the constructs you need for this kind of type in a custom type in a library, that should be a red flag that your language isn't expressive enough for general-purpose use.

Yep. That's how I feel about HKT. I'm never going to program in a language without HKT again if I can possibly help it, and I'll put up with a lot of nonsense from Scala (like the IDE situation being a choice between the one that locks up for seconds at a time and the one that puts spurious error highlights on all your code) if the alternative is not having HKT.

> One property of a killer app is that people tend to know it when they see it. You don't normally need to educate people as to why they want your app, they already know they do.

Eh maybe. The quote about "faster horses" comes to mind. What everyone wants is a language that makes it easy to say what you mean and have it come out correct. But it's hard to know what kind of language facilities would help you do that until you've worked with them - and not just done some small examples but written a real line-of-business app while making a real effort to work with the grain of what those features give you.

Higher-kinded types mean you can have type parameters that are themselves parameterized. E.g. in Java (or Kotlin) you can do

    interface MyType<T> {
      T something();
    }

    interface MyType<T<_>> {
      T<String> something();
      T<Integer> somethingElse();
    }

> You have Multiple Inheritance in kotlin, which does more or less the same.

Only if you control the classes involved, and most of the time you don't - I can't see any way to create a union where one of the types is from an external library, not even by making them both subtypes of a common interface. (Particularly frustrating since Kotlin supports extension methods, which have all the same complexity for the reader, but as far as I can see you can add a method to a library type but you can't add an interface onto it). (Also Ceylon's native union types are nicer than subtypes).

> I don't get this. Xml in java code? Ceylon and Scala I think they compile to bytecode too.

What I mean is, real-world Java codebases end up full of proxying/bytecode-manipulation/reflection controlled by annotations and/or (in older codebases) XML. E.g. Spring/Guice, Hibernate/JPA, Jersey, Jackson, Quasar... . It's worth saying that this happens for a good reason: Java isn't expressive enough to practically express functionality that people need, and thus they resort to using these techniques instead (the realistic alternatives are callback hell, dropped transactions, copy-pasted code...). But HKT (and related/similar functionality) give you enough expressiveness to replace these things with plain old code.

Well, it's not so much solving it as solving it practically. Even in Java it's obvious what the solution is: have a single method for performing database transactions that opens and closes the transaction so that it's impossible to get the transaction boundaries wrong (the problem the annotations were introduced to solve), and have operations that need to happen inside a transaction represented with a type that can only be used by calling that method (combined with some way of enforcing that you can't "smuggle" the database connection out of that type - or else by separating interface and implementation and ensuring that the module in which your database operations are defined simply doesn't even have access to the database libraries).

The reason people don't do this in Java is that you lose compositionality. The idea exists up to a point - it's sometimes called the "command pattern" - but if you have a bunch of functions that return commands then you need to be able to combine them to happen in a single command (so that you can run them all in the same transaction), and if you don't have that then you lose the ability to split up your code into small reusable functions. You can write functions for composing commandey functions, but you have to write them all yourself for your specific command which ends up being pretty much the same problem. To be able to have a library of functions for dealing with commands in a generic way you have to be working in a language with HKT. Ideally you also want syntax sugar for composition (in Scala, for/yield) so that you can compose command-ey functions more-or-less like regular functions.

> In my experience it's pretty common for developers to ask "Why can't Java be smarter and realize I never want a NPE and instead of throwing one just automatically make the result of the line it happens on null?" > Obviously that's not the same as asking for non-nullable types but it is asking for the language to solve the NPE problem.

Up to a point, but I suspect they'd ask the same about exceptions. And I don't think they'll find Kotlin satisfactory in that regard either - IME this line of "magically fix it" thinking doesn't actually work, because the appropriate action takes some actual business-dependent logic to determine.

Map builds a new collection based on the function you provide it. At the end of a map call you end up with a potentially transformed collection instance.

arrayOf("A","B","C").onEach{ print("onEach $it")}.forEach{ print("forEach $it")}

prints:

onEach A forEach A onEach B forEach B onEach C forEach C