I was worried it was that WiZ, luckily it's not
Their bulbs are one of the few WiFi bulbs that don't require an app to operate (only for the initial configuration)
Shelly does not require an app at all. Initial setup can be done via the WIFI AP it generates by default. Cloud is a checkbox in the app/web interface.
Personally, I found the second season to be a decent show in its own right, but comparison is 100% the thief of joy in this case. Season one was one of the most gorgeous pieces of sci-fi media I've ever seen and season two just looked OK by comparison and had a much slower pace and felt more emotionally vulnerable compared to season one's hardboiled tone.
If they were separate shows I would be tempted not to compare them at all.
IMO the first book was really good, the others are pretty bad. So they were always going to have the problem... and frankly they altered the original book in ways that were worse without actually resolving any problems with length.
> 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#
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.
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 .
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.
If setting <LangVersion> to 12 and maybe doing `dotnet add package PolySharp` was too challenging then the source generators API is probably not for you. It's not a language issue :)
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'.
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.
> 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.
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.
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.
Reading this thread is the first I'm learning of this. Even with the enthusiasm expressed here, I'm still suspicious that there will be incompatibilities. Microsoft has a history of doing things a certain way.
That's your bias and not the language fault, everything works pretty much the same across every OS, I haven't developed non-UI C# apps on Windows since 2018 (because of course you need Windows to build WinUI and WPF apps, but you have options on macOS and Linux too)
