bfrydl

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.

You can't list objects by tag.

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.

I think it's likely that's the joke.

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 think this is because of Rust. In my opinion the Rust game dev community is overly fixated on ECS.

On the bright side, Rust has some damn good ECS libraries.

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.

Describing ops as “writing yaml files” is like describing software engineering as “typing.”

I mean that's all well and good but I can't switch over my company's infrastructure to GCE for the next two days.

Organization may not be a “business” thing but Trello, Asana, JIRA, and Slack sure are.

Nesting multiple branches of ternary operators doesn't work well but if it's a sort of “if elseif elseif else” situation I think this looks pretty nice:

    x > 0 ? 'positive' :
    x < 0 ? 'negative' :
    'zero'

There's a balance to it for sure. It sounds like estimation was taken far too seriously on your team if it was affecting you outside of work too. However, estimation is one of the primary skills of a software engineer. It's always hard to estimate well, but it's infinitely harder for a less technical person to do it for you. I think it's important to understand that and do one's best to improve at it over time.

This point of view seems ignorant of history and human nature. For example, after slavery was abolished in the south, prison wardens realized they could just rent out their prisoners to former slave owners to make some extra cash. In support of this, the state governments came up with all kinds of nonsense like truancy laws so they could put black people in jail for any reason, even being unemployed. They just made them slaves again, legally.

Using prisoners for profit means there is profit in imprisoning more people.

If these people are actually your friends, maybe you should show them more respect and stop assuming that the reason they are single is that they are less mature than you and chose to “chase hedonism” and “Instagram followers” over long term relationships. Despite what you might believe, it isn't easy for every person to find a long term partner, and not everyone wants to do it at the same point in their lives.

> Firstly, life is pointless and meaningless without children

That seems like a very personal opinion you should be stating with much less certainty about other people's lives.

With TypeScript you even get compile-time type safety for your JSX.

I did not know about tinygo and this is pretty impressive. However, it is only a subset of Go missing a few features, most notably the fact that memory is never deallocated.

Also, the equivalent JavaScript is still a fraction of this size. That's actually roughly the size of Preact, which implements nearly all of React.

I said it was bad practice that led to the large size of Medium's website, but only 20% of that download size is their application's JavaScript. In what way did the use of JavaScript make it “easier” for the remaining 80% of the download size to happen?

Large bundle sizes are not a consequence of creating UIs on the frontend, they are a consequence of bad practice. I have created plenty of purely frontend apps that don't even approach 1 MB let alone 6 MB. In fact, most languages that can target WASM seem to produce enormous modules compared to a reasonable frontend JavaScript app. Rust is an outlier in my experience because of its minimal runtime.

It's also worth noting for example that only 1/5th of the data transferred when I load medium.com cold is their JavaScript, so WASM can't really help them either way.