Other Software > Developer's Corner

Discourse - A discussion platform by StackExchange's Jeff Atwood

(1/4) > >>

wraith808:
StackExchange's Jeff Atwood switches to Ruby on Rails and Postgres; code dumps entire new project at once -- Discourse, a platform for community discussion. (github project)

It actually looks pretty cool.

Renegade:
Wow. There *is* some pretty impressive and cool stuff in there. I was surprised. They've actually done some really nifty stuff and not just rehashed "yet another BBS".

40hz:
Interesting new product...

Not sure I agree with some of the concepts and design philosophy behind it however. They seem to be wanting to wed certain elements of "social" sites to a more traditional 'flat' discussion forum. From what I've seen, every attempt at doing that wound up producing a hybrid that wasn't as good (or usable) as either. And I think that's largely because online "socializing" and "discussion" are two separate things even if they do share many surface resemblances. To my mind it's the difference between indulging in chit-chat or 'small talk' and having a real conversation. But I'm getting old - which means I don't mind reading and I have a decent attention span - so that's probably just me.

I also can't help but wonder how well it will scale because it's written using ROR.

Fans of Ruby often argue it's not Ruby itself that's the problem (as in sloooooow) - but the way people (who don't understand it well enough) code it. I don't have sufficient expertise to know which is more correct. But my own experience with Ruby and ROR apps has been that while it seems great for prototyping, it's invariably sluggish in operation. Especially under load.

I know a few coders who sometimes use ROR to test concepts and designs before doing their actual production coding in Javascript. None of them are amateurs. So I'm guessing they have very good reasons for not using Ruby for their final deployments.

I did like one comment on the tryout page. Somebody said it "felt much like Google Wave - except the interface works." That cracked me up. ;D

And it does feel a lot like Wave now that I'm thinking about it. :huh:

mouser:
I think it's quite interesting -- I agree with 40hz that some of the UI decisions don't quite mesh with my preferences -- but it is interesting that they are trying something different.

f0dder:
Looked at it yesterday and chitchatted a bit with mouser on IRC about it - but haven't looked at it enough to have any super well-formed opinion. Some ideas seem nifty, others perhaps less so. Not sure what to think of it being pageless - the idea that your "reading progress" is saved is nifty, but for really long threads you're going to have a veeeery tiny drag-selector on the scrollbar. OTOH, it's nice not having to do a page refresh (and losing contents of your edit box...) to read more - but that could be accomplished with AJAX in a paged environment as well.

Guess I'll have to play with it a bit more, and see what happens as it gets more polish. My initial impression is that it could work well for some sites, but I don't think it'd suit DoCo.

I also can't help but wonder how well it will scale because it's written using ROR.-40hz (February 07, 2013, 06:36 AM)
--- End quote ---
I was pretty puzzled when I saw it was built on ROR, considering how well ASP.Net has worked for the StackExchange platform. But I guess it's a combination of only parts of the ASP.Net stack being open, and (perhaps more important) not being able to run ASP.Net gratis (you really do need to run it on Windows, MONO is not quite there yet).

Fans of Ruby often argue it's not Ruby itself that's the problem (as in sloooooow) - but the way people (who don't understand it well enough) code it.-40hz (February 07, 2013, 06:36 AM)
--- End quote ---
Bollocks.

Ruby itself is damn slow and doesn't support multithreading (there's projects like JRuby, but meh), and while Ruby is a sorta-kinda-OK language it's not really that special in and by itself... if it wasn't for Rails, it would still be a niche language most people hadn't heard about. And Rails is a big effin' rats nest of vulnerabilities - stay clear!

Ruby follows the old crappy UNIX notion of "let's spawn a process per request! Processes are cheap! :D :D :D", so to get any kind of decent speed, you need a load balancer that dishes work off the one of several spawned Ruby processes (which need to be restarted every now and then because of memory leaks). There are hacks to reduce the impact of this, but... meh.

I really don't get why one chooses to do anything but prototypes in Ruby/Rails, really. You've already moved beyond the "Runs on every cheap-ass host" PHP and into the domain of having to pay at least a bit for the hosting, so why Ruby?

Go Scala - and if you need fast turnaround, go Play around (despite the name, it's ready for production use).

Navigation

[0] Message Index

[#] Next page