Yeah, you never really know how the sausage is made. You can watch all these videos and conference presentations of our-awesome-system-to-ensure-super-duper-scalable-uptime, spend hours debating this or that architecture, and generally be less productive than if you just kick the box in the right place, every so often.
HN wasn't designed to minimize development effort. It was written to exercise an experimental programming language whose implementation is not (to put it mildly) optimized for performance. Considering its origins, it's surprising this site even has the performance it does.
Let's also mention that other "properly engineered" sites done by "rockstar programmers" don't even come close to how well HN works. Given the traffic and the audience, it is quite a remarkable thing, actually. All this with an experimental version of Lisp. :)
Good but still the site needs a backend upgrade seeing that we are sitting in 22nd Century, there must be a major backend upgrade so you guys can work easily.
So to be clear: you care more about the integrity of exercising Arc via HN than you care about your users. Because we both know that writing HN correctly would reduce latency dramatically along with short- and long-term ops effort. It'd also fix all those nasty "dead or expired link" errors. Also, users wouldn't be terrified to click "reply" without copying their posts to the clipboard, first.
Ostensibly, HN is a tool used to support YC's business. Though I believe that PG, et al. recognize it's importance to a broader community, it is not primarily an end in itself.
I suspect that the HN software does much more important but less obvious things which meet YC's goals than those you mention. I also suspect it does those things well.
As for page expirations, well, they aren't a deal breaker for me.
> I suspect that the HN software does much more important but less obvious things which meet YC's goals than those you mention. I also suspect it does those things well.
If I was PG I would test YC founder's time/frequency spent on HN against the success of their startups. I would use that data in evaluating new applicants. This test might ferret out founders with a procrastination problem.
I might also try discovering possible throw away HN accounts created by founder's applying under their official HN identity. That could really ferret out some assholes not technically competent enough to cover their tracks and dumb enough not to think this possibility through.
Also, PG's essays are one of the great success stories of content marketing.
That's how I found this community, and although I probably will never apply to YC, the enthusiasm for it's backed startups have rubbed off on me. I wouldn't have been an early AirBNB or Dropbox user if not for those essays.
You raise some valid usability problems, and yet you're here commenting. So, evidently the value of the site to you outweighs your usability concerns. Meh, won't fix.
This is seriously misinformed. You have no idea what goes into making a site "as simple as HN", and I very much doubt you would be able to write one in a month, let alone a week.
Please list your assumptions about what ideas I have - since you're clearly assuming I don't work for a company that knows how to write websites that scale.
Edit: I find it adorable that you all think HN is a hard site to run. Good luck breaking 200 qps.
Edit: I find it adorable that you all think HN is a hard site to run. Good luck breaking 200 qps.
It is a hard site to run due to its audience. Realize that this site gets poked around by hundreds of hackers. All trying to learn or break the system. Trying to not get your ass handed to you with a commonly language/framework is hard enough. I can't fathom how they do it with an experimental language and libraries. Though they are Lisp hackers. If anyone can do it, its a Lisper...
You missed my point. When you're in a situation where you have authority and ability to rewrite anything, with a reasonable expectation of success, it's often more productive to just do anything that works, and then change it if it becomes too big a pain. It's surprising how often any extra effort / thought just isn't worth the time.
Even if that's true, consider how long it takes to type the command to reboot a server. Let's say pg reboots it 70 times a year. So, maybe he spends 1 hour to 1.5 hours a year rebooting HN. That's a better use of time than spending 2+ hours to make the site more scalable. There's no one he's interested in (i.e. deal flow) who's going to stop using HN or applying to YC because the site goes down every 5-6 days.
There may be all kinds of other reasons to update the code, but that comes down to available time, experimentation, and enthusiasm, not productivity.
And could run it under an angel, auto rebooting when mem leak above a certain threshold and traffic below a certain level, allowing a couple days' window to look for a low impact time.
This is more or less what Apache and IIS do with child processes or long running threads. It's a production proven approach.
This is the part where you put your money where your mouth is and make a better HN in your favourite language. It isn't rocket science, after all. Right?
