[HN Gopher] Detekt - A static code analyzer for Kotlin
___________________________________________________________________
Detekt - A static code analyzer for Kotlin
Author : TheWiggles
Score : 76 points
Date : 2025-07-24 11:16 UTC (11 hours ago)
(HTM) web link (detekt.dev)
(TXT) w3m dump (detekt.dev)
| synesso wrote:
| I've been using detekt for years. Why is this suddenly the top
| article on HN?
| collinvandyck76 wrote:
| There's a ton of reasons why that may happen. One of which
| being that someone may not have known about it and wanted to
| share.
| TheWiggles wrote:
| Yes, this is exactly why I posted it. I'm learning Kotlin but
| thought others would find it useful.
| self_awareness wrote:
| Random trend, that's all.
|
| Sometimes people post the same link to HN for weeks, and
| nothing happens. Suddenly after 10th try, trend catches up, and
| the same link is on the main page.
| smokel wrote:
| Out of curiosity, how many of you are using Kotlin for backend
| development? It seems that Java has caught up a bit, and the
| advantages of Kotlin (extension methods, better syntax, better
| null-checking) might not be enough to justify the risk of lock-
| in?
|
| Personally, I quite like Kotlin, but I haven't been able to
| convince most of my greybeard colleagues to make the leap.
| glasskaar wrote:
| My workplace of ~3k employees has Kotlin as the golden path for
| our backend services. We previously mainly used Java, but I
| think it's been Kotlin for almost every new service since 2018.
| I think it works great for us.
| Traubenfuchs wrote:
| One of our ex developers was a big kotlin fan and enabled it in
| every java/maven project he touched -that is actually quite
| easy and interoperability between java and kotlin is fine. He
| also refactored every class he touched to kotlin. After he
| left, no one else was really into continuing his work. Our
| mobile devs use kotlin though and they are happy.
|
| I'd say it's nice and I would actually start every new
| (spring/java) project I do in kotlin now. But for existing
| projects, I actually see no value. It does not magically make
| code easier to understand and it doesn't reduce bugs, it's just
| a bit more fun and challenging to write and pads your resume...
|
| We did have one issue where upgrading the kotlin version from
| 1.x to 2.x in a project broke all depending projects due to a
| classfile version issue though. I deferred it by just forcing
| the version back to 1.x. That's the kind of annoyance you can
| encounter.
| Tmpod wrote:
| I think those features are quite good on their own, but Kotlin
| has many more worthy features, such as sealed hierarchies,
| import aliases, delegation, operator overloading, default
| arguments, named arguments, reified generics, inline value
| classes (though somewhat limited by JVM features still), a very
| nice stdlib (in part augmenting Java's stdlib), etc. Even newer
| stuff like context parameters are really interesting and have
| useful applications.
|
| The language ends up being more complex, but I find it a joy to
| use; going "back" to Java projects always leaving me wishing I
| could use Kotlin instead :P
|
| Yet it's true, Java has improved quite a lot in the last
| decade. It is ahead of Kotlin in a few things, like pattern
| matching (though not incredible, it's still better than the
| nigh nonexistent support in Kotlin).
| jillesvangurp wrote:
| I'm a bit opinionated here and I know some people will
| disagree. But being a grey beard myself (50), I don't disagree
| with your sentiment here. People tend to get stuck in their
| ways as they get older. And I've observed a lot of people my
| age resisting anything new (languages, frameworks, anything
| that's newer than what they learned 20 years ago.
|
| Working with younger people exposes that quite mercilessly and
| I can recommend doing that if you catch yourself doing a lot of
| repetitive projects with people well over 40. Try something new
| if you want to stay relevant. Move on if your colleagues can't
| deal with that. It's only going to get worse with them.
|
| I've been using Kotlin with Spring boot for backend development
| since 2018. I did Java before that; since 1995. Java has indeed
| improved and was probably nudged along by what Kotlin and Scala
| and other languages have done. But it hasn't really caught up
| properly IMHO. Everything Kotlin does right out of the box
| (intentionally, to fix what Java did wrong here), Java
| continues to do wrong out of the box and this is actually a big
| deal because it does a lot of important stuff wrong mainly for
| compatibility reasons. That's the big biggest difference. These
| are things that Java cannot fix in a backwards compatible way.
| That alone is a good reason to switch.
|
| Examples of this are that it makes code less null safe, non
| final, introduces unnecessary mutable state, etc. Kotlin allows
| you to do these things when you need to but it defaults to
| things being closed, final, val (instead of var), etc. And
| these are just things that Kotlin has been doing right since
| it's first releases. It has progressed a lot since then.
|
| If you like verbosity and don't want access to the countless
| convenient extension functions, DSLs, co-routine support, etc.
| that e.g. Spring ships for Kotlin, go for Java. In they end you
| kind of do the same things. But IMHO in a needlessly verbose
| and clumsy way.
|
| But you are missing out. IMHO anything to do with Spring Flux
| is just an order of magnitude easier via Kotlin and co-routines
| and IMHO even attempting to use that from Java is misguided.
| But in Kotlin, you can hardly tell the difference with non
| reactive code. With Java, this turns into a mess of leaky
| abstractions, function chaining, and lots of boiler plate. Our
| server is effectively using only a handful of threads with lots
| of websockets, connections, background processing etc.
| happening.
|
| Reactive/async stuff across all of the mainstream Java server
| frameworks is well supported from Kotlin and has been for many
| years. E.g. the co-routines library ships with lots of
| extension functions for just about anything you can name. The
| green thread stuff Java does is often cited as a thing that
| closes the gap. But from a Kotlin point of view it's just
| something that makes using legacy Java code a bit less tedious.
|
| Jetbrains and Spring did some joint announcements at the latest
| Kotlin conf. The upcoming major release of Spring Boot is going
| to be even more Kotlin heavy and centered than the current one
| is. And honestly, you had a superior experience with v1 way
| back even. They won't abandon Java support. But at this point,
| you are really missing out if you are sticking with Java. There
| are non technical reasons for doing that but very few (if any)
| technical reasons.
|
| They are doing a big push with the new release on making
| nullability checks on all the Spring Java stuff stricter for
| Kotlin and making sure Kotlin does the right things. And all
| their documentation was already dual Kotlin/Java but looks like
| it might be leaning towards Kotlin first going forward.
|
| Many reasons to like Kotlin. If somebody tells you it's Android
| only that was never true and there's a lot of quiet Kotlin
| usage with anything Java because there's not a single Java
| framework that you can't seamlessly use from Kotlin. And almost
| universally it's a better experience. The older the better
| actually. Because the old one tend to not use any of the new
| Java features. Where new is introduced in the last 15 or so
| years.
| foobarian wrote:
| I think the Spring support is not highlighted enough. It is
| very good, among other things OpenAPI client code generation
| is very good out of the box.
| darthrupert wrote:
| As a Rust enjoyer, I wouldn't get into Java at least without
| being forced to (better is not good enough in this case), but
| Kotlin seems neat. The only thing that has been blocking trying
| it out is that the non-IntelliJ experience has been rather
| poor.
| killingtime74 wrote:
| Atlassian uses Kotlin extensively. Thousands of developers
| working on JIRA, Confluence and other associated products.
| gavinray wrote:
| _Raises hand_
| stefs wrote:
| i use kotlin at work mainly for frontend development, but i
| choose it for almost all projects i have control over (i.e.
| personal projects which are usually backend development and
| smaller scratch-an-itch tools at work). that said, i haven't
| re-evaluated pure java in a long time, but i'm pretty sure i'd
| still miss many of kotlins features.
| frevib wrote:
| We introduced Kotlin at ING (15k IT colleagues) years ago and
| adoption rate is 11% and growing: https://medium.com/ing-
| blog/kotlin-adoption-inside-ing-5-yea...
|
| Many larger companies in The Netherlands have moved away from
| Scala and Java and use Kotlin now. The switching costs are
| neglegible and the benefits are big.
|
| The problem with Kotlin is, you don't want to go back to Java.
| ragnese wrote:
| EDIT: Forgot to confirm that I do, in fact, use Kotlin for a
| fairly large and moderately complex backend system (multiple
| deployed systems, including one HTTP REST-ish API).
|
| I'm of two minds about it.
|
| I started working with Kotlin back when Java was still a very
| ~~stagnant~~ _stable_ language. I definitely find Kotlin 's
| syntax to be much more comfortable, expressive, and in many
| ways much more simple than Java's.
|
| But at this point, the only big technical features that still
| put Kotlin over Java for me is the handling of nulls by the
| type system (which is, admittedly, mitigated decently well in
| practice by Java tooling configurations and ugly annotations),
| and value types (zero heap-allocation wrapper classes).
|
| Another thing to keep in mind is that now that Java is actually
| adding features again, the Kotlin developers will have to also
| play "catch-up" to Java in ways that it didn't have to when it
| first gained popularity. It puts Kotlin in an awkward spot when
| Java's implementation of sealed classes and interfaces was
| initially better and more flexible than Kotlin's, or when
| Java's `switch` is now more powerful than Kotlin's `when`, etc.
|
| Kotlin is also betting heavily on their multi-platform stuff,
| which I'm skeptical about. It seems to me that it will further
| slow the ability to add useful features to the language if you
| have to cater to the lowest-common-denominator between Java and
| JavaScript (and Objective-C? -is that how it works for iOS?)
| runtimes. Instead of being the best language for a given
| platform, it'll just be a pretty good language for a few
| platforms. I wish them all the best in dethroning JavaScript
| from infecting every computing platform and domain, but I'm
| just skeptical.
|
| So, honestly, I don't actually recommend people start new
| projects in Kotlin. I'd suggest going for Java, or something
| that's meaningfully different in semantics and philosophy like
| Clojure or Scala. I say this, but I'm not actually sure that
| I'd be able to follow my own advice, because I really don't
| want to have to stomach Java's syntax, idioms (way too many
| annotations), and stupid null handling.
| clumsysmurf wrote:
| I am also worried about the concurrency side of Kotlin. Since
| Roman Elizarov, the architect of the coroutine / flow
| implementation, left JetBrains two years ago, it seems to be
| stagnant. Looking through the tracker conversations I almost
| get the impression whoever inherited it doesn't know where to
| take it next.
| ragnese wrote:
| That's a whole huge can of worms, too. Coroutines and the
| suspend keyword were a great innovative feature at the time
| (very clever implementation on the JVM and good API design
| given the limitations of the implementation and syntax
| design constraints), but now that Java has so-called
| virtual threads, you don't "need" Kotlin for
| convenient(-ish), simple(-ish), scalable, structured
| concurrency like you used to, either.
|
| One could rightly debate over whether Kotlin's coroutines
| design and APIs are better than Java's virtual threads for
| writing asynchronous code. But, at the core, the story used
| to be that Kotlin had coroutines and lightweight structured
| concurrency "built-in" (with a blessed first-party helper
| library for the actual concurrency part) and Java did not
| have anything that accomplished the same goals. Now it
| does.
| gavinray wrote:
| Vsevolod Tolstopyatov (https://github.com/qwwdfsad) is the
| other brain behind Coroutines, Concurrency, and Atomics in
| Kotlin, and he's still very much active.
| esafak wrote:
| I do, because the Java ecosystem (which includes its
| programmers) is always going to have one foot in Java 8; it's
| the prototypical enterprise language.
| ragnese wrote:
| That's a fair point. You don't _have_ to write Java with
| giant graphs of objects-in-objects-in-objects and heavy
| mixing of (often mutable) data and logic in the same
| classes, but it 's hard to deny that the culture,
| conventions, and idioms in the Java ecosystem can be quite
| different from the culture, conventions, and idioms in
| Kotlin.
|
| On the other hand, when I see Kotlin code that's not
| written by JetBrains (especially on the backend), it often
| _does_ just look like Java code with cleaner syntax...
| vips7L wrote:
| >but at this point, the only big technical features that
| still put Kotlin over Java for me is the handling of nulls by
| the type system
|
| Soon (tm): https://openjdk.org/jeps/8303099
|
| The one feature that keeps me in Java, albeit not popular, is
| checked exceptions. I far prefer checked errors over checked
| nulls if I have to make a choice.
| kevinherron wrote:
| We use it for (non-Spring) backend development. It's lovely and
| always my first choice over Java.
|
| I like to avoid mixing Java/Kotlin within the same module when
| I can, but it still works, and parts of our codebase are mixed
| this way. (by module I mean e.g. the same Maven or Gradle
| module, i.e. try to avoid a situation where you have a
| `src/main/java` and `src/main/kotlin` next to each other)
| selimco wrote:
| You can put kotlin code in src/main/java
| LennyWhiteJr wrote:
| Almost my entire org uses it for backend server development at
| Amazon. There is very strong support for Kotlin support within
| the Amazon dev community.
| esafak wrote:
| I've never heard of language lock in. The source is here:
| https://github.com/JetBrains/kotlin
|
| Come in; the water is fine.
| smokel wrote:
| There are many systems written in Cobol, Delphi, C++, that
| would really benefit from not being written in those
| languages.
|
| There are serious headaches to be had when you have to
| maintain software for ten years and up.
|
| Porting systems to another language is often terribly
| expensive.
| jasonmarks_ wrote:
| I do not have an opinion on if Kotlin is great as a backend for
| every project. Kotlin does excel as a pick for projects where
| you are also compiling for native mobile front ends.
|
| Write a Kotlin multiplatform client side business logic module
| in tandem with your Kotlin backend. The multiplatform module
| compiles for both your Android and Apple environments and for
| extra flexibility you are able to quickly port code from the
| client business logic module to the backend (or vice versa).
| mx_03 wrote:
| We use it for backend. F500 company.
|
| There is almost no locking with Kotlin. You can stop writting
| Kotlin code any time and start writting Java code.
|
| However I think it's not possible to call coroutine code from
| Java.
| cogman10 wrote:
| Exactly why we use it. Our java devs have been able to pickup
| and start writing kotlin. None of them have regretted it that
| I've seen.
|
| It's extremely close to Java in terms of most concepts. That
| makes it an easy language to switch into and out of. It's
| java with a nicer syntax and more sugar.
| sannysanoff wrote:
| when you do LLM-assisted coding in Kotlin, it burns 2-3 times
| less tokens than Java!
|
| PROFIT!
| corytheboyd wrote:
| Been in a weird position where I had to learn Java real fast,
| then learn Kotlin real fast to replace it. I find Java to be so
| incredibly unproductive compared to Kotlin, for all the reasons
| a sibling comment listed. I mean come on, default argument
| values and named input parameters are table stakes-- it kills
| off the billion overloads, billion positional arguments, annd
| builder pattern nonsense all at once. Kotlin immutability by
| default is fantastic, I am 1000% behind default immutable data
| structures. The stupid, awful nullability madness disappears
| (mostly, need to train people to never use ! and !!). I
| appreciate Java, it got us to Kotlin, but Kotlin is ACTUALLY
| FUN to use, and expresses all ideas I have cleanly. Less,
| cleaner code just makes things easier to maintain, full stop.
| RamblingCTO wrote:
| We did and it's awesome. Normal SaaS startup-sized codebase.
| Migrated from java maybe 4 years back. Was so perfect that you
| could migrate file by file. Later on we split up the codebase
| via gradle modules. Very very happy with that! Java will never
| get where kotlin is. It's a perpetual catch up game.
| jamesgasek wrote:
| It is used extensively at Amazon
| rileymichael wrote:
| i've been writing kotlin since 1.0 (2016) and my past few jobs
| have been at startups using kotlin entirely on the backend.
| it's really enjoyable, there isn't another language with as
| good of a development experience due to Jetbrains controlling
| both sides.
|
| coroutines are the biggest downside imo. they're great for
| android and other environments, but now that we've got loom on
| the jvm they're needlessly complex (accidental blocking calls,
| coloring, headaches with libraries that use thread locals,
| reentrant lock, etc.)
| robch wrote:
| I have been using detekt for work and personal projects for years
| now. Writing advanced lint rules that take advantage type
| resolution makes it the best linter for Kotlin. I just hope they
| get k2 support soon.
| jascha_eng wrote:
| The worst thing about kotlin is the intellij lock in. VSCode
| support is exceptionally poor and that makes using modern AI
| tooling (like cursor) a pain.
| PaulHoule wrote:
| Java has also improved greatly since JDK 7 so the need for JDK
| languages that are Java, but just a little better, is less than
| it was.
| smith7018 wrote:
| Kotlin is much better than "Java, but just a little better."
| c03 wrote:
| Kotlin has everything. A language isn't better just because
| it has more.
|
| Its great for DSLs though.
| PaulHoule wrote:
| Java is pretty good for DSLs too.
| ohdeargodno wrote:
| Language.Builder().getOh().getYes().getJava().getIsSoNice
| ().setFor(() -> { return "DSLs";});
|
| No trailing lambdas, no infix operators, no @DslMarkers,
| no top level functions, and an infinite list of examples
| of Java verbosity making even the smallest thing look
| like an ancient greek epic. Java is utterly terrible for
| DSLs.
| vips7L wrote:
| Language { oh { yes {
| Java { isSoNice }
| } }
|
| You can contrive awfulness in any language.
| PaulHoule wrote:
| The awfulness of one style of Java DSL is the awfulness
| of Lisp, that is
| building(of(S("expressions"),everything())
| vips7L wrote:
| Not going to lie, my brain doesn't really comprehend
| lisp. So the joke (or point?) is way over my head.
| BrandonSmith wrote:
| Kotlin ecosystem extends way beyond the Java runtime. I have
| apps developed in Kotlin running in browsers and iOS, in
| addition to Android.
| kle wrote:
| I agree, but I can strongly recommend Claude Code with the
| Intellij plugin. Actually works pretty great for kotlin!
|
| And, JetBrains finally started working on an open language
| server. It's not perfect but it makes it bearable to at least
| edit Kotlin in Cursor/VS Code.
|
| https://plugins.jetbrains.com/plugin/27310-claude-code-beta-
| https://github.com/Kotlin/kotlin-lsp
| llm_nerd wrote:
| When did you last use IntelliJ? It has excellent AI tooling.
| jlengrand wrote:
| Won't be true for long any more since they just officially
| announced they'll be releasing the language server.
| cardanome wrote:
| I just have Cursor open in another window for the agent mode
| while I do my editing with intellij (or other jetbrains
| products).
|
| I would never voluntary do any editing in VS Code or forks of
| it. It is just so slugish on large files. Plus there is always
| subtle things that annoy me, I can't even describe it, it just
| feels off. I hope Zed takes off as it is a bit more tolerable
| though still not there yet.
| LennyWhiteJr wrote:
| I love Detekt! It's particularly good for enforcing project
| conventions that can't be covered with standard linters. With
| access to the full AST, you can basically enforce any kind of
| rule you want with custom analyzers. And LLMs take out 90% of the
| effort for creating new analyzers.
| esafak wrote:
| Do you use it in CI? Do you have a template or something to
| share?
| LennyWhiteJr wrote:
| Yeah, it's included as one of the gradle scripts which fails
| the build in CI if the rules don't pass.
|
| No template, as it's specific to my team's project, but one
| example is that we enforce that classes within our core
| domain don't import types from outside the project. You could
| accomplish this with separate projects, but that comes with
| its own complexities. This rule basically says "any domain
| type shall not import a non-domain type".
| rileymichael wrote:
| there's an official template here:
| https://github.com/detekt/detekt-custom-rule-
| template/tree/m...
|
| and here's the diff for a 'real world' rule I implemented:
| https://github.com/michaelbull/kotlin-
| result/compare/master....
___________________________________________________________________
(page generated 2025-07-24 23:01 UTC)