Most of the new language features you showed were previews of changes that are potentially coming in future versions. They are not available in 2.0.
5 місяців тому+3
Indeed, most of these were not mentioned in the release notes. We already moved our Android project to K2 and if the destructuring expressions really worked like that, our code wouldn't have compiled in the first place, but we saw none of that.
3:37 fyi the correct term is "destructuring" not destructing. Destructing an object usually refers to freeing its memory, what we are doing here is very different. On the other note a lot of cool features especially better smartcast
Coming from C#, this is kind of like a readonly property: private sting x; //is mutable public string X => x; // is immutable (or you can do, which makes an implicit private backing field int he generated IL, but in your code, you just use X) public X {get; private set;} (Or if you like old school) private string x; public string X { get => x; private set => x = value; }
It's not "destructing", it's "destructuring". And triple quote strings are called "raw strings". Overall the changes seem rather underwhelming, there's no new features to functional programming for example (Kotlin's strongest point).
Kotlin is fairly younger I think, Microsoft has to worry about lots of compatibility things to introduce features like that. Take a look at the latest breaking changes in C#13; accessing the backing field in auto properties was held back for nearly two years just because the keyword „field“ might break existing code and needs to be refactored. So I guess Microsoft is dealing with other issues than Jetbrains is adding new language features.
when i wrote: dataarg class Config (val Arg1: Int = 1) i get the error: Syntax error: Expecting a top level declaration (without dataarg - all ok) IntelliJ IDEA 2024.2 Kotlin compiler version: 1.9.25 Language version: 2.0
I'm getting "Explicit backing fields are not supported in FE 1.0" when I try the live data example you gave? Here's what Gemni says: In Kotlin 2.0.0, backing fields are not supported in the frontend (FE) 1.0. This means that you cannot access or modify the backing field of a property directly. There are a few reasons for this change. First, backing fields are not necessary in Kotlin. The compiler automatically generates getters and setters for properties, so you don't need to worry about creating them yourself. Second, backing fields can be a source of bugs. If you accidentally modify the backing field directly, you can easily break your code.
Hey @Stevdza-San, I have migrated my project to Kotlin 2.0, how I can use the BackingFields now, when I'm trying to use it, I got this error: Explicit backing field declarations are not supported in FE 1.0
Wow these are great additions! I've never encountered the type issues fixed however. I didn't really get the extensible data arguments tho, I'll have to look into it more. It makes me wonder if it means passing an object as argument instead of having real function arguments, therefore what would be the performance drawbacks (GC pressure)
It should have been rather easy to implement it as a zero cost abstraction (similar to value classes or inline functions). The best way to find out - other than by looking up the docs - is decompiling the bytecode to Java to see how it's resolved under the hood... (I like doing it that way because it's more instructive)
@@vibovitold good point, I hope so too. In a way it is almost odd that this new concept is a "class" but I guess it avoids introducing a completely new thing in the language and its tooling.
I already have a tutorial series about Notifications and Work Manager. Also you can check my Stopwatch tutorial to learn more about Foreground service.
I want to uplift my career as native android developer. I have beginner level expertise over 1.5 year. Please suggest any relevant certification that may help me to grow in market.
Nice summary! Thanks for the video. A small english correction, "more cleaner" is considered a grammatical error. One should simply say "cleaner" or maybe "even cleaner".
Nobody forces you to use them, or even to upgrade to 2.0. Besides, a lot of these changes actually simplify things (such as more intuitive smart casting).
@@StevdzaSan You can do so many things in one line of code in Kotlin, but... If you read such code, you must do a lot of effort to understand a sense of this oneliner. I think in this matter Java is more readable although you often must write more lines of code.
@letmebe_pro I don't think that Kotlin is less readable. However, you do need to learn its syntax to properly understand it. But once you do, it's a whole different story 🚀
I think the point is the more clutter is added to a language, the harder it becomes for beginners to learn it. This seems to be a common complaint nowadays with languages such as Kotlin, Swift and Rust. I guess the problem is at what point do we say it’s “enough”? This is why we see answers such as Go, which was made to be the exact opposite in terms of complexity, and why some people praise C to this day for being a small enough language despite its drawbacks.
i'd say, none of these features are actually useful. wasn't it their selling point that you can write modern procedural code, while maintaining full java compatibility? shouldn't they be cutting off oop capabilities, not adding new weird stuff? (i really don't get what prevented people from doing "dataargs" before v2.0, this trick has existed since structs were invented)
@@yurowitzit's interoperable with Java. not "backwards compatible". Java isn't its previous version, it's still under development, they are alternatives of eachother and interoperability works in both directions. its syntax is clearly different from Java - much more similar to other more modern languages such as Swift. it's a JVM language of course - but so is eg. Scala
None of this will matter in a few years. Languages only need to be usable by AI code writers, not humans. Humans will become experts at creating requirements and specifications for new systems. Code will be almost entirely generated and tested by AI.
You will still need to understand the programming language to debug AI code, you can't be 100% reliant on them. Not to mention that the AI learns based on examples. If examples are not provided anymore it will start to stagnate. Also, what if I want to program for fun?
@@Asgoritolin We're using synthetic data to pre-train models already. I've generated millions of lines of code purely through models. We've developed an agentic swarm that uses TDD to create code, UX test frameworks to verify against requirements, etc. It's not yet 100% hands off, but it's just a matter of time. The generated artifacts -- plus some RLHF -- will serve to both train future models and inform test-time inference. Certainly there will be a role for developers, and you definitely can code for fun the same way people are still hacking on Z80 boards today for fun.
@@csmac3144a So your plan is to just trust the AI. And when it fails, just debug it with AI? Idk man. Being 100% reliant on it is just ridiculous. Someone has to manually supervise it at the end. Not to mention that, even if you create synthetic samples, you still need to know that programming language to make them. Remember that programming is in everything and therefore can have direct consecuences on people's lives. No system is 100% reliable and that's where software engineers come in.
The easy part is behind you - we've got a catchy headline. Now it would be a good time to substantiate this claim with some observations and examples. Although I suspect the easy part may be the only part :)
Kotlin 2 before GTA6 is crazy
I suspect there will be Kotlin 3 before GTA 6
@@curizic Maybe even Kotlin 4.0 before GTA 6.
Most of the new language features you showed were previews of changes that are potentially coming in future versions. They are not available in 2.0.
Indeed, most of these were not mentioned in the release notes. We already moved our Android project to K2 and if the destructuring expressions really worked like that, our code wouldn't have compiled in the first place, but we saw none of that.
true, seems like typical click bait
3:37 fyi the correct term is "destructuring" not destructing. Destructing an object usually refers to freeing its memory, what we are doing here is very different. On the other note a lot of cool features especially better smartcast
I love the backing field😮
Coming from C#, this is kind of like a readonly property:
private sting x; //is mutable
public string X => x; // is immutable
(or you can do, which makes an implicit private backing field int he generated IL, but in your code, you just use X)
public X {get; private set;}
(Or if you like old school)
private string x;
public string X
{
get => x;
private set => x = value;
}
Loved the guarded condition!
Thank you so much Stev !
hope we'll have union & intersection types everywhere one day
It's not "destructing", it's "destructuring". And triple quote strings are called "raw strings".
Overall the changes seem rather underwhelming, there's no new features to functional programming for example (Kotlin's strongest point).
Kotlin having error types before C# is crazy. Can't wait for real C# Unions.
Kotlin is already lightyears ahead of C# and remember my words... it'll compile to .net some day 😁
Kotlin is fairly younger I think, Microsoft has to worry about lots of compatibility things to introduce features like that.
Take a look at the latest breaking changes in C#13; accessing the backing field in auto properties was held back for nearly two years just because the keyword „field“ might break existing code and needs to be refactored. So I guess Microsoft is dealing with other issues than Jetbrains is adding new language features.
Great summary, thanks.
Do these new union types for errors open the door to explicit errors/errors as values instead of using `throw`?
I can't find any info on these error objects (6:59). Is it documented or announced somewhere? Could this be only a part of the internal API?
They are yet to be released, they just announced it on a Kotlin conf. You can watch the video from the conference itself, google it.
@@StevdzaSan got it! Thanks
thank u for the great content ❤
i didnt even know there is kotlin 2.0
thanks man
awesome content Stefan... are you going to update your Kotlin masterclass course with this subject?
Yep I'll add a few new lectures in the following period.
when i wrote:
dataarg class Config (val Arg1: Int = 1)
i get the error:
Syntax error: Expecting a top level declaration
(without dataarg - all ok)
IntelliJ IDEA 2024.2
Kotlin compiler version: 1.9.25
Language version: 2.0
why multiplatform kotlin template error when android studio is set to kotlin 2.0?
1:47 I can't find dataarg!! even kotlin playground 2.0.0 not compiling !! How to use?
It comes with Kotlin 2.1 or 2.2 as beta
I'm getting "Explicit backing fields are not supported in FE 1.0" when I try the live data example you gave?
Here's what Gemni says:
In Kotlin 2.0.0, backing fields are not supported in the frontend (FE) 1.0. This means that you cannot access or modify the backing field of a property directly.
There are a few reasons for this change. First, backing fields are not necessary in Kotlin. The compiler automatically generates getters and setters for properties, so you don't need to worry about creating them yourself. Second, backing fields can be a source of bugs. If you accidentally modify the backing field directly, you can easily break your code.
Loveee the backing field update
Thanks for the video, san
Is the dataarg close to a trait in a php class?
Thanks 👍
When will your Kotlin masterclass be v2?
Hey @Stevdza-San,
I have migrated my project to Kotlin 2.0, how I can use the BackingFields now, when I'm trying to use it, I got this error: Explicit backing field declarations are not supported in FE 1.0
Kotlin 2.0(RC1) introduced explicit backing fields as far as I know.
Wow these are great additions!
I've never encountered the type issues fixed however.
I didn't really get the extensible data arguments tho, I'll have to look into it more. It makes me wonder if it means passing an object as argument instead of having real function arguments, therefore what would be the performance drawbacks (GC pressure)
It should have been rather easy to implement it as a zero cost abstraction (similar to value classes or inline functions). The best way to find out - other than by looking up the docs - is decompiling the bytecode to Java to see how it's resolved under the hood... (I like doing it that way because it's more instructive)
@@vibovitold good point, I hope so too.
In a way it is almost odd that this new concept is a "class" but I guess it avoids introducing a completely new thing in the language and its tooling.
Thats huge stuff. Thanks
Well compiled video.
thanks for this
love smartcasts
i cant find any documentation about union types??
I think the best addition is regarding livedata
Good choice on taking the goods from C#
..also from Swift
where is static extensions? ((
how to use dataarg class ?
please guide us to learn some topics like Notification channels , work managers and foreground services , please sir its a request
I already have a tutorial series about Notifications and Work Manager. Also you can check my Stopwatch tutorial to learn more about Foreground service.
Ok sir Thanks ❤
Btw your tutorial of remote Mediator+ pagination is well explained ❤(That Boruto App With Ktor backend Course on udemy )
I want to uplift my career as native android developer. I have beginner level expertise over 1.5 year. Please suggest any relevant certification that may help me to grow in market.
@@haseeb776 Send me a message on Instagram.
Nice summary! Thanks for the video. A small english correction, "more cleaner" is considered a grammatical error. One should simply say "cleaner" or maybe "even cleaner".
Destructuring YEEEAAAAAA
Thanks
Major Change
wowww K2 is amazing, I hope my laptop can run new android studio version + emulator.
dataarg❌
Dat aarg✅
🤩
Prepare for the language of the future.
this is what I needed, more keywords and making language more complicated /s
No worries, buddy, I'll simplify it for you when the time comes 😎🙌
Nobody forces you to use them, or even to upgrade to 2.0.
Besides, a lot of these changes actually simplify things (such as more intuitive smart casting).
Kotlin all the way
❤❤
I want dataargs in all my oop languages
👌
feels like C# clone
It’s the other way around really, c# is hastily adopting all sorts of syntax from more modern languages
@@desertfish74 C# is stealing from f# Kotlin is stealing from c# it's a circle of life.
GOATlin 🗣🗣🗣
Hi, There a lot of countries that aren't connect to global banking system, It'll be nice if you put your crypto wallet address for those donations
The new destructing constraint is insane! Why would they do this? I hope they'll loosen it soon enough.
i have same consideration with you, cause after migrate to 2.0, we may get error compilcation.
#1
Every new upgrade - > Kotlin less intuituve/readable. Java is easier in syntax
Why do you think that?
@@StevdzaSan You can do so many things in one line of code in Kotlin, but... If you read such code, you must do a lot of effort to understand a sense of this oneliner. I think in this matter Java is more readable although you often must write more lines of code.
@letmebe_pro I don't think that Kotlin is less readable. However, you do need to learn its syntax to properly understand it. But once you do, it's a whole different story 🚀
I think the point is the more clutter is added to a language, the harder it becomes for beginners to learn it. This seems to be a common complaint nowadays with languages such as Kotlin, Swift and Rust. I guess the problem is at what point do we say it’s “enough”? This is why we see answers such as Go, which was made to be the exact opposite in terms of complexity, and why some people praise C to this day for being a small enough language despite its drawbacks.
DielsonSales I think they add more features because they see beginners flocking other languages...
Elvis op, Aligator op and now Butth*le o.
i'd say, none of these features are actually useful. wasn't it their selling point that you can write modern procedural code, while maintaining full java compatibility? shouldn't they be cutting off oop capabilities, not adding new weird stuff? (i really don't get what prevented people from doing "dataargs" before v2.0, this trick has existed since structs were invented)
isn't kotlin a Java clone
No, it isn't, although if this video (even if you hadn't known anything about Kotlin before) didn't help you realize that, I doubt any comment will
lmao! wth
I wouldnt say clome but its heavily inspired by it and could pretty much replace it anywhere. Its also backward compatible
@@yurowitzit's interoperable with Java. not "backwards compatible".
Java isn't its previous version, it's still under development, they are alternatives of eachother and interoperability works in both directions.
its syntax is clearly different from Java - much more similar to other more modern languages such as Swift.
it's a JVM language of course - but so is eg. Scala
None of this will matter in a few years. Languages only need to be usable by AI code writers, not humans. Humans will become experts at creating requirements and specifications for new systems. Code will be almost entirely generated and tested by AI.
Lol
And who do you think will code this "AI" to code? Oh its humans? Oh damn so we need to learn to programme anyway?
You will still need to understand the programming language to debug AI code, you can't be 100% reliant on them.
Not to mention that the AI learns based on examples. If examples are not provided anymore it will start to stagnate.
Also, what if I want to program for fun?
@@Asgoritolin We're using synthetic data to pre-train models already. I've generated millions of lines of code purely through models. We've developed an agentic swarm that uses TDD to create code, UX test frameworks to verify against requirements, etc. It's not yet 100% hands off, but it's just a matter of time. The generated artifacts -- plus some RLHF -- will serve to both train future models and inform test-time inference. Certainly there will be a role for developers, and you definitely can code for fun the same way people are still hacking on Z80 boards today for fun.
@@csmac3144a So your plan is to just trust the AI. And when it fails, just debug it with AI?
Idk man. Being 100% reliant on it is just ridiculous. Someone has to manually supervise it at the end. Not to mention that, even if you create synthetic samples, you still need to know that programming language to make them.
Remember that programming is in everything and therefore can have direct consecuences on people's lives. No system is 100% reliable and that's where software engineers come in.
Kotlin is terrible. Swift is better.
i hope you are joking
Source - Trust me bro
Says a guy that has never touch Kotlin
🤡 🤡
The easy part is behind you - we've got a catchy headline.
Now it would be a good time to substantiate this claim with some observations and examples. Although I suspect the easy part may be the only part :)