Live data from Hacker News

Fast

catherinejue.com

131–140 of 450 posts

Re: Fast

#131

Fast is also cheap. Especially in the world of cloud computing where you pay by the second. The only way I could create a profitable transcription service [1] that undercuts the rest was by optimizing every little thing along the way. For instance, just yesterday I learned that the image size I've put together is 2.5× smaller than the next open source variant. That means faster cold boots, which reduces the cost (and…

Not in development and maintenance dollars it's not

Re: Fast

#132
post #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?

...and that sounds nice to me as well, but if I never get far enough to give it to my users then what good is fast binaries? (implying that I quit, not that Rust can't deliver). The holy grail would be to have both. Go is generally 'fast enough', but I wish the language was a bit more expressive.

Re: Fast

#133
post #61
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.

For ACH, it's the scheduling and batching that makes it slow. The transfer itself should be instant but often my bank sends it out around midnight. This is why Venmo and Zelle are so popular. You can also modify/cancel a bank transfer before it goes through, which is nice. This is the same in Switzerland. If you request an IBAN transfer, it's never instant. The solution there for fast payments is called TWINT, which…

People are almost always talking about Faster Payments [0] rather than BACS. It really is instant.

[0] https://en.m.wikipedia.org/wiki/Faster_Payment_System_(Unite...

Re: Fast

#134
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…

I feel the same way about Go vs Rust. Compilation speed matters. Also, Rust projects resemble JavaScript projects in that they pull in a million deps. Go projects tend to be much less dependency happy.

And that leads to dependency hell once you realize that those dependencies all need different versions of the same crate. Most of the time this "just works" (at the cost of more dependencies, longer compile time, bigger binary)... until it doesn't then it can be tough to figure out.

In general, I like cargo a lot better than the Go tooling, but I do wish the Rust stdlib was a bit more "batteries included".

Re: Fast

#135
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…

To a first approximation HN is a group of people who have convinced themselves that it's a high quality user experience to spend 11 seconds shipping 3.8 megabytes of Javascript to a user that's connected via a poor mobile connection on a cheap dual-core phone so that user can have a 12 second session where they read 150 words and view 1 image before closing the tab.

Fast is _absolutely not_ the only thing we care about. Not even top 5. We are addicted to _convenience_.

Re: Fast

#136

> Asking an LLM to research for 6 minutes is already 10000x faster than asking for a report that used to take days. Assuming, like, three days, 6 minutes is 720x faster. 10000x faster than 6 minutes is like a month and a half!

More like 300x if you count working hours. Although I've yet to see anything that would take a person a few days (assuming the task is worth spending a few dats on) and that an LLM could do in six minutes, even with human assistance.

Re: Fast

#137

Earlier quoted context omitted.

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"?

At least in theoretical computer science, often, but that's another matter entirely.

Re: Fast

#138

Fun story time! Early in my career as a software engineer, I developed a reputation for speeding things up. This was back in the day where algorithm knowledge was just as important as the ability to examine the output of a compiler, every new Intel processor was met with a ton of anticipation, and Carmak and Abrash were rapidly becoming famous. Anyway, the 22 year old me unexpectedly gets invited to a customer meetin…

So, did you make it faster?

Unfortunately, there wasn't a single bottleneck. A bunch of us, not just me, worked our asses off improving performance by a little bit in several places. The compounded improvement IIRC was satisfactory to the customer.

Re: Fast

#139

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…

Ive wanted tp poll HN about how many people actively track usernames.

With IRC its basically part of the task, but every forum i read, its rare that i ever consider whose saying what.

Re: Fast

#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.

Post reply on HN