kadendogthing

He gave a few examples, but to be honest HN filters for quantity over quality with topic discussion.

It cargo cults academia but isn't actually very academic or novel.

Spread out your thoughts in a PG style manner and make sure it's emotionally sparse and you're good. You can literally say nearly anything here, even to the point of it being disingenuous or hateful and it will stand.

>Here's why YouTube can go fuck itself

I stopped reading. YouTube is a completely free platform. It will even pay you to host your content there if it's popular enough. You're free to go else where.

TiKTok does not pay you. Your subscribers are just a number, and you have no evidence that most of them are even real and you offer no evidence in your post that any of it matters.

Anyone who's had to analyze complex systems at a high level will recognize that this is a pattern that often emerges in some form. The over all pattern happens in game engines, plugin systems, UI frameworks, in service buses, all over the place. It's just now at the code level. It's a good observation, though it seems the author has arrived at the correct conclusion/analysis and tried to shoe horn it in to fundamentally lacking systems (i.e., other languages/stacks that are inherently not functional, have side effects, and do not work off "events"/sync points).

My thoughts on this are: append only programming is less effectual than having an over all append only system, where many programs take input (including the original source "message"), then hand off the out put to the next program in line. Which programs get run depends entirely on that run context's configuration. When you have disparate programs working towards a final goal, and these programs are defined in a readable configuration it gives you quite a few benefits. Good clean logging structures, easy to reason about, easy to change (feature toggling, data migration points, etc), and easy to clean up when required.

I call it unix'ing your systems.

There's a lot of comments calling this silly but please attempt to give it a few read overs and apply it to systems you've worked with. Hopefully they've been large enough to draw similarities to what he's talking about in a very clean, academic manner.

>We’ve been undergoing a 70-year long period of deregulation, and it’s been overwhelmingly positive.

This is such a ridiculously untrue statement.

>Here's one situation where it is very different.

It's not.

> I kind of wonder what parallel universe you come from.

The one where I don't value bespoke development just because it's bespoke?

The universe where I have to actually quantify what's good and what isn't?

The worst kind of comments related to this discussion are always the ones that are insufferably offended that they can't out perform decades of experience and knowledge without doing anything.

>I've never yet see anyone argue that the reason tools took over the writing of HTML is because hand-written HTML wasn't good enough.

Check who you're listening to? It's a fairly common argument.

Yes. I don't know why HN likes to pretend they're exceptions to patterns and processes that came about for a number of reasons.

In this specific case, the hand crafted HTML that I've come across in my lifetime is usually absolute garbage. I can normally see how the developer who wrote it thinks they're being clever or nifty, and dare I say it "clean", but it usually falls short and causes more harm than good.

So imagine we as an industry organically build tools to address this. 10 years later it's pretty good, but like 5 major websites still handcraft things because they have complicated user experiences with a broad user base.

We then get dork heads who see this, believe they're part of the exception, despite not having anything remotely close to the userbase or requirements of these websites, refuse to understand why certain things are the way they are, and think they're above these processes and frameworks despite not having invested any real time or effort into the skills necessary to justify not using these frameworks or fabricated HTML.

And the worst part is it's just HTML. And we still get it wrong.

TL;DR Programmers think they're better than they really are. Use the frameworks.

This reads like script kiddies who became professional programmers and just want things done how they've always been done.

Error handling in go is not concise, and calling it explicit is in insult to anyone with a modicum of abstract reasoning skills. Error handling in go is not explicit, it's verbose. Error handling in go is not concise, it's broad. Error handling in Go is not consistent, it's an exercise left up to diligent programmers.

As golang's code base grows, you're going to see this mistake play out over and over and over again.

Having a Result<T> construct would have been great for go.

>the compensation should reflect the confluence of supply and demand in the market.

Yeah. There's no way way it's more complicated than this. If there are other effects not reflected on a simple X/Y axis then I don't wanna know about it!

Here's an exercise for the reader:

* Why is this coming from "tulsatoday"

* Why is the article written in a particular manner?

* What biases and agenda is the publication attempting to platform here?