@Umbrella Corporation How so? Only thing I see going for kotlin is a whole lot of hype, which isn't going to last. Android apps developed using java have better performance and less lag. It would appear to me java is superior to kotlin in almost every way. I'm not going to go learn a new language just so it can fix pointers for me. Or is there something I'm missing about kotlin that somehow makes it better than java?
Java inline types and virtual threads will provide an insane performance boost allowing the CPU to avoid massive amounts of cache misses. When this is combined with the Vector API it'll be huge for SIMD processing.
I think it's quite important that with Kotlin, you can clearly see variable definitions, and they line up. Makes reading the code easier. The same principle applies to the internal function. In Kotlin, you can see the `fun` word, and know it's a function. With Java, there was a `boolean` and then a name. Much harder to skim the code and realize there's an internal function.
*Title:* "The end of Kotlin" *Actual content:* "A million ways why Kotlin is better. But Java is scheduled to gain some of these features over the next few years." 😂😂
I think Java just recycling Kotlin and try for some kind of "resurrection" but Kotlin is a future. Still Java don't have null-safe calls. For other things i don't really care. Less code = less mistakes. And only way to produce "safe code" is with usage of null-safe calls and i don't mean check of nullability with if...
@@hefaistoss1 I use Java and Kotlin and together, they are obviously flexing about Java doesn't have, but if you know both at the save level, you'd know why Kotlin isn't as used as Java. Thought, I'd like null safety
@@hefaistoss1 yes, you're right less code (or you could say, less complicated logic too) means less mistakes, but the truth is, I've seen a LOT of new developers who started learning kotlin from the get go, doesn't know sh*t on how the actual code works (i.e. how it work inside the system) and basically just use whatever the tutorial gave them and resulted in a less performant code (yes, it happens a lot. please DO look somewhere else around you). I don't really care about which one is the future programming language. The point is, once you get used to and understand how the internals are working together, no matter what programming language you use, you'll produce a code with less null-related errors
Optional is the way Java introduced to deal with null safety. It's not a language feature, but you can use it anyway, if you need to. It's used by popular frame works as JPA.
I really appreciate the example and comparison of destructuring. It's interesting to see some discourse over positional attributes and changes management.
Another interesting competitor, which is not mentioned, is C#. Lately I'm focusing on C# and I see those features also implemented in C#. The way that Java implements 'smart casting'is the same as in C# (and it is already available). Coincidence? I don't think so. C# 8 also implemented nullable types, just like in Kotlin. I'm pretty sure that Oracle is also watching Microsoft's endeavors.
As he showed the "smart casting" feature in Java, I immediately thought of C# too. I don't think Oracle cares that much about Kotlin as a competitor as they care about C#
I think what kotlin and java ecosystem lacks are a more standard toolchains. In go and rust world, I don't have to fight the toolings and choose which code standard that I wanted to choose. If only in kotlin I can just generate "kotlin init my-project" with all the minimal best practices, and no linter settings, just make it standard toolins. And if I could do "kotlin run" or "kotlin build", I think it will catchup to more developers.
That and the pervasiveness of IDEs really turns me off. When other communities are busy working on easily pluggable, flexible tools for people to make more complex tooling on top of, the JVM world seems to start with bad abstractions, realize the mistakes halfway, and start over from scratch with an entirely new behemoth. Kotlin, despite being probably the most fun language that I've come across, is an absolute pain to get set up with anything outside of IntelliJ, which is a shame because it seemed like a perfect replacement to Python for scripting and online problem-solving purposes.
@@joachim5080 i think he's refer to the simplicity of the tools, yes. as a java dev i know java has a lot of more mature an better tooling, is just that sometimes it's too complex, ant -> maven -> gradle they are all are different
@@biskitpagla yes i agree, but java at least has the jshell ( run java in a repl ) and you can also code in emacs/vim with an lsp plugin or vscode, kotlin doesn't even develop a proper lsp outside intellij
It's so funny to listen about some cool features and syntactic sugar which Kotlin has, and Java will recieve 3 years later, assuming that some languages (Scala for example) already have them for at least 10 years.
When scala introduces features they usually shoot themselves in the foot. When java gets a new feature one can rest assured that it’s useful, stable and understandable. So i rather wait a few years before dealing with crazy junk
Mmm, I didn't see properties, right? I mean getting rid of getters and setters in normal classes. Also, I hope Java does something to be able to use future features on previous versions, like Babel does for JavaScript. (I saw a similar tool, now I can't remember its name, but it was very beta).
A better way to put it is that generics are essential for some applications and less for others. It's optional for Go's userbase mainly because developers who inherently need them to do anything useful have self-selected away from Go.
There currently seems to be an obsession with new 'language features'. It doesn't matter how gimmicky or silly they are, they will be accepted without question into the language. There used to be sensible debate about whether or not new features should be added, and quite often they were rejected. But now the flood gates have been opened and any ridiculous crap is welcomed into the language as soon as the devs can add it.
I agree with that sentiment in part, but the opposite is also true. The requirements for what languages should accomplish change along the years, and it was only very recently that developer experience took the front seat in language development. Compared with more modern languages, Java is super verbose and yet harder to read. Learning from the better parts of other languages is cool, and Java definitely needs some modernizing. Hopefully it'll not be redundant features just for the sake of it, but instead features that make the code easier to read and more pleasurable to write.
simioni I also agree with you in part. Languages have to change and adapt to new requirements and developers. And some of the changes that are happening are good.
There's a place for Kotlin, and then there's a place for Go. Both are valid approaches to pl design with differing strengths and weaknesses. That said, one thing that I don't like about Kotlin is just how relatively unopinionated the language is. There're other "batteries-included" languages out there like Python and even Haskell but it's not as common for people to develop idioglossias in them as it is in Kotlin. For every single problem Kotlin seems to offer three more solutions, all of which happen to be equally promoted by the language's design.
Why is the java code missing the pesky semicolons that java requires but kotlin does not? Did I miss a massive upgrade to java that eliminates the need for semicolons everywhere?
In all seriousness with the velocity of Java releases do you think something similar to what happened with CoffeeScript will happen and Kotlin will be absorbed by Java 20. What I found very interesting is some of the Kotlin bytecode is calling Java bytecode. Are there examples of what kotlin does that isn't a terse transpilation on top of Java?
Strictly speaking, wouldn't it be JVM bytecode. All languages that run on the JVM have to transpile to the same bytecode in order to run on the JVM. It's just changes to the JVM bytecode are driven by changes/enhancements to the Java language only. Other languages have to create workarounds for features that aren't natively supported in the bytecode. For example, prior to JDK8, bytecode didn't support methods on interfaces. So Kotlin would work around it with classes and other manipulation. In fact, if you're on JDK8+ and want to use default methods on interfaces in your bytecode, you have to tell the Kotlin Compiler explicitly with @JvmDefault.
@mike w you gave the most perfect example! I actually went through this in most of my lectures. And that's why I'm happy I've had my grounding in hard core Java cause once I work from that Interface all the way up to functional interfaces & lambdas.. Its then that the students get everything.. Even the Kotlin guys! ;-) Great answer!
The only thing that gonna make kotlin alive is Native..other than that, all the kotlin feature will be implemented in java..Thx to kotlin because make java a better language
"The only thing that gonna make kotlin alive is Native..other than that, all the kotlin feature will be implemented in java..Thx to kotlin because make java a better language" Not true. Google is a huge supporter of the Kotlin language. Even if Java was able to become even better than Kotlin in the future, Google would still prefer Kotlin because the last thing Google wants is another lawsuit with Oracle.
I do not see a boilerplate language like java could potentially adapt all kotlin features.By the time kotlin more advance,java might only adapt val features in kotlin lmao.As you can see,java code is really taking much boilerplate code than kotlin to do the same thing.And,with the presence of jetpack compose,kotlin features language which became more advance and google support,i do not see java could even stand a chances again flutter,let alone kotlin.so yeah
@@TheRealFFS java isn't something all about oracle. Kotlin is still dependant on some other language, mostly java. I got nothing against kotlin itself. But it feels like too much when they mock/asperse java . It's like asking to demolish the ground floor once first floor is completed.
@@harshar6897 What are you talking about? I have no idea what you're trying to say, or what your reply has to do with your original post. I don't think they're mocking anything. It's competition, and that's good. Java is trying to keep up as best as it can, but some of its primary faults still remain, mainly 'null' and its verbosity. The best thing it has going for it is its large ecosystem and user base.
That's true, just like how the same is true for Java because of the billions of dollars that went into its marketing and the absolutely horrendous OS-specific APIs of that time.
Apart from nullability he forgot to mention operator overloading. Massive miss by Java which makes any kind of avanced math in it feel like you're writing COBOL
Second on my list would probably be extension functions! There's a lot of other things which I think are nice-to-haves, but nullability feels like the really foundational omission from Java's future.
agreed. I know everyone was hyped up about nullability stuff in kotlin when it got popular and stuff but when I first discovered kotlin, the thing that amazed me the most was extension functions. I guess it looked too good to be true to an Android developer like me who is mostly stuck with Java 7/8 :')
I guess he has not included operator over-loading because it can be added in future, unlike nullability which cannot be removed without breaking existing code.
@@nimaparsa5960 Yeah, the "official" preview plugin uses Kotlin Language Server (like the Vim one): marketplace.visualstudio.com/items?itemName=fwcd.kotlin
During the whole video I was thinking: but Java won't have nullability! And yes, in the end Jake said it. Just because of nullability Kotlin will remain much more convenient and efficient, than Java
Not in the same degree. You don't have idiomatic non-nullable object types, you can still null any object in Java, no matter if it's wrapped around a Optional or not
@Niklaus Bucher your point is spot on. Optional actually makes things worse since Java still cannot represent things that are non-null. Kotlin: - String means "not null" - String? means "maybe null" Java: - String means "maybe null" - Optional means "the optional can be null or the string can be null"
These few features are going to kill off kotlin? I doubt it I can code Kotlin way faster than Java. The amount of time I save typing kotlin compared to Java is 10 fold
Under Oracle, Java as a language is still kicking, but as platform is almost dead. JCP is dead. Oracle was the worst possible successor for Sun Microsystems. Welcome, Kotlin! I loved Java, but we are not engaged anymore.
you made me lough althogh if any thing in java is loosing populerity is the java language not the java platform jvm because it runs dozens of languages and java kotlin among others is just one of these languages and java in the enterprise developement is one of the best if it was not the best
@@mosup5007 dude, English isn't my native language to have any authority about, but I think you need some improvement here. Keep studying. When I said Java as a platform I was referring its stack, not the JVM itself. Even so, you need to remember that JVM isn't the only virtual machine based technology anymore, and even Java language doesn't compile just to it. On Android, for instance, Java never compiled to JVM. The old Dalvik machine had success where the JVM ever failed: mobile devices. And the new ART keep doing it. Is still unpractical run JVM even on modern mobile devices (with a power of old PCs and even not so old) because is so heavy and slow. About Kotlin, the language compile/run against really a LOT of environments. Even JavaScript on a web browser! Any VM supporting dynamic invoking can run it. JVM included. About Java as language, it not aged nicely. Again is probably Oracle's fault by the lack of JCP involvement, but the sintax became really messy across time. So many syntactic sugar, the lambda implementation isn't exactly the best possible, so many things solved with preprocessors (annotations) instead language specs, etc. Project jigsaw also destroyed the platform backward compatibility (a thing that we was proud in the past) In old times, if you had a self contained executable jar file you knew that you can run it anywhere against any JDK or JRE implementation. Now, so many old files doesn't run anymore by lack platform libraries, *even when you put the libraries in the classpath* because the classloader isn't accepted to that libraries. Is a damn pain in the neck. Old Java just worked. Write Once, compile once, Run Anywhere. Isn't like that anymore. My final advice to you: technology change across time, like people. Don't be like a cheerleader to any kind of tech.
@@CopernicoTube I worked for the biggest cloud companies you can name and I can say that at least 80% of codes is written in Java and still used in new projects.
@@voronoit4091 Yeah because transition is the most pain in the butt to do it.But luckily,the presence of jetpack compose,which only available on kotlin,with so much less codes and huge feature served in it,would likely a game changer in mobile development
Poeple just get paid to post 'The end of X'. Unfortunately I will not continue to watch the video. Not because I'm a kotlin supporter, but because I was a victim of those marketings.
Please don’t call these things destructors. Even “deconstructor” isn’t a very good name, but it’s much better than destructor, since nothing is being destroyed. Also that name is already used by C++ for actual object destruction(freeing memory). In python, the concept under discussion here is called “tuple unpacking.” I’d start with that.
I disagree. Deconstructor is a perfectly good term since we reverse the constructor. Especially since we already have a tupel class and this code works with tupel in Kotlin but not only.
@@911SuperGTIn my opinion it would be better to become a datatype and has a wrapper class(I don't know why it shouldn't... I'll be thankful if someone explain it)
Next time I get an NPE in production, I'll be sure to call you to ask why nullability is solved. As long as you can compile code which gives you NPEs, I wouldn't consider nullability solved. I'm all on the java train for most things. It's a strong language that can do it all -- including crash your system because you forgot to check for null in a weird case which is now the normal case.
@@scottmacwatters Never use null. Use Optional instead. Using null in Java today is like using !! at Kotlin. In fact looking at kotlinlang.org/docs/reference/null-safety.html, I see there plenty holes at Kotlin null safety. Please don't get me wrong I agree that null safety at Kotlin as elegant, but is is far away from being killer feature.
Until the JVM has value types (and Optional becomes a value type) using Optional has extra overhead with the extra object reference lookup vs Kotlin null checking which is compile time. You can use Optional with Kotlin if that is your thing but Optional isn't "free" wrt runtime cost.
No they did not. Java still lacks the ability to say that a reference can not be null. And the official documentation say that optional should only be used as a return type, not as an argument type. The main reason for this is that if a function takes an optional, the code can still call it with null. Also the optional syntax in java is insanely verbose. Just try to compare the code needed to call a method on a reference if it's not null. And the Kotlin compiler is so smart, that if you have tested if a reference is not null, the compiler know this so later in the code it will be ok to use the reference as if the type was "can't be null". Optional in java was created to only solve the problem of how to signal that an return value was optional(Could be null). it does solve this specific problem, but that is only a very small part of the null problem. In kotlin you can use the type system, to do a static verification that this program can newer throw a null pointer exception*. Doing that in java is impossible. This is one of the reasons that we are currently looking at moving from Java to Kotlin(On a jvm) for our furture server side code. That way we can still use all the great java libraries.
I agree too.. But tell that to a Kotlin fan boy and see the nonsense you get back! Hahahaaaaa Yes Kotlin might have some cooler features but in no way it has the depth of Java.. No way. No chance. Java will always be the beast. And as time goes on.. It'll just get more & more refined. Love it or hate it.. It delivers. See my comment on this same video..(by the way already attacked by Kotlin fan boys!!!)
Guys, you just haven't used Kotlin deeply. It is for 100% compatible with Java. 1. Q: what you use instead of coroutines? 2.Ok, let's imagine, you invokeMethod1, then wait for result of some Callback{onSuccess(sResult); onFailure{fResult}}, then invokeMethod2(sResult), and process Exceptions -> please provide here your implementation in Java
Why is Kotlin's ? dangerous? It clearly specifies, that you must expect to receive null value. From that point, you either: - a, handle null case safely - b, don't care about mountains of warnings THEN fail I don't see what is dangerous about this, especially that in Java you kinda always should expect null, or make assumptions about being nonnull and make sure your assumptions are met. You can use annotations for that, but hell it is so verbose to annotate everything instead of just one ? character extending the type system with nullability, which IS the proper way to integrate null into the system - as C# noticed it too and is now applying the ? nullable type thing to reference types too. It is dangerous not to know whether some method is expecting null or not and whether you receive null or not. Throwing an exception upon receiving null is digusting imo, it should be part of specification (some write it in JavaDoc, but that is not compile checked), so part of the type system. Optional is a completely different tool. You cannot use Optional for every parameter where you expect a value or null, that would look ridiculous. I loved and use Java every day at work, but Kotlin does nullability a hell lot better. Java IS null-dangerous, Kotlin is not. In Kotlin null is not danger, it is a useful tool. In Java you better use Null Object Pattern for safety, which is a half solution, in Kotlin there is no need to, because null policy must be specified everywhere (via ?'s).
@@scriber36 To my mind, null-safety is really not so great+explicit in Kotlin, just because of !! operator is required some time. Yet, there are: sealed classes/coroutines/StringUtils/semicolons )))
@@artemurubkov3588 Kotlin states never use the !! operator - if you use it you are a bad Kotlin programmer in most cases - that is written in its specification. You are never forced to use it, since you can do the same safely via a null-check or use the ?. operator if null result is acceptable.
as much as String interpolation looks cool, it can (and WILL) break existing code if it gets added to java later on. imagine having a string that is like String s = "test $something"; then you updated your java version to which they added string interpolation and getting a compiler error "Variable 'something' cannot be resolved "
Java (rabbit) will never catch Kotlin (turtle). Because Kotlin introduced improvements to Java, right? When Java catch up with those improvements, Kotlin will be more advanced in the meantime. And again, and again. *That's why Kotlin will always be more advanced than Java.* Got it? 😜
it's a bit infuriating to see that the Java designers can not get out of the habit of making their language clumsy and cumbersome. Why in gods name are they dropping whitespaces in multiline strings? They are actually adding more weird java things to think about that distracts from writing your application when they should be getting rid of them. Why are they dropping the beans conventions for records of all things? For decades now we built everything on top of beans and now? I predict people are going to use linters to ban using the new Java Records because they break the whole ecosystem.
Records are nicer for data only objects. Less boilerplate without using annotation magic like lombok, immutability etc. Less code means less bugs and more time for coding the application. Javabean way is already considered as a less favourable way in books like effective java
I do not agree on the beans point at all, you're making it sound like things that are already years in development are going to embrace Java 14 etc with open arms and migrate. Very few big projects are moved at all. Records are a new approach for an old thing, designed for new projects and faster and easier development. People always talk about how writing something in another language is much less verbose, but that is a new language, a new project - no mention of changing the existing code base. Same thing here, new versions of existing tools will adjust and new projects will thrive. And I also love the getters without "get", so much cleaner. Agree with you on the first point about the spaces though, that's a weird one
Mhhh, it sounds more like controllers and models to me like in laravel php. The bean controls, the record holds data. Up to the dev how to implement it though.
guys beans is the convention that a property foo has getter getFoo() and maybe a setter setFoo(value). For records they'll make it foo(), breaking everything that expects the beans convention, so essentially every library and application that generically reads data from objects.
@@cas1652 if you're familiar with laravel style models its actually okay. Of course it would break older java ruts, but transitioning from php/laravel to java would be easier. It gives a kind of flexibility in approach.
Congratulations to all Android Developers who never fell victim to the Kotlin hype Google created just bcz Oracle is gona sack their ass of $9billion!!! I use Kotlin, sure its nice.. But I will always remember the backbone of all great programming will always be JAVA!
I'm not missing out on shit.. I use Kotlin.. And thank my lucky stars my grounding was in Java & C#. And I don't make a living by playing fan boy to groups, teams or languages... I've been in the industry for more than 22yrs now and can safely say this like all the real guns - No matter what you do with your IT skills, Java will align with the future. Take a close look at dart today and tell me how many Python guys can pick it up faster than Java guys. Take a closer look at graalVM.. And tell me how many JS guys really get the idea from where that kick is coming. I'm not saying C or C++.. That might be a bit too much.. But Java is surely the one to not trade away for Kotlin. Flutter has already started proving cooler.. So if you ask me, your the guy missing out on cool stuff with Dart.. And hard core stuff with Java!!!
@@jatinrana7998 .. Well said ;-) I only use it when I'm forced to.. Otherwise Java is insane! Love it or hate it.. It'll just keep getting better and better.. All these piddly little decorational advantages they say Kotlin has won't be visible post the next 2-3 updates in Java ;-)
@@yoapps137 i also hate it when client force me to use kotlin who have no knowledge of programming, they ask for it because somebody told them kotlin is cool.
Java is like the out-of-touch old man that tries to follow memes but doesn’t really “get it” It’ll always be playing catch up to the likes of C# or Kotlin, which are just simply better languages by all accounts in my opinion.
![[DRAGON BALL LEGENDS REVEALS ＆ STUFF] LEGENDS FESTIVAL 2024 Special Edition Part 1](http://i.ytimg.com/vi/mV5bGIswTtQ/mqdefault.jpg)
By the time java 19 comes out companies might actually be on java 11.
I think you mean "By the time java 19 comes out companies might actually be on java 9."
@@DavidThoren It is more likely they will move to next LTS version which is java 11.
depends on the company, we are running multiple desktop, server and web apps on jdk13, and there is no issue with updating to latest.
That's a c++ joke.
@@DavidThoren I think you mean "By the time Java 19 comes out companies might actually still be on Java 8"
Variable Type Inference (Java 10) [3:59]
Local Functions (Java 16/17) [7:15]
Multiline Strings (Java 15) [10:38]
Value-Based Classes (Java 15/16 Records) [18:20]
Sealed Hierarchies (Java 15/16) [22:40]
Type Matching (Java 15/16) [25:56]
Destructuring [29:09]
Coroutines [45:07]
Executores.networkStealingPool()
The end of Kotlin? [46:40]
Java 16/17 Pattern Matching
Java 14: Expression Switch
Java 18/19: Inline Classes
Java 16/17: Virtual Threads
conclusion [47:21]
And if you're wondering why "inline classes" is in the summary but not the talk, skipped for time :(
Congratulate us, the Android developers who are still stuck at java 8, which isn't even fully supported!! We aren't gonna let Kotlin die
And with differing non spec behaviours
@Tired doctor yes you can. Try to work with new apps but to support any legacy code you would have to learn Java
@Umbrella Corporation How so? Only thing I see going for kotlin is a whole lot of hype, which isn't going to last. Android apps developed using java have better performance and less lag. It would appear to me java is superior to kotlin in almost every way. I'm not going to go learn a new language just so it can fix pointers for me. Or is there something I'm missing about kotlin that somehow makes it better than java?
@@seriousskateboarding9938 Java code seems more primitive and full of words, kotlin simplified it and clean
I was thinking about ultra native development
The internet manual, rule 47:
-Any youtube video phrased as a question can be answered with a simple NO
Edinson Sanchez Bederidge’s Law.
Applies to headlines, too.
Thanks, I thought so too.. now I don't have to watch the video.
The answer usually is "it depends"
Java inline types and virtual threads will provide an insane performance boost allowing the CPU to avoid massive amounts of cache misses. When this is combined with the Vector API it'll be huge for SIMD processing.
Got clickbaited so hard. But I ain't mad because I still want to watch it.
Agreed!
it's not clickbait .. it's pretty obvious cause today version of java is 13 ._.
Lol watching it at 3 in morning, cause of clickbait
"The end of Kotlin"
*Obvious clickbait*
But you are still here
Yeah. I am only here to see this "end of Kotlin" bullshit
That was Jake say for the Intro
It was meant to be a joke entry for the talk afaik but he got greenlit and here we are
I think it's quite important that with Kotlin, you can clearly see variable definitions, and they line up. Makes reading the code easier.
The same principle applies to the internal function. In Kotlin, you can see the `fun` word, and know it's a function. With Java, there was a `boolean` and then a name. Much harder to skim the code and realize there's an internal function.
Correct dude
Both are unreadable shit
*Title:* "The end of Kotlin"
*Actual content:* "A million ways why Kotlin is better. But Java is scheduled to gain some of these features over the next few years."
😂😂
yeah, it will be most performative in Java, but it is still a promise
I think Java just recycling Kotlin and try for some kind of "resurrection" but Kotlin is a future. Still Java don't have null-safe calls. For other things i don't really care. Less code = less mistakes. And only way to produce "safe code" is with usage of null-safe calls and i don't mean check of nullability with if...
@@hefaistoss1 you are using lambdas when you shouldn't be
@@hefaistoss1 I use Java and Kotlin and together, they are obviously flexing about Java doesn't have, but if you know both at the save level, you'd know why Kotlin isn't as used as Java. Thought, I'd like null safety
@@hefaistoss1 yes, you're right less code (or you could say, less complicated logic too) means less mistakes, but the truth is, I've seen a LOT of new developers who started learning kotlin from the get go, doesn't know sh*t on how the actual code works (i.e. how it work inside the system) and basically just use whatever the tutorial gave them and resulted in a less performant code (yes, it happens a lot. please DO look somewhere else around you).
I don't really care about which one is the future programming language. The point is, once you get used to and understand how the internals are working together, no matter what programming language you use, you'll produce a code with less null-related errors
I've just finished a book about Java 1.0.2
Optional is the way Java introduced to deal with null safety. It's not a language feature, but you can use it anyway, if you need to. It's used by popular frame works as JPA.
Your daily reminder that you could do all this in LISP in 1958.
While keeping LISP simplicity and not adding stupid stuff every year. That's why I love Clojure.
I really appreciate the example and comparison of destructuring. It's interesting to see some discourse over positional attributes and changes management.
The feeling of coding without generic for 8 years, go ask Go developer
Feels terrible, man!
Another interesting competitor, which is not mentioned, is C#. Lately I'm focusing on C# and I see those features also implemented in C#. The way that Java implements 'smart casting'is the same as in C# (and it is already available). Coincidence? I don't think so. C# 8 also implemented nullable types, just like in Kotlin. I'm pretty sure that Oracle is also watching Microsoft's endeavors.
@rudolf de grijs Can they please make something like Blazor so Java code can compile into native webassembly like .net core can?
As he showed the "smart casting" feature in Java, I immediately thought of C# too. I don't think Oracle cares that much about Kotlin as a competitor as they care about C#
@@GuiChaguri Kotlin is more of companion rather than competitors because of interoperability. C#, on the other hand, lives in different ecosystem
And you have in C# a code from version 1 that run on jdk 19 ?
What does he mean with "Kotlin has an IDE to potentially evolve in ways that Java cannot" (48:14)? IntelliJ also supports Java.
No. They suppress java
This is like when Apple announces a feature that Android has had for years, but theirs is better for some incrementally small reason.
I think what kotlin and java ecosystem lacks are a more standard toolchains. In go and rust world, I don't have to fight the toolings and choose which code standard that I wanted to choose. If only in kotlin I can just generate "kotlin init my-project" with all the minimal best practices, and no linter settings, just make it standard toolins. And if I could do "kotlin run" or "kotlin build", I think it will catchup to more developers.
Java has so much more robust tooling than go.. was that comment a joke?
@@joachim5080 Except Gradle is a tool hated by many developers worldwide.
That and the pervasiveness of IDEs really turns me off. When other communities are busy working on easily pluggable, flexible tools for people to make more complex tooling on top of, the JVM world seems to start with bad abstractions, realize the mistakes halfway, and start over from scratch with an entirely new behemoth. Kotlin, despite being probably the most fun language that I've come across, is an absolute pain to get set up with anything outside of IntelliJ, which is a shame because it seemed like a perfect replacement to Python for scripting and online problem-solving purposes.
@@joachim5080 i think he's refer to the simplicity of the tools, yes. as a java dev i know java has a lot of more mature an better tooling, is just that sometimes it's too complex, ant -> maven -> gradle they are all are different
@@biskitpagla yes i agree, but java at least has the jshell ( run java in a repl ) and you can also code in emacs/vim with an lsp plugin or vscode, kotlin doesn't even develop a proper lsp outside intellij
When you actually have to write and maintain real code for a living you don't want rapid change.
The title made me sick. I've just finished a Kotlin course.
Kotlin is the future.
@LeBlanco MOB Kotlin is not only for android programming lol xD I do modding and game development for windows/multiplatform in Kotlin xD
It's so funny to listen about some cool features and syntactic sugar which Kotlin has, and Java will recieve 3 years later, assuming that some languages (Scala for example) already have them for at least 10 years.
Whatever features get bolted on Java, it's always done in this Javaesque, square, human-hostile syntax that feels clunky and absurd (to me)
When scala introduces features they usually shoot themselves in the foot. When java gets a new feature one can rest assured that it’s useful, stable and understandable. So i rather wait a few years before dealing with crazy junk
@@vibovitold Hard agree. I was convinced that functional code is elegant by default until I saw functional Java.
I'm still at java 8. Tried migrating to java 9, whole project crashed. Went back to java 8 🤣
@Tired doctor Yes you can
Get another job
The only Java version numbers that truly matter though are the LTS (Long Term Support) versions. So, Java 11, right now.
Mmm, I didn't see properties, right? I mean getting rid of getters and setters in normal classes. Also, I hope Java does something to be able to use future features on previous versions, like Babel does for JavaScript. (I saw a similar tool, now I can't remember its name, but it was very beta).
Lombok?
It's exactly first of September 2022. Let's see
Holy shit he’s wearing a Circa Survive sweater!
Just signed for an all-Kotlin job, seems like Kotlin survived :D
I very much enjoyed this talk. Clear, considered and unbiased comparison. Nice one.
Glad you enjoyed it!
what？Java 19 is coming ,im still use java 8 🤣
I think majority is still using java 7 and 8
dam i though writing android 9 java 8 latest ,, haish
After switching to GoLang from java spring .. my productivity has increased 1000% . Generics is a good add on but not essential 🤣
A better way to put it is that generics are essential for some applications and less for others.
It's optional for Go's userbase mainly because developers who inherently need them to do anything useful have self-selected away from Go.
I would have trusted your statement if you weren't the type of people who exaggerate things to 1000%.
Java 19 is NEXT MONTH!
So both Kotlin and Java will continue to take in features that Scala already has right now, but at a rather slow pace.
basically what C# does with F# 😂
... so when is Java getting extension methods/properties and inline/reified methods???
There currently seems to be an obsession with new 'language features'.
It doesn't matter how gimmicky or silly they are, they will be accepted without question into the language. There used to be sensible debate about whether or not new features should be added, and quite often they were rejected. But now the flood gates have been opened and any ridiculous crap is welcomed into the language as soon as the devs can add it.
I agree with that sentiment in part, but the opposite is also true. The requirements for what languages should accomplish change along the years, and it was only very recently that developer experience took the front seat in language development. Compared with more modern languages, Java is super verbose and yet harder to read. Learning from the better parts of other languages is cool, and Java definitely needs some modernizing. Hopefully it'll not be redundant features just for the sake of it, but instead features that make the code easier to read and more pleasurable to write.
simioni I also agree with you in part. Languages have to change and adapt to new requirements and developers. And some of the changes that are happening are good.
I also agree. Some things are benificial, others make me think, why? It enables lazy hard to trace coding. But oh well, one doesn't have to use it.
There's a place for Kotlin, and then there's a place for Go. Both are valid approaches to pl design with differing strengths and weaknesses. That said, one thing that I don't like about Kotlin is just how relatively unopinionated the language is. There're other "batteries-included" languages out there like Python and even Haskell but it's not as common for people to develop idioglossias in them as it is in Kotlin. For every single problem Kotlin seems to offer three more solutions, all of which happen to be equally promoted by the language's design.
Why is the java code missing the pesky semicolons that java requires but kotlin does not? Did I miss a massive upgrade to java that eliminates the need for semicolons everywhere?
In all seriousness with the velocity of Java releases do you think something similar to what happened with CoffeeScript will happen and Kotlin will be absorbed by Java 20.
What I found very interesting is some of the Kotlin bytecode is calling Java bytecode. Are there examples of what kotlin does that isn't a terse transpilation on top of Java?
Strictly speaking, wouldn't it be JVM bytecode. All languages that run on the JVM have to transpile to the same bytecode in order to run on the JVM. It's just changes to the JVM bytecode are driven by changes/enhancements to the Java language only. Other languages have to create workarounds for features that aren't natively supported in the bytecode.
For example, prior to JDK8, bytecode didn't support methods on interfaces. So Kotlin would work around it with classes and other manipulation. In fact, if you're on JDK8+ and want to use default methods on interfaces in your bytecode, you have to tell the Kotlin Compiler explicitly with @JvmDefault.
@@mikew3752 Thanks for giving me some clarification
@mike w you gave the most perfect example! I actually went through this in most of my lectures. And that's why I'm happy I've had my grounding in hard core Java cause once I work from that Interface all the way up to functional interfaces & lambdas.. Its then that the students get everything.. Even the Kotlin guys! ;-)
Great answer!
Java 15 September 2020, so accurate!
Does anyone know what kind of tool can create such presentation?
Prezi
@@christopherholmes559 Thank you!
Great presentation!
Yesss
i am going to ruin the talk for you: focus on the presenters breathing between words and sentences
The guy struggles to breathe.
😂😂
Thank God I didn't notice it. LOL
Java 19 is finally out!
The only thing that gonna make kotlin alive is Native..other than that, all the kotlin feature will be implemented in java..Thx to kotlin because make java a better language
48:14
"The only thing that gonna make kotlin alive is Native..other than that, all the kotlin feature will be implemented in java..Thx to kotlin because make java a better language"
Not true. Google is a huge supporter of the Kotlin language. Even if Java was able to become even better than Kotlin in the future, Google would still prefer Kotlin because the last thing Google wants is another lawsuit with Oracle.
I do not see a boilerplate language like java could potentially adapt all kotlin features.By the time kotlin more advance,java might only adapt val features in kotlin lmao.As you can see,java code is really taking much boilerplate code than kotlin to do the same thing.And,with the presence of jetpack compose,kotlin features language which became more advance and google support,i do not see java could even stand a chances again flutter,let alone kotlin.so yeah
in some decades, the will be no numerical possibility to represent Java version
Not even 1 minute in and he started trolling Go. How serious should I take this talk...
that pattern matching shit is from erlang, good one java
Very nice balanced and informative presentation.
Isn't likely that Java only began to change in 2004 because .NET got popularity and Java was behind C# in terms of modern features?
Very good
Imagine live conferences being a thing again when Java 19 is released xD
Really interesting talk.
The end of Kotlin?
The answer is at @48:37
surprisedly nice talk
If it wasnt for android and google's pressure on developers, kotlin would not even had a chance even to end.
So? 🤷♂️
@@TheRealFFS java isn't something all about oracle. Kotlin is still dependant on some other language, mostly java. I got nothing against kotlin itself. But it feels like too much when they mock/asperse java . It's like asking to demolish the ground floor once first floor is completed.
@@harshar6897 What are you talking about? I have no idea what you're trying to say, or what your reply has to do with your original post.
I don't think they're mocking anything. It's competition, and that's good. Java is trying to keep up as best as it can, but some of its primary faults still remain, mainly 'null' and its verbosity. The best thing it has going for it is its large ecosystem and user base.
That's true, just like how the same is true for Java because of the billions of dollars that went into its marketing and the absolutely horrendous OS-specific APIs of that time.
Cool video! Learned multiple new things!
Apart from nullability he forgot to mention operator overloading. Massive miss by Java which makes any kind of avanced math in it feel like you're writing COBOL
Second on my list would probably be extension functions! There's a lot of other things which I think are nice-to-haves, but nullability feels like the really foundational omission from Java's future.
agreed. I know everyone was hyped up about nullability stuff in kotlin when it got popular and stuff but when I first discovered kotlin, the thing that amazed me the most was extension functions. I guess it looked too good to be true to an Android developer like me who is mostly stuck with Java 7/8 :')
I guess he has not included operator over-loading because it can be added in future, unlike nullability which cannot be removed without breaking existing code.
Why only idea supported? What about other ide?
Kotlin works well in VSCode as well as Vim.
@@damienstanton VSCode ? not sure fully support
@@nimaparsa5960 Yeah, the "official" preview plugin uses Kotlin Language Server (like the Vim one): marketplace.visualstudio.com/items?itemName=fwcd.kotlin
Kotlin works in eclipse with pluggin and vs code etc.
Kotlin main purpose is to promote their ide which is idea
During the whole video I was thinking: but Java won't have nullability! And yes, in the end Jake said it.
Just because of nullability Kotlin will remain much more convenient and efficient, than Java
Literally came here from introduction to kotlin vedio feeling very stupid.
Kotlin is a bless to all developers
Great presentation. But one question, Hasn't Java tackle 'null' with 'Optional' in Java 8 already?
Not in the same degree. You don't have idiomatic non-nullable object types, you can still null any object in Java, no matter if it's wrapped around a Optional or not
@Niklaus Bucher your point is spot on. Optional actually makes things worse since Java still cannot represent things that are non-null.
Kotlin:
- String means "not null"
- String? means "maybe null"
Java:
- String means "maybe null"
- Optional means "the optional can be null or the string can be null"
Too much precious time dedicated to string formatting topics
For real!!! Who cares! Right?! smh
@@alessandroaiezza4339Sure no one cares LOL
Java its Monster
Java 19?!? I thought 13 just came out!!!
watch the video first.
@@kenocontreras - It's on my watch later
We being fooled
September 22 is when java 19 will come out
Does anyone know how old Jake is ?
Why is Java rushing with its versions??
Marketing gimmick. Same happened with web browsers.
These few features are going to kill off kotlin? I doubt it I can code Kotlin way faster than Java. The amount of time I save typing kotlin compared to Java is 10 fold
Under Oracle, Java as a language is still kicking, but as platform is almost dead. JCP is dead. Oracle was the worst possible successor for Sun Microsystems.
Welcome, Kotlin! I loved Java, but we are not engaged anymore.
you made me lough althogh if any thing in java is loosing populerity is the java language not the java platform jvm because it runs dozens of languages and java kotlin among others is just one of these languages and java in the enterprise developement is one of the best if it was not the best
@@mosup5007 dude, English isn't my native language to have any authority about, but I think you need some improvement here. Keep studying.
When I said Java as a platform I was referring its stack, not the JVM itself. Even so, you need to remember that JVM isn't the only virtual machine based technology anymore, and even Java language doesn't compile just to it.
On Android, for instance, Java never compiled to JVM. The old Dalvik machine had success where the JVM ever failed: mobile devices. And the new ART keep doing it. Is still unpractical run JVM even on modern mobile devices (with a power of old PCs and even not so old) because is so heavy and slow.
About Kotlin, the language compile/run against really a LOT of environments. Even JavaScript on a web browser! Any VM supporting dynamic invoking can run it. JVM included.
About Java as language, it not aged nicely. Again is probably Oracle's fault by the lack of JCP involvement, but the sintax became really messy across time. So many syntactic sugar, the lambda implementation isn't exactly the best possible, so many things solved with preprocessors (annotations) instead language specs, etc.
Project jigsaw also destroyed the platform backward compatibility (a thing that we was proud in the past) In old times, if you had a self contained executable jar file you knew that you can run it anywhere against any JDK or JRE implementation. Now, so many old files doesn't run anymore by lack platform libraries, *even when you put the libraries in the classpath* because the classloader isn't accepted to that libraries. Is a damn pain in the neck.
Old Java just worked. Write Once, compile once, Run Anywhere. Isn't like that anymore.
My final advice to you: technology change across time, like people. Don't be like a cheerleader to any kind of tech.
@@CopernicoTube I worked for the biggest cloud companies you can name and I can say that at least 80% of codes is written in Java and still used in new projects.
@@voronoit4091 Yeah because transition is the most pain in the butt to do it.But luckily,the presence of jetpack compose,which only available on kotlin,with so much less codes and huge feature served in it,would likely a game changer in mobile development
should I be worried if I am still learning java 8?
I'm still in java7 😭😭
If you want to know what is real suffering you should downgrade to Java 1.1
TLDR; The answer is no
Poeple just get paid to post 'The end of X'. Unfortunately I will not continue to watch the video. Not because I'm a kotlin supporter, but because I was a victim of those marketings.
Great talk! :)
Please don’t call these things destructors. Even “deconstructor” isn’t a very good name, but it’s much better than destructor, since nothing is being destroyed. Also that name is already used by C++ for actual object destruction(freeing memory). In python, the concept under discussion here is called “tuple unpacking.” I’d start with that.
I disagree. Deconstructor is a perfectly good term since we reverse the constructor. Especially since we already have a tupel class and this code works with tupel in Kotlin but not only.
Great Content keep it up bro!
Oracle, what a sad word
I will be happy if they make string one of the key words such as int, float and... IT IS ANNOYING
Why? String is better of as a class than a datatype.
@@911SuperGTIn my opinion it would be better to become a datatype and has a wrapper class(I don't know why it shouldn't... I'll be thankful if someone explain it)
really nice talk )
Nullability argument is very weak. Java solved nullability issue by introducing Optional which happens to be Functor(map) and Monad (flatMap).
Next time I get an NPE in production, I'll be sure to call you to ask why nullability is solved. As long as you can compile code which gives you NPEs, I wouldn't consider nullability solved.
I'm all on the java train for most things. It's a strong language that can do it all -- including crash your system because you forgot to check for null in a weird case which is now the normal case.
@@scottmacwatters Never use null. Use Optional instead. Using null in Java today is like using !! at Kotlin. In fact looking at kotlinlang.org/docs/reference/null-safety.html, I see there plenty holes at Kotlin null safety. Please don't get me wrong I agree that null safety at Kotlin as elegant, but is is far away from being killer feature.
Until the JVM has value types (and Optional becomes a value type) using Optional has extra overhead with the extra object reference lookup vs Kotlin null checking which is compile time. You can use Optional with Kotlin if that is your thing but Optional isn't "free" wrt runtime cost.
@@RobBygrave it is right, but Scott's point was that even for long run Kotlin will stay superior to Java.
No they did not. Java still lacks the ability to say that a reference can not be null.
And the official documentation say that optional should only be used as a return type, not as an argument type. The main reason for this is that if a function takes an optional, the code can still call it with null. Also the optional syntax in java is insanely verbose. Just try to compare the code needed to call a method on a reference if it's not null.
And the Kotlin compiler is so smart, that if you have tested if a reference is not null, the compiler know this so later in the code it will be ok to use the reference as if the type was "can't be null".
Optional in java was created to only solve the problem of how to signal that an return value was optional(Could be null). it does solve this specific problem, but that is only a very small part of the null problem.
In kotlin you can use the type system, to do a static verification that this program can newer throw a null pointer exception*. Doing that in java is impossible. This is one of the reasons that we are currently looking at moving from Java to Kotlin(On a jvm) for our furture server side code. That way we can still use all the great java libraries.
Java is killing jvm langs by copying.
And that's a good thing! :D
That positional destructuring is pretty gross.
I used Kotlin for a while and I made a conclusion that Java is better. Kotlin's ? is practically dangerous.
I agree too.. But tell that to a Kotlin fan boy and see the nonsense you get back! Hahahaaaaa
Yes Kotlin might have some cooler features but in no way it has the depth of Java.. No way. No chance. Java will always be the beast. And as time goes on.. It'll just get more & more refined. Love it or hate it.. It delivers. See my comment on this same video..(by the way already attacked by Kotlin fan boys!!!)
Guys, you just haven't used Kotlin deeply. It is for 100% compatible with Java. 1. Q: what you use instead of coroutines? 2.Ok, let's imagine, you invokeMethod1, then wait for result of some Callback{onSuccess(sResult); onFailure{fResult}}, then invokeMethod2(sResult), and process Exceptions -> please provide here your implementation in Java
Why is Kotlin's ? dangerous? It clearly specifies, that you must expect to receive null value. From that point, you either:
- a, handle null case safely
- b, don't care about mountains of warnings THEN fail
I don't see what is dangerous about this, especially that in Java you kinda always should expect null, or make assumptions about being nonnull and make sure your assumptions are met. You can use annotations for that, but hell it is so verbose to annotate everything instead of just one ? character extending the type system with nullability, which IS the proper way to integrate null into the system - as C# noticed it too and is now applying the ? nullable type thing to reference types too.
It is dangerous not to know whether some method is expecting null or not and whether you receive null or not. Throwing an exception upon receiving null is digusting imo, it should be part of specification (some write it in JavaDoc, but that is not compile checked), so part of the type system.
Optional is a completely different tool. You cannot use Optional for every parameter where you expect a value or null, that would look ridiculous. I loved and use Java every day at work, but Kotlin does nullability a hell lot better. Java IS null-dangerous, Kotlin is not.
In Kotlin null is not danger, it is a useful tool. In Java you better use Null Object Pattern for safety, which is a half solution, in Kotlin there is no need to, because null policy must be specified everywhere (via ?'s).
@@scriber36 To my mind, null-safety is really not so great+explicit in Kotlin, just because of !! operator is required some time. Yet, there are: sealed classes/coroutines/StringUtils/semicolons )))
@@artemurubkov3588 Kotlin states never use the !! operator - if you use it you are a bad Kotlin programmer in most cases - that is written in its specification. You are never forced to use it, since you can do the same safely via a null-check or use the ?. operator if null result is acceptable.
end of Kotlin ? LOL.. clickbait nonsense
Release 19, Java still has no string interpolation? No need to watch the rest of the video - DISLIKE
as much as String interpolation looks cool, it can (and WILL) break existing code if it gets added to java later on. imagine having a string that is like String s = "test $something"; then you updated your java version to which they added string interpolation and getting a compiler error "Variable 'something' cannot be resolved
"
A clickbaiter admitting this is a clickbait. That's a first.
this guy has real trouble breathing though
but java forced you to do everything in OOP which is sucks..no thank you
Java (rabbit) will never catch Kotlin (turtle). Because Kotlin introduced improvements to Java, right? When Java catch up with those improvements, Kotlin will be more advanced in the meantime. And again, and again.
*That's why Kotlin will always be more advanced than Java.* Got it?
😜
Mika Mikic no becus Oracle enginairs > Jetbrein enginaires
Yes
Java is one of the worst languages in the world. Thank god for allowing us to use Kotlin 🙏
it's a bit infuriating to see that the Java designers can not get out of the habit of making their language clumsy and cumbersome. Why in gods name are they dropping whitespaces in multiline strings? They are actually adding more weird java things to think about that distracts from writing your application when they should be getting rid of them.
Why are they dropping the beans conventions for records of all things? For decades now we built everything on top of beans and now? I predict people are going to use linters to ban using the new Java Records because they break the whole ecosystem.
Records are nicer for data only objects. Less boilerplate without using annotation magic like lombok, immutability etc. Less code means less bugs and more time for coding the application.
Javabean way is already considered as a less favourable way in books like effective java
I do not agree on the beans point at all, you're making it sound like things that are already years in development are going to embrace Java 14 etc with open arms and migrate. Very few big projects are moved at all.
Records are a new approach for an old thing, designed for new projects and faster and easier development. People always talk about how writing something in another language is much less verbose, but that is a new language, a new project - no mention of changing the existing code base. Same thing here, new versions of existing tools will adjust and new projects will thrive.
And I also love the getters without "get", so much cleaner. Agree with you on the first point about the spaces though, that's a weird one
Mhhh, it sounds more like controllers and models to me like in laravel php. The bean controls, the record holds data. Up to the dev how to implement it though.
guys beans is the convention that a property foo has getter getFoo() and maybe a setter setFoo(value). For records they'll make it foo(), breaking everything that expects the beans convention, so essentially every library and application that generically reads data from objects.
@@cas1652 if you're familiar with laravel style models its actually okay. Of course it would break older java ruts, but transitioning from php/laravel to java would be easier. It gives a kind of flexibility in approach.
Java is still alive I thought it died a while ago
It went zombie mode and started devouring features from literally every single other language in existence.
@@biskitpagla true
Java is trying too hard
Can someone give this man a jar of water!? He's dry as hell!!
Congratulations to all Android Developers who never fell victim to the Kotlin hype Google created just bcz Oracle is gona sack their ass of $9billion!!! I use Kotlin, sure its nice.. But I will always remember the backbone of all great programming will always be JAVA!
kotlin is not hype. ur just missing out while the rest of us enjoy how much better kotlin is than java
I'm not missing out on shit.. I use Kotlin.. And thank my lucky stars my grounding was in Java & C#. And I don't make a living by playing fan boy to groups, teams or languages... I've been in the industry for more than 22yrs now and can safely say this like all the real guns - No matter what you do with your IT skills, Java will align with the future. Take a close look at dart today and tell me how many Python guys can pick it up faster than Java guys. Take a closer look at graalVM.. And tell me how many JS guys really get the idea from where that kick is coming. I'm not saying C or C++.. That might be a bit too much.. But Java is surely the one to not trade away for Kotlin. Flutter has already started proving cooler.. So if you ask me, your the guy missing out on cool stuff with Dart.. And hard core stuff with Java!!!
@@tdsora it's all hype , used it and now back to java. Kotlin is good though but not worth switching.
@@jatinrana7998 .. Well said ;-)
I only use it when I'm forced to.. Otherwise Java is insane! Love it or hate it.. It'll just keep getting better and better.. All these piddly little decorational advantages they say Kotlin has won't be visible post the next 2-3 updates in Java ;-)
@@yoapps137 i also hate it when client force me to use kotlin who have no knowledge of programming, they ask for it because somebody told them kotlin is cool.
Java is like the out-of-touch old man that tries to follow memes but doesn’t really “get it”
It’ll always be playing catch up to the likes of C# or Kotlin, which are just simply better languages by all accounts in my opinion.
Always dislike clickbait videos
I'd say it's sarcasm, not clickbait.
your anwer 48:38
Dont talk shit man, i just moved to kotlin!
why is this guy talking about JAVAsyntax as if Kotlin was the first one to do ALL of the features?
most kotlin people were java people, all of these were news to them just how kotlin is still news to current java people
Why is this dude breathing so heavy
If Android don't choose Swift it will be and not only for Java/Kotlin, it will be end for all that bind with JVM ecosystem.
Why would Google want to use a competitors language?