badhombres

In the first example, I have to learn and understand OpenFGA, in the second example I have to learn and understand OpenFGA and your abstractions.

Disallow bespoke abstractions and use the industry standard ones instead. People who make abstractions inflate how productive they’re making everyone else. Your user base is much smaller than popular libs, so your docs and abstractions are not as battle tested and easy to use as much as you think.

The trade offs are though that patterns and behind the scenes source code generation is another layer that the devs who have to follow need to deal with when debugging and understanding why something isn’t working. They either spend more time understanding the bespoke things or are bottle necked relying on a team or person to help them get through those moments. It’s a trade off and one that has bit me and others before

The implication is that all remote work is part time effort for full time pay?

I think that’s a bit of a stretch to say go will implement all the features of c# and Java because of a few new features. Go isn’t a frozen language, they just take a lot of time and discussion before committing to a major change.

I have a feeling that in the future developers are still going to be needed, but in an architecture and debugging/optimization fashion. Not in a writing boilerplate code aspect. There is also an issue with validating the output before it gets released to production.

Not surprising. Every company is going to take the opportunity to trim costs when it doesn't affect their PR as much as it would any other time.

It's going to take a little more than a sed statement to make this change

I think this one difficult subject does not take away from the common feeling that overall Go is simple. This is like looking at a small scratch on the car and claiming the entire car is damaged.

Yep, enough that they need a caveat every time someone new is told of the product. It happens, and it's gotten worse due to Agile.

I think that's very extreme. Products grow at a gradual pace. I don't think there are defining moments when a product no longer supports something, or is no longer used in a way that it was intended to.

I would argue it's easier to maintain peoples understanding of a product since that will also be done gradually. It's not easy to update naming inside of a code base without potentially breaking software significantly or causing unknown bugs elsewhere. I think most software would fail the renaming test. It's also generally not worth the money and time needed to make that change.

But as products evolve, their boring names become misleading. At least with non-boring names you can re-define what they represent in your company.

I appreciate the ingenuity of the solution. But I still prefer Tailwind-esque style of css styling.

They did in the article? They're not asking it to change, they're just expressing their opinion.

To me this reads as a positive to the default handlers, as it shows how easy it was to make it work into a format that works for the programmer's preference. I appreciated the solution to the complaint