Noooo, you have to override 50% of the class methods to hard couple your filter’s implementation to an event-bus-style bean with Spring in the package name to avoid NIH! What if someone needs to extend your Authentication Provider in the future but can only use a limited quota of keystrokes to implement their ticket as an inobvious side-effect? How else will they add the aud from your JWT to the MDC? Some kind of pointcut??

I use it because I need HDMI :/

Yes, it also feels rather stiff, unlike the more relaxed content us software engineers are accustomed to reading.

This but make it so only the browser can’t tell time.

Noooo, you don’t understand, we just have to never make this mistake again and then there won’t be anymore regressions!

I don’t know the Go answer, but this problem exists in other languages and platforms. It can be incredibly annoying when the http client library doesn’t support unwrapping, even with generics.

If you need the subfield to have a name based on the type, you’re going to need introspection / code generation.

And now the IntelliJ plugin isn’t included in the all products pack for some reason.

Edit: It looks like it actually is included, or is supposed to be.

The website is state of the art for 2015 ± 15 years.

The omission of Swift here tells you all you need to know I think.

Edit: I misread this, but my point stands regarding Swift, it has a pretty big usage-reputation gap.

What is your goal? Custom stuff isn’t too hard if you just want to implement basic password login and token-based auth. Otherwise you could use something like Firebase, Okta, or Cognito.

What about ftp? 🤔

Yesterday, for capturing URLs.

Look the issues with java.util.UUID and Postgres.

I found the if-blocks more concerning than the lack of parentheses. Although I would’ve preferred parentheses for better parity with Kotlin for the if-else blocks (instead of then).

“Okay Todd, looks like Steve is working on auth, so you’ll be on the blacklist today-… ahah I mean, working on the blacklist today ahem…”

What I mean to say is that Google isn’t invested in native android either. It’s been repeatedly strip mined by first-timers looking for a quick promotion and left to burn.

Things got so bad that Google gave up on native Views and created Jetpack Compose, which has been a source of many complaints related to performance.

In 2024 Flutter has instant hot-reload, and the “native” (but 100% bundled) solution still requires a complete reinstall on the device. In fact, Dart can compile to native code (or JIT) without an issue, yet Kotlin Native is barely in GA in the new compiler support has been lagging while the new compiler isn’t out of beta and is still poorly supported by tooling.

Consider the absurdity: React Native is the only true native framework out of RN, Jetpack Compose, and Flutter. And all of this barely scratches the surface of the tooling problems that Flutter 99% avoids by allowing development on desktop, web or iOS simulator.

I won’t be recommending that anyone use Dart or Flutter on new projects.

You seem to think Google cares at all. Android has been languishing and Flutter is lightyears ahead. KMP is junk compared to what Flutter has accomplished with a fraction of the bells and whistles.

I just hate reading it. I wish it looked more like Kotlin and less like JavaScript 😭

As someone who switched from another domain to tech, I suggest trying to reason through your hesitation to switch away. Do you want to stay in tech because you like tech or because you’re afraid of “giving up”?

In my other domain, I worked hard and did OK, but not stellar. In tech however, it’s a completely different story. The other domain was “cool”, and I don’t regret what I learned along the way, but tech clearly comes easier to me compared to someone doing well in the other domain.

You need to be honest with yourself before you make the decision to switch. Are you running away from tech or towards something else?

I recall snapshots not being quite as cheap as on ZFS.