So many words about PHP, but I wonder what exactly is there in Ruby that Discourse uses that is not available in PHP. What I know for sure is that with PHP there would be much more contributors and plugin makers.
Principle of least surprise? Some proper design?
Dynamic method declarations / monkey patching. Lack of primitive types, everything is an object. Arrays and hashes as distinct object types…
Is this really used in the the Discourse codebase?
This is about language characteristics while I’m asking about what would be so difficult to do in PHP that Discourse needs and does it much easier with ruby?
There is no sense for a holiwar of PHP vs Ruby cause pretty anything is doable and very easy in both languages…
I’m just saying it’s very strange to say PHPBB is wrong because of PHP. If you don’t like / use that language, it means nothing, so I’m curious to know which language specific features are really in use and simplify things compared to PHP.
To be more specific, my point is not against Ruby but against the lower number of people available to contribute and create plugins. And saying
everything is an object is definitely not a reason to choose one language and not another.
Check out Discourse’s SiteSetting class. All of the accessor methods are created dynamically after parsing the
site_settings.yml file. It’s also used excessively in Rails’ Active Record.
Objectively, nothing. Both languages are Turing complete, they can solve any computable problem. However, so is Brainfuck. Go ahead and write Discourse in that language…
Ruby makes life easier for a developer because it isn’t carrying around backwards-compatibility. For instance: PHP’s arrays are still primitive datatypes and must be wrapped to allow OO access. Enumerating through a collection of elements requires different code depending on whether the collection is an array, hash or a database relation. That makes code messy and the programmer’s life harder.
Unfortunately, I’ve lost track of PHP’s development for a while, but I would assume that there is no equivalent and no way to replicate Ruby’s
BasicObject#instance_exec method which enables powerful custom DSLs.
The story goes that when @codinghorror was deciding how to build Discourse, he was looking at which language communities would be beneficial to OS projects, and also the skills of the team members he wanted to work with. It came down to Ruby or Python.
We are only discussing PHP because it is seen as the default web language - but excluding that point, it has no advantages. And how will it be in the future? In ten years time PHP will seem even more outdated than it does now.
My point is that the decision was more down to the culture of the OS communities for each language than the specific technical details of them. Discourse, though it does use monkey patching and other Ruby features all over the place, doesn’t really need to have been built with the tools it has. That these features are being exploited speaks more to the skill of the dev team than their intrinsic value.
PHP isn’t optimized for web applications. It’s mostly optimized for web scripts.
For one, Discourse’s real-time nature is much more practical to implement in Rails than in PHP.
I’m sure that you could mess around with AJAX instead of WebSockets or to have some never-ending script running… I’ve heard that there’s a few memory leak issues involved in that though.
The memory leaks have nothing to do with the PHP Language itself. It’s mostly to do with how the engine is built. PHP mainly relies on releasing memory at the end of the execution of the current script.
It doesn’t expect you to be running one program endlessly. This is where the problem stems from, in my opinion.
Actually, Discourse uses Ajax-polling, not WebSockets. Thus it would be just the same in PHP.
Thanks, this answers my original question sensibly.
I was under the impression that Discourse was using WebSockets, due to the high browser requirements as it’s only available in the most cutting edge browsers. I figured that if Discourse had such high requirements then, it would be taking advantage of every latest browser innovation.
Thank you for the correction.
Sam made a great in-depth explanation about why Discourse doesn’t use WebSockets. (hard to search for because he added spacing between!)
This is not quite a duplicate since it is about PHP and contributors, but most of what you ask is answered at
I read this as
Why didn’t you build Discourse out of duct tape and paper clips? Lots of people know how to use duct tape and paper clips.
Yes, indeed they do… but sometimes you want to build a building out of more substantial building materials like steel and concrete.
It is actually interesting whether Google Go was considered as a platform for Discourse. It is even more radical transition from PHP than Ruby or Python with some performance and coding advantages over both of them.
I might be wrong however, I believe that Google Go is a language which is on the same sort of layer as C/C++/etc. You could also ask why Discourse isn’t written in C++ or Java. Less people code for this layer, as it’s much much harder.
This means that a much smaller people would get involved in the Discourse development.
They aren’t building an OS or a browser here, it’s a forum software.
And honestly, I have no clue where Go is going to go. Google has this habit of starting up sites / projects / etc. and then, they decide to abandon them due to lack of interest, if it doesn’t gain momentum fast enough for their liking.
Because no sane person would write a JSON api in PHP.
I don’t think it’s JSON specifically which is the problem.
JSON in particular isn’t too painful.
In terms of problems, PHP actually has a ton of useful libraries, which are disabled by default and which you have to enable. You can’t do that from a script, you have to do it when you build it.
This creates the terribly annoying situation where you have a really useful library like… say… Unicode (Multibyte and iconv) but, you have no clue if the end-user has it enabled (it’s bundled with PHP) and so, you have decide whether to make it mandatory (and risk losing some people) or complicating your software.
Some of the standard functions support Unicode. Some of them don’t. htmlentities() does. substr() doesn’t. You have to do mb_substr (Multibyte Extension) to do Unicode instead of substr otherwise, you risk a possible vulnerability depending on how you handle it.
$title = htmlentities(html_entity_decode(substr($title,0,32), ENT_HTML5,"UTF-8"),ENT_HTML5,"UTF-8")."..";
So, I end up with code like this with PHP to completely rule out the risk of XSS vulnerabilities. (I don’t think there are any other surprises here, are there?)
It’s possible in PHP. I wouldn’t recommend it, but it is possible with an extension. It’s not bundled with PHP. It was one of the PECL ones, I believe.
I wouldn’t rely on some of it’s features, like the sandboxing though and you have to jump through hoops to install it as the developer lost interest in it.
Right, and you can, well…
The question remains, why would you?
It does appear that your concern is surrounding why not choosing a more popular language like PHP.
That could have potentially benefit the project with more contributions.
I read somewhere that having a high entry barrier (a more complex stack), will naturally and selectively allow to more advanced programmer to contribute. Which can hypothetically translate into Quality over Quantity. I am not sure if that was a consideration in the initial decision or just a side affect.
Ok I will take the rule of php defender on this one
I also lost some track of php development, I might be mistaken here but PHP 5.4 support anonymous functions and you can bind to an object scope.
I am not sure configuration is a problem, Discourse is installed in a Docker container, which is a like womb that nourish the baby with whatever it needs. and it isolated from the outside world.
if it need PHP version 6 and multi-byte enabled it can get it. and it is not the “end-user” call.
so I am not sure if this is a valid concern.
I can see why better Unicode support will actually put ruby in favor over PHP. but this should not be language war discussion. or may be it is, already.
With PHP, much of the hosts are shared hosts so, it very much is a situation where the host decides what is enabled when they install PHP and each extension adds overhead. This is contrary to just loading an extension when you actually need it.
Even if you’re hosting it yourself, if you find that one software needs something, you’d have to reinstall PHP again and make sure that you pass the right parameters to it.
Switching hosts can be a big PITA especially, when you have a domain with a specific host.
This means that people can easily pass over a software over the requirements alone and it happens a lot in the PHP world and upgrading isn’t exactly frictionless for the hosts.
The problem with PHP’s Unicode implementation is that it’s inconsistent. MySQL supports Unicode however, PHP for the most part doesn’t which has been the cause of quite a few SQL Injection vulnerabilities.
Some of the built-in functions support Unicode. Some of them do not. You more or less need to look-up each and every one of them to find out.
Mixing encodings is a common source of vulnerabilities, as the database engines usually support and default to Unicode. Vulnerabilities which are easy to create however, they can be time consuming to fix and PHP doesn’t have a sensible default for many of the encodings which the functions default to.
PHP is fundamentally insecure and you have to go out of your way to make it secure.
This isn’t a language x has feature y discussion. This is a problem which makes it harder to write secure code.
When you look at software like MyBB or phpBB, you can clearly see how much work they’ve put into securing it in the code and it’s mainly due to PHP itself.
I’m actually leaving out a lot of information about how horribly inconsistent the functions can be about encoding as otherwise, I’ll be here all night.
Needless to say, some of them support Unicode (preg_* has it’s own way of doing it, as part of the Regex), htmlentities has a third parameter for the encoding, substr only does ASCII, mb_substr has a parameter for the encoding, MySQL supports Unicode and the default encodings can vary.