I don't use Java but stumbled upon this talk, it was fantastic! Swift is probably my favourite language and it was really cool to hear you talk about how you came to a lot of the same conclusions they did. Of course the Swift team didn't have a 30 year legacy to contend with. I'll be really interested to see the Java team's answer to generics and union types when the time comes.
@@Mig440 Java doesn't have union types, except that exception handling works kinda like union types. Are you thinking of sealed interfaces? Because those require you to be writing the underlying types, which actual union types shouldn't.
@@ethanchapman1776 sealed types are nominal union types, which fits javas typesystem better than a purely structural union. C# is proposing adding structural union types
@@Mig440 It has had generics to since Java 5, yes. But Swift's generics are far more extensive and the speaker touched on some of the possible future evolutions of Java's generics in the talk.
Useful information! Feels like Valhalla is just around the corner now (maybe 2 years if we ask nicely?) My only requests for Valhalla are: 1) if we offer certain guarantees in Java, I don’t think we should force the VM to make those guarantees in all situations as well. A general purpose VM is better for everyone! 2) The memory model of the program, at least at a high level, is inherent to the work of the programmer - hence I think we should have reliable control over things like secret boxing of large value objects (e.g. base it on an exact byte size and offer an annotation or compiler flag to fail at compile-time when a class or function exceeds that limit, etc.) Depending on the byte limit, this could be a *major* headache for game developers to track down. 3) Multi-threading is already a massive “abstraction leak” of how a program is supposed to work imo. If there’s a critical section error, then all bets are already off, no? So I would rather Range be a value class and multi-threading have slightly worse consequences for failure than the other way around. (Those multithreaded guys are smart anyway, they can handle it!) In any case, thank you! I learned a lot from your talks that I’ll be applying to my own projects as well. Complexity is hard to deal with!
Looking at the slide at 20:22. Using "new" in a loop like that would require some habit changing, for sure. But it's nothing new (no pun intended): with Loom, people had to change their habits around pooling threads and otherwise treating them as a scarce resource.
Withers might save us. Those are methods that say "copy a record but with one field changed" so if we had them here, it would say "return withTotal(total+n)"
Yes, people get a little weirded out by the fact that `new` is not allocating a new heap node. But it is creating a new object, and "where does this object live" is a low-level detail that should not intrude into the programming model. (Further, if the creation expression was different between identity and value classes, we could not migrate an identity class to be a value class.)
So I'm guessing any attempt to get object identity will throw an exception when done on value class instances? If so, I have this question: after changing obvious JRE classes to value objects, is there any estimate how much existing code will start failing because someone, somewhere, does synchronized() on an Integer? Obviously not much because it's probably a mistake, but it wasn't forbidden before as such.
Yes, that’s exactly what will happen, if the compiler can’t catch it then the runtime will throw an exception. And yes, any code synchronizing on new Integer() will break. But it’s not the first breaking change, e.g. any introduction of new default methods to existing interfaces breaks code that implements those interfaces with a method of same name and parameters but different return type but such cases are rare and they usually scan lots of existing open source code beforehand to estimate the impact.
@@Ewig_Luftenglanz char is an unsigned integer you can interpret as a message of length 1... Not exactly a text primitive, but i'll grant it's pretty close.
Burdens like extreme run-time optimisation , binary portability, a vast ecosystem of libraries, totally automated memory management, full object orientation?
Why does the presenter as if these problems were not already solved in C#? The innovation was already done in that ecosystem. Java is just playing catch-up.
Because it's not the same problem, neither the same ecosystem, neither the same constraints. c# solved many problems in ways java can't because at thise times C# was very small so it didn't had the same urgency as java to maintain backwards compatibility (generics are an excellent example) Btw C# has still issues that are not being solved coz they can't break things now that they are big. Async2 it's an example of hiw they tried to bring an equivalent to vietual threads to C# and failed (at least this time, i am sure C# guys are gonna get back with something new) Besides, what C# did to solve memory density is different, inC# you explicitly compress memory by using structs, in the jvm model is the jvm the one thst optimize memory Layout automatically.
Ignoring for a moment that Java cannot use C# solution (break every code in existence cause your ecosystem is small and you don't care - which *was* at the time an okay solution for C#, but not anymore) Brian Goetz highlighted all of the languages they took inspiration from. Maybe listen first next time, then try to throw shade at someone.
Except it’s the opposite of that, since Java 8 we’ve had a plethora of new features like records, pattern matching, switch expressions, sealed types, foreign function and memory API, virtual threads, structured concurrency, Cleaner API, VarHandles, stream gatherers and more. Legacy stuff is also being deprecated and removed such as finalizers, SecurityManager, Unsafe memory access functions, 32bit support, Applets, Nashorn etc. Java is evolving at a rate that it’s never done before and Valhalla will be the biggest change it’s ever seen.
@@Sm0keySa1m0n Java still evolving in a slow pace, some jeps still needs several versions, iterations or years to be finished or to be considered production ready. Also just a few of them have a direct impact in the developer quality of life when you compare to other languages or newer languages ... The JVM is an amazing piece of software, but it´s showing it's age in the modern software development environment, corporate and legacy compatibility are things that really holds back the evolution of the whole platform ... The developers and the architects of the JVM and language also do an amazing working inside their constraints, but I see a lack of direction, they seem to be shooting in every possible direction in the hope of hitting something that will really cause a significant breakthrough ... I also see a lack of execution, almost all Java presentations are just a slide show with lots texts and a lack of code examples and real world use case application or impacts ... just my thoughts ...
@@RicardoSilvaTripcall Java is taking its time to deliver features that are well-designed and thought-through. Languages that push out features as fast as possible end up cluttered and incoherent, C# is a prime example. Preview features enable developer feedback to be considered and design changes to be made accordingly, hence usually taking multiple iterations to complete, I don't see how this can be interpreted as a negative practice. I also completely disagree that there's no direction, the majority of the JEPs being delivered fit together to realize a grander vision, with one of the major examples being "data-oriented programming" which makes use of records, sealed types, pattern matching, and switch expressions. Valhalla itself is a bit of a roadblock as there's multiple features waiting upon its completion, but being such an enormous change to the language, it's only right that they take their time and do it properly. I also don't see how "legacy compatibility" is holding the language back, corporations hold themselves back by not staying up to date but Java itself is evolving just fine.
@@RicardoSilvaTripcall Yes, Java is evoling in a slow pace, that's correct, but that's a positive thing, not negative. I think the amount of changes that come to Java are more than enough. If you're developing a little project with a couple 10k lines it's not a problem to have new features, but - and that's where the cobol comparison kind of makes sense - if you have to maintain a couple million lines of code in a decades old project, you can't update that all to the newest features without a clear migration path and at least some legacy compatibility. Do I wish that some features of java would be depreacted and removed. Oh yes, totally. Would I hate it? Even more so, because I might get stuck on a java version because it's not feasable to migrate the project to that new java version.
I don't use Java but stumbled upon this talk, it was fantastic! Swift is probably my favourite language and it was really cool to hear you talk about how you came to a lot of the same conclusions they did. Of course the Swift team didn't have a 30 year legacy to contend with.
I'll be really interested to see the Java team's answer to generics and union types when the time comes.
Java has had generics since java 5 and union types since java 17
@@Mig440 Java doesn't have union types, except that exception handling works kinda like union types. Are you thinking of sealed interfaces? Because those require you to be writing the underlying types, which actual union types shouldn't.
@@ethanchapman1776 sealed types are nominal union types, which fits javas typesystem better than a purely structural union. C# is proposing adding structural union types
@@Mig440 It has had generics to since Java 5, yes. But Swift's generics are far more extensive and the speaker touched on some of the possible future evolutions of Java's generics in the talk.
Useful information! Feels like Valhalla is just around the corner now (maybe 2 years if we ask nicely?)
My only requests for Valhalla are:
1) if we offer certain guarantees in Java, I don’t think we should force the VM to make those guarantees in all situations as well. A general purpose VM is better for everyone!
2) The memory model of the program, at least at a high level, is inherent to the work of the programmer - hence I think we should have reliable control over things like secret boxing of large value objects (e.g. base it on an exact byte size and offer an annotation or compiler flag to fail at compile-time when a class or function exceeds that limit, etc.) Depending on the byte limit, this could be a *major* headache for game developers to track down.
3) Multi-threading is already a massive “abstraction leak” of how a program is supposed to work imo. If there’s a critical section error, then all bets are already off, no? So I would rather Range be a value class and multi-threading have slightly worse consequences for failure than the other way around. (Those multithreaded guys are smart anyway, they can handle it!)
In any case, thank you! I learned a lot from your talks that I’ll be applying to my own projects as well. Complexity is hard to deal with!
Where are my unsigned longs? 😢😂
Do you need that?
I like Rust's u/isize and u/i{number}, more explicit.
Looking at the slide at 20:22. Using "new" in a loop like that would require some habit changing, for sure. But it's nothing new (no pun intended): with Loom, people had to change their habits around pooling threads and otherwise treating them as a scarce resource.
Withers might save us. Those are methods that say "copy a record but with one field changed" so if we had them here, it would say "return withTotal(total+n)"
Yes, people get a little weirded out by the fact that `new` is not allocating a new heap node. But it is creating a new object, and "where does this object live" is a low-level detail that should not intrude into the programming model. (Further, if the creation expression was different between identity and value classes, we could not migrate an identity class to be a value class.)
So I'm guessing any attempt to get object identity will throw an exception when done on value class instances?
If so, I have this question: after changing obvious JRE classes to value objects, is there any estimate how much existing code will start failing because someone, somewhere, does synchronized() on an Integer? Obviously not much because it's probably a mistake, but it wasn't forbidden before as such.
Yes, that’s exactly what will happen, if the compiler can’t catch it then the runtime will throw an exception. And yes, any code synchronizing on new Integer() will break. But it’s not the first breaking change, e.g. any introduction of new default methods to existing interfaces breaks code that implements those interfaces with a method of same name and parameters but different return type but such cases are rare and they usually scan lots of existing open source code beforehand to estimate the impact.
25:22 nice
JEP me harder!
I'd be disappointed if we land in a place where "long" is not nullable but "complex" is. Seems like we shouldn't need to say "complex!" everywhere.
I think it's somewhat strange the language never got a text primitive
It has char
@@Ewig_Luftenglanz char is an unsigned integer you can interpret as a message of length 1... Not exactly a text primitive, but i'll grant it's pretty close.
I feel like this is so 'rust-like', but with a lot of burden rust doesn't need to bare.
Burdens like extreme run-time optimisation , binary portability, a vast ecosystem of libraries, totally automated memory management, full object orientation?
burdens are treasures at the same time. Look at the maven central repository
Switch to Kotlin
This isn’t primarily a Java vs. Kotlin problem. Every language targeting the JVM faces this problem (and will benefit from Valhalla).
Why does the presenter as if these problems were not already solved in C#?
The innovation was already done in that ecosystem. Java is just playing catch-up.
I'm not sure I agree. Personally, I'd consider solving a similar problem under a different set of constraints to still be innovation.
Because it's not the same problem, neither the same ecosystem, neither the same constraints.
c# solved many problems in ways java can't because at thise times C# was very small so it didn't had the same urgency as java to maintain backwards compatibility (generics are an excellent example)
Btw C# has still issues that are not being solved coz they can't break things now that they are big. Async2 it's an example of hiw they tried to bring an equivalent to vietual threads to C# and failed (at least this time, i am sure C# guys are gonna get back with something new)
Besides, what C# did to solve memory density is different, inC# you explicitly compress memory by using structs, in the jvm model is the jvm the one thst optimize memory Layout automatically.
Why are you watching a talk about Java then? Just use C#
Ignoring for a moment that Java cannot use C# solution (break every code in existence cause your ecosystem is small and you don't care - which *was* at the time an okay solution for C#, but not anymore) Brian Goetz highlighted all of the languages they took inspiration from. Maybe listen first next time, then try to throw shade at someone.
Java has basically becoming the new Cobol, little to no forward movement and an absolute focus on keeping legacy code bases around forever.
Except it’s the opposite of that, since Java 8 we’ve had a plethora of new features like records, pattern matching, switch expressions, sealed types, foreign function and memory API, virtual threads, structured concurrency, Cleaner API, VarHandles, stream gatherers and more. Legacy stuff is also being deprecated and removed such as finalizers, SecurityManager, Unsafe memory access functions, 32bit support, Applets, Nashorn etc. Java is evolving at a rate that it’s never done before and Valhalla will be the biggest change it’s ever seen.
Said the dude that clearly hasn't touched java in his life, nevermind newer versions)
@@Sm0keySa1m0n Java still evolving in a slow pace, some jeps still needs several versions, iterations or years to be finished or to be considered production ready. Also just a few of them have a direct impact in the developer quality of life when you compare to other languages or newer languages ... The JVM is an amazing piece of software, but it´s showing it's age in the modern software development environment, corporate and legacy compatibility are things that really holds back the evolution of the whole platform ... The developers and the architects of the JVM and language also do an amazing working inside their constraints, but I see a lack of direction, they seem to be shooting in every possible direction in the hope of hitting something that will really cause a significant breakthrough ... I also see a lack of execution, almost all Java presentations are just a slide show with lots texts and a lack of code examples and real world use case application or impacts ... just my thoughts ...
@@RicardoSilvaTripcall Java is taking its time to deliver features that are well-designed and thought-through. Languages that push out features as fast as possible end up cluttered and incoherent, C# is a prime example. Preview features enable developer feedback to be considered and design changes to be made accordingly, hence usually taking multiple iterations to complete, I don't see how this can be interpreted as a negative practice.
I also completely disagree that there's no direction, the majority of the JEPs being delivered fit together to realize a grander vision, with one of the major examples being "data-oriented programming" which makes use of records, sealed types, pattern matching, and switch expressions. Valhalla itself is a bit of a roadblock as there's multiple features waiting upon its completion, but being such an enormous change to the language, it's only right that they take their time and do it properly.
I also don't see how "legacy compatibility" is holding the language back, corporations hold themselves back by not staying up to date but Java itself is evolving just fine.
@@RicardoSilvaTripcall Yes, Java is evoling in a slow pace, that's correct, but that's a positive thing, not negative. I think the amount of changes that come to Java are more than enough. If you're developing a little project with a couple 10k lines it's not a problem to have new features, but - and that's where the cobol comparison kind of makes sense - if you have to maintain a couple million lines of code in a decades old project, you can't update that all to the newest features without a clear migration path and at least some legacy compatibility.
Do I wish that some features of java would be depreacted and removed. Oh yes, totally. Would I hate it? Even more so, because I might get stuck on a java version because it's not feasable to migrate the project to that new java version.