Hacker News new | past | comments | ask | show | jobs | submit login

Did you had fun knocking this strawman?

Nobody said or implied that you need to eschew libraries and write everything from scratch to achieve performance, and it is frankly a very dishonest way of conducting this conversation.

Especially considering that we’re talking about someone (Casey) whose previous job was pretty much selling high-performance libraries (RAD Tools).

The claim from the (to be cheeky) “anti-performance” crowd is that it is impossible or unnecessary to extract more performance from modern computers. All that we’re saying is that things are not so black and white.

“The conclusion”, if you need one, is that people saying that more performance is impossible or impractical as a knee-jerk response are often wrong.




If there is no conclusion then you are just un-productively saying "modern software sucks".

My point is, if the claim is that modern software is bad, what do they offer as the solution to that?

> The conclusion”, if you need one, is that people saying that more performance is impossible or impractical as a knee-jerk response are often wrong.

This is barely a statement. I've never heard "performance is impossible" from anyone, and it's amusing you would accuse me of a strawman and then introduce one like this.


The phrase “software is crap” was said by someone criticizing Casey Muratori, not by himself or by me. It was a mischaracterization.

If you want to paraphrase him correctly, he has claimed several times that there are several low-hanging-fruits performance-wise in modern software.

> I've never heard "performance is impossible" from anyone

First, I said “impossible or impractical”. This comment section is littered with the second. Second, this is not an exaggeration, nor refers to you. It actually happened: a FAANG product manager told Casey it would take several years and a PHd degree to fix some performance issues in a MS product that Casey had diagnosed. Casey then proceeded to create a performant proof of concept with feature parity over a weekend or so.

> what do they offer as the solution to that?

Are you asking for a silver bullet? Because there are none. The first step towards a solution for low performance in modern software is stopping the automatic reactions of saying performance is unnecessary, impractical or even impossible, whenever someome with enough knowledge of the problem domain claims otherwise.

The path to faster software involves actual hard work, rather than attempting to publicly shame people who offer solutions.

I really don’t think this is unreasonable at all.


> The path to faster software involves actual hard work, rather than attempting to publicly shame people who offer solutions.

Again, what solutions? Until you can define what these are I'm not sure what his position is or what he's advocating for.

No offense but I've exhausted my interest in the topic, take care


> Again, what solutions?

I am talking about actual concrete solutions. “Do this code change and the bottleneck will go away”.

This person offered ACTUAL CONCRETE SOLUTIONS to performance issues. He literally opened bug-tickets and discussed with the team, and provided proof-of-concepts, but a FAANG manager attempted to shut him down.

This is not some snake oil salesman offering magic performance beans, this is someone who actually knew what they were talking about, and was able to diagnose performance problems in the operating system and solve it, for free. This isn’t some hypothetical, he REALLY did fix it despite being told it was impossible.

EDIT: Like the sibling poster said, the systemic solution is to "git gut". Which is clearly impossible as long as developers and managers foster a culture of dismissing performance, or in some cases inventing excuses not to work on it, as was seen in the Casey/Microsoft debacle.


>Again, what solutions?

The solution is to git gud.

There certainly was actionable advice in the couple of his videos I've seen (I haven't watched many, he's a wandering talker). But the underlying theme is about development process and frame of mind. Just adopting a list of techniques would miss the "greater than the sum of it's parts" value.


>The solution is to git gud.

someone unironically espousing this as a "solution" to a struggling creator will never understand why other frameworks become popular when they cater to helping them out instead of throwing a book at them. That's why Unity is more popular among small creators. They don't necessarily want to be an engineer, they want to create art.

This mentality spreads outside of programming to other software as well. Gimp, Blender (which is fortunately making changes towards accessibility), etc.


If not blatantly obvious, I was being flippant.

You seem committed to the idea anyone is advocating yac-shaving by a highly constrained developer. I'm not seeing that.

Like anything in software projects, the path of least resistance will get you to the quality floor. Trivially actionable advice doesn't exist because it will become part of the quality floor. That's just the evolution of software.

That doesn't mean there isn't actionable advice that's low on the learning curve. But like others skill, there is an unavoidable learning curve, it also takes time to apply the skill, and choosing when to apply it is a skill in and of itself. That's just life in development.

I'm not saying to never sacrifice quality to get products out the door. But there's also nothing wrong with acknowledging when that's being done. And the state of affairs is that performance is very frequently sacrificed, leading to a pretty damn sorry looking status quo.


>If not blatantly obvious, I was being flippant.

Poe's law is in effect. I've seen that sentiment elsewhere and even in this post espoused unironically. It happens quite often in these circles unfortunately.

>I'm not saying to never sacrifice quality to get products out the door. But there's also nothing wrong with acknowledging when that's being done.

there isn't, but there is something wrong when you question the quality of a developer over it, while not understanding their constraints on knowledge, time, scope, and overall goals. It's just very presumptuous and I've never seen a justified case to shame someone as such.

Promote good practices, educate on bad ones. You can do this without such attitude as "git gud" which targets devs directly (which may not be something you said, but it is said often enough that I feel a need to address it).


> someone unironically espousing this as a "solution" to a struggling creator

Nobody is, though, and if you see other replies with the “git gud” text you’ll see this is used as a way to attack anyone who cares about performance.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: