Hacker News new | past | comments | ask | show | jobs | submit login

For one example of a D program in production use, check out http://forum.dlang.org. The forum software is entirely written in D (written by Vladimir Panteleev).

(Although due to this announcement, the site is being slammed at the moment. It's a single server hosting dlang.org, not a farm.)




The responsiveness of this forum is amazing. Is the client side doing some pre-fetching?

I remember finding the website disturbingly fast on my first visit. I wonder if it is just me being so used to loading delays, or if there is a point were you can be so fast that it is detrimental to the user experience. The latter doesn't sound like it makes sense so it must be of matter of getting used to it.


Well, a forum is essentially the same thing as BBSs were in the 80s but now we have computers that are several thousand times faster. I find it much more "amazing" that the other forums are so slow.


BBSs in the 80s / 90s were operated by users in their own homes and usually weren't allowing for multiple connections. The software itself was pretty dumb and slow.

Forums these days need to allow for multiple users to log in, read content and post messages. I'm pretty sure that the link above received several hundreds or thousands of users in a single hour. Forums these days also use database systems (or other services external to the process) that represent a big bottleneck. Then you've got the issue of static assets, like CSS, Javascripts, images and so on.

As a general rule of thumb, if you want scalability, you have to trade some throughput for it, as scalability concerns hurts performance.

That said, popular open-source web software, in general is awful in terms of everything.


The forum sends back a simple preformatted chunk of HTML which is then inserted at a certain spot.

It does not send a complex JSON object that is then marshalled into some kind of Angular-Knockout-Backbone framework of the day where complex magic creates views, links and templating language formats objects into HTML created via DOM.

As JS in the browser speed up, all those framework find some way of using it. Sure, your 5-item TODO list app looks good...


Is there any caching going on, server-side?

It is ridiculously fast.


I'm not kidding here, I had forgotten the internet could be that fast. Static content, I miss you...


Static content served via CDN with a simple layout (read: many nerd blogs) is page loading nirvana. :)


There is caching of the newsgroup messages, but I don't know about the generated page.



It's not like modern forum URLs are all that much better.

I mean, yes, superficially this is less obtuse:

http://advrider.com/forums/showthread.php?t=801516

But the number holds no meaning to a human either way.


No meaning is a little strong, eg:

http://advrider.com/forums/showthread.php?t=801515

exist (while http://advrider.com/forums/showthread.php?t=801517 doesn't at this time).

"Normally" such an app (avrider) would be set up with routing such that the url became /forum/thread/<id> -- and with a simple 6-digit id, that's much more managable to type/communicate manually than an uuid or something.

All that said, I basically agree -- exposing some "magic" constant/serial number to the user usually doesn't do much to help with the ux. It's actually an interesting problem: what would be the better, more "true" web/REST-like url-scheme for a forum? Perhaps forum/topic/sub-topic/thread-topic ? How limiting would that be wrt. reorganizing the forum threads (and not breaking links) -- this is especially an issue if there's a chance of re-using uri's -- it's annoying to have a link to one discussion morph into a link to another one. I don't think there are any solutions that are significantly better than a (symbolic/numerical) thread/topic id...

edit: Actually I see the sense in the email-id-like urls of the d-mars forum (or usenet-like).


Thing is nobody really ever types a url anymore, beyond perhaps:

http://advrider.com/forums




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: