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?
> Consider everyone who lives in an apartment who doesn't have the option of replacing their lock
I've lived in apartments. Giving other people access to your apartment is - in general - a horrible idea. I let guests into my apartment. Personally. It's a pretty straightforward workflow, believe it or not.
> And he did a horrible job of it. Horrible. But he considers himself the BDFL of Markdown. Break that down for me.
Christ, you're being a dick. All John Gruber did to you was design a minimalist markup language and write a quick-and-dirty proof-of-concept Perl script to implement it. Just use a better implementation and get on with your day.
If that was all he did, it would be fine. But it isn't. His website still encourages people to use his script and his specification, even though they are known to be buggy. If you publish something on the internet and it turns out be wrong or defective, you have a moral obligation to point that out, especially if better alternatives are available.
Is it insane to try and keep the good stuff from disappearing under the garbage? Have you ever searched for something, only to come across a multitude of pages that were just incomplete, wrong or otherwise useless? A search term for which the gems are buried under so much manure you need all your Google-fu to find the gem? How do you think this will play out in the years to come?
People like Gruber, with an audience, a following, should set an example. If his code has bugs and he is informed of those bugs, he should take a few minutes to list those bugs. He doesn't have to solve them. He doesn't even have to point people elsewhere. Just listing them is enough and saves a lot of people a lot of time. If you can't be bothered to do that, please take your code down: it is nothing but pollution, keeping us from finding the better code.
This submission, which suggests forking or standardizing Markdown, has currently over 400 points. My guess is that "just use a better implementation and get on with your day" is not a good enough answer for many of us, including Jeff Atwood and David Greenspan.
> But there are problems --- like, backend processing, or proxies, or routers and transformers, or feed processors --- where event loops are the most natural way to express a performant solution.
Your backend processing apparently fits in one machine, since you "hook Mysql up through Redis." I'm personally astonished you get so much done without a distributed environment tolerant of the relevant failures I see when I read that sentence.
Your more general adage is useless. The one you responded to is useful. A more useful, also general adage would be "the more choice in selecting parameters to an API, the more likely there will be bugs consuming that API."
Exactly. Money exists to be extracted from fools at their expense, whether those fools are your investors, employees, customers, or all 3. That's real value in the market at work.
