> 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…
Fast
121–130 of 450 posts
Re: Fast
#122Re: Fast
#123This 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…
Re: Fast
#124Kinda 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!
Re: Fast
#125> 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.
"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
#126Pavel 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!
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
#127Re: Fast
#128Re: Fast
#129Earlier 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 ∞.