3 ms·

> Since we discuss C# here, it is a good jack of all trades language where you can do almost anything, with decent performance, low boilerplate. That's basical

by Ygg2 2y ago

> Since we discuss C# here, it is a good jack of all trades language where you can do almost anything, with decent performance, low boilerplate. That's basically modern-day Java, with Lombok and other tidbits. Furthermore, if I recall correctly, Java has better performance on web benchmarks than C#. > Had Java been better, Kotlin wouldn't need to be invented. Kotlin was invented to make a sugary version of Java, and thus drive more JetBrains sales. It got popular because Oracle got litigious. As someone who's been on the Java train for almost two decades, what usually happens, if any JVM Lang becomes too popular, Java has the tendency to reintegrate its features into itself. > Whatever you like, find fun and makes you a productive and happy developer. There is nothing wrong in using C or C++. Or Python. Or Haskell. Sure, assuming it fits the domain. Like, don't use Python for kernel dev or Java for some obscure ML/AI when you could use Python.

Kipters 2y ago
> That's basically modern-day Java, with Lombok and other tidbits. I wouldn't call Lombok "modern", more like "a terrifyingly hacky way to tackle limitations in the language despite the unwillingness to make the language friendlier" and a far cry from what source generators can do in C#
- xxs 2y ago
  Getters and setters are a mediocre design choice, not a limitation. Records have existed for years, too.
  - e3bc54b2 2y ago
    > Records have existed for years As a fan of Records, this is a punch to the gut. The ecosystem is years and years away from using records. Almost every huge monolith decade+ project is still on Java 8, those who moved to something new still can't be liberal with them, because oh look, none of the serialize/deserialize libs can work with them because everything, to this day, abuses reflection for generating objects like a giant fucking hack it is. Apology for the rant, but I migrated a big project to 21 early this year, am in the middle of migrating another 1M+ line codebase to 21, and the sorry state of records is such a sad thing to witness. I give a decade before records are anything but 'a fancy feature'.
    - deleted 2y ago
      [deleted]
    - xxs 2y ago
      It's a fair point of stuck w/ java8, yet the reference was about "modern java". With that said - lombok is not needed at any form there either, use a c-tor with fields and make the public final. If you have too many fields in a class, it's likely a good idea to split it regardless. In all cases dumb getter/setters are just public fields but taking more meta space (and larger byte code, the latter has some consideration when it comes to inlining) Also, if I had 1M LOC and my serialization/communication libraries didn't support whatever I've picked - I'd patch the libraries to support it.
      - e3bc54b2 2y ago
        > It's a fair point of stuck w/ java8, yet the reference was about "modern java". And I'm saying that even after writing the most of the first project (closing in on 100kLOC now) in 21, I still can't have records where the make the most sense (service boundaries) because libs and larger ecosystem don't support them. > Also, if I had 1M LOC and my serialization/communication libraries didn't support whatever I've picked - I'd patch the libraries to support it. 1MLOC in java land is.. not unusual. And if you're talking about patching libs like jackson/jaxb/whatever, my good person, you truly underestimate how much actual work people have (where Java upgrade is a distant afterthought, I only did it because I wanted to scratch the itch and see how far I could push processes in my org), or how much impact that might have for a drive-by contribution. Updating such core ecosystem libs in java is no small feat. They are used absolutely everywhere, and even tiny changes require big testing. There is a reason you find apache libs in every single project, because they have matured over past couple of decades without such drastic rug-pull of a change.
        xxs 2y ago
        I did say all that (incl the 1M+) stuff coming from personal experience. I have "fixed" all kind of libraries (incl. database drivers, JDK itself, PKI cert loading, netty/jetty, ORM providers). I'd consider jaxb/jackson on the easy side of things. Also I'd actively remove all apache commons as well. Even in Java8 most of the functionality is redundant. With all that I meant it should not be really underestimation.
- Ygg2 2y ago
  Hack or not, it's been working relatively well for the past decade. But even, if you account for that, the records in Java do most of what Lombok used to do - make class externally immutable, add default `toString`, `equals` and `hashCode` implementations, allow read-only access to fields. > what source generators can do in C# Having had the displeasure of developing source generators in C# (in Rider), what they do is make code impossible to debug while working on it. On top of relying on an ancient version of netstandard. I cannot emphasize enough how eldritch working on them is. While developing, whatever change you write isn't reflected when you inspect codegen code, and caching can keep old code beyond even post re-compilation unless you restart the build server, or something. So whenever you try to debug your codegen libs, you toss a coin: - heads it shows correct code - tails it's showing previously iteration of code gen code, but the new code is in, so the debugger will at some point get confused - medusae it's showing previous iteration of code gen code, but new code hasn't been propagated, and you need to do some arcane rituals to make it work. Hell, even as a user of codegen libs, updating codegen libs caused miscompilation because it was still caching the previous codegen version.
  - Kwpolska 2y ago
    > relying on an ancient version of netstandard They require 2.0, which is the only version that is actually useful, since it supports .NET Framework 4.x.v
    - Ygg2 2y ago
      You do realize netstandard 2.0 is 7 years old right? That it misses a ton of functionality compared to current dotnet. Stuff like MaybeNull annotation .
      - Kwpolska 2y ago
        It misses a ton of functionality compared to the current .NET (Core), but it does not miss much compared to .NET Framework 4.8. The reason why source generators require it is because they may be run by Visual Studio, which is built on top of the classic .NET Framework. .NET Standard 2.0 is a good trade-off IMO if you need to support both the classic Framework and the modern .NET.
DeathArrow 2y ago
> benchmarks https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/csharp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- Ygg2 2y ago
  Ahem. > web benchmarks https://www.techempower.com/benchmarks/#hw=ph&test=composite&section=data-r22 https://www.techempower.com/benchmarks/#hw=ph&test=composite...
  - EraYaN 2y ago
    Those are notoriously cheat-y for just about all languages on that list. Any actual project is never going to get close to the efficiency that those number would require. Both Java and .NET over promise by A LOT with the numbers they get there.
    - Ygg2 2y ago
      Cheat-y in what way? I don't consider micro benchmarks that interesting especially since C# does have two aces that Java will get in mid term - namely Simd and primitive types. The Tech Empower benchmarks do seem to reflect general state of Java Web Framework ecosystem with Vert.x being they hyper fast web framework and Spring being way slower.
      - EraYaN 2y ago
        Well the amount of tricks that basically nobody can implement in production that those implementations do to get the numbers that they do is ridiculous. Meaning the numbers they get are wildly optimistic at best and misleading at worst. If you take the standard template for any of these frameworks (both Java and C# and any other language) and you add authentication etc, the real performance will be 5-10% of the numbers reported in those benchmarks. Have a look through some of the weirdness in the implementations it's wild (and sometimes educational). The .NET team especially has done stuff specifically to get faster on those benchmarks.
xxs 2y ago
>That's basically modern-day Java, with Lombok and other tidbits. Lombok is exceptionally backwards. You don't need getters/setters; and you should know how to try hashCode (and equals). ...and records exist
- Ygg2 2y ago
  The last few Spring projects I worked on that used the latest Java, still used Lombok. Records do exist, but you can't or don't want to always use them.

by Ygg2 2y ago

Kipters 2y ago

> That's basically modern-day Java, with Lombok and other tidbits. I wouldn't call Lombok "modern", more like "a terrifyingly hacky way to tackle limitations in the language despite the unwillingness to make the language friendlier" and a far cry from what source generators can do in C#

xxs 2y ago
Getters and setters are a mediocre design choice, not a limitation. Records have existed for years, too.
- e3bc54b2 2y ago
  > Records have existed for years As a fan of Records, this is a punch to the gut. The ecosystem is years and years away from using records. Almost every huge monolith decade+ project is still on Java 8, those who moved to something new still can't be liberal with them, because oh look, none of the serialize/deserialize libs can work with them because everything, to this day, abuses reflection for generating objects like a giant fucking hack it is. Apology for the rant, but I migrated a big project to 21 early this year, am in the middle of migrating another 1M+ line codebase to 21, and the sorry state of records is such a sad thing to witness. I give a decade before records are anything but 'a fancy feature'.
  - deleted 2y ago
    [deleted]
  - xxs 2y ago
    It's a fair point of stuck w/ java8, yet the reference was about "modern java". With that said - lombok is not needed at any form there either, use a c-tor with fields and make the public final. If you have too many fields in a class, it's likely a good idea to split it regardless. In all cases dumb getter/setters are just public fields but taking more meta space (and larger byte code, the latter has some consideration when it comes to inlining) Also, if I had 1M LOC and my serialization/communication libraries didn't support whatever I've picked - I'd patch the libraries to support it.
    - e3bc54b2 2y ago
      > It's a fair point of stuck w/ java8, yet the reference was about "modern java". And I'm saying that even after writing the most of the first project (closing in on 100kLOC now) in 21, I still can't have records where the make the most sense (service boundaries) because libs and larger ecosystem don't support them. > Also, if I had 1M LOC and my serialization/communication libraries didn't support whatever I've picked - I'd patch the libraries to support it. 1MLOC in java land is.. not unusual. And if you're talking about patching libs like jackson/jaxb/whatever, my good person, you truly underestimate how much actual work people have (where Java upgrade is a distant afterthought, I only did it because I wanted to scratch the itch and see how far I could push processes in my org), or how much impact that might have for a drive-by contribution. Updating such core ecosystem libs in java is no small feat. They are used absolutely everywhere, and even tiny changes require big testing. There is a reason you find apache libs in every single project, because they have matured over past couple of decades without such drastic rug-pull of a change.
      - xxs 2y ago
        I did say all that (incl the 1M+) stuff coming from personal experience. I have "fixed" all kind of libraries (incl. database drivers, JDK itself, PKI cert loading, netty/jetty, ORM providers). I'd consider jaxb/jackson on the easy side of things. Also I'd actively remove all apache commons as well. Even in Java8 most of the functionality is redundant. With all that I meant it should not be really underestimation.
Ygg2 2y ago
Hack or not, it's been working relatively well for the past decade. But even, if you account for that, the records in Java do most of what Lombok used to do - make class externally immutable, add default `toString`, `equals` and `hashCode` implementations, allow read-only access to fields. > what source generators can do in C# Having had the displeasure of developing source generators in C# (in Rider), what they do is make code impossible to debug while working on it. On top of relying on an ancient version of netstandard. I cannot emphasize enough how eldritch working on them is. While developing, whatever change you write isn't reflected when you inspect codegen code, and caching can keep old code beyond even post re-compilation unless you restart the build server, or something. So whenever you try to debug your codegen libs, you toss a coin: - heads it shows correct code - tails it's showing previously iteration of code gen code, but the new code is in, so the debugger will at some point get confused - medusae it's showing previous iteration of code gen code, but new code hasn't been propagated, and you need to do some arcane rituals to make it work. Hell, even as a user of codegen libs, updating codegen libs caused miscompilation because it was still caching the previous codegen version.
- Kwpolska 2y ago
  > relying on an ancient version of netstandard They require 2.0, which is the only version that is actually useful, since it supports .NET Framework 4.x.v
  - Ygg2 2y ago
    You do realize netstandard 2.0 is 7 years old right? That it misses a ton of functionality compared to current dotnet. Stuff like MaybeNull annotation .
    - Kwpolska 2y ago
      It misses a ton of functionality compared to the current .NET (Core), but it does not miss much compared to .NET Framework 4.8. The reason why source generators require it is because they may be run by Visual Studio, which is built on top of the classic .NET Framework. .NET Standard 2.0 is a good trade-off IMO if you need to support both the classic Framework and the modern .NET.

DeathArrow 2y ago

> benchmarks https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/csharp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Ygg2 2y ago
Ahem. > web benchmarks https://www.techempower.com/benchmarks/#hw=ph&test=composite&section=data-r22 https://www.techempower.com/benchmarks/#hw=ph&test=composite...
- EraYaN 2y ago
  Those are notoriously cheat-y for just about all languages on that list. Any actual project is never going to get close to the efficiency that those number would require. Both Java and .NET over promise by A LOT with the numbers they get there.
  - Ygg2 2y ago
    Cheat-y in what way? I don't consider micro benchmarks that interesting especially since C# does have two aces that Java will get in mid term - namely Simd and primitive types. The Tech Empower benchmarks do seem to reflect general state of Java Web Framework ecosystem with Vert.x being they hyper fast web framework and Spring being way slower.
    - EraYaN 2y ago
      Well the amount of tricks that basically nobody can implement in production that those implementations do to get the numbers that they do is ridiculous. Meaning the numbers they get are wildly optimistic at best and misleading at worst. If you take the standard template for any of these frameworks (both Java and C# and any other language) and you add authentication etc, the real performance will be 5-10% of the numbers reported in those benchmarks. Have a look through some of the weirdness in the implementations it's wild (and sometimes educational). The .NET team especially has done stuff specifically to get faster on those benchmarks.

xxs 2y ago

>That's basically modern-day Java, with Lombok and other tidbits. Lombok is exceptionally backwards. You don't need getters/setters; and you should know how to try hashCode (and equals). ...and records exist

Ygg2 2y ago
The last few Spring projects I worked on that used the latest Java, still used Lombok. Records do exist, but you can't or don't want to always use them.