3 ms·

>That's just such a Java thing to do. "Oh we failed to design the perfect solution, so we are not going to change anything until we find that perfect solution."

by agilob 2y ago

>That's just such a Java thing to do. "Oh we failed to design the perfect solution, so we are not going to change anything until we find that perfect solution." That's not true at all. In the last years there were lots of features that were introduced, later disabled, enabled and then disabled again because they were causing smaller or bigger issues. There was a major work on metaspace tuning (guard allocations) that went in, stayed in for 2 or 3 versions then was removed. AVX features were enabled and disabled multiple time because companies where getting wrong results or crashes. It's a fair game to remove something you as a developer don't consider ready. Just think how much garbage your team or company have shipped that wasn't ready, you had to patch under pressure or explain to users that it's not really working as described by marketing team and users should stick to old ways for a few more months.

klauserc 2y ago
Totally agree about the "removing a misbehaving" feature part. The frustration I was trying to express is more related to "perfect being the enemy of good". JEP-430 was introduced 3 years ago. By that point C# has already had string interpolation in place for 6 years and the C# solution achieves 90% of what JEP-430 set out to do. Java users could have benefited from 90% of that feature for 9 years by now. It sounds a bit dramatic when we are talking about string interpolation, I realize that.
neonsunset 2y ago
> AVX features There is also a proof that they can be shipped for a complex runtime without such level of pain: added back in .NET Core 3.0[0] and there were relatively few AVX-related bugs in the compiler since then and all of them were fixed in servicing (patch) releases upon discovery, without deprecation. [0]: https://learn.microsoft.com/en-us/dotnet/api/system.runtime.intrinsics.x86.avx2 https://learn.microsoft.com/en-us/dotnet/api/system.runtime....
- kaba0 2y ago
  I mean, AVX was buggy itself in plenty of hardware for a very long time, it’s not only on the software side.
  - neonsunset 2y ago
    Do you know which CPU cores was it buggy in for a very long time? The ones that everyone uses had flawless support for more than a decade. In either case, I don't see how that disproves the argument that support of hardware features like AVX in a runtime comparable to JVM can be done well. (though I'm biased to say low-level features are a weak point of JVM and a strong point of .NET, you don't have to sacrifice high-level convenience in other areas to get that)

by agilob 2y ago

klauserc 2y ago

Totally agree about the "removing a misbehaving" feature part. The frustration I was trying to express is more related to "perfect being the enemy of good". JEP-430 was introduced 3 years ago. By that point C# has already had string interpolation in place for 6 years and the C# solution achieves 90% of what JEP-430 set out to do. Java users could have benefited from 90% of that feature for 9 years by now. It sounds a bit dramatic when we are talking about string interpolation, I realize that.

neonsunset 2y ago

> AVX features There is also a proof that they can be shipped for a complex runtime without such level of pain: added back in .NET Core 3.0[0] and there were relatively few AVX-related bugs in the compiler since then and all of them were fixed in servicing (patch) releases upon discovery, without deprecation. [0]: https://learn.microsoft.com/en-us/dotnet/api/system.runtime.intrinsics.x86.avx2 https://learn.microsoft.com/en-us/dotnet/api/system.runtime....

kaba0 2y ago
I mean, AVX was buggy itself in plenty of hardware for a very long time, it’s not only on the software side.
- neonsunset 2y ago
  Do you know which CPU cores was it buggy in for a very long time? The ones that everyone uses had flawless support for more than a decade. In either case, I don't see how that disproves the argument that support of hardware features like AVX in a runtime comparable to JVM can be done well. (though I'm biased to say low-level features are a weak point of JVM and a strong point of .NET, you don't have to sacrifice high-level convenience in other areas to get that)