5 ms·

The problem with this approach is that in the mean time the people will have to adopt crutches like https://github.com/Randgalt/record-builder https://github.co

by marwis 3y ago

The problem with this approach is that in the mean time the people will have to adopt crutches like https://github.com/Randgalt/record-builder https://github.com/Randgalt/record-builder and by the time Java adds missing features all the codebases will be forever polluted with legacy workarounds that nobody will dare to remove because of backwards compatibility. It also hinders adoption of new features as people will prefer to maintain consistency in their codebases.

pjmlp 3y ago
Some people, I never liked such kind of crutches. Stuff like Lombok are persona non grata when coding in Java, other than when imposed on us via 3rd parties without alternatives.
- marwis 3y ago
  Well this isn't really like Lombok since it doesn't hack compiler internals but just generates some code using very standard annotation processor. The alternative is to write this code by hand which isn't any better.
davidalayachew 3y ago
I think you have correctly identified the cost of aiming for long term, evergreen success -- you must sacrifice short term gain to get it. Yes, because records are still slowly being improved, it means that people will put together workarounds and temporary solutions so that they can get their desired feature as soon as possible. It also means that some will just throw up their hands in frustration and say "It's half-baked!", then disregard the feature entirely. It's a tradeoff that the Java team considers on a regular basis. It was a similar tradeoff that led to them releasing Virtual Threads before they had a solution implemented for the pinning problem. That one wasn't so much that they needed feedback before they could fix the problem, but moreso that they didn't want to miss out on potential feedback while they were fixing the pinning problem. So, they released VT with this (temporary) deficiency, and they are working on it now while gathering as much insight as possible into how VT's are being used across the ecosystem. Tradeoffs like this are painful, but they make for a better language. Not to mention, for faster long term progress. 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.
- 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.

by marwis 3y ago

pjmlp 3y ago

Some people, I never liked such kind of crutches. Stuff like Lombok are persona non grata when coding in Java, other than when imposed on us via 3rd parties without alternatives.

marwis 3y ago
Well this isn't really like Lombok since it doesn't hack compiler internals but just generates some code using very standard annotation processor. The alternative is to write this code by hand which isn't any better.

davidalayachew 3y ago

I think you have correctly identified the cost of aiming for long term, evergreen success -- you must sacrifice short term gain to get it. Yes, because records are still slowly being improved, it means that people will put together workarounds and temporary solutions so that they can get their desired feature as soon as possible. It also means that some will just throw up their hands in frustration and say "It's half-baked!", then disregard the feature entirely. It's a tradeoff that the Java team considers on a regular basis. It was a similar tradeoff that led to them releasing Virtual Threads before they had a solution implemented for the pinning problem. That one wasn't so much that they needed feedback before they could fix the problem, but moreso that they didn't want to miss out on potential feedback while they were fixing the pinning problem. So, they released VT with this (temporary) deficiency, and they are working on it now while gathering as much insight as possible into how VT's are being used across the ecosystem. Tradeoffs like this are painful, but they make for a better language. Not to mention, for faster long term progress. 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.

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.