3 ms·

I have to say, I find it surprising that ycombinator hasn't hired another developer to work on HN. It's great that you're actually well-versed in the codebase,

I have to say, I find it surprising that ycombinator hasn't hired another developer to work on HN. It's great that you're actually well-versed in the codebase, but you shouldn't be the lead moderator, lead customer support contact, and lead developer, that's nuts! Heck, I can't tell—are you merely the "lead" on those things, or are you the sole person? You often say "we" when talking about HN, but I can't tell if that's a royal we or not. I know that HN is meant to be low-resource, but if ycombinator thinks it has any value at all, they ought to be able to spare another developer. This is just basic organization management. Of course you haven't finished your software yet, you can't do everything!

dasil003 5y ago
> but you shouldn't be the lead moderator, lead customer support contact, and lead developer of HN, that's nuts! Now you know why his name is dang!
BitAstronaut 5y ago
I vote they hire user BitAstronaut when he finishes his degree in a few months. Seems like a pretty cool person.
nmstoker 5y ago
I'm not particularly surprised. How much do you think the long term value gained from HN has been impacted by the slow down today? My bet would be not very much at all - I doubt there are few regular users who would be deterred from coming back. Plus there is no income stream to protect. Thus justifying a non-lean approach seems a stretch. Generally things appear to work pretty well here and the odd day where things aren't perfect isn't the end of the world.
- Wowfunhappy 5y ago
  I agree it's not a significant problem if Hacker News goes down for a day. However, paginated threads really suck, and that's also a stop-gap pending performance improvements. And, it would generally be good if dang was freed up for e.g. moderating.
dang 5y ago
I can tell you for sure that it's my problem, not YC's. They're all in favor of what you describe.
- Akronymus 5y ago
  I can't seem to find a better comment to ask about this: What do you think about the SAFE stack? (I know that the HN backend is written on a completely different stack.) Do you think it will gain some popularity and/or is a competitive advantage over something like a plain lamp/lemp stack? Or do you expect it to languish and die? Really just curious what you think about it and would appreciate a reply if it isn't much trouble to you.
  - lioeters 5y ago
    It's the first time I've heard about the SAFE stack. I have no experience or opinion about it, but here's a reference for curiosity's sake. - Saturn for back-end services in F# - Azure as a hosting platform plus associated platform services - Fable for running F# in the web browser - Elmish for client-side user interfaces https://safe-stack.github.io/docs/overview/ https://safe-stack.github.io/docs/overview/
  - exikyut 5y ago
    Just to clarify, HN is written in Arc, a Lisp variant, and (purely incidentally) runs on FreeBSD. As the sibling replier noted, SAFE appears to be hosting-provider-specific. Also, I'm definitely not OP, but since I'm here, and just in case... My own knee-jerk reaction goes straight to the value proposition of the cloud vendor it's tied to, which is a very odd/unusual dimension to bring to a programming stack (eg, LAMP isn't tied to Windows, or to GCP, it's entirely neutral). Cloud vs bare-metal vs VPS vs virtual hosting vs etc all have different cost dimensions and optimalities. Given that I can run PHP on App Engine, GCP, and (with a small amount of existential screaming) random Web hosts... PHP is canonically a bit more flexible than SAFE. (Then you've got the argument of "but you can technically run SAFE elsewhere" - to which I respond "okay make the A mean something else then!") As for my generic opinion on the rest, it's all about what it brings to the table. If it introduces something genuinely new that adds a bit of "essence of 10x", if you will, if that new thing is tied to the rest of the stack, and the stack gets out of people's way to enable that 10x thing, then yeah, the stack'll follow after the new thing and catch on in the process. Thing is, "getting out of the way" is the critical part that is so easily gotten wrong - if you're trying to show people new ways of doing things, and it just feels like how they were doing things before, it doesn't matter if they look different, the magic just falls apart, and the new thing won't catch on. IOW, in much the same way that successful existing products are a million tiny details gotten right, successful visions for new things are those same million tiny details from the perspective of the new thing that doesn't "exist" yet. Does this do that? Secondly, regarding your curiosity about whether this thing will languish and die... for what reasons might that be especially important? For the sake of debate, I'm not presuming you're actually coming from that perspective, I'm asking what if, and answering that what if by saying that the success or failure of a tool ultimately doesn't matter, because tools aren't ways of doing things, in much the same way considering operating system to be better than another is mushing too much unrelated context together. It's very good to build good designs that excel because they are well thought out, but I've learned (without becoming cynical :D) that success and failure are ultimately memetic and arbitrary, and that bad things can succeed because they're in the right place at the right time, not because the fundamentals of the universe are broken or biased towards bad things succeeding, but because the technical discourse of "A is better than B" confuses the semantic priority of problems vs solutions, and thus typically do not consider (or provide room to consider) the almost-always-limited scope of the situations A and B might be being used in (the problems), which may not give any consideration to the majority of the ways A might be better than B (the solutions). The fitness function isn't about All The Things™ the solution brings to the table, it's about whether the solution fits the problem at hand. As for "but what about the future?", I think that ultimately boils down to understanding the problem space well enough such that all the things a current problem might need to tackle in the future become apparent in the present, so the solution can integrate those considerations from the get-go. To reiterate, it's about understanding the problem space correctly, not the solution space. The above was written with more than a healthy dose of assumption, and I apologize if I've extrapolated nonexistent signal from your question.

dasil003 5y ago

> but you shouldn't be the lead moderator, lead customer support contact, and lead developer of HN, that's nuts! Now you know why his name is dang!

BitAstronaut 5y ago

I vote they hire user BitAstronaut when he finishes his degree in a few months. Seems like a pretty cool person.

nmstoker 5y ago

I'm not particularly surprised. How much do you think the long term value gained from HN has been impacted by the slow down today? My bet would be not very much at all - I doubt there are few regular users who would be deterred from coming back. Plus there is no income stream to protect. Thus justifying a non-lean approach seems a stretch. Generally things appear to work pretty well here and the odd day where things aren't perfect isn't the end of the world.

Wowfunhappy 5y ago
I agree it's not a significant problem if Hacker News goes down for a day. However, paginated threads really suck, and that's also a stop-gap pending performance improvements. And, it would generally be good if dang was freed up for e.g. moderating.

dang 5y ago

I can tell you for sure that it's my problem, not YC's. They're all in favor of what you describe.

Akronymus 5y ago
I can't seem to find a better comment to ask about this: What do you think about the SAFE stack? (I know that the HN backend is written on a completely different stack.) Do you think it will gain some popularity and/or is a competitive advantage over something like a plain lamp/lemp stack? Or do you expect it to languish and die? Really just curious what you think about it and would appreciate a reply if it isn't much trouble to you.
- lioeters 5y ago
  It's the first time I've heard about the SAFE stack. I have no experience or opinion about it, but here's a reference for curiosity's sake. - Saturn for back-end services in F# - Azure as a hosting platform plus associated platform services - Fable for running F# in the web browser - Elmish for client-side user interfaces https://safe-stack.github.io/docs/overview/ https://safe-stack.github.io/docs/overview/
- exikyut 5y ago
  Just to clarify, HN is written in Arc, a Lisp variant, and (purely incidentally) runs on FreeBSD. As the sibling replier noted, SAFE appears to be hosting-provider-specific. Also, I'm definitely not OP, but since I'm here, and just in case... My own knee-jerk reaction goes straight to the value proposition of the cloud vendor it's tied to, which is a very odd/unusual dimension to bring to a programming stack (eg, LAMP isn't tied to Windows, or to GCP, it's entirely neutral). Cloud vs bare-metal vs VPS vs virtual hosting vs etc all have different cost dimensions and optimalities. Given that I can run PHP on App Engine, GCP, and (with a small amount of existential screaming) random Web hosts... PHP is canonically a bit more flexible than SAFE. (Then you've got the argument of "but you can technically run SAFE elsewhere" - to which I respond "okay make the A mean something else then!") As for my generic opinion on the rest, it's all about what it brings to the table. If it introduces something genuinely new that adds a bit of "essence of 10x", if you will, if that new thing is tied to the rest of the stack, and the stack gets out of people's way to enable that 10x thing, then yeah, the stack'll follow after the new thing and catch on in the process. Thing is, "getting out of the way" is the critical part that is so easily gotten wrong - if you're trying to show people new ways of doing things, and it just feels like how they were doing things before, it doesn't matter if they look different, the magic just falls apart, and the new thing won't catch on. IOW, in much the same way that successful existing products are a million tiny details gotten right, successful visions for new things are those same million tiny details from the perspective of the new thing that doesn't "exist" yet. Does this do that? Secondly, regarding your curiosity about whether this thing will languish and die... for what reasons might that be especially important? For the sake of debate, I'm not presuming you're actually coming from that perspective, I'm asking what if, and answering that what if by saying that the success or failure of a tool ultimately doesn't matter, because tools aren't ways of doing things, in much the same way considering operating system to be better than another is mushing too much unrelated context together. It's very good to build good designs that excel because they are well thought out, but I've learned (without becoming cynical :D) that success and failure are ultimately memetic and arbitrary, and that bad things can succeed because they're in the right place at the right time, not because the fundamentals of the universe are broken or biased towards bad things succeeding, but because the technical discourse of "A is better than B" confuses the semantic priority of problems vs solutions, and thus typically do not consider (or provide room to consider) the almost-always-limited scope of the situations A and B might be being used in (the problems), which may not give any consideration to the majority of the ways A might be better than B (the solutions). The fitness function isn't about All The Things™ the solution brings to the table, it's about whether the solution fits the problem at hand. As for "but what about the future?", I think that ultimately boils down to understanding the problem space well enough such that all the things a current problem might need to tackle in the future become apparent in the present, so the solution can integrate those considerations from the get-go. To reiterate, it's about understanding the problem space correctly, not the solution space. The above was written with more than a healthy dose of assumption, and I apologize if I've extrapolated nonexistent signal from your question.