5 ms·

> 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 i

> 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.
        e3bc54b2 2y ago
        You are really part of the cream, and I mean it as an honest compliment. I am part of the dark matter, although self-initiated java upgrades already put me on the right side of bell-curve. > Also I'd actively remove all apache commons as well. Even in Java8 most of the functionality is redundant. I used to think that. Then I had to decompress zip files in memory and selectively process the children. Of course Java has the functionality covered in stdlib, but they require so much boilerplate, and commons-compress was such a pleasure that I was done in 10 minutes. The same goes for other apache libs too. OTOH, I wholeheartedly agree about Lombok being unjustified curse.
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.

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.
      - e3bc54b2 2y ago
        You are really part of the cream, and I mean it as an honest compliment. I am part of the dark matter, although self-initiated java upgrades already put me on the right side of bell-curve. > Also I'd actively remove all apache commons as well. Even in Java8 most of the functionality is redundant. I used to think that. Then I had to decompress zip files in memory and selectively process the children. Of course Java has the functionality covered in stdlib, but they require so much boilerplate, and commons-compress was such a pleasure that I was done in 10 minutes. The same goes for other apache libs too. OTOH, I wholeheartedly agree about Lombok being unjustified curse.

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.