Right now, people who are not involved in the development of kotlin doesnt really get much information.
If i want to know whats going on i have to watch stackoverflow/devnet/youtrack/github-commits
to see whats happening behind closed doors.
There is no roadmap about what stuff will be implemented/is done.
Neither some estimated etas for new milestones/betas.
IMO it could attract more people if they know what language-features are going to be implemented,
get excited and discuss them.
Nowadays people will search for something like a roadmap/release ETA and just
run off because they cant find any information. (Andrey talked about a beta release
“in a couple of months”. That was in 2013. No word about any beta release till then)
We do not publish ETAs/plans because in the past too many public estimates I gave were too wrong (like the one you refer to), and I don’t enjoy being a well-known liar
It turns out that a project like Kotlin is a little hard to give an ETA for: too many things require something very much like research, so there’s no way to estimate their delivery times. Roadmaps tend to get stale over time, although I admit that we could have put more effort into them and share more of our plans with the public, will probably do so.
It would be interesting to have some blog posts after you’ve researched a new feature,
something like “Oh we picked up this feature with this syntax, because of that and that, inspired by haskell/Lisp/whatever”,
so we can see that the language/tools are still emerging at full steam
Maybe you’ll get some good feedback about those new features? e.g. the new feature X does not synergize that well with the already existing feature Y, and so on.
Oh and I’d be interested in reading about how kotlin changed the development inside jetbrains on an enterprise project compared to java,
but I’m not sure if its too early to say something about that.
Totally agree. As a community of developers who invest their time in Kotlin we would like to assure from time to time if project is not dying. Now, this happens only with milestones and it is too rarely.
Personnally, I'm looking at the commits there to know what might be coming next... :^O
Also, being on snapshot sometimes gets you a taste of the next changes...
I’m not interested in ETAs for the reasons you stated. A roadmap would be enlightening, but I tend to follow commits on github daily to get a sense for what is coming.
However, I think regular releases are necessary for a library ecosystem to flourish for Kotlin.
When I’m not using libraries I’m free to use whatever version of Kotlin I like (I tend to track the latest release in the maven central repo and download the matching plugin version from team city - this gives me the most recent version that works with gradle).
However, as Kotlin libraries start to appear we need some way to try to keep them compatible. We need a synchronisation point where:
Kotlin devs push a new release to maven central and publish a matching IDE plugin release
Library devs update to the new Kotlin release and push to maven central
Kotlin users update their IDE and upgrade libaries
The existing milestones are fine as this synchronisation point. However, the last milestone (M10) was released at December 17, 2014 (11 weeks 3 days ago).
The library I’m writing (https://github.com/andrewoma/kwery) won’t work with it and I’m lucky that the Jackson Kotlin library I use is still compatible (as it’s built with 10.4 and I’m using 10.770).
How about time boxing milestone releases so they’re a maximum of 4-6 weeks?
We are aiming at milestone times of about 8 weeks of development. M11 is so much longer in wall clock time because of NY holidays in Russia that are rather long (almost two weeks this year). We are going to release M11 in about a week from now.
For me, it's not so much ETAs but keeping track about what's going on. I'm watching the github commits but that's too much details. It would be nice if there were more blog posts about what's going on in the project, which features are being worked on. Maybe an example or two when a feature is finished (for those that are using daily builds of the plugin).
I never really liked the class object syntax because of the combination of class and object. You could also name them static object but it sounded like you wanted to avoid static at all costs.
What are the main use cases that you see for multiple class objects?
We are not talking about multiple class objects, only about multiple named objects nested in the same class. Use cases are the same as for nested classes: scoping, visibility etc
Thanks Andrey. For some reason my post to the blog comments never showed up, so I'll try again here.
I’m starting to wonder what actually the purpose of class/default objects is, in a language like Kotlin?
In Java, we have static for:
Performance. Static dispatch is faster than dynamic.
Namespacing, as top level functions are not allowed.
Allowing global and instance state/code to be put next to each other, i.e. you can have an instance method use a static utility function that's right below it
Kotlin default objects:
Require dynamic dispatch so there's no performance win. Sure HotSpot doesn't care much but not all JVMs are so advanced.
Create a new namespace, but Kotlin allows top level functions, so you could as well use a package.
Require a new lexical scope, so functions that don't access object state must be placed inside that block and cannot be interleaved with other code.
Require an ugly annotation to get Java binary compatibility anyway
I wonder what the use cases are that aren't satisfied by just a regular top level object declaration?
I was wondering about that static aspect as well (because of Java compatibility). What if one could apply the platformStatic annotation to a class object to make all contained members static?
Andrew, I keep the jackson-kotlin module up to date within a day of a new byte-code incompatible release. We use both snapshot and latest in Maven and monitor the maven repo and the latest plugin build that matche maven (possibly unstable latest matching plugin http://teamcity.jetbrains.com/guestAuth/repository/download/bt345/pushedToMaven.tcbuildtag/updatePlugins.xml [login as guest if required] ... we watch the bootstrap-stable plugin builds to see what Kotlin team is using as well)
Library writers, when working with a pre-release language need to commit to keeping up to date. So if you run into issues, just let me know and we can usually have a new jackson-kotlin out within a day.
We should think about a naming convention that indicates the minimum required Kotlin version to match a library, but for now README.MD is doing that, and only moving forward so no new features on old Kotlin versions, only new releases for new stable Kotlin.
A note about 0.10.1316 which you might stumble into, it has some things in flux like the ‘default object’ keyword conversation, therefore I’m not updating jackson-kotlin to that version automatically but since it is not byte code compatible with 0.10.770 let me know if you need a release, we could call it something odd to make it clear it is just for that build. If so, please post an issue on the github repo and I’ll see it: https://github.com/FasterXML/jackson-module-kotlin
The agreement should be: "Kotlin will not die until everyone contributing all shows up in a bar (Irish with Guinness please), and we all agree to exit on the same day. Until then, everyone keeps going without worry"
Because, really it won’t die. It is the best option for the Java VM. Android people have discovered it is the best for Android and are going nuts lately talking about it. It has no big downsides other than “waiting for 1.0” which really, you can use it in production today if you test well (we do!). And the upsides are priceless…
