https://kotlinlang.org logo
Join Slack
Powered by
Do we have any stats on the pick up of Kotlin in t...
# spring
b
Do we have any stats on the pick up of Kotlin in the Spring world?
s
We don’t share this specific numbers but what I can say is that it is significantly more used than Groovy but Java still dominates by far. Surprisingly, Lombok is more used than Kotlin, and my goal is to change that.
👍 9
💯 2
🧌 1
b
not the most accurate things but shows trends…
n
@sdeleuze too bad you don’t share google trends is a good idea but then, it doesn’t reflect reality https://trends.google.com/trends/explore?q=kotlin%20spring,groovy%20spring,lombok%20spring
Screenshot 2019-10-19 at 08.28.33.png
e
It would be interesting to see if Kotlin still misses something that people acdtively use Lombok for. One thing I’m aware of — convenient loggers. We’re looking at what we can do there. What else?
p
@Synchronized (if don't use Kotlin coroutines)
n
@elizarov imho i think that it’s an organizational issue if you are a java shop, it’s easy to just add one more dependency whereas to use kotlin you’d need to ask many layers to approve the choice
s
Yeah what @nfrankel said
g
And even if your a Java shop, and your allowed to use Kotlin, it's easier for a new microservice to just keep using Java..
e
That’s the core question. If you are a “Java shop” why you are not a “Kotln shop” yet? Is it because of the lack of knowledge about the advantages of Kotlin or there’s something else?
What I really wish to know is breakdown of all those reasons to see what’s the main one and what we (Kotlin) can do to alleviate it.
n
unless you change the way organizations are built, i’m afraid you can do nothing on this front 😅 perhaps advocate to enterprise architects and middle-managers?
c
It is strange how people who was once fearless enough to enter the field of software end up being fearful of change. 😢
b
For me what I am afraid is that our community knowledge is being held in slack, and is not visible from a search engine…
n
@corneil you need to adopt the viewpoint of the manager it’s a simple benefit/cost evaluation
c
When that cost/benefit is done with a quarterly view it is problematic. I find that even in business that have processes that run longer than a quarter or a year
n
a lot of things are problematic in companies but it is as it is 😞
😢 1
s
@elizarov First class and mature frontend support (JS today, WebAssembly tomorrow) would allow a big push for Kotlin for middle sized webapp projects and would allow to leverage the great multiplatform support. The other thing you can do is to provide better support for other IDEs like Eclipse (even if I understand your are not super pushee on that due to IDEA)
On your side that’s the 2 main things I see to increase adoption significantly for server side usage.
c
More bindings for JS and TS framework and samples will go a long way. Multiplatform for shared models and functionality. I like how JS on MP protects me from npm.
l
success leaves clues. If Kotlin indeed has benefits like we all here believe it does then our projects are more likely be successful quicker and naturally people will imitate that. So the best thing to do writing articles etc so people know how to use the technology better. Personally I would like to see code walks through s of coroutines so I feel really confident in the code I am writing.
➕ 1
a
@elizarov I've thought about how can I sell the Kotlin to my company (big b2c enterprise, spring backend, lots of microservices) but I can't really find a way: I did not attempt for real, because I don't think it's cool to advertise the tool just because it's trending or simplifies things just for me or passionate few. I've talked with several senior developers (not hardcore Java fans, have expertise in Haskell, Go and Lisp), and some of them do not like the idea of Kotlin because it introduces unnecessary complexity to the projects. Java bugs/problems are known (for decades) and Kotlin is young, has no really strict code culture, allows too much -- so it's an additional overhead, you need to control code quality more, keep up with updates et cetera. Lombok covers most of the easy-to-sell features, and even without them projects can be managed in simple trusted manner. Teams consist of professionals with many years of experience, so selling e.g. co-routines like "you can write async code like sync" doesn't really mean much on the scale, because most of the code is reactive anyway, it's reviewed, and QE/perf testing will highlight edge cases (or you'll get feedback from Lx support). Also it's not really the core issue in the enterprise, Kotlin will not solve communication/requirement mess, which eats team time the most. I think we might try Kotlin for some projects or some non-critical parts, but I'm not really sure about company-wide acceptance. Also you can't bring some features (e.g channels, actors) just because you want, it must be accepted by solution architect and management. Also you need to train people how to use new stuff (a lot of people). I've tried to google arguments, but there is nothing besides some beginner-level stuff like already-in-lombok features and "look how we can simplify 8 java lines to 3 kotlin lines". I can't see killer features for the company's projects. I'll be grateful if you can give some insight. PS: I'm thinking about building my argument with nullable types and how it's applicable for e.g. model packages, highlight some probable bugs and missed nullability checks. From my point of view it's simple enough for any Java developer (no complex kotlin features), free nullable annotations interop with Java (IDE support) and SpotBugs integration.
c
I think the big wins are in safety via immutability and nullability and conciseness via type inference and improved type system.
b
SonarKotlin has 40 rules SonarJava has 540+ (whatever that means)
11 Views
Open in Slack
PreviousNext
Powered by