4 ms·

Yep, all true. These days Java isn't slow to develop on at all. There are plenty of very good frameworks where you can get going with developing a web app or r

Yep, all true. These days Java isn't slow to develop on at all. There are plenty of very good frameworks where you can get going with developing a web app or rest service in next to no time with far better tooling support, sophistication etc. .NET is a serious contender though. Node isn't really on the same ballpark in terms of maturity.

ShadowBanThis01 3y ago
Not to mention that Node isn't a language, and Deno is cleaner.
- pkphilip 3y ago
  I was referring to Java as a platform rather than just as a language. .NET isn't a language either
  - ShadowBanThis01 3y ago
    Indeed, but I only wanted to include so much pedantry!
DeathArrow 3y ago
>.NET is a serious contender though. It the other way around. Java has barely caught up with C#. C# team is typically introducing more features, faster.
- royjacobs 3y ago
  I'm not sure language design should be a race to see who can add the most features, though. I prefer Java's more thoughtful approach to introducing new features.
  - keithnz 3y ago
    in what way do you think it's more thoughtful than C#?
    - za3faran 3y ago
      No OP, but for example you still see the C# folks still struggling to add discriminated unions to the language because of complex interactions due to its too many features[1]. Virtual threads are easier to use than async/await is another example. [1] https://github.com/dotnet/csharplang/issues/113 https://github.com/dotnet/csharplang/issues/113
      - neonsunset 3y ago
        Performant implementation of discriminated unions in .NET (unlike any that you would see in JVM) requires modification of both the type system and the runtime to account for non-boxing representation of struct unions as well as unions in which GC references alias value types/structs. This is highly non-trivial and the people who could be working on this are currently busy with other features namely Rust-like traits called explicit and implicit extensions. Don't forget that .NET is worked on by at least 10x smaller community and teams than JVM implementations and yet delivers much better YoY degree of improvement and much nicer user experience (Gradle lol). In addition, green threads approach is a strictly worse and a more limited solution that only solves thread blocking without unlocking the variety of terse concurrency patterns enabled by the way the tasks are handled in .NET. They also add significant overhead to interop with native code due to thread pinning/stack switching (also applies to Go).

ShadowBanThis01 3y ago

Not to mention that Node isn't a language, and Deno is cleaner.

pkphilip 3y ago
I was referring to Java as a platform rather than just as a language. .NET isn't a language either
- ShadowBanThis01 3y ago
  Indeed, but I only wanted to include so much pedantry!

DeathArrow 3y ago

>.NET is a serious contender though. It the other way around. Java has barely caught up with C#. C# team is typically introducing more features, faster.

royjacobs 3y ago
I'm not sure language design should be a race to see who can add the most features, though. I prefer Java's more thoughtful approach to introducing new features.
- keithnz 3y ago
  in what way do you think it's more thoughtful than C#?
  - za3faran 3y ago
    No OP, but for example you still see the C# folks still struggling to add discriminated unions to the language because of complex interactions due to its too many features[1]. Virtual threads are easier to use than async/await is another example. [1] https://github.com/dotnet/csharplang/issues/113 https://github.com/dotnet/csharplang/issues/113
    - neonsunset 3y ago
      Performant implementation of discriminated unions in .NET (unlike any that you would see in JVM) requires modification of both the type system and the runtime to account for non-boxing representation of struct unions as well as unions in which GC references alias value types/structs. This is highly non-trivial and the people who could be working on this are currently busy with other features namely Rust-like traits called explicit and implicit extensions. Don't forget that .NET is worked on by at least 10x smaller community and teams than JVM implementations and yet delivers much better YoY degree of improvement and much nicer user experience (Gradle lol). In addition, green threads approach is a strictly worse and a more limited solution that only solves thread blocking without unlocking the variety of terse concurrency patterns enabled by the way the tasks are handled in .NET. They also add significant overhead to interop with native code due to thread pinning/stack switching (also applies to Go).