Actually the strong-type-inference plus greytext thing is one part of Kotlin where I'm not sure what to think about it.
When I first saw Kotlin examples on the internet with all the "it.something" I was "What is going on there?!? What is that supposed to do".
Then the first time I tried writing Kotlin myself everything became super clear due to that Greytext shown in IntelliJ. However 80% of the time I'm looking at code is not in an IDE. It's either on code reviews or in the browser (github, internal code browsers, etc). All the information is not available there, and one has to be aware again what the implicit types will be.
The challenge certainly also exists in other langues with type inference (auto in C++, var in Java/C#, inference in Rust, etc), but for some reason I found it worse in Kotlin. Maybe due to the commonly used methods which take a closure/interface as last parameter, and and the fancy builders.
The good news is there's GitHub integration in the IDE so you can review code with type inference hints. And adding/removing the types (converting between the inlined hints and real text) is a hotkey away. I tend to treat it as a matter of experience and style, when to specify the types explicitly vs not. Quickly disabling the hints is also reachable via hotkeys and then it is often apparent when a type isn't immediately obvious.
Definitely my favorite language currently, and extremely well-suited for server-side, it's certainly not just about Android.
KotlinJS feels so much more natural, safer and faster to write (in IntelliJ especially) than writing plain JS does.
Thanks for your input
However, it's fair to make a distinction between the slowly evolving Android runtime and the JVM. Java language features are catching up with Kotlin, and might even surpass it (I believe pattern matching might land in Java sooner than in Kotlin). Also Kotlin might get stuck for a while when big breaking changes finally come to Java (like Valhalla). I understand why some companies/teams think it's not worth it.
myFun(someVar, { it.something() })
myFun(someVar) {
it.something()
}
myFun {
it.something()
}
So you can partially specialize, and then the lambda gets the already allocated/opened resource, thus acting as region/arena resource allocator.
And you can combine it with currying to apply the concept to multiple kind of parameters.
I loved Grape for single-file scripts. Does any language have similar single-file dependency manager? I guess Go, but then, you have to compile Go, so it might not be as useful, because you distribute binaries anyways.
Depends on what you call pattern matching. Kotlin had pattern matching from day one, but it's just one level, Java might have it recursive by java 19
Guest languages relevance always fades away as the platform language improves and the FFI gets out of touch with that old version of the language.
C18 on UNIX vs C++, JavaScript vs Typescript (see private members), and when time comes inline classes/reiffed generics/SIMD types vs being able to target both Android and JVM on Kotlin's case.
But in reality, it's not the same thing, it's not the same time, not the same market environment.
Kotlin can succeed where others failed before because just about everything about it is incomparable with sorts like Beanshell.
In reality, while the differences are minor, they are the same thing. Time fades away, and market dynamics operate the same as they did 10,20..100 years ago.
The hubris is in using absolute statements ("platform languages always win") instead of being a little bit more humble with their projections. Old men should know better that history rarely unfolds as expected.
Kotlin has made too many promises that it can't keep.
ISO C++ has kept upgrading the support regarding ISO C libraries, as long as new grammar features aren't required.
Even ISO C++20 has finally added support for structure member initialisation, it is just a subset of what is possible in C.
So while UNIX vendors are free to use all C features, due to their symbiotic relationship, ISO C++ applications can only safely compile C89 code.
No full structure member initialisation, restrict, VLA,...
Kotlin Bootcamp for Programmers[0]
Developing Android Apps with Kotlin[1]
There's also an advanced android development course which is a follow up which I am going through now.
[0] https://www.udacity.com/course/developing-android-apps-with-...
[1] https://www.udacity.com/course/developing-android-apps-with-...
Google has it's own way of doing things - boilerplate, overengineered and full of ugly practices. Anyone will be better of learning from a source that isn't a bunch of interns that got thrown into the Android team.
Even the samples use Java 7 style code when comparing for terseness.
All the Jetbrains IDEs have that. When they enabled it, I was annoyed for a while (not enough to turn them off), but now I love them :) Especially, as you mention, for LINQ (in C#, essentially chained operations like map/reduce/etc.)
I like WebStorm so much better. The inline parameter names on function calls, the local history, the awesome diff tool, the refactoring capabilities (even for Javascript). This makes is well worth the money. Also, I like IntelliJ's perpetual fallback license policy. Feels very fair to me.
It required a huge outcry, but they did the right thing in the end :)
That's nothing. You should have been here when they used to let us buy the tools :-)
But, at least at my company, we always tend to hit some corner case that the documentation doesn't cover or some bug that isn't searchable because let's face it probably < 1% of people using a Java ORM is using Ebean compared to JPA or Hibernate.
In the end it's left me longing for a proper JPA implementation.
[0] https://ebean.io/docs/setup/activerecord
I've been primarily writing Kotlin for the last.. uhh, 3-4 years I guess. TS and VSCode pairing is good, but Kotlin + IntelliJ is both more faster and accurate in terms of knowing what you want and when you want it. Autocomplete, code generation, refactoring, moving works so good it is a huge productivity boost. And the "peeking" at types (the implied type is shown in a small gray box) lets you keep your code clean but very readable.
I can't tell you how many times it has autocompleted FooClass.Companion.functionName() for me and then immediately suggested that I should remove the Companion part. "Ya think?"
The performance also doesn't seem that awesome for me. It doesn't require a very large file before it starts taking several seconds to highlight and analyze it. Granted, I haven't upgraded to 1.4 yet, which supposedly improves performance.
It's very hard to pin point, but if you're developing a large project, you'll notice when autocomplete works 100% of the time (IntelliJ), and 93% of the time (VSCode).
Exactly this. You notice the "smoothness" is off, which when accumulated burns your context faster and kills your flow.
Normally I'm quite reluctant to start a new project in a new language, but Kotlin edited on IntelliJ just seems so very smooth. I'm doing a side project which is a game, where most of the website parts are Kotlin.
Most of what I'll say will be a bit vague, I mainly write Python and C++. I'm also not too clear on what benefits come from the language and which from the IDE, my understanding is that JetBrains had a lot to do with it so they are probably connected.
- Compile times seem pretty fast.
- Errors seem clear, haven't been as stumped as I'd expected with a new language.
- Greytext types that are inferred are super useful. I do wonder how I'd do if the IDE didn't tell me what the types were. But it basically means you get all the benefits of type annotation without having to write out the types.
- The style of using a lot of filter/map/reduce makes my code more terse, but the greytext hints keep it easy to understand.
- Great sugars. No need to add getters and setters for every member. Likewise it seems to change the calls to old Java lib getters and setters. Data classes can be short and sweet. One-liner functions in-line for simple stuff to keep simple stuff short.
- Can still do whatever you want with Java libs. Unit testing for instance works much the same.
- Ecosystem has moved nicely with Kotlin. Ktor and Ebean seem to be on board and pretty mature.
- Null safety built in makes it clear where you need to do something about it.