What @vladimir_schneider is saying makes sense. I’m not speaking from experience, but just saying their expressions make sense, I feel that I identify with them, and I have the same concerns. The things @yole has said feel dismissive and like they were missing the point.
First off, it seemed like @yole was saying that non-specific feedback is not helpful. That is completely wrong and is very typical engineering miss-thinking. To point out that in general, the refactoring and formatting tools are not nearly as good as Java’s and that this is holding them back from wanting to use it is not undetailed enough to be helpful, it is actually more helpful than filing a bunch of issues for each individual problem they experienced because it points out an underlying problem or problem theme. Why bother to file a bunch of issues they happened to run into if anyone using these tools would run into many of their own issues easily with real world use? This makes it seem like there is a lack of dogfooding with Kotlin, or as @vladimir_schneider inferred, new Kotlin development is taking priority over quality IDE support.
Of course there are limited resources and things must be prioritized and the prioritization will never be perfect. But Kotlin is a language made by JetBrains, and they are the leader in making the best IDEs. Many people will assume this means Kotlin will have just as good as, if not better IDE support than Java. If the experience ends up being different than that, it will be an unexpected turnoff. Kotlin language features should be developed in tandem with, and by the same team as, those providing IDE support. Every new Kotlin feature should not be considered out of beta until the team feels they have out of beta IDE support that equals or rivals what you would experience with Java.
If the people working on the language features are not the same people making the tools to help use them in the IDE, there will be a lack of synergy. The language and the IDE are not unrelated tools, they share a very tight relationship. I actually think this concept of having the same people develop both, should be taken a step further. The IDE support should be added first, or at least simultaneously, as new language features are developed, as a way of aiding the language designers to think in terms of how the language will be used from an IDE. This will help them see relationships they would otherwise miss, and ensure an overall high quality experience, rather than just a high quality language. Why wait for feedback from users when you can be your own users and get the feedback from yourself first?
That leads back to the point about asking for specific feedback from users. That is only helpful when what you are lacking in general is detailed feedback from users. If we can see you seem to already be overwhelmed with specific feedback that you don’t have enough time to keep up with, this does legitimately demotivate people from providing specific feedback, and leads naturally to the idea that general feedback would be more helpful. There are only so many very specific things a team can address at once, but they can also continually improve their mindset and project management philosophy, which is the type of feedback being offered here. Both areas of feedback should be welcome, yet both do have a limit in what can be prioritized for improvement by the team at any given time.
Anyway, I realize this is an old thread, and things have probably improved, somewhat. But unless the team has changed to a more dogfooding mindset and the language and IDE are developed together to provide a desired experience, I don’t expect things will ever get better enough, or at the very least it will take a very, very long time.