Can I get some reasons to use Java instead of Kotlin?
reddit.com
reddit.com
With that said, I really hate how tight of a hold JetBrains has on Kotlin. While you may find an outlier here or there, (someone using Eclipse/NetBeans - heck, I've even used Visual Studio Code and Vim to hack on some stuff) 99% of the people writing Kotlin are using IntelliJ. Kotlin is built to sell IntelliJ. (And the lock-in is pretty apparent) I don't begrudge a company the right to do this. I don't like it, but I have a choice whether or not to use the language.
Lastly, Kotlin feels unencumbered. One can program in a functional style like Scala. One can program in an OO style like Java. It feels "free". The sugar that it adds to Java makes my day to day a pleasure.
So consider me a fan of the language itself. I highly recommend building things with it. Am I optimistic about its future? That's really hard to say. Google's behind it at the moment, but Google's attention span rivals that of a fruit fly.
"Should I use Java or Kotlin on Android?" and "Should I use Java or Kotlin for <any other use of the JVM>?" are two totally different questions.
Dart enters the chat, sobbing quietly.
[1]: https://github.com/udalov/kotlin-vim
Looking at [1] I see: "Feature Request: Highlight Function Names"
This is no different in Kotlin. If you want richer features like completion, refactoring and static analysis, use an IDE.
Can you give examples? Are there licensing constraints, or is it just that they do most of the development, documentation, planning, etc internally?
I'm a Vim user for pretty much everything I do, there's no chance I'm getting a decent Kotlin experience. Java's not too bad these days. I'll admit, IntelliJ is awesome for both Java and Kotlin... I just don't want to pay for the privilege of writing enterprise Kotlin.
Their planning is half internal/half external. There are public specs that get feedback for all language upgrades. How JB choose to prioritise is up to them, of course.
Now, I will say that build times are way better on Java. A large part of this is the ability to generate ABI jars with Gradle, which you can't do with Kotlin. If anyone from Gradle or Jetbrains are reading this, please please please try and make this work, I know there's ongoing tickets but in larger projects Kotlin and Java are not even close, for this specific reason.
Now in kotlin it feels like it's just "drown it in question marks". I certainly end up with lots of nonnull signatures and far more reliable null handling than in java, but the ease almost feels wrong.
it starts that way, but over time you don't need the question marks as much because you're dealing with more and more code where the variables are guaranteed to not be null.
Some coworkers seem to type questionmarks faster than that IntelliJ "convert to kotlin" button and I hate it, but much less than I'd expect.
Question marks are basically more concise Optional chaining.
if (o instanceof SomeClass) {
o.someClassMethod();
}
if (o instanceof SomeClass) {
final var s = o;
...
}
if (o != null) {
final var s = o;
...
}
The annoying thing with Java language development is that they just don't seem interested in rounding it out with consistency/completeness.
I fairly strongly prefer Optional over nullable types. Especially how it works seamlessly with streams.
There are still issues at the API boundaries with Java or JS code, but that's about it. Outside of that, NPEs are usually in more niche places to do with initialization order and that sort of stuff.
Of course if you're inventing a totally new language you probably want to just avoid the possibility of null outright.
I loved using CoffeeScript at the time because JavaScript felt like an incredibly stagnant language. CoffeeScript brought so many usability improvements. But that in turn inspired ES6 JavaScript and now no-one uses CoffeeScript.
I wouldn't be surprised if we see something similar with Kotlin. But it has an invested and motivated corporate backer that CoffeeScript never had who are branching out in new directions like Kotlin Native, so I wouldn't count it out yet. Native offers some interesting possible futures for cross-platform development (for instance you can deploy to both Android and iOS, WASM soon I believe?). That alone might justify keeping it around.
I agree CoffeeScript usage has gone down dramatically, but has Typescript not usurped it? It doesn't seem like everyone just went back to using JS, so maybe Scala was CoffeeScript, and Kotlin is closer to Typescript?
But I see TypeScript as a different beast altogether because of its aims. CoffeeScript and Kotlin were both created to make a complicated messy language more straightforward and powerful. TypeScript aims to make JavaScript safer by introducing types. If anything it slows development down, not makes it faster (and before someone jumps on me for saying that: yes, I think it's worth the price). IMO that makes comparisons difficult.
shudders at the thought
After using TypeScript for almost 5 years now, I can not imagine a scenario where I would write JavaScript without type safety - other than a 5 minute POC to test something out.
I look forward to the day when TypeScript can be compiled to wasm binaries and it can be a language all on it's own rather than a superset/wrapper of JavaScript.
Since modern browsers and JavaScript give you a lot of functionality out of the box which people used to use libraries for, there are quite a few projects which are under that threshold.
Error messages in TypeScript are quite cryptic for a modern language. Compiling it is super slow. Type safety, well they are doing their best considering the very dynamic nature of JavaScript but now if we compare it to other languages that compile to JS like Elm, it is just not that huge of a step.
With Elm you get a guarantee of no runtime exceptions at all in productions plus the most helpful compiler ever written. Even compilation time feels much faster. Similiar for competitors like ReScript, Purescript and the like.
Of course TypeScript is the easiest to learn for established JS Developers. And I am quite grateful that the option exists but I just wish it would be better considering how much money is put into it.
Elm is an entirely different language. Typescript is little more than a typing layer on top of JavaScript.
As such, your typescript should look almost exactly like your JS would, with the only difference being that all your variables are now typed.
It doesn't really "slow development down", it just forces you to explicitly specify the data structures that exist whether you decide to acknowledge them or not. Eschewing types is just a form of technical debt that every developer has to repay as they deduce the application data structures through trial and error, often times in production.
In languages I am familiar with, types are just muscle memory. If anything, development is faster because of code completion.
In languages I am learning, yes there tends to be some fumbling with the type system. But that fades with experience.
Given a great type system and editor/IDE types can even be used to derive implementations.
The exception I can think of is enum types. These always result in some amount of generated code.
TypeScript can also apply some other transformations to your code during compilation, but as far as I know that's just so you can use newer JavaScript language features and target older JavaScript runtimes.
Which provides typing and works in the lua vm.
Is that something you were looking for ?
If you stick to two rules, you're out of misery
- never store null in a field, a collection, etc
- checks all parameters that are not nullable (most of them) with Objects.requireNonNull
(it's what Kotlin does automatically BTW)I would go as far as say 95% of them are. So now your code is filled with effectively pointless checks (you run into an error at runtime instead of compile time) if your language had non nullable variables in the first place.
There's a very good reason why low-latency and high performance computing crowd don't use inventions like Scala or Kotlin but they do use Java.
Yes, they all run on the same JVM but most of the nice features and syntactic sugar comes at a price of generating huge amounts of garbage. It's possible to achieve zero- or low-allocating code with almost fully idiomatic Java but not so much with the alternatives.
https://stackoverflow.blog/2021/02/22/choosing-java-instead-...
EDIT: I'm getting downvotes, so to be quite clear my questions are genuine; I'm very curious about how JVM languages work, and my intent is not to disparage JVM or its languages! :)
You still have access to "raw" JVM arrays, mutability, etc.
The difference is that you can choose to just restrict the 'ugly' code to your performance bottlenecks and code everything else at a higher level. This gets even better in Scala 3 with opaque types, etc.
It has nothing to do with how easy it is to achieve the performance if you really want to. Well, OK, I might grant that there are a couple of very minor things that kind of work against you in e.g. Scala, namely lack of a native 'for-which-is-a-thinly-veiled-while-loop' and such, but that can be worked around with e.g. spire's cfor or just using while loops.
Compared to the amount of effort to get anything-on-JVM working well in a low-latency environment in the first place, these obstacles are all trivial.
I like Kotlin and would recommend it, but to answer the question:
- slower complication time
- more complicated language: this means code that’s harder to optimize, or that can be overly complex when written by junior developers or language aficionados. (This doesn’t have to happen, but it does in my experience)
- lack of libraries means you will use Java code, and Java and Kotlin code mixing is really well done, but will still expose you to many quirks. This will mean developers will need to know Java on top of Kotlin.
- less stable: things are changing faster in Kotlin, and you’re more likely to see breaking changes if you have a big codebase when the next version comes out.
- performance: in the same way C++ can be as fast as C code - Kotlin can be as safe as Java. In practice though, you will use more abstractions and you may want critical components to remain in Java. From my experience though, runtime performance is not an issue in practice for all examples I’ve seen tested.
Kotlin/Java with a framework like Spring is the sweet spot for web/api development. Fast enough for most use cases, great tooling, huge ecosystem, just the right level of abstraction, easy to deploy, easy to debug, very expressive code using annotations. An API backed by an ORM can be written in 10 minutes with less than 50 lines of Kotlin.
The cons are mostly compile time and startup time. Startup time isn't very relevant for backend services. Compile times aren't great but not horrible either.
The pain point with Java as mentioned in other comments in this thread is the presence of null, which among some other things make it a little verbose. That's where Kotlin comes in. Usually my projects will use framework libraries in Java and my own code is all Kotlin. The nulls go away once code exits from Java land into Kotlin land.
I currently find myself playing around now a lot with Dart which has a lot of the same convenience and just handles it via code generation rather than dynamic magic at runtime. For me at least, it's a really nice trade off. It also for the record has fully sound null safety which is something I have only ever seen in Swift previously but is a real pleasure to work with.
I guess in the Java world you have options like Quarkus that also give you a similar kind of experience.
Disclaimer: I am one of the maintainers of one such tool, namely https://github.com/uber/NullAway
It certainly won't help with verbosity (in fact, it does the opposite to at least a small degree :)), but it can dramatically reduce the number of actual NPEs when running your Java code.
Obviously I am not saying this is a reason to not use Kotlin. But, when, e.g. based on the things mentioned elsewhere in this comment section, you are deciding to stick with Java for a particular codebase, it doesn't mean static null checking is not an orthogonal option to consider.
> The cons are mostly compile time and startup time. Startup time isn't very relevant for backend services. Compile times aren't great but not horrible either.
I'd also throw in readability into the mix. Without knowing the magic it's hard to reason about. Then even by knowing what the magic does you have to have some intuition for its arbitrary rules based on its implementation in reflection-land.
<rant> Let's take an example: Autowiring. Java is the type of language heavily that pushes programmers to use the Strategy Design Pattern. It's almost the core of the language's philosophy. However, if I want a file that globally states to always use a specific Strategy then I have to turn away from native Java to the dark magic of dependency injection frameworks (Guice, Spring). If I'm reading such code, I have to know to look for a file that maps a Bean to a specific strategy; which is not apparent anywhere on either file. It's somewhere else in XML or a vague annotation that I have to now wrap my head around. To do so, I have to understand arbitrary limitations to the dark magic like whether this Bean is matched by name, type, or qualifier. All of this can be a little overwhelming at times when you're looking at a file where every variable is a Bean. </rant>
But if you drink the cool-aid, boy does it taste good. I can't start a new project without Guice (pun intended) now-a-days.
In principle we could do the same in Java. The wiring code would contain the word `new` a lot though.
In PHP 5.2 you can't even write inline callback functions, but since then you have closures, type signatures for functions (both for class types and scalar types), namespaces, short array syntax, anonymous classes, generators, null coalesce operator, typed class properties to name a few.
And with PHP 8 new leap forward with things like named arguments, attributes (similar as Java annotations), constructor property promotion, union types, match expressions, nullsafe operator.
Other interesting new stuff is FFI (Foreign Function Interface) so you can all C code directly from PHP.
Performance is also increased a lot, most notably is the array performance much better, opcache built in, but other things like now PHP has a JIT. And GC today is way better than the old days.
PHP community has also changed, lots of good frameworks and libraries and you can use composer (like npm but better IMHO) to use with your project.
You can of course write PHP as the in PHP 5.2 days if you want because new features are optional, so you can take your old code and (almost) run it in PHP 8, but if you adopt modern PHP with strict typing is as good long term as Java, especially if use something like Jetbrains PhpStorm IDE or some of the many static analyzers (psalm, phpstan, phan) that exist today.
https://www.php.net/manual/en/migration56.new-features.php
https://www.php.net/manual/en/migration70.new-features.php
https://www.php.net/manual/en/migration71.new-features.php
https://www.php.net/manual/en/migration72.new-features.php
https://www.php.net/manual/en/migration73.new-features.php
That being said, my mind still hasn't adjusted at all to thinking about names before thinking about types, guess that's very much to expect after a decade of naming 95% of variables "class name, but lowercase".
(PS: I actually maintain the fantasy that there might be room for a language that abandoned the entire idea of local variable names and just referred to e.g. parameters as "the {type} parameter", pushing typical cases of more than one instance of a certain type sharing a scope into the type system)
First, there is really not that much reason to use Kotlin for the type of applications that would normally be written in Java.
When I look at Kotlin code in my org most of it looks like Java with some very slight, cosmetic differences. The reality is overwhelming majority of people writing Kotlin is Java developers and overwhelming majority of those continues what they were doing in Java but now in Kotlin.
It is more difficult to find people with experience to work on Kotlin.
Kotlin is slower than Java, but for most applications it shouldn't really matter (in that if you make it your focus you are probably wasting time while you could be doing something more worthwhile).
To develop in Kotlin well, you should also know Java. So now you really need to know two languages.
Let's face it, people who go to work with Java projects are not exactly cream of the crop (and I am saying this after working with Java for the past 20 years). Java has some excellent frameworks (ie. Spring), documentation and guidance (ie. stack*) on how to structure your application that makes it much easier for a junior developer to start writing new service and for everybody to understand existing code (because it all looks alike). As a tech lead this lets me focus on other stuff rather than telling developers how to write a controller, how to read configuration file, how to structure your database layer, etc.
And bunch other reasons...
> Let's face it, people who go to work with Java projects are not exactly cream of the crop
is a bit of a weird take.
If you're saying that most people working in software engineering aren't "exactly cream of the crop" to begin with, then you probably have a point (I'm a java dev as well, by the way), but I don't see how the programming language changes the equation.
True in 2004, probably still true to some extent in 2021.
By the same logic, Python would now also be in the 'uncool' group, since everyone and their mother uses it.
> if a company chooses to write its software in a comparatively esoteric language, they'll be able to hire better programmers, because they'll attract only those who cared enough to learn it.
During whole my career, I have found that there are always new things to learn. Learning is not limited to picking new language. And if you work in more popular language, no matter which one, there are always new framerworks, libraries, security issues, performance optimizations, approaches, tools to integrate with, algorithms, you name it.
What he is saying there is either that picking new language matters more then the above. I don't find that convincing.
> So a language that makes source code ugly is maddening to an exacting programmer, as clay full of lumps would be to a sculptor.
Is a programmer with aesthetic preference against java really inherently superior? I find that whole section low on arguments and high on colorful emotions appealing metaphors.
* Most software is done in teams.
* If the code is good, it will be in use for a long time.
* Hence if you want to work on software that matters, you will often work with a language that is not your one true love.
Me and my extremely brilliant collegues in my current project write Java, because that's the language the team has chosen. The language, when it's one of the major ones, has no significance.
Here, fixed it for you: Let's face it, people who go to work with any software projects are not exactly cream of the crop.
This is natural. You have bad performers, meh performers (a majority) and top performers (a minority) and it goes like this in almost every area of human's productive activity.
Developers who barely can write loops don't go write games in C++. They are much more likely to go write corporate backends in Java because corporations are notoriously very bad at sorting who is good and who is bringing negative value.
You can apply that saying to any language or project. The fact you are biased against Java is a bit disturbing. I know it is cool to be a Java hater but why?
Your comment reminds me of this:
It's unsurprising that stronger students prefer OCaml, because it's objectively the more interesting (or at least the more intellectually stimulating) language.
When we're talking about programming languages as engineering tools, a whole lot of ancillary issues must be taken into account. Is the language performant enough? Is the tooling good enough? Does it have good library support? What about C integration? Is it easy do build and deploy?
Java vs. OCaml is precisely a great example of this conundrum: OCaml is objectively the better language by a mile, Java has objectively better support by a mile.
I don't know if OCaml is better than Java because I don't use OCaml.
But in general, the better you are at development the greater choice you have. And also better developers on average prefer more powerful tools because for them the steep learning curve is not prohibitive and because they can recognize value of using more powerful tool.
Weaker developers are basically happy they can program at all and most weak developers to settle on the first programming language they learn.
Want to filter out poor developers? Don't hire anybody who only knows single programming language well.
Not because knowing two languages makes you better but because you put effort in learning another language which means you had the curiosity, perseverance and ability to do it.
Learning a programming language when you are good developer is no issue -- I do it in passing just to solve some particular problem and move on. If you are poor developer learning a language might be major effort and accomplishment you may not want to pay for again.
I personally know of no good developer who only knows single language.
Then I matured (both as person and as programmer) and now I don't hold the same views.
The end effect being that if you work for a company and you don't have a huge hiring budget you don't go looking for developers in esoteric languages.
Because then availability of developer is much more important than showing they can pass steep learning curve.
On the other hand developers who can't pass steep learning curve will gravitate to a language without one, where they can be hired more easily.
Does steepness of learning curve mean a language is better or worse? Not necessarily.
Does a person getting into Java development mean the person is bad developer? Of course not.
The salaries breakdowns I have seen did not worked like this at all. Esoteric languages paid less. I think it was mostly because those companies were in unstable businesses and because people who like those languages accept pay cuts more often. The salaries for boring languages were higher.
And second, the assumption that only difficult thing that can possibly attract people is difficult/esoteric language is odd. If you are in that situation, then you are in fundamentally easy situation. In fact, forums are full of developers for whom frameworks used in jave world are impenetrably complicated to learn. I can't square that with supposed superior willingness to learn. (I can easily square not liking these.)
That's because salary is only one part of the cost. You are looking as if it was the only cost, which is not true.
Finding people for the project costs. Finding people with exotic abilities costs a lot and takes a lot of time which may complicate your plans or require you to have extra staff just in case somebody leaves.
It may pay less because in some specific niches people will work for less just to be able to do what they like to do. If I had ability to join a serious Common Lisp project I might do the same.
I've never used Kotlin, but this is exactly my experience with Groovy. Ten years ago, my department had some Groovy enthusiasts that pushed it heavily, but now we have a bunch of Groovy systems where the majority of the development staff are NOT Groovy enthusiasts, and many are either new hires or low-cost offshore devs with only Java backgrounds. Now all Groovy provides us is the opportunity to experience new classes of bugs that we probably wouldn't see if they systems were written in Java [1].
Generally, I think long lived systems should be written in some kind of "lowest common denominator" language. That's likely to be more easily maintained long in the future. They especially should NOT be written in some other language where someone can get by by pretending it's the LCD language, since that an invitation for bugs wherever the other language violates LCD language assumptions.
[1] My favorite is one where a previous entry-level guy wrote a loop, declared the control variable as a STRING, then used ++ to increment it. Instead of failing fast, Groovy "made sense" of this by interpreting that last char of the string as a char, incrementing that, then coercing the whole thing back to an int for the comparison. This worked, UNTIL the control variable had to go past 9, after which the increment resulted in a ':' and the coercion back to an int started failing in prod.
(Real advances come through safely bundled abstractions, not typing speed)
I'll be honest. I barely write any sort of loop in groovy.
I just checked. One of my projects had 1 for loop and zero while loops. Everything else was done with findAll, collect, each etc.
In general, applications that just process collections of items and running some logic on them can most of the time get away without using for loops, as is probably your case.
- coroutines in Kotlin are a crappy solution compared to the future Java one, which is to keep using the Thread API and switch to an async model underneath, without the developer having to care about it at all
- multi-line Strings aren't fucked like in Kotlin (leading-whitespace behaviour)
- superior tooling: IntelliJ works much faster, refactorings are more reliable in Java
- build times are much better
This is of course ignoring quality issues....
Plus... if Kotlin really is the new hotness and companies want it then mediocre devs can also learn it.
So any "genius early adopter" advantage that Kotlin might have is short lived.
Though speaking from personal experience, the dude/lady with 5 years of java 7 and below experiences gets stuck in their ways and doesnt write more modern Java code. I had one dude who got mad and would try to block PRs if you did lambda functions from those bodyshops.
My experience dealing with body shops. If you ask for Kotlin, the body shops will send you devs that have Kotlin on their resume, and if your lucky the body shop had them do a 10 hour online course on it. If your corporate model uses body shops you are probably gonna get better results from them with a more mature language than something newer.
As for quality, the app worked and works well, but there were some serious WTF design decisions made that have made it impossible to maintain the app, not to mention total lack of testing.
- To make library usage more idiomatic in Scala. This usually means replacing nulls with Options, exceptions with Try, and mutable or java collection data structures with immutable or scala collection data structures.
- To provide idiomatic concurrency interfaces, such converting a synchronous libraries or internal threadpools to scala.util.concurrent.Future (or scalaz.concurrent.Task)
If you're on a tight deadline for something, you might want to just stick with Java (if you know it) until you can dedicate enough time to learn Kotlin well. If you're new to both Java or Kotlin, then learn both. :)
What? Java has made use of extended precision floating point on x86 (well, x87) since 1.2. There is actually a proposal to stop doing this now that the x87 instructions are no longer the best way to do floating-point arithmetic [1].
Or is this about something else?
EDIT: Why am i asking here? I asked on the Reddit thread.
Checked exceptions are an old idea. Good to see them go away. Just use a “context manager” by passing a callable somewhere.
Java and Kotlin will gradually diverge, particularly as Java gains features which are similar to Kotlin features but implements them slightly differently. Third party library APIs will start use the new constructs and you'll be stuck with two slightly different ways of doing something very similar in your codebase.
Over the course of 10 or 20 years, that will probably happen again and again. Java evolution used to be pretty conservative but it's picked up pace and its closest non-JVM competitor C# is miles ahead in expressiveness.
For example, CoffeeScript seemed like it made sense 10 years ago. JavaScript was full of defects and CoffeeScript fixed a lot of them, at the cost of a slightly different syntax, though not so different that you couldn't debug the resulting JS. But you wouldn't want to be stuck with a CoffeeScript codebase today.
For anyone interested in looking at C#, look at https://rahulrevo.substack.com/p/language-ecosystems-net and how they have evolved differently.
I'm not familiar with this. Please elaborate how you would handle say an I/O failure while R/w a file with this approach?
Unchecked exceptions are preferred because many frameworks (APIs) are poorly designed.
The Correct Answer[tm] is to fix those libraries, not paper over their flaws.
I think kotlin definitely works for android developers but other cases need more thinking. If you're building webapps in smallish teams then maybe those work too.
Some reasons against Kotlin are-
* If you are working in a mid to large team then having all developers learn a new language is a massive cost. Learning Java is also still a requirement if you're developing in Kotlin since many open source libraries are in Java. So teams need to be aware of 2 similar but different tech stacks.
* If you are developing platform libraries then you would look at higher adoption by using Java 11 LTS as the baseline. You could add an optional kotlin library for a better experience.
* Others have pointed out how Kotlin will be an evolutionary dead end as Java catches up on features.
So, you have to code on Java 40 hrs per week year by year. All those `Foo foo = new Foo();`, every day. And you think: "If only there was a language like Java, but better, and it was interoped with Java, so you can gradually introduce it into Java codebase!".
When I switched to Kotlin, I liked some nice things, but found that in the big picture, it wasn't a huge advantage, and many of the language artifacts I didn't like.
Most importantly: Kotlin doesn't produce more succinct code. The code is not really that much shorter. If you go to Android and look at all the Java/Kotlin examples, they are almost always similar in terms of length and complexity.
Once you find yourself dealing in an entirely Java world, with Java idioms, libraries, builds, jars and reading java source ... the bit of 'impedance mismatch' to your own Kotlin code then becomes a pain.
Kotlin is no way better than having to work in 'two languages at once' with the constant switching. And of course a whole bunch of extra tools as well.
Also, Kotlin is more of a 'bunch of features' than a cleanly designed language.
So in the end if you are using K for a very specific reason (maybe js compile target), or if you can do the whole project cleanly in K (maybe Android) etc. then maybe K is the choice.
But I've switched back to Java and accepted slightly more verbose typing and never missed it. The IDE's do a lot of that work anyhow.
Even more qualitative ... I find Java easier to read and maintain for some reason.
I would almost prefer a few small changes to Java than I would a new language.
The article is talking about proper Java.
I just assumed it was about Android because I've never heard about Kotlin being used besides Android. But then I suppose I don't hear about (because I don't work with) Java much either.
I know a lot of people put a lot of importance on it, but I find the language the least interesting part of programming.
Recently someone suggested rewriting our Node.js backend in Python. I've never worked in Python (except the few times I helped my son with his homework), but I'm all for it (as soon as we have some room in our planning, which we currently don't). It's a great opportunity to learn something new. Although apparently it's because other teams in our current department (we've moved around a bit) also use Python on the backend, and they want to be able to move programmers around between projects, but then I wonder if those programmers understand the concepts behind our application, because that's the interesting part of programming.
OTOH, Kotlin is growing extremely fast. It was already top 8 in the global developer population report in Q4 2018. Will it gain enough critical weight that it will become one of the standard JVM languages and influence how features are added to Java?
https://slashdata-website-cms.s3.amazonaws.com/sample_report...
Kotlin was nicer to work in that Java, but 99% of the concepts seemed to transfer neatly between the two. Server-side web app development was somewhat limited by the lack of a mature ORM. Exposed and ktorm were the big ones; Exposed explicitly didn't support many PostgreSQL features and had no plans to do some, while ktorm is a small project seemingly maintained primarily by a single developer.
I assume you mean a mature ORM written in pure Kotlin with this statement. Because Kotlin interopts so well with Java, you can use any of the battle tested web frameworks like Spring (Boot) with ORM's like Hibernate. Most of these frameworks/libraries even have additional kotlin extensions to enhance the experience.
Kotlin + Spring + Postgres is my default stack to do a web/api project in 2021. Super productive environment with good configuration/cloud/di/orm support and a huge ecosystem of available libraries.
Most Java syntax and semantics are pretty much self explanatory for anyone who has worked with any object oriented language before. (Java programs are often rather difficult to understand though, but that's due to overengineering, not the language itself.)
I also recently read this https://billthefarmer.github.io/blog/android-kotlin/
adding to dilemma of choice.
> The obvious difference with the app is that the Java version size is 74Kb, the Kotlin version is 781Kb. Rather a lot of bloat for a small simple app.
No, it really isn't. Anything less than one MB is negligible. Importantly, since we have exactly one sample for each we don't know if that's fixed overhead or variable. Does a 5MB Java app become a 5.7MB Kotlin app? Then the overhead is fully fixed and it doesn't matter. Does a 5Mb Java app become a 50MB Kotlin app? That's a problem. The truth is probably somewhere in between.
We don't know because the author made the unfounded statement about bloat with just one data point.
Then if you want to do anything related to 3D, realtime audio or machine learning, you also need either C or C++, as those APIs are NDK only (OpenGL is actually also available to Java, but Vulkan is the official 3D API since Android 10).
Now if you want to target Android only as hobby, use whatever you feel like.
Hiring and outsourcing. Millions of Java devs.
The JVM can already optimise classes with no subclasses because it knows all the classes that are currently loaded, so it doesn't need language support.
Build times.
kotlinc still has codegen bugs. Been a while since I saw one in javac.
faster compile time