This year, we ran the first Kotlin Developer Survey. We designed the survey to help us identify and ...

# announcements

[hhariri]

This year, we ran the first Kotlin Developer Survey. We designed the survey to help us identify and prioritize the pain points that most significantly affect Kotlin users’ satisfaction. We will use the collected data to refine and prioritize the Kotlin team’s plans.

📈 Check out the first survey’s key findings, our plans to address the most popular issues we discovered, and get some tips about what you can do about them right now.

[Tolriq]

Glad to see the IDE freeze prioritized.

[agrosner]

Thank you!

[dewildte]

Glad to see I am not the only one who finds the multi-platform build setups a learning curve.
That’s been one of the biggest pieces of friction for me.

[itnoles]

is Gradle is really best build systems for Kotlin?

[mcpiroman]

My summary would be: Kotlin design 👍 , Kotlin implementation 👎

[Stephan Schröder]

@itnoles Gradle is the best build system for Kotlin that is in use. There is/was also the experiment of Kobalt https://beust.com/kobalt which sounded promising, but nobody started using it after Gradle adopted a Kotlin dsl, which was good enough for most people. (At the point where I took a look at Kobalt it's IntelliJ plugin didn't work anymore. So the project is definitely abandonned.)

[Colton Idle]

looking forward to IDE and autocomplete improvements. never in my life has coding been so painful.

[dewildte]

@Colton Idle Can you expand a bit, I have found my experience with Kotlin and the IDE to be outstanding.
So I am curious to know why it is so bad for you?

[agrosner]

It happens at my company on a large project with 100+ modules

[agrosner]

M1 certainly speeds it up but there still is a noticeable lag

[Stephan Schröder]

@dewildte this is Bruce Eckel's take on what the problem with Gradle is: https://www.bruceeckel.com/2021/01/02/the-problem-with-gradle/
For me the Kotlin DSL makes working with Gradle possible but now and then you come to the point where you (re)discover that the Kotlin DSL is just a layer on top of a powerful core written in an untyped programming language.

[dewildte]

@Stephan Schröder I am reading the link are starting to understand the problem here.

[Colton Idle]

Basically. even now. I have nothing else open on my laptop. I have a 3k line kt file and if I type BigDeci it takes like 20 seconds for it to autocomplete to BigDecimal . Its insane. and drives me mad.

[Tolriq]

In a 3k file kt try to ctrl+alt+L with optimize import and see the world collapsing 🙂

[Colton Idle]

lol

[Colton Idle]

like. i know my files shouldn't be like 3k lines long. but its not like its 30k lines long.

[Tolriq]

My comment was not meant like that 🙂, more like I feel the pain too in even smaller files, and each time I press those keys before commit I cry.

[gildor]

@Stephan Schröder It’s terrible take from Bruce Eckel.
I recommend everyone read the answer article on this from @melix
https://melix.github.io/blog/2021/01/the-problem-with-gradle.html

[Jonas Trollvik]

What tool are you using for the survey? Really nice looking graphs

[Stephan Schröder]

@gildor my observation is that there is - for most people - a problem with gradle. Of course there are always a few individuals who are more than competent with it. You can see by simply open their gradle files, they are super ellegant. The scary thing is that I was/am - at my last and current job - the most knowledgable person on the topic of gradle, and I would only self-rate myself as advanced beginner. I have my simple patterns and my cockie cutter solutions to common problems, but when those fail i'm lost (so no deeper understanding. I did an online course on gradle and wasn't smarter afterwards. I'm pretty sure the teacher had no deeper understanding either). Again, most people I meet know even less then I do. So Cedric's post sounds like survivership bias to me.
I guess, that the problem stems from the extreme configurability of gradle (of course, since I still -after many years of using it- lack deeper understanding of gradle, I can't really say how extreme that configurability really is. but I know it's beyond my horizon.)

[Kathrin Petrova]

Hi @Jonas Trollvik !

What tool are you using for the survey? Really nice looking graphs

We are using https://app.alchemer.com/, but these graphs were styled for this report by JetBrains Designers team 🪄

[poohbar]

@gildor no, it’s a great take by Bruce.. I hate the response from @melix especially on point #4. Having 16 ways to do one thing is okay in a programming language. Not okay in a build tool.

Anyway, I have been using Kotlin with Maven without issues and will continue to do so. If JetBrains drops support for Maven or vice versa I am going back to Java.

Gradle is by far the worst part of the Kotlin ecosystem and I wish we stopped pushing it as a viable solution to anything.

[melix]

easy to complain...

[dewildte]

I think as a community it's important not to minimize the opinions or struggles of others.
We should strive to understand and build up.
This constructive and empathetic approach
Can bleed into our tools and help improve them.

[poohbar]

easy to complain...

Yeah. I am complaining that JetBrains is pushing the worse build tool out of the two standards just because people think XML is icky. 🙂

But that ship has sailed a long time ago.

[melix]

no comment, if that's to read such things, no reason to summon me

[cedric]

@Stephan Schröder Sadly true, I stopped working on Kobalt, little point after all the mindshare that Gradle has. I still think that its DSL and plug-in system is superior to Gradle's, but well I'm not exactly subjective either 🙂

[cedric]

Although I have to say after a few years of writing a lot of Rust, the only build system that's better than Kobalt is Cargo 🙂

[dewildte]

@cedric Would it be valuable to encapsulate what makes Cargo so great
and then explain how to achieve the same advantages in Gradle?
Maybe not here but in a more verbose article?
The fact of the matter is that many of us have to use Gradle
and all the help we can get from the experienced users of it would be useful.

[cedric]

Interesting thought

[dewildte]

I am in the middle of trying to migrate a team of Android developers and a product into
Jetpack Compose.
To my surprise most of the developers had 0 experience with it and it’s daunting for them.
I had to distill my experience with it into bite size chunks in order to help them get to grips with things.
In my mind much of Gradle seems like a mystery to me because of all the implicitness of it’s operations.
And lack of guidance from the big corps on it further complicates the issue.
No really great (and free) courses that explain how to get from nothing to these very complex examples.

[dewildte]

Most of my time is spent explaining internals too.
Many developers I have worked with are not confident using tools
whose guts are a mystery.

[cedric]

I started Kobalt because even though I followed and embraced Gradle since the early days and even though I read its 90+ chapters of doc ( multiple times), I still never developed a good understanding of it and I always ended up writing my build files with a lot of copy/pasting from StackOverflow, and them promptly forgetting what I just did, let alone understand it. Maybe I'm just not smart enough for Gradle. I also wanted a Kotlin DSL that's real Kotlin and not saddled with weird legacy requirements. If I want a global variable, I want to say const val VERSION = "1.3" and not project.ext.version = "1.3" (or whatever the correct syntax is).

[dewildte]

That statement really encapsulates why I love the Kotlin DSL.
The discoverability through the type system helps me explore and understand things.
I can jump to the implementation of a class and understand how it works and then how to use it.
Groovy was really lacking in that area.

[dewildte]

I do things like this. and see what functions a thing has.

[cedric]

100% this. In my early days of development of Kobalt, when I wrote the first version of a build file and autocomplete magically worked right away, I cried tears of joy 🙂 Autocompletion of Groovy, and build.gradle in particular, never worked reliably for me, in 10+ years of multiple versions of the plug-in

[Colton Idle]

wow. and here I thought I was the only one and the Cedric Beust has had the same issues. 😍

[cedric]

There are dozens of us. Dozens!

[cedric]

Dozens of millions.

[mcpiroman]

If there only was something like Gradle but half that bloated and complicated..

[igor.korotenko]

just to +1, I'm developing android apps since ant and eclipse old times, learned compose to the level of being confident enough to rewrite app pretty quick, but I never really understood gradle to the level of not googling everything I want to do, and absense of fear doing something wrong going a bit further templates. Ofc maybe I'm just not smart enough, but I believe good design == absence of requirements of being smart user

[Larry Meadors]

gosh, all this time i thought i was just a bonehead for not grokking gradle when all the cool kids were using it...this conversation has helped my self-esteem greatly 😂

[Larry Meadors]

imo, the statistics on the build tools over-state "performance"; "build setup" is hard because the "tooling support" and "documentation and examples" are sub-par

[Larry Meadors]

my biggest gripe w/ gradle is that you can put anything anywhere and if it's wrong it just doesn't work 😐 no error or warning, just ... nothing.