Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fast

catherinejue.com

Post reply on HN
Print view View original

321–330 of 450 posts

Re: Fast

#321

Post by lukevp »

mvieira38 wrote: post #70
9rx wrote: 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…

Only in the small subset of programmers that post on HN is that the case. Most users or even most developers don't mind slow stuff or "getting into flow state" or anything like that, they just want a nice UI. I've seen professional data scientists using Github Desktop on Windows instead of just learning to type git commands for an easy 10x time save

GitHub Desktop is way better for reviewing diffs than the git cli. Everyone I’ve ever worked with who preferred cli tools also did an add and commit everything, and their PRs always have more errors overall that would be caught before even being committed if they reviewed visual diffs while committing.

Re: Fast

#322

Post by SchemaLoad »

resonious wrote: post #262
PaulHoule wrote: post #2

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…

As a counter example (re: agents), I routinely delegate simple tasks to Claude Code and get near-perfect results. But I've also had experiences like yours where I ended up wasting more time than saved. I just kept trying with different types of tasks, and narrowed it down to the point where I have a good intuition for what works and what doesn't. The benefit is I can fire off a request on my phone, stick it in my poc…

Sounds like a slot machine. Insert api tokens, get something that's pretty close to right, insert more tokens and hope it works this time.

Re: Fast

#323

Post by gherkinnn »

NobodyNada wrote: post #211
KPGv2 wrote: post #157

Earlier quoted context omitted.

The one and only thing I'd do is make the font bigger and increase padding. There's overwhelming consensus that you should have (for English) about 50–70 characters per line of text for the best, fastest, most accurate readability. That's why newspapers pair a small font with multiple columns: to limit number of characters per line of text. HN might have over 100 chars per line of text. It could be better. I know I c…

A narrow column of text can make it easier to read individual sentences, but it does so by sacrificing vertical space, which makes it harder to skim a page for relevant content and makes it easier for me to lose track of my place since I can't see as much context, images, and headings on screen all at once. I also find it much harder to read text when the paragraphs form monotonous blocks spanning 10 lines of text ra…

Naturally. Centuries of typography as a field and your anecdote obliterates it.

Re: Fast

#324

Post by SideburnsOfDoom »

bobtheborg wrote: post #82
Liftyee wrote: post #54

I always have to remind myself of the bank transfer situation in the US whenever I read an article complaining about it. Here in the UK, bank transfers are quick and simple (the money appears to move virtually instantly). Feel free to enlighten me to why they're so slow in the US.

"Community banks mostly don’t have programmers on staff, and are reliant on the so-called “core processors” ... This is the largest reason why in-place upgrades to the U.S. financial system are slow. Coordinating the Faster ACH rollout took years, and the community bank lobby was loudly in favor of delaying it, to avoid disadvantaging themselves competitively versus banks with more capability to write software (and o…

UK Banks use FiServ too. So that can't be the only reason.

Re: Fast

#325

Post by shayief »

emmelaich wrote: post #286
shayief wrote: post #140

I got so tired of waiting for GitHub pages taking ~600ms to load (uncached), so decided to build my own Git hosting service with Go and HTMX. I know this is completely different scale, but compare: [1] https://github.com/git/git [2] https://gitpatch.com/gitpatch/git-demo And there is no page cache. Sub 100ms is just completely different experience.

Very nice. Also a plea. Don't animate the >. Or, don't wait for the animation to finish before showing the contents.

ah, interesting. It starts fetching tree items on mousedown (vs onclick) to load them faster, so > starts moving a bit too early.

Re: Fast

#326

Post by creamyhorror »

pron wrote: post #152
cycomanic wrote: post #146

Earlier quoted context omitted.

I've already written about this several times here. I think the current trend of LLMs chasing benchmark scores are going in the wrong direction at least as programming tools. In my experience they get it wrong with enough probability, so I always need to check the work. So I end up in a back and forth with the LLM and because of the slow responses it becomes a really painful process and I could often have done the ta…

Programmers (and I'm including myself here) often go to great lengths to not think, to the point of working (with or without a coding assistant) for hours in the hope of avoiding one hour of thinking. What's the saying? "An hour of debugging/programming can save you minutes of thinking," or something like that. In the end, we usually find that we need to do the thinking after all. I think coding assistants would end…

> "An hour of debugging/programming can save you minutes of thinking,"

I get what you're referring to here, when it's tunnel-vision debugging. Personally I usually find that coding/writing/editing is thinking for me. I'm manipulating the logic on screen and seeing how to make it make sense, like a math problem.

LLMs help because they immediately think through a problem and start raising questions and points of uncertainty. Once I see those questions in the output, I cancel the stream, think through them, and edit my prompt to answer the questions beforehand. This often causes the LLM's responses to become much faster and shorter, since it doesn't need to agonise over those decisions any more.

Re: Fast

#327

Post by SchemaLoad »

mvieira38 wrote: post #70
9rx wrote: 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…

Only in the small subset of programmers that post on HN is that the case. Most users or even most developers don't mind slow stuff or "getting into flow state" or anything like that, they just want a nice UI. I've seen professional data scientists using Github Desktop on Windows instead of just learning to type git commands for an easy 10x time save

They do mind, which is why we see such a huge drop off in retention if pages load even seconds too low. They just don't describe it in the same way.

They don't say they buy the iPhone because it has the fastest CPU and most responsive OS, they just say it "just works".

Re: Fast

#328

Post by didibus »

emmelaich wrote: post #280
didibus wrote: post #194

Earlier quoted context omitted.

You're taking the wrong conclusion, "Fast" is a winning differentiator only when you offer the same feature-set, but faster. Your example says it, people will go, this is like X (meaning it does/has the same features as X), but faster. And now people will flock from X to your X+faster thing. Which tells us nothing about if people would also move to a X+more-features, or a X+nicer-ux, or a X+cheaper, etc., without the…

Really not sure about that. People will give up features for speed all the time. See git vs bzr/hg/svn/darcs/monotone,...

Hum, personally I've always found git having more features than those, though I don't know them all, at least when git released it distinguished itself by its features mostly, specifically the distributed nature and rebase. And hg/bzr never looked to me like they had more features, more so similar features +/-, so they'd be a good example of git has the same features+faster so it won.

Re: Fast

#329

Post by gherkinnn »

didibus wrote: post #194
9rx wrote: 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…

You're taking the wrong conclusion, "Fast" is a winning differentiator only when you offer the same feature-set, but faster. Your example says it, people will go, this is like X (meaning it does/has the same features as X), but faster. And now people will flock from X to your X+faster thing. Which tells us nothing about if people would also move to a X+more-features, or a X+nicer-ux, or a X+cheaper, etc., without the…

I hate it but it's true. Look at me, my fridge as an integrated tablet that tells me the weather outside. Never mind that it is a lil louder and the doors are creaky. It tells me the weather!

Re: Fast

#330

Post by wldlyinaccurate »

hn_throwaway_99 wrote: post #104

Just want to say how much I thank YCom for not f'ing up the HN interface, and keeping it fast. I distinctly remember when Slashdot committed suicide. They had an interface that was very easy for me to scan and find high value comments, and in the name of "modern UI" or some other nonsense needed to keep a few designers employed, completely revamped it so that it had a ton of whitespace and made it basically impossibl…

It brings me genuine joy to use websites like HN or Rock Auto that haven't been React-ified. The lack of frustration I feel when using fast interfaces is noticeable.

I don't really get why so many websites are slow and bloated these days. There are tools like SpeedCurve which have been around for years yet hardly anyone I know uses them.

Post reply on HN