Kotlin is a great fit for badckend development. But the experience of searching for a job in this area? Not so nice. I put very prominently on my profiles that I do Kotlin and backend programming and that I explicitely do not want to do Android, but that’s still the vast majority of offers I’m getting. Any ideas on how do improve that experience?

Kotlin developer is becoming a synonym to Android developer 😔 Community needs more push towards Kotlin on server side, there are hardly any good books or resources available on Kotlin Server side

I think we need more marketing above all

apply for java positions. chances are they are already using kotlin, if not they'll probably consider it

that’s one way to do it. But frankly I am much more productive in a pure Kotlin codebase, so having a way to filter out the java positions would be nice.

Stackoverflow jobs does a pretty good job in filtering what you like and disslike ...

I think I will write an article about this. I started another thread here https://kotlinlang.slack.com/archives/C0922A726/p1571475269385200

And don't forget to join #hiring 😉

I am a backend dev, working in the JVM/Spring stack and we are currently moving from Kotlin back to Java. We also stopped asking for Kotlin during hiring for this reason. And why? The tooling. IntelliJ just works much faster and better with big Java projects than big Kotlin projects, let alone big Kotlin+Java mixed projects which perform the worst. It has reached a point where we just can't afford using Kotlin anymore and it is jeopardizing our entire development. Introducing a compiler error into a Kotlin file slows the whole IDE to a crawl and typing/selecting/fixing the issues freezes the editor for >10 seconds on every action. JetBrains refuses to acknowledge this as a problem and fix it. There is a whole bunch of issues on YouTrack and nobody is working on resolving them. I can't recommend starting a production-level enterprise backend project in Kotlin at this point.

Writing micro-services works just fine as they tend to be smaller, but this is a good caveat. If you have a monolith, tread lightly/slowly.

@poohbar From what I've heard, the main focus of IntelliJ 2019.3 is performance increases. Perhaps try 2019.3 EAP and see if that helps? https://blog.jetbrains.com/idea/2019/10/preview-the-performance-improvements-in-intellij-idea-2019-3/

95% of shops don't actually need microservices. Unless you are Netflix or Amazon you will be fine with a monolith. And if Java monolith worked fine, the same Kotlin should work just as good or even better in the same IDE. Which is definitely not the case from my experience. @todd.ginsberg Well I am definitely going to try 2019.3 but none of the performance issues I reported are being fixed in 2019.3.

sounds like you have much more IntelliJ pain than we do (most of our logic is frontend I guess, so the Kotlin backend is not so big) but I definitely find the slow startup painful

I'm surprised you find the startup much of an issue in comparison to overall usage. Are you starting and stopping IntelliJ a lot during the day? I find I start it, and leave it running, so the startup isn't that big a deal. Plus I remind myself how much it does once it's up. Not going to complain about a bit faster startup, but personally agree with poohbar that it's a low priority.

No, I avoid it most of the time. I tend to restart it occasionally to clear caches, in which case the indexing takes several minutes

Yes, indexing is slow, but of course that should be expected, as it is indexing 'the world' on a cache reset. Why do you reset the cache? I only do that if I'm having a weird issue, and that happens quite rarely.

ah - we are pure kotlin aside from some imports, that might explain it?

Likely explains it as imports don't matter. The library is already in byte-code, so the Kotlin compiler doesn't have to interact/wait for the Java compiler before it can do its thing. Also I get the impression that poohbar's project is 'huge'. Older backend monolith's tend to have many Ks of lines with business logic, interfaces for abstractions, tests etc.

I do believe our project would perform better if it was 100% Kotlin. However, that was never the goal. It's pretty big and we never wanted to rewrite the whole thing. Which is a use case I thought JetBrains was aiming to support. I was wrong though and now I pay the price. Reminds me of when I trusted Google that they would make the upgrade path from angular.js to Angular 2 smooth. Was nothing but. Pretty much had to do a full rewrite, months of work.

@poobar just curious what are your computer specs? Personally I cannot stand any lag, I have a computer that costs 4k.

@poohbar Don't worry, I wasn't suggesting that you should, or could, rewrite the whole thing. More intellectual curiousity to see if the project would still be too large for just the Kotlin compiler. And yes, I believe the intent is to be usable with mixed projects, but obviously a mixed project will never perform as well as a single language one will. BUT I agree that it should be usable, and your scenario doesn't sound usable at all. Not even close. Reminds me of my experience with the Gradle Kotlin DSL in early forms. There were issues with Kotlin only projects and massive slowdowns in the IDE. I haven't seen those for a 100% Kotlin project in a long time, but I have negligible experience with a mixed code base. I'm curious. How many lines are we talking for your project? For the Angular scenario, personally, I think it was a mistake for Google to even hint that Angular 2 was an upgrade. It was such a re-write of fundamental approaches, that it was effectively a new framework. As you say, upgrading wasn't realistic at all.

@Luis Munoz It's a 2015 Mac Pro (2.2 GHz i7, 16 GB RAM). It's not the fastest machine but I can easily compare the IDE performance to other projects that are Java-only and are perfectly usable. I don't think an upgrade to a 4k desktop would bring me 100x the speed of the IDE. It would be probably much less than that. @Mike The project is not really that massive. It's 50,000 lines of Java and 20,000 lines of Kotlin. We currently use Kotlin for all tests and for all data classes. I thought it was a good idea originally. I honestly have not thought, in my naivete, that "the project will never perform as well as a single language one will". I had no idea. The thing is, I don't really believe it's just "slow". Freezing for 20 seconds completely while blocking the UI on any compiler error I attempt to fix sounds more like a bug than just non-performance. The project also uses Maven instead of Gradle and I feel like Maven is getting much less attention from JetBrains nowadays.

@poohbar: I can't remember the last IntelliJ release that didn't have issues with Gradle projects either... If there's one thing I have noticed with using Jetbrain's products for a couple of years it's that they're great at adding new stuff (ie: changing the %$!"/ icons for every release), but issues can stay open for years without any dev attention. I've also seen the slowdowns you're talking about, my current project is about 5000 lines of Kotlin (and some Java, probably like 5 classes that are used with an annotation processor), and I've had complete freezes happening when modifying classes with a lot of type inference.

@fred.deschenes Exactly! And I don't really understand it from their perspective. They pretty much have no competition feature-wise in JVM IDEs. Couldn't they just slow down and focus on bug fixes and performance updates? Honestly, I would be content if they have not released a single new feature for a year.

They have actually announced that 2019.3 was going to focus on performance and quality. So let's hope for a step forward.

@poohbar You're right that multi-language compiler causing slowdowns isn't intuitive. I've thought back, and I first ran into it when I was hearing about Groovy. Saw a presentation, and the presenter discussed what was required in order for Groovy and Java to interop. One of those 'of course' things once it's explained, but not thought of beforehand. And the Kotlin compiler will always be slower than the Java one, but it should just be slower. I agree that what you're experiencing is not slowness, but unacceptable defects in process/ I am also surprised that it's not being taken more seriously as 70K lines isn't all that large a project. Jetbrains has been giving Maven support some love lately, but I also feel it's secondary to Gradle. As I primarily use Gradle, I don't notice.

@fred.deschenes @poohbar your experiences aren’t matching mine (thankfully for me). I’m not experiencing any of the problems you do and we’ve got 77K Java, 71K Kotlin and 32K Groovy. I’m running on a MBP too, so not a super-fast machine

@tddmonkey Maven or Gradle? How many modules?

Gradle, 60 modules

Tangent: what don't you like about Gradle in idea? It wasn't great a couple years ago, but seems to work very well right now. Lots of love from both Gradle and Jetbrains here as gradle has put a pot of effort into making tooling integrations easier,faster,better.

I struggle to see what it gives me, but I’ve known it cause hassle for plenty of people

Yeah, I think the unique combination of Maven+Java+Kotlin is what trips IntelliJ up. Because most people use Gradle. I can't use Gradle because I hate it, so that's that.

Yeah, I think the unique combination of Maven+Java+Kotlin is what trips IntelliJ up

this is what i'm using too, and it's very slow even on a small project (10-20k lines)

@tddmonkey It gives you consistency between IDE and CLI nowadays as IntelliJ is able to delegate most things to Gradle directly. Also don't have to remember to update the IntelliJ project externally every time the build.gradle changes. IntelliJ will either do it automatically ( I don't recommend that), or warn you that it has detected changes, and allow you to update/re-import. But YMMV. @poohbar Well, if you're 'stuck' using Maven (I slightly prefer Gradle, but like Maven too), then I think you're also 'stuck' giving up on Kotlin. I don't see Maven support ever getting the attention it would need to sort this out (assuming that's fundamentally the difference). But of course I don't represent JetBrains in any way so this is nothing more than my opinion. Fortunately for you, the Java language is improving. It will never be Kotlin, but it is getting better in some key areas.

@Mike That's really sad to hear. I think Gradle is a huge step back and don't understand it's popularity. And to be honest, I don't actually think it's that popular in real enterprise projects. Maven is rigid and solid. Gradle is a bunch of thrown together scripts that are impossible to decipher. Groovy is also a bad choice for a build system and Kotlin build files have performance issues.

“real enterprise projects”?

As I say, opinion only, but that's my interpreation. I'm at a FI, and we use Gradle almost exclusively. But I don't think either of us needs to get into a discussion about Gradle. I agree on your comment on Maven, and disagree on Gradle. Enough said I think as it's not the point here.

I have a customer that tried to move to Maven with a project consisting of over 300 modules, about 120 were ear/war/corba modules and the rest libraries. Eventually we moved to Gradle and now they are able to build consistently and they have partial local builds with huge improvements in build time. There are more than 20 developers working on the codebase and the original projects started in 2001.

My opinion. Maven is perfectly fine for most projects. Gradle was created for exactly what you just described. Complicated, custom projects. But it does handle most projects just fine with conventions. It's just because it's so flexible, people will inevitably abuse it, creating spaghetti builds like the old ant days. The other concern with Gradle is the recommended practice has changed a few times over the years, and unless you know that, you're just as likely to be using an older, less elegant approach to achieve things. Gradle is meant to be declarative, but people still tend to use it imperatively. Defining everything that needs to be done explicitly as scripts/tasks rather than using the declarative nature of Gradle. It's a big mind shift from Maven.

Yes, I disagree with your points on Gradle/Maven but I do agree that this not what the thread is about. I think we can all feel a little sympathy for the poor souls who use the Maven+Java+Kotlin combination because at least for me it was impossible to tell that that combination is somehow going to become unusable in medium sized project. JetBrains lack of response on this is deplorable. It would be better if they explicitly stated they it's not supported rather than this.

We can agree on that. It shouldn't matter if you're using Gradle or Maven (or Ant, or Sbt or Bazel), as the build tool is secondary to Java/Kotlin. This is disappointing, but very valuable, information to have.

I don't understand how you could "generate a project" externally and then use it without the build tool integration. How would IntelliJ know how to compile the project? Would it basically work like an IntelliJ project without any build tool? So I would manually add the dependencies in Project Structure? It's been a while since I last did that.

@poohbar no - it generates everything that is required for the project to be built and run. It’s not that much different from Gradle/Maven integration, it just happens once, outside of IDEA, instead of being controlled from within. @Mike I’ll check if anyone on my team does an import

In earlier days the gradle 'idea' plugin would generate all the artifacts when you ran

./gradlew idea

and same with the 'eclipse', Now the IDE has simplified the process. If they can just wait until I save the gradle or pom file before trying to update the project it would be awesome.

@tddmonkey So how exactly do you do that in case of Maven? Are you talking about using "mvnw"? How do I turn off Maven integration in the project?

I have no idea, I don’t use Maven

Right.

@corneil Turn off auto-import. Intellij then won't start importing until you ask it to. And it will pop up a dialog to let you know it detected a change with an 'ignore' and an 'import' button. If I'm making changes, the dialog pops up, and I just leave it there until I'm ready to re-import. @tddmonkey I use Intellij's import exclusively. My projects are simple, single module projects, so don't know if that's the issue, or you switched a while ago, and have never gone back, or there are still issues that I just haven't experienced, or heard about. Most people I work with use import. But whatever's working for you is what makes sense as there's no 'one solution fits all' in this industry.

In my experience Maven is fine for single module projects. Anything beyond that and I pull in Gradle.

2019.3 promises way more than startup times. They also corrected quite a few things in Java type inference: "We’ve invested a lot of effort into optimizing Java type inference, which helped us fix the various editor hangs. Also, Java type inference for long method call chains now works much faster."

so strange why they think startup time is important

it is a detail, but it participates to first impression. And it also helps them tackling other issues.

so strange why they think startup time is important

To be fair, a lot of people complain about startup times. I know people who use vscode for Java because "it's light weight and starts fast". I think it's ridiculous, but I've seen a lot of people complain about it.

vscode is an editor not an IDE

i agree with that, but it's still competition for them

I'd agree that VSCode is 'lightweight' in comparison to IntelliJ when it comes to Java coding. Lightweight on refactoring support. Lightweight on code analysis. Lightweight on static analysis, Lightweight on Git support. Lightweight on debugging, etc, etc, etc 👿 Using VSCode is likely ultimately slowing them down. I suspect they keep opening and closing their editor, and only look at a few files, whereas those of us that are heavy IntelliJ users open it at beginning of day, and 'live' in it for rest of day, so start up time is not very important.

yeah my IntelliJ stays open for like... weeks at a time, I never understood closing and opening it multiple times a day

^^ The same as people who shut down their machine at the end of the day. I literally just close my laptop lid and that’s it. Next morning I open it and I’m ready to code in seconds

@poohbar So, am working in a mixed Java/Kotlin project and it was bogging down to the point that I was killing IntelliJ and starting it fresh. I then went in and disabled all non-essential plugins, and it's ticking along very nicely now. And this isn't a large project. A number of the plugins were things I don't need for Kotlin/Java. Node, Python and things like that. But one plugin I've had conflicts/issues with before is the Lombok plugin. Do you have the Lombok plugin installed and enabled? If you do, I'd try disabling it and see if that helps. And turn off any plugins you don't need for that project. I don't think Lombok and Kotlin 'play nice', and if you're using Kotlin, then you don't need Lombok anymore anyway (at least once you have a chance to migrate Lombok code to Kotlin of course)

That's interesting, did you forward that to the lombok plugin devs?

No. Generally speaking, I don't have the Lombok plugin enabled as I can appreciate what Lombok brings to the table, but I've always avoided using it. Having said that, it only seems to intermittently 'collide' with Kotlin, as I've had the Lombok plugin enabled, and had no problems with Kotlin projects, but have had issues in the past. Maybe it's a problem when one has a mixed project? Don't know enough to provide much details to anyone.

@Mike wow, that made a huge difference

Hmm. I wonder if it's a case of both of them watching for code changes and bytecode changes, and the keep triggering each other in certain scenarios. I don't have anything more than a hunch on this, but glad it helped someone else too.

@Mike Disabling plugins is the first thing I do. I have only the bare essentials enabled. Maybe I should disable all the Spring ones too since they don't really work anyway. I also heard that disabling inspections helps but I am not sure if I want to go too crazy with that as inspections can be really useful.

As long as Lombok isn't a 'bare essential' for your project... I've had issues with it before, too. Seems like you have a lot of issues with IntelliJ that I don't, as I find the Spring plugins helpful. And if you disable inspections, you may as well start using VSCode or similar.

I use Kotlin specifically so that I wouldn't have to use Lombok 😄

I'm curious. As this seems to be more related to Intellij and Maven integration, have you tried toggling the Maven Runner option for 'Delegate IDE build/run to Maven'. With Gradle, having this on initially was terrible, but with improvements in Gradle and IntelliJ, I now run this way all the time. Don't know what the scenario is like on the Maven side. By the sounds of it, you can't be worse off by trying the opposite of what you currently have.

I’m only seeing slowness when using projects that have a lot of DSL code - specifically tornadofx

please, did the 2019.3 resolve performance/lag issues?