3 ms·
Better is subjective. Java is a great language, has a mature and stable codebase, it runs at near-Cpp speed, has built-in SNMP-like monitoring, and the develope
by exabrial 3y ago
Better is subjective. Java is a great language, has a mature and stable codebase, it runs at near-Cpp speed, has built-in SNMP-like monitoring, and the developers are super careful about not breaking backwards compatibility. That's all about there is to say about it. Kotlin is also a good language for many of the same reasons, mainly because it is run on the JVM. One really isn't better, they're just different. Use the tool you know how to use, and master it.
The only category I would say is objectively "better" is Java (and other JVM languages like Kotlin) has the best IDEs out of _any_ language. There is nothing on-par for Python, Ruby, C/Cpp, etc as far as autocompletion, type inference, automated refactoring, partial recompiles, hot code swapping, unit test integration, Tomcat or server integration, code formatting, etc. Java is great because of it's IDEs. If we were writing Java in notepad.exe it'd be a pretty clunky experience, but nobody serious does that.
- randoglando 3y ago> The only category I would say is objectively "better" is Java has the best IDEs out of _any_ language. Kotlin was made by the people behind IntelliJ. I'm not sure I understand your point.
- exabrial 3y agosorry, I should have included Kotlin in that part of my comment. IntelliJ Kotlin is quite incredible. Every time I've needed to use it, my expectations have been met. Makes switching to vscode feeling going from an framing nailer to beating in rusty iron nails with a rock.
- iraqmtpizza 3y agoextension functions can be scattered across any number of files and the import statements do not tell you where they are declared. kotlin was specifically designed to drive sales of IntelliJ
- wiseowise 3y agoAnd it’s slow as molasses without feature parity. One feature that comes to mind is rearrange methods. I haven’t used Java in years so someone who actually uses both can find more cases where Kotlin support is worse than Java’s.
- coldtea 3y agoThat's a single IDE from a single vendor though.
- anotherevan 3y agoWe were looking at starting a new Spring Boot project several years ago and considered Kotlin over Java - but the single decent IDE made me reluctant and we went with the familiar Java instead.
- jiggawatts 3y agoWhile I miss IntelliJ IDEA, I’ve found Visual Studio has mostly caught up for C# refactoring. If that’s not enough for your use-case, there’s always the Rider plug-in.
- nikanj 3y agoThe developers absolutely wrecked backwards compatibility by shuffling classes between namespaces just a few years ago. I guess the new names are somehow better, but so many things broke because things needed renaming For Reasons
- CraigJPerry 3y agoYeah the backwards compatibility point is overplayed i think. It is mostly true but The java world paused at 8 for a hair too long and when it came time to move to 11, workarounds were needed for things like JavaEE and JavaFX being removed.
- ebiester 3y agoAFAIK, most people using Kotlin are somehow tied to some variant of Java 8, such as Android. Kotlin is very useful for that use case, but otherwise was a useful kick for Java but I don't know if I'd start a new project in it.
- The_Colonel 3y agoJava still has no counterparts to many important Kotlin features - number one being null safety. Java is not even trying to address it (no, JSR305, checker framework, Optional are not solutions).
- cogman10 3y ago> Java is not even trying to address it Valhalla might. There's been a lot of time put into nulls and primitives for valhalla. How that manifests seems to be up in the air still. But I would not be surprised to find non-nullable types in the future (like `int`).
- The_Colonel 3y agoWell yeah, but if that's null safety only for value objects, then it's still a very incomplete solution.
- kaba0 3y agoThe latest iteration is thinking about proper nullable/non-nullable types like String?. They want to have the user care about the semantics only (whether it makes sense to have a null value here) for any kind of object, but this same notation will also give a big performance boost to value types, as those can then be stored in memory more efficiently.
- cogman10 3y agoThere's always going to be a hole because of a legacy of not having null in the type system. Java can't simply break that. I don't think this is something that will only apply to null safety objects. Maybe initially, but I don't see there being major restrictions to extending this to other classes.