This is a terrible article. I'm not even sure the author researched this before writing it. There's straight up false information about each of the languages.
I'm quite tired of “What Color is Your Function”. In the five years since it was written I have yet to care about this supposed explosive problem in any language that uses async/await. It just seems like something that gets trotted out whenever anyone dares to suggest there are benefits to the approach or to talk about Rust. I'm not sure why I am supposed to accept it as meaningful truth.
One issue I have with this is that on many of the “battlegrounds” of the “culture wars”, non-participation is effectively the same as fighting for one particular side.
I think the people disagreeing with this greatly overestimate what is actually contained in a library like Redux. An entire ecosystem sprang up around it and most of it is completely unnecessary and overly complex. The base library itself is almost nothing at all and should not be hard for anyone with experience to independently create.
I agree that Rust is more suited to ECS than hierarchies. However, the choice is not between ECS or inheritance. The reason I say that the community is overly fixated on it is that many of the benefits attributed to ECS aren't unique to ECS.
I don't know if I think Helm is garbage but I feel like it's almost always more trouble than its worth. Most charts can be boiled down to just a couple resources and instead of sifting through its weirdo templates you might as well just look at the actual resource configs. It's almost always just a single Deployment or similar + RBAC.
I've actually been using Terraform to manage Kubernetes resources at my latest job, along with literally everything else. I don't even use alb-ingress-controller or external-dns or any of that. I just have Terraform make target groups from the service resources. It breaks a lot less.
Sure, there's nothing that says established practice is better. That is not, in my opinion, a good defense of Go which makes many baffling design decisions. Besides, an appeal to the authority of Rob Pike is surely not a valid defense if mine is not a valid criticism.
I'm (perhaps unfairly) uninterested in writing out all the details, but “they think they know better” is because I see Go as someone's attempt to update C to the modern world without considering the lessons of any of the languages developed in the meantime. And because of the weird dogmatic wars about generics, modules, and error handling.
I would argue that Go's design as a whole is characterized by an attitude of ignoring established ideas for no other reason than that they think they know better.
In my opinion, the first is a terrible interface because I have no idea what any of the parameters do, not because there are so many. The second is a good interface to me because all of the values are labeled. I don't see any problem with having this many parameters when all of those parameters are relevant (see: Vulkan). Named parameters often implies default values too, which means you wouldn't have to specify them all.
I basically emulate this in other languages, like Rust, with an “options” struct that has default values.
I personally think reasons like this are just pulled out of thin air to justify simple style preferences. For example, `this` is an entire word that the editor draws in a different color, so it seems unlikely that `_` is easier to scan for. Even I'm not claiming to have objective reasons for preferring `this`.
I adopted this style after working in TypeScript for a while and then going back to C#. I came to really like having an explicit receiver on every function. I work in a lot of languages where that's required, such as TS and Rust, and now the “normal” C# style of calling a method without receiver is confusing.
Also lots of people love to add _ or m_ before fields to distinguish them from local variables, so why not just use `this.`? I think once you actually use this style it starts to make a lot more sense.
How exactly does the default state work if that's the case? Is it just up to the user to treat the state as immutable and copy it rather than modifying it?
Seems like compared to Redux this would make server-side rendering very challenging. Each atom is a global singleton so I'm not sure how you could render individual requests.
I find it really annoying how JavaScript is treated on developer forums like this one. Why is it that when the same exact things are done in a typical language it's called “tooling” but in JavaScript it's “duct tape hacks on top of hacks”?
Don't get me wrong, my favorite language is Rust, but pretending the JavaScript ecosystem is unusable doesn't make you cool. I can be extremely productive in TypeScript.
> Isn't this missing the point? It's not about the overhead of declaring a new function, it's that you've made one of the props change on every render, so your child element needs to run its render function every time.
This is the larger issue, but the `useCallback` hook can be used to memoize anonymous render functions based on given values to avoid this problem.