5 ms·

If you haven't tried it yet, here's my seal of approval for Kotlin. Normally I'm quite reluctant to start a new project in a new language, but Kotlin edited on

If you haven't tried it yet, here's my seal of approval for Kotlin. 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.

Semaphor 6y ago
> Greytext types that are inferred are super useful. 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.)
- 1f60c 6y ago
  You probably already know this, but if you spread the query over multiple lines, it’ll show you the exact type at each step.
- jansan 6y ago
  I am using IntelliJ's WebStorm for my own project and Visual Studio Code for a company project, because all other team members are using it and we agreed to use the same tool. 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.
  - Semaphor 6y ago
    > 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 :)
  - donmcronald 6y ago
    > Also, I like IntelliJ's perpetual fallback license policy. Feels very fair to me. That's nothing. You should have been here when they used to let us buy the tools :-)
listenallyall 6y ago
I believe scope functions are a killer feature of the language. Being able to chain methods and write compact functions without having to declare variables, it makes so much code act and feel functional and direct. Immutability isn't on your list, it also contributes to the functional feel of the codebase. Definitely my favorite language currently, and extremely well-suited for server-side, it's certainly not just about Android.
- agumonkey 6y ago
  It's impressive how many people are screaming "will never leave android" when discussing kotlin. Thanks for your input
  - hocuspocus 6y ago
    I've honestly never heard anyone say that. Since Spring 5 it's pretty clear there's some interest in server-side Kotlin; there are several heavy-weights behind that. 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.
    - asdfthvaa2 6y ago
      >I believe pattern matching might land in Java sooner than in Kotlin 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
      - hocuspocus 6y ago
        Calling Kotlin's when pattern matching is a stretch. Even the official documentation doesn't call it like that anywhere.
amitheonlyone 6y ago
I agree. I tried Kotlin when I was working on an Android app and it was a pleasant experience. Somehow, everything easily makes sense and the Android Studio support for Kotlin is excellent. I followed two Udacity courses before starting on the app. If it helps anyone, these are the courses: 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-kotlin--ud9012 https://www.udacity.com/course/developing-android-apps-with-... [1] https://www.udacity.com/course/developing-android-apps-with-kotlin--ud9012 https://www.udacity.com/course/developing-android-apps-with-...
- scns 6y ago
  I would recommend working through Google's Codelabs if you wanna learn Android Programming with Kotlin. They are split up in Basic and Advanced.
  - thecupisblue 6y ago
    I would recommend skipping anything google recommended and finding courses made by people with real android development experience. 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.
- pjmlp 6y ago
  Android team makes it on purpose to use Java harder on Android, for obvious reasons. Even the samples use Java 7 style code when comparing for terseness.
notjustanymike 6y ago
The way you describe it sounds a lot like the Typescript / VSCode pairing. Is that accurate?
- thecupisblue 6y ago
  Not even close. 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.
  - andyfleming 6y ago
    All that works well TypeScript as well. The difference is that Kotlin only really works well in IntelliJ. TypeScript works well in both WebStorm/IntelliJ and VS Code.
    - thecupisblue 6y ago
      Not even close in my experience. Autocomplete is slow, generation offers quite less and refactoring is quite slower.
    - BossingAround 6y ago
      Autocomplete in VS has always been kind of 'meh'... Works OK for Go, should work fine for TS (until your type packages are off, in which case good luck to you), but IntelliJ code completion for stuff like Java and Kotlin is just on another level. 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).
      - vips7L 6y ago
        In Java I don't notice many differences in the autocomplete in VsCode (eclipse) vs IntelliJ.
vips7L 6y ago
I have a love and hate relationship with Ebean. On the outside it's a breath of fresh air compared to JPA (which is extremely stagnant atm), it provides ActiveRecord [0] if that's your thing, built in type safe generated query beans [1], built in migrations [2], and it's pretty easy to setup and easier to use than say Hibernate. 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 https://ebean.io/docs/setup/activerecord [1] https://ebean.io/docs/query/query-beans https://ebean.io/docs/query/query-beans [2] https://ebean.io/docs/db-migrations/#db-migrations https://ebean.io/docs/db-migrations/#db-migrations
Matthias247 6y ago
> - 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. 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.
- thu2111 6y ago
  That's definitely an issue. 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.
- john_miller 6y ago
  btw it's "type inference", not "type interference"
  - Matthias247 6y ago
    thanks - I'll try to remember it. Fixed the text

Semaphor 6y ago

> Greytext types that are inferred are super useful. 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.)

1f60c 6y ago
You probably already know this, but if you spread the query over multiple lines, it’ll show you the exact type at each step.
jansan 6y ago
I am using IntelliJ's WebStorm for my own project and Visual Studio Code for a company project, because all other team members are using it and we agreed to use the same tool. 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.
- Semaphor 6y ago
  > 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 :)
- donmcronald 6y ago
  > Also, I like IntelliJ's perpetual fallback license policy. Feels very fair to me. That's nothing. You should have been here when they used to let us buy the tools :-)

listenallyall 6y ago

I believe scope functions are a killer feature of the language. Being able to chain methods and write compact functions without having to declare variables, it makes so much code act and feel functional and direct. Immutability isn't on your list, it also contributes to the functional feel of the codebase. Definitely my favorite language currently, and extremely well-suited for server-side, it's certainly not just about Android.

agumonkey 6y ago
It's impressive how many people are screaming "will never leave android" when discussing kotlin. Thanks for your input
- hocuspocus 6y ago
  I've honestly never heard anyone say that. Since Spring 5 it's pretty clear there's some interest in server-side Kotlin; there are several heavy-weights behind that. 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.
  - asdfthvaa2 6y ago
    >I believe pattern matching might land in Java sooner than in Kotlin 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
    - hocuspocus 6y ago
      Calling Kotlin's when pattern matching is a stretch. Even the official documentation doesn't call it like that anywhere.

amitheonlyone 6y ago

I agree. I tried Kotlin when I was working on an Android app and it was a pleasant experience. Somehow, everything easily makes sense and the Android Studio support for Kotlin is excellent. I followed two Udacity courses before starting on the app. If it helps anyone, these are the courses: 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-kotlin--ud9012 https://www.udacity.com/course/developing-android-apps-with-... [1] https://www.udacity.com/course/developing-android-apps-with-kotlin--ud9012 https://www.udacity.com/course/developing-android-apps-with-...

scns 6y ago
I would recommend working through Google's Codelabs if you wanna learn Android Programming with Kotlin. They are split up in Basic and Advanced.
- thecupisblue 6y ago
  I would recommend skipping anything google recommended and finding courses made by people with real android development experience. 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.
pjmlp 6y ago
Android team makes it on purpose to use Java harder on Android, for obvious reasons. Even the samples use Java 7 style code when comparing for terseness.

notjustanymike 6y ago

The way you describe it sounds a lot like the Typescript / VSCode pairing. Is that accurate?

thecupisblue 6y ago
Not even close. 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.
- andyfleming 6y ago
  All that works well TypeScript as well. The difference is that Kotlin only really works well in IntelliJ. TypeScript works well in both WebStorm/IntelliJ and VS Code.
  - thecupisblue 6y ago
    Not even close in my experience. Autocomplete is slow, generation offers quite less and refactoring is quite slower.
  - BossingAround 6y ago
    Autocomplete in VS has always been kind of 'meh'... Works OK for Go, should work fine for TS (until your type packages are off, in which case good luck to you), but IntelliJ code completion for stuff like Java and Kotlin is just on another level. 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).
    - vips7L 6y ago
      In Java I don't notice many differences in the autocomplete in VsCode (eclipse) vs IntelliJ.

vips7L 6y ago

I have a love and hate relationship with Ebean. On the outside it's a breath of fresh air compared to JPA (which is extremely stagnant atm), it provides ActiveRecord [0] if that's your thing, built in type safe generated query beans [1], built in migrations [2], and it's pretty easy to setup and easier to use than say Hibernate. 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 https://ebean.io/docs/setup/activerecord [1] https://ebean.io/docs/query/query-beans https://ebean.io/docs/query/query-beans [2] https://ebean.io/docs/db-migrations/#db-migrations https://ebean.io/docs/db-migrations/#db-migrations

Matthias247 6y ago

> - 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. 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.

thu2111 6y ago
That's definitely an issue. 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.
john_miller 6y ago
btw it's "type inference", not "type interference"
- Matthias247 6y ago
  thanks - I'll try to remember it. Fixed the text