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

I don't. I can't commit to constantly using it. Probably a personality flaw.

I don't think it's always as simple as that. Some wrongs are more important than others. The little wrongs, wouldn't be worth that mark on your career as being seen as unreliable, other wrongs would be worth it.

I would love to self host, but the time and effort I would have to put into doing, maintaining, and convincing my spouse (which is a whole effort by itself) is so significant it will take away from my other goals in life.

It's a stable and well proven technology that still has a lot of developer activity. Businesses are trying to make money, not explore technology, so a lot of them don't want to bother risking deliverables on something they may not have experience with.

IMO

Valid points about FFI. That makes me think if Go devs cared enough about Desktop GUI, then they would try to make that weak point stronger. Their focus is elsewhere (networking, cli tools, web) which doesn't rely on FFI as much.

I'm curious why there isn't a push for more support in desktop gui for Go.

Is it because desktop gui is not as supported in modern times and Go is a recent language that is carrying that attitude or is it because Go attracts more web developers in general and they already have web applications as their solution for a gui?

Maybe something else?

Absolutely. If I use a SQL db for my applications (I'm a software dev for context), I generally write raw SQL vs using an ORM. I find the long term issues of an ORM to not be worth investing and understanding SQL.

I'm also not having to learn a new library, in addition to the standard DB connection libraries, ~if~ when I switch a language or platform for some project.

I mean eventually enough duct tape can be solid like a tank :)

So I can use zig and have someone pay me to use it :)

thank you, I'm going to take a look at these!

Great writeup. Some of the points are moot now that generics are being released, but some very valid concerns.

I would also add that Enums + Exhaustive Switch is a very very weak area in Go that would really benefit the language a ton. I've used those features in other languages and that's one of the things I miss the most, especially when dealing with a ton of web API's that have a defined set of values for properties.

Able to have the confidence that we're checking for every situation that could occur on an enum type across the codebase is one less thing I need to worry about.

I'm curious on what the percentage of contribution from the different aspects of loading a website are. How much are from the data center, from the network transfer, from the computer loading the website, etc.

If the data centers could run on cleaner energy, how much does that contribute to the CO2e measurements?

I'm curios on the difference between the 8 cores and 10 cores for the M1 Pro. I'm definitely not going to get the Max, I'm just not the user that needs the GPU's

I truly believe that Excel is the most abused software of all time. It has been mangled, malformed, smashed, and manipulated to do stuff that I don't believe the creators ever intended. Adding a scripting capability to it has unlocked the spirit of challenge in all SME's of finance related fields to make Excel the sole software they will use for all problems.

This title is misleading. User clicked on translate and there was some UI error and when they hit submit the payment went through but they just saw an error message. They reloaded the page and re sent it again.

Stripe didn’t charge twice because of a translate feature.