11 ms·

Is it me, or does the article feel like it is written by someone who didn’t actually bother to learn Kotlin. Instead they learnt the bare minimum syntax and tri

by __sr__ 8y ago

Is it me, or does the article feel like it is written by someone who didn’t actually bother to learn Kotlin. Instead they learnt the bare minimum syntax and tried to write Java in Kotlin. The author complains a lot about how Kotlin is different from Java. Err.. it is a new language — it is supposed to be different — otherwise why bother? > I have my favorite set of JVM languages. Java in /main and Groovy in /test are the best-performing duo for me. In summer 2017 my team started a new microservice project, and as usual, we talked about languages and technologies. There are a few Kotlin advocating teams at Allegro, and we wanted to try something new, so we decided to give Kotlin a try. The opening lines set the tone for the article. The author tried Kotlin because other people wanted to — not because he found it interesting. Most people learn a new language by writing a toy project or two. They don’t start with a real project. And of course it will take time to get used to a new language and be as productive in it as as you were in the old one. The friction is always there, no matter which language you are switching to. I am sorry, but I can’t take this article seriously — I feel that it’s written for the sole purpose of venting author’s frustrations.

singularity2001 8y ago
It is just you. Edit: and some hundred others. (using my karma as stats counter)
DeonPenny 8y ago
No thats exactly how it's written. It's written by someone who is so stuck in java land and never bothered learning any other language or paradigms.
ptero 8y ago
I feel the same way: author wants Java and was hoping only for a better Java: compatible with most patterns, tools, even libraries, but addressing some of his pet frustrations. When Kotlin did not satisfy his hopes he got disappointed. Understandably, but I do not see it as the Kotlin problem. The other problem I have with this post is that it did not state desires/hopes up front. The intro only mentions compile-time null-safety and less boilerplate (for which many languages are better than Java), then adds his desires throughout the text. Thus his complaints seem not a thought through list of failures to satisfy specific desires, but just randomly throwing rocks at vague targets. My 2c.
- riku_iki 8y ago
  > a better Java: compatible with most patterns, tools, even libraries, but addressing some of his pet frustrations. But is this a main pitch of Kotlin?..
  - pdpi 8y ago
    Being compatible doesn't mean that compatibility is the path of least friction, especially when it clashes with good design. A good example of that tension is the final/open thing: Wonky frameworks abuse inheritance and force you to use open all over the place, but Effective Java suggests you should make every class/method final unless you specifically design it to be extended.
lmm 8y ago
> The author complains a lot about how Kotlin is different from Java. Err.. it is a new language — it is supposed to be different — otherwise why bother? Kotlin advocates try to have it both ways. If it's a full new language, to be evaluated as a full language, then why would you adopt it when it's missing important features compared to Scala? The narrative is that it's a set of small enhancements to Java that are easier to pick up than Scala, but the reality doesn't live up to that.
- mavelikara 8y ago
  > then why would you adopt it when it's missing important features compared to Scala? A useful IDE, much faster compile time, lower cognitive load in daily usage.
- kllrnohj 8y ago
  > then why would you adopt it when it's missing important features compared to Scala Such as?
  - kodablah 8y ago
    There are a lot of things I miss. Case objects, macros, string contexts, (built-in) options as single-element collections, tuples, built-in either, abstract/self types, implicits, etc. We can argue about "importance" or even if those are good things, but we can't pretend that there aren't many missing features. Granted these days I appreciate Kotlin more than Scala, but that is more about tooling and backing.
    - kllrnohj 8y ago
      > We can argue about "importance" or even if those are good things, but we can't pretend that there aren't many missing features. I don't think anyone would deny that Scala has the most features of anything, it's purely a question of importance. Important missing features is more interesting to discuss than purely missing features. I've found myself more missing features from C++ when working in kotlin - specifically constexpr & static_assert.
vorg 8y ago
> > I have my favorite set of JVM languages. Java in /main and Groovy in /test are the best-performing duo for me. [...] we decided to give Kotlin a try. > The opening lines set the tone for the article He also wrote: > we decided to stick with Groovy in /test (Spek isn’t as good as Spock). If they were going to switch from the legacy language for /main code (i.e. from Java to Kotlin), why didn't they also switch from the legacy language for /test code too (i.e. from Apache Groovy to Kotlin) instead of dismissing it with "Spek isn't as good as Spock". And if they use Gradle, why not switch from Groovy to Kotlin for build scripts also.
afro88 8y ago
This was my first take on swift as an Obj-C dev back in 2014. I did an app extension in swift, basically just trying to write Obj-C code in swift (force cast and force unwrap all the things!). I didn't like it, I felt like it got in the way, and probably would've given a list of things like the author that are just lang differences. Needless to say after my 2nd round with swift it clicked, and then clicked again and again in different ways as the months rolled on. Never looked back.

by __sr__ 8y ago

singularity2001 8y ago

It is just you. Edit: and some hundred others. (using my karma as stats counter)

DeonPenny 8y ago

No thats exactly how it's written. It's written by someone who is so stuck in java land and never bothered learning any other language or paradigms.

ptero 8y ago

I feel the same way: author wants Java and was hoping only for a better Java: compatible with most patterns, tools, even libraries, but addressing some of his pet frustrations. When Kotlin did not satisfy his hopes he got disappointed. Understandably, but I do not see it as the Kotlin problem. The other problem I have with this post is that it did not state desires/hopes up front. The intro only mentions compile-time null-safety and less boilerplate (for which many languages are better than Java), then adds his desires throughout the text. Thus his complaints seem not a thought through list of failures to satisfy specific desires, but just randomly throwing rocks at vague targets. My 2c.

riku_iki 8y ago
> a better Java: compatible with most patterns, tools, even libraries, but addressing some of his pet frustrations. But is this a main pitch of Kotlin?..
- pdpi 8y ago
  Being compatible doesn't mean that compatibility is the path of least friction, especially when it clashes with good design. A good example of that tension is the final/open thing: Wonky frameworks abuse inheritance and force you to use open all over the place, but Effective Java suggests you should make every class/method final unless you specifically design it to be extended.

lmm 8y ago

> The author complains a lot about how Kotlin is different from Java. Err.. it is a new language — it is supposed to be different — otherwise why bother? Kotlin advocates try to have it both ways. If it's a full new language, to be evaluated as a full language, then why would you adopt it when it's missing important features compared to Scala? The narrative is that it's a set of small enhancements to Java that are easier to pick up than Scala, but the reality doesn't live up to that.

mavelikara 8y ago
> then why would you adopt it when it's missing important features compared to Scala? A useful IDE, much faster compile time, lower cognitive load in daily usage.
kllrnohj 8y ago
> then why would you adopt it when it's missing important features compared to Scala Such as?
- kodablah 8y ago
  There are a lot of things I miss. Case objects, macros, string contexts, (built-in) options as single-element collections, tuples, built-in either, abstract/self types, implicits, etc. We can argue about "importance" or even if those are good things, but we can't pretend that there aren't many missing features. Granted these days I appreciate Kotlin more than Scala, but that is more about tooling and backing.
  - kllrnohj 8y ago
    > We can argue about "importance" or even if those are good things, but we can't pretend that there aren't many missing features. I don't think anyone would deny that Scala has the most features of anything, it's purely a question of importance. Important missing features is more interesting to discuss than purely missing features. I've found myself more missing features from C++ when working in kotlin - specifically constexpr & static_assert.

vorg 8y ago

> > I have my favorite set of JVM languages. Java in /main and Groovy in /test are the best-performing duo for me. [...] we decided to give Kotlin a try. > The opening lines set the tone for the article He also wrote: > we decided to stick with Groovy in /test (Spek isn’t as good as Spock). If they were going to switch from the legacy language for /main code (i.e. from Java to Kotlin), why didn't they also switch from the legacy language for /test code too (i.e. from Apache Groovy to Kotlin) instead of dismissing it with "Spek isn't as good as Spock". And if they use Gradle, why not switch from Groovy to Kotlin for build scripts also.

afro88 8y ago

This was my first take on swift as an Obj-C dev back in 2014. I did an app extension in swift, basically just trying to write Obj-C code in swift (force cast and force unwrap all the things!). I didn't like it, I felt like it got in the way, and probably would've given a list of things like the author that are just lang differences. Needless to say after my 2nd round with swift it clicked, and then clicked again and again in different ways as the months rolled on. Never looked back.