I would love to work with someone who can explain complex low-level problems so accessibly and move from the big picture to the details and back with ease as Mr. Brian Goetz does! It would've make my developer career so much easier and enjoyable.
There seems to be a pattern here. Brian's talks tend to have dull and somewhat uninteresting titles, but then turn out to be chock full of extremely well explained software engineering wisdom.
Gawd, I can't help but think how I wish to just for once work on something where I can iterate many times to get it right, instead of the usual "ship the proof of concept" approach.
And after shopping poc, just fix all the bugs before the next release, and keep in mind that we are going to connect new partners already the next month.
I like how the Java ecosystem is clearing up the technical debt. JVM languages have come and gone, Java has borrowed some of their best parts and made itself better. JDK 21 onwards, Java's future looks bright. Next I would like to see is a culture of less verbosity in code. This is as much a function of coding culture in Java community as much it is about language support.
The lambda builder stuff seems like a solution in search of a problem. All you're doing there is filling in a buffer and passing it to the "assembler". The builder doesn't really seem at add anything. Sure you can then run the lambda twice, but if you'd just stuck with a buffer you wouldn't have to run all that code twice.
cool api. since they designed everything from scratch I find it a bit odd that they have slots as int instead of properly exposing a record type (e.g., SlotId) so you can't accidentally pass an int from elsewhere. It's not like you'd need to do arithmetic on slot ids (if you use the api to create them)
I would guess the tradeoff is avoiding allocations of trivial types at the expense of some safety. Valhalla may have made it redundant but delaying the API for when Valhalla eventually lands would not have been acceptable. To me it seems they still went with the best choice they had.
I would love to work with someone who can explain complex low-level problems so accessibly and move from the big picture to the details and back with ease as Mr. Brian Goetz does! It would've make my developer career so much easier and enjoyable.
14:00 Best explanation of how Inversion of Control really works
There seems to be a pattern here. Brian's talks tend to have dull and somewhat uninteresting titles, but then turn out to be chock full of extremely well explained software engineering wisdom.
At19:08, eliminating magic numbers for slots makes the code so much clearer. At 21:40 is the wisdom take-away. I'm excited for this.
i'm a simple man. i see brian goetz, i click
Gawd, I can't help but think how I wish to just for once work on something where I can iterate many times to get it right, instead of the usual "ship the proof of concept" approach.
And after shopping poc, just fix all the bugs before the next release, and keep in mind that we are going to connect new partners already the next month.
We must be working for the same company. Actually, pretty much all the companies I've worked for.
"They took away your IDE like 7 years ago" and what comes afterwards: Even a proper. good sense of human. Great session, thank you!
Great improvements
Really looking forward to testing that!
Will the code generation also be a part of the project? I see the mention of "write" there in JEP summary =)
I like how the Java ecosystem is clearing up the technical debt. JVM languages have come and gone, Java has borrowed some of their best parts and made itself better. JDK 21 onwards, Java's future looks bright. Next I would like to see is a culture of less verbosity in code. This is as much a function of coding culture in Java community as much it is about language support.
Verbosity is fine. It's layered the way it is for a reason so you could swap out the layers.
Verbosity should not be reduced. Just use ide
It would be strange if you did not have a strict model in the API for something that obviously had a strict model.
Great presentation! Can't help to think how interesting would be to see this API usage in Kotlin.
The lambda builder stuff seems like a solution in search of a problem. All you're doing there is filling in a buffer and passing it to the "assembler". The builder doesn't really seem at add anything. Sure you can then run the lambda twice, but if you'd just stuck with a buffer you wouldn't have to run all that code twice.
cool api. since they designed everything from scratch I find it a bit odd that they have slots as int instead of properly exposing a record type (e.g., SlotId) so you can't accidentally pass an int from elsewhere. It's not like you'd need to do arithmetic on slot ids (if you use the api to create them)
I would guess the tradeoff is avoiding allocations of trivial types at the expense of some safety. Valhalla may have made it redundant but delaying the API for when Valhalla eventually lands would not have been acceptable. To me it seems they still went with the best choice they had.
looks like llvm … … 👍👍👍