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"

And if you're wondering why "inline classes" is in the summary but not the talk, skipped for time :(

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"

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

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

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

Correct dude

Both are unreadable shit

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

@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 ?

While keeping LISP simplicity and not adding stupid stuff every year. That's why I love Clojure.

No. They suppress java

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

Yesss

Feels terrible, man!

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 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

@@raianmr2843 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

Glad you enjoyed it!

Lombok?

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.

The guy struggles to breathe.

😂😂

Thank God I didn't notice it. LOL

@Tired doctor Yes you can

Get another job

Prezi

@@christopherholmes559 Thank you!

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%.

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.

basically what C# does with F# 😂

I think majority is still using java 7 and 8

dam i though writing android 9 java 8 latest ,, haish

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

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"

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.

Marketing gimmick. Same happened with web browsers.

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

watch the video first.

@@kenocontreras - It's on my watch later

We being fooled

September 22 is when java 19 will come out

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

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 "

For real!!! Who cares! Right?! smh

@@alessandroaiezza4339Sure no one cares LOL

If you want to know what is real suffering you should downgrade to Java 1.1

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.

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.

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.

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)

And that's a good thing! :D

Java is literally what gave birth to those languages and allowed them to prosper in a platform-independent environment

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.

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.

Mika Mikic no becus Oracle enginairs > Jetbrein enginaires

Yes

most kotlin people were java people, all of these were news to them just how kotlin is still news to current java people

I'd say it's sarcasm, not clickbait.

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.