Live data from Hacker News

Why HN was slow and how Rtm fixed it

ycombinator.com

201–202 of 202 posts

Re: Why HN was slow and how Rtm fixed it

#201
post #183

Earlier quoted context omitted.

I love this response. Would be really interested in a follow-up from axod (or by pg about axod's version). It's easy to criticize, but let's see what happens when the pedal hits the metal.

My response TBH, would be that there is no point spending months tweaking the engine of a ford to try and get it to perform like a porche. Just get a porche in the first place. I don't value "being able to write it in my favorite language" at all. From what I've read, pg does. To the extent that the product suffers. There would be absolutely no point me trying to improve mzScheme when you can do exactly the same job…

Of course you can write a link aggregator in a weekend, but you can't write HN in a weekend - there's a lot of complexity in the HN source around controlling voting rings, spam, etc. When you're dealing with complex issues, it's a net win to use a language that enables you to think at the highest level of abstraction possible.

Re: Why HN was slow and how Rtm fixed it

#202

Earlier quoted context omitted.

If it's just a porting issue, there is Pthreads-win32 which worked well enough the last time I used it few years ago.

I don't know the details. I suspect the answer is that the threading support was written when pthread support was less common, and the MzScheme developers haven't been sufficiently interested in rewriting it.

Racket now includes a new facility -- "features" -- which are essentially a lightweight OS-level thread. There's also another -- "places" -- which is a more separated heavy threads (closer to a new process), but that one is not enabled by default.
Post reply on HN