5 ms·

> Tradeoffs like this are painful, but they make for a better language. Not to mention, for faster long term progress. Don't think like Java is a good example

by marwis 3y ago

> Tradeoffs like this are painful, but they make for a better language. Not to mention, for faster long term progress. Don't think like Java is a good example of that, more like the anti-example. Plenty of more sophisticated languages move way faster without negative effects on long term progress (C#, Kotlin, to some extent Scala) > A well designed feature becomes easy to extend. A poorly designed one is easy to extend initially, but becomes far more difficult in the long run. Most of Java problems come down to unfortunate design choices in the past. E.g. checked exceptions vs lambdas

pjmlp 3y ago
I dearly miss checked exceptions in C#, it is like tracking land mines, when fixing code from others that happily decided to ignore exceptions that then blow up in production. Also moving fast and breaking things newly adopted .NET culture is the reason I am mostly stuck on .NET Framework for corporate production apps, unless we're doing newly written microservices, and some big names like Sitecore decided it was easier to buy products written in other languages than rewrite their stuff into .NET Core.
- marwis 3y ago
  In theory exceptions can be easily found with static analysis. I suppose lack of such tools (and failure of code contracts which I think could've verified it statically) means that vast majority of people are happy with status quo. Just an idea - maybe you can use CodeQL? The transition to .NET core is indeed rather painful but it's just Microsoft's choice. Things were dropped/backwards compatibility broken mostly to simplify runtime but I saw nothing that couldn't have been emulated with some modest effort. Also they could've easily softened the transition by continuing development of .NET Standard a bit longer and allowing side by side hosting of 4.x and Core in same process as that seemed to be the plan in the beginning. I guess they don't care.
  - neonsunset 3y ago
    Both this and parent comments are so...strange. If you had any significant experience working with post-"Framework" .NET, you would know that the features that got deprecated were unsound, carried significant performance and complexity cost hindering the efforts towards further platform evolution. And most actually important use cases saw appropriate dev work to provide polyfills and shim packages to provide the path for migration. .NET Standard existed and still exists as a bridge for .NET Framework and "odd" platforms like UWP (effectively dead), Unity and maybe a couple of others - you never know! Fortunately it slowly but surely fades into obscurity as all the actively developed platforms are converging around pure 'net6+'-based TFMs. Special note regarding "being stuck with .NET Framework" - this may be true for some enterprise scenarios but I have grown to adopt a mental model of considering opinions like these as nonsensical or deeply out of touch with reality as much more useful way of dealing with audience that still lives in this camp. It is not worth entertaining, nor it is reasonable to respond to "move fast and break things" criticism after all these years - some people just have a bone to pick, for the pace is "moderate" and there are no changes made like in the early days of .NET Core 1.x and 2.x when the platform's fate was uncertain.
    - marwis 3y ago
      Do you consider in-box PowerShell and MS Office to be rare enterprise/nonsensical scenarios? Or how about C# Source Generators that were introduced just few years ago and are stuck on .NET Standard 2.0 because of Visual Studio using .NET framework? There is a lot of actively developed software out there either built in .NET or using it to provide extensibility that is now stuck as you can't add support for .NET Core without breaking all existing plugins. The only alternative is complete redesign with out-of-process architecture which is not going to be compatible and might be inappropriate in some scenarios.
davidalayachew 3y ago
> Most of Java problems come down to unfortunate design choices in the past. E.g. checked exceptions vs lambdas Funnily enough, your example has actually supported my point. They just released a proposal that effectively side-steps the problem of checked-exceptions-in-lambdas. Here is a link -- https://inside.java/2023/12/15/switch-case-effect/ https://inside.java/2023/12/15/switch-case-effect/ This is still just a proposal, so nothing is hammered out. And we can talk about the merits of this solution. But my point is, by focusing on designing features the way they have, you can minimize intrusion while maximizing the value provided. I think this proposal demonstrates that extremely well. This proposal allows the developer to maintain all the good parts about checked exceptions and lambdas, while being able to side-step the major downside. > Don't think like Java is a good example of that, more like the anti-example. Plenty of more sophisticated languages move way faster without negative effects on long term progress (C#, Kotlin, to some extent Scala) To be clear, when I say long term, I am measuring on the scale of decades. In that respect, I actually don't think your statement is correct. To give an example with Kotlin, someone (I think Brian) talked about Kotlin's release strategy for features being great for short term, but costly in the long term. Kotlin had record-esque classes long before Java ever got theirs, but now that Java finally has theirs, Kotlin is using an annotation to disambiguate between Java style records and Kotlin style records -- https://kotlinlang.org/docs/jvm-records.html#declare-records-in-kotlin https://kotlinlang.org/docs/jvm-records.html#declare-records.... While this isn't some critical problem on its own, this type of rift growing wider means that Kotlin is going to have to wrestle with how much they want to allow Java representation of concepts to exist in Kotlin. For example, how will Kotlin handle Java's version of pattern-matching vs their own? The 2 are not the same, so you cannot just call them aliases of each other - they have different semantics. To give another example with C#, there has been a lot of recent discussion about finding potential alternatives to their async-await concurrency model. They cite the level of effort it takes to maintain the async await style code and the costs that come from this. Rust had a similar conversation not too long ago too. The point I am trying to say is that, I think Java's strategy of play it slow and conservative is actually paying off for them, but on the scale of decades. Some of the languages it gets compared too aren't even that old yet.
- marwis 3y ago

by marwis 3y ago

pjmlp 3y ago

I dearly miss checked exceptions in C#, it is like tracking land mines, when fixing code from others that happily decided to ignore exceptions that then blow up in production. Also moving fast and breaking things newly adopted .NET culture is the reason I am mostly stuck on .NET Framework for corporate production apps, unless we're doing newly written microservices, and some big names like Sitecore decided it was easier to buy products written in other languages than rewrite their stuff into .NET Core.

marwis 3y ago
In theory exceptions can be easily found with static analysis. I suppose lack of such tools (and failure of code contracts which I think could've verified it statically) means that vast majority of people are happy with status quo. Just an idea - maybe you can use CodeQL? The transition to .NET core is indeed rather painful but it's just Microsoft's choice. Things were dropped/backwards compatibility broken mostly to simplify runtime but I saw nothing that couldn't have been emulated with some modest effort. Also they could've easily softened the transition by continuing development of .NET Standard a bit longer and allowing side by side hosting of 4.x and Core in same process as that seemed to be the plan in the beginning. I guess they don't care.
- neonsunset 3y ago
  Both this and parent comments are so...strange. If you had any significant experience working with post-"Framework" .NET, you would know that the features that got deprecated were unsound, carried significant performance and complexity cost hindering the efforts towards further platform evolution. And most actually important use cases saw appropriate dev work to provide polyfills and shim packages to provide the path for migration. .NET Standard existed and still exists as a bridge for .NET Framework and "odd" platforms like UWP (effectively dead), Unity and maybe a couple of others - you never know! Fortunately it slowly but surely fades into obscurity as all the actively developed platforms are converging around pure 'net6+'-based TFMs. Special note regarding "being stuck with .NET Framework" - this may be true for some enterprise scenarios but I have grown to adopt a mental model of considering opinions like these as nonsensical or deeply out of touch with reality as much more useful way of dealing with audience that still lives in this camp. It is not worth entertaining, nor it is reasonable to respond to "move fast and break things" criticism after all these years - some people just have a bone to pick, for the pace is "moderate" and there are no changes made like in the early days of .NET Core 1.x and 2.x when the platform's fate was uncertain.
  - marwis 3y ago
    Do you consider in-box PowerShell and MS Office to be rare enterprise/nonsensical scenarios? Or how about C# Source Generators that were introduced just few years ago and are stuck on .NET Standard 2.0 because of Visual Studio using .NET framework? There is a lot of actively developed software out there either built in .NET or using it to provide extensibility that is now stuck as you can't add support for .NET Core without breaking all existing plugins. The only alternative is complete redesign with out-of-process architecture which is not going to be compatible and might be inappropriate in some scenarios.

davidalayachew 3y ago

> Most of Java problems come down to unfortunate design choices in the past. E.g. checked exceptions vs lambdas Funnily enough, your example has actually supported my point. They just released a proposal that effectively side-steps the problem of checked-exceptions-in-lambdas. Here is a link -- https://inside.java/2023/12/15/switch-case-effect/ https://inside.java/2023/12/15/switch-case-effect/ This is still just a proposal, so nothing is hammered out. And we can talk about the merits of this solution. But my point is, by focusing on designing features the way they have, you can minimize intrusion while maximizing the value provided. I think this proposal demonstrates that extremely well. This proposal allows the developer to maintain all the good parts about checked exceptions and lambdas, while being able to side-step the major downside. > Don't think like Java is a good example of that, more like the anti-example. Plenty of more sophisticated languages move way faster without negative effects on long term progress (C#, Kotlin, to some extent Scala) To be clear, when I say long term, I am measuring on the scale of decades. In that respect, I actually don't think your statement is correct. To give an example with Kotlin, someone (I think Brian) talked about Kotlin's release strategy for features being great for short term, but costly in the long term. Kotlin had record-esque classes long before Java ever got theirs, but now that Java finally has theirs, Kotlin is using an annotation to disambiguate between Java style records and Kotlin style records -- https://kotlinlang.org/docs/jvm-records.html#declare-records-in-kotlin https://kotlinlang.org/docs/jvm-records.html#declare-records.... While this isn't some critical problem on its own, this type of rift growing wider means that Kotlin is going to have to wrestle with how much they want to allow Java representation of concepts to exist in Kotlin. For example, how will Kotlin handle Java's version of pattern-matching vs their own? The 2 are not the same, so you cannot just call them aliases of each other - they have different semantics. To give another example with C#, there has been a lot of recent discussion about finding potential alternatives to their async-await concurrency model. They cite the level of effort it takes to maintain the async await style code and the costs that come from this. Rust had a similar conversation not too long ago too. The point I am trying to say is that, I think Java's strategy of play it slow and conservative is actually paying off for them, but on the scale of decades. Some of the languages it gets compared too aren't even that old yet.

marwis 3y ago