#1 By: Chris Bridgett, February 6th, 2013 11:48
Maybe this isn't the intention of this forum (or maybe it is), but it will probably fall in-front of the right eyes to bring me up to speed.
What was the reasoning behind the team's choice to roll with emberjs/Ruby/Postgre?
I have no doubt that Discourse is for sure going to cause a stir in the 'forum industiry'/'online community industry' given the people behind it and the innovative new concepts it brings to the table.
Wouldn't it have been better built in PHP/MySql. Don't shoot me. I know that probably sounds blasphemous to the 'purist' (or 'moderately competent' :D ) programmers out there, but think about it. The PHP community dwarfs the Ruby community, as a result of which the availability of web hosts offering PHP/MySql at 'small business prices' dwarfs those supporting the technology stack for Discourse.
Or was it a business desicion? Will you sell more of your upcoming hosting offerings by using a more obscure technology stack?
(Or I'm guessing the real answer is it's probably the language the founding members were more profficient in - aside from Jeff, as I read in his blog.. or on the about page... somewhere).
tl;dr - Wouldn't the uptake have been quicker in terms of both community input and Discourse installations if Discourse were written in a more popular technology stack (e.g. Php/MySql).
I'm not a PHP advocate nor trying to start a holy war, just curious.
#2 By: Brandon Rampersad, February 6th, 2013 11:53
I think this will be more of a hosted app for small users than having them install it themselves.
#3 By: Michel Billard, February 6th, 2013 11:54
If people keep making open-source software using PHP/MySql for that sole reason then it's never gonna change. Ruby on Rails is very easy to learn and to me much more enjoyable to work with. There are a number of easy solutions (ex: Heroku) already available that make it much more powerful than PHP/MySql. Getting the whole thing to run on Heroku costs more than a Wordpress install somewhere else, but Discourse appears to have more powerful features than simply listing posts.
As more people develop open-source solutions in Rails, I'm sure the options will get better.
#4 By: Chris Bridgett, February 6th, 2013 11:54
#5 By: Mike Weller, February 6th, 2013 11:57
Postgres is also superior to MySQL in many ways. You just have to see how MySQL handles defaulting NULLABLE column types on an INSERT to understand why using it is simply dangerous.
See this link for some details. Postgres is a solid choice.
edit: As for PHP, it's basically everywhere. But Jeff and his team are developing forum software for the next decade. PHP is already a legacy platform as far as many developers are concerned. The design of the language has many issues, the standard library is a mishmash of inconsistent naming, and if it's going to be open source, the last thing you want is inexperienced developers hacking away at a PHP code base and sharing that crud with the world. We've all seen the kind of code I'm talking about and it's not a pretty thing.
#6 By: jcolebrand, February 6th, 2013 12:01
Because you must not understand how these things work, do you? Traditionally PHP requires Apache and only operates via cgi-style interfaces. Ruby, however, with Rails, is a completely standalone engine. Because of that you have reduced the operational complexity, and allowed people to make the stack more optimized for what you're trying to accomplish.
As for the db storage choices, you have to evaluate the needs, and in this case, the choice was likely MySQL (part of Oracle now, so it's dubious that there will be everlasting free support), MariaDB (forked from MySQL so likely to also have issues in the future, such as a divergent API from MySQL which will confuse people who think this should be fit for MySQL) and Postgres. Postgres is more robust than MySQL in a fair number of ways, and requires less overhead.
So they chose the simpler, and simpler, and simpler choices for webstack, db, cache-engine and moved forward with writing their code.
Which would you choose in each situation? More complex or simpler? That's what they did.
#7 By: Brandon Rampersad, February 6th, 2013 12:07
I wonder if they even considered nosql choices like mongo or couch.
#8 By: jcolebrand, February 6th, 2013 12:08
They're too intelligent of a team not to have considered that.
You do realize most of the core of this team also has StackOverflow/StackExchange style experience, right?
#9 By: Chris Bridgett, February 6th, 2013 12:11
No need to attack me, I was only initializing a discussion in attempts to improve my understanding - i.e. a key function that forums serve.
#10 By: jcolebrand, February 6th, 2013 12:17
Ah, but to question the choices and name specific alternatives, you must understand them. Otherwise you should leave out the challenging bits about "shouldn't they have done it in"
Sticking to "why didn't they" was sufficient to learn the reasons why. Proposing alternatives for reasons that you assume to be "better" when you don't understand them is not really socially responsible.
So, I'm sorry if I actively offended you, but yes, I did mean to call you out on making suggestions without understanding.
#11 By: Chris Bridgett, February 6th, 2013 12:18
Fair enough, maybe I should have just left it at 'Why not something else?'. I've always found I explain points/concepts better by illustrating them with examples. I must have chosen a poor example in this case. :)
#12 By: Why not?, February 6th, 2013 15:28
#13 By: Brandon Rampersad, February 6th, 2013 15:33
Why Python and not Node.JS?
#14 By: Adam Davis, February 6th, 2013 15:39
They should totally drop this and try jQuery.
#15 By: jcolebrand, February 6th, 2013 16:15
That is an excellent question, however.
Probably familiarity of the stack and the Rails usage?
#16 By: Alex, February 6th, 2013 16:57
I read that they are using PostgreSQL as their main data store and Redis for their job queue, rate limiting, as a cache and for transient data. Sounds like a smart choice to me. Especially Redis, Redis kicks *ss. :)
#17 By: Justin Giancola, February 6th, 2013 18:15
But why is that? Did Wordpress, phpBB et al. choose PHP/MySQL because there was cheap hosting available? I don't think so. Cheap hosting for PHP/MySQL became available because there was such a demand to host Wordpress, phpBB, etc. installations.
#18 By: Dskraus, February 6th, 2013 18:23
Right. Hosting totally became a commodified business. Very much a business that seems to just try to compete with each other on price point for amount of storage space, bandwidth etc. It's a race to the bottom.
#19 By: Randito, February 6th, 2013 18:57
By going with Ruby, you can leverage a large ecosystem of gems that are especially particular buzzword complaint.
There's event machine, redis, postgres, haml, sass, coffeescript and lots of other goodies under the hood. There's restclient for making REST calls (not sure how it's used though). There's fog for AWS integration.
There's a few gems (ha!) hiding in there, too. Check out the "onebox" and "messagebus". Those have been the really cool finds I have found while digging through the code at https://github.com/discourse/discourse. (I suspect onebox is piece that goes out and grabs content for links you place in the editor. i.e. github, flickr, etc).
# errbit is broken with 3.1.3 for now
gem 'airbrake', "3.1.2"
gem 'rails3_acts_as_paranoid', "~>0.2.0"
gem 'slim', '<= 1.3.0'
gem 'sinatra', :require => nil
gem 'clockwork', :require => false
# gem 'rack-mini-profiler', '0.1.21'
# gem 'rack-mini-profiler', :path => '/home/sam/Source/MiniProfiler'
gem 'rack-mini-profiler', :git => 'git://github.com/SamSaffron/MiniProfiler'
gem 'oauth', :require => false
gem 'simple_handlebars_rails', path: 'vendor/gems/simple_handlebars_rails'
# Gem that enables support for plugins. It is required
gem 'discourse_plugin', path: 'vendor/gems/discourse_plugin'
# Discourse Plugins (optional)
# Polls and Tasks have been disabled for launch, we need think all sorts of stuff through before adding them back in
# biggest concern is core support for custom sort orders, but there is also styling that just gets mishmashed into our core theme.
# gem 'discourse_poll', path: 'vendor/gems/discourse_poll'
gem 'discourse_emoji', path: 'vendor/gems/discourse_emoji'
# gem 'discourse_task', path: 'vendor/gems/discourse_task'
gem 'rails_multisite', path: 'vendor/gems/rails_multisite'
gem 'message_bus', path: 'vendor/gems/message_bus'
gem 'koala', :require => false
gem "active_model_serializers", :git => "git://github.com/rails-api/active_model_serializers.git"
gem 'vestal_versions', :git => 'git://github.com/zhangyuan/vestal_versions'
gem 'fog', :require => false
# Gems used only for assets and not required
# in production environments by default.
# allow everywhere for now cause we are allowing asset debugging in prd
group :assets do
# gem "asset_sync"
# need this to compile coffee on the fly
gem "ember-rails", :git => 'git://github.com/emberjs/ember-rails.git' # so we get the pre version
gem 'therubyracer', :require => 'v8'
gem 'ruby-openid', :require => 'openid'
group :test, :development do
# Pretty printed test output
#gem 'turn', :require => false
gem 'mocha', :require => false
gem 'test-unit', :require => "test/unit"
gem 'simplecov', :require => false
gem 'rb-inotify', :require => RUBY_PLATFORM.include?('linux') && 'rb-inotify'
gem 'terminal-notifier-guard', :require => RUBY_PLATFORM.include?('darwin') && 'terminal-notifier-guard'
group :development do
gem 'binding_of_caller' # I tried adding this and got an occational crash
# gem 'stacktrace', :require => false
#20 By: rs999, February 6th, 2013 19:43
Which is why I am wondering why they didn't go down the .NET/SQL Server route. Maybe Jeff got bored with that stack or maybe he saw something in stackexchange that he thought he could do better with Rails?
#21 By: Neil, February 6th, 2013 19:59
Why choose only no sql vs. sql? Discourse uses both PostgreSQL and Redis. Relational is good. No sql is good.