Live data from Hacker News

Fast

catherinejue.com

121–130 of 450 posts

Re: Fast

#121
post #12

> Rarely in software does anyone ask for “fast.” They don't explicitly ask for it, but they won't take you seriously if you don't at least pretend to be. "Fast" is assumed. Imagine if Rust had shown up, identical in every other way, but said "However, it is slower than Ruby". Nobody would have given it the time of day. The only reason it was able to gain attention was because it claimed to be "Faster than C++". Watch…

Eh, I think the HN crowd likes fast because most tech today is unreasonably slow, when we know it could be fast.

Re: Fast

#123
post #36

This is interesting. It got me to think. I like it when articles provoke me to think a bit more on a subject. I have found this true for myself as well. I changed back over to Go from Rust mostly for the iteration speed benefits. I would replace "fast" with "quick", however. It isn't so much I think about raw throughput as much as "perceived speed". That is why things like input latency matter in editors, etc. If som…

This is all well and good that we developers have opinions on whether Go compiles faster than Rust or whatever, but the real question is: which is faster for your users?

Re: Fast

#124
post #101

Kinda funny but I think LLM-assisted workflows are frequently slow -- that is, if I use the "refactor" features in my IDE it is done in a second, if I ask the faster kind of assistant it comes back in 30 seconds, if I ask the "agentic" kind of assistant it comes back in 15 minutes. I asked an agent to write an http endpoint at the end of the work day when I had just 30 min left -- my first thought was "it took 10 min…

I'm consistently seeing personal and shared anecdotes of a 40%-60% speedup on targeted senior work. As much as I like agents, I am not convinced the human using them can sit back and get lazy quite yet!

Curious, what do you count as senior work?

Re: Fast

#125
post #56
post #12

> Rarely in software does anyone ask for “fast.” They don't explicitly ask for it, but they won't take you seriously if you don't at least pretend to be. "Fast" is assumed. Imagine if Rust had shown up, identical in every other way, but said "However, it is slower than Ruby". Nobody would have given it the time of day. The only reason it was able to gain attention was because it claimed to be "Faster than C++". Watch…

And yet we live in a world of (especially web) apps that are incredibly slow, in the sense that an update in response to user input might take multiple seconds. Yes, fast wins people over. And yet we live in a world where the actual experience of every day computing is often slow as molasses.

The trouble is that "fast" doesn't mean anything without a point of comparison. If all you have is a slow web app, you have to assume that the web app is necessarily slow — already as fast as it can be. We like to give people the benefit of the doubt, so there is no reason to think that someone would make something slower than is necessary.

"Fast" is the feature people always wanted, but absent better information, they have to assume that is what they already got. That is why "fast" marketing works so well. It reveals that what they thought was pretty good actually wasn't. Adding the missing kitchen sink doesn't offer the same emotional reaction.

Re: Fast

#126
post #20

Pavel Durov (founder of Telegram) totally nailed this concept. He pays special attention to the speed of application. The Russian social network VK worked blazingly fast. The same is about Telegram. I always noticed it but not many people verbalized it explicitly. But I am pretty sure that people realize it subconsciously and it affects user behaviour metrics positively.

Telegram is pretty slow, both the web interface and the Android app. For example, reactions to a message always take a long time to load (both when leaving one, and when looking at one). Just give me emoji, I don't need your animated emoji!

Can't agree.

These operations are near instant for me on telegram mobile and desktop.

It's the fastest IM app for me by a magnitude.

Re: Fast

#128
Adding to this - that's why I insist all my students should learn touch-typing, for at least 10 minutes per lesson. It really changes how you interact with your computer, and how much touch typing quickly makes you able to type as fast as you can think changes your approach to automating things in a quick script or doing some bash-fu. A very underrated skill in todays world.

Re: Fast

#129
post #85

Earlier quoted context omitted.

> "so if we make it execute in 0 seconds, does it mean you're going to make an infinite amount of money?" I don't get it. Wouldn't going from 1 second to 0 seconds add the same amount of money to the yearly profit as going from 2 seconds to 1 second did? Namely, $1M.

A process taking 0 seconds means that, in one year, it can be run 31540000 sec/0 sec = ∞ times, multiplying the profit by ∞.

Since when is the constraint "how many times can I run this thing"?
Post reply on HN