Ruby guys can always do the argument "Our code required 50% more servers, but it increases developer productivity by 50%, and since developers cost more than servers - it is a win".
Has anyone ever really made that argument with PHP? It seems one of the least developer friendly languages possible on a large project. So developer unfriendly + server unfriendly = ?????
The 1 million Badoo saved here is nothing compared to how much more money they made from having these people build their platform.
That is a sad, albeit realistic thought.
Well that's true on a certain scale. There is no way I could have completed some projects with a small team, in a short amount of time if I had to use some like Go or Rust. Ruby,Python or PHP are useful for what they are good at : "front-ends" (on the server). So is Java by the way, but while Java is fast it eats way too much memory while doing nothing. Again, at a certain scale , developer cost VS performance cost is a reality. It's not very useful to boast about chosing Go or compiled language X or Z while your competitor can bring an app into production in 1/8 of the time it takes to develop the solution in PHP.
AFAIK Parse.com spent a year rewriting their Ruby app in Go. In the meantime, there brought no new functionality and then they just closed shop. Sure they got to write a fancy blogpost about how successful they were with Go. so successful they rewrote their app in nodejs when they decided to opensource it.
> So developer unfriendly + server unfriendly
How is PHP developer unfriendly ? It has 15+ years of libraries to do almost anything. You should probably have a look at PHP7 before passing any kind of judgement.
How is it server unfriendly ? PHP is with Java the most deployed language in the world.
It's junior-developer-friendly, but if you want to do something serious, there are better options.
Using a modern framework like Yii2 makes it just as good as any other modern franework in any other dynamic language (rails, django, entity, etc). Yii2 performance also doubles from PHP5.6 to PHP7 for those interested: https://caleblloyd.com/software/yii2-php-7-performance/
But what kills PHP for me (and Rails and Django, for that matter) is the lack of native support for asynchronous operation and poll/epoll.
If you're stuck with one thread per user, then you can't scale beyond a couple thousand concurrent users on one system without latency getting terrible.
You can just do so much more on one server with Node it's not even funny. 70k queries per second with low latency are not uncommon; add in some work and that goes down, of course, but a well written app can have 20k+ queries per second of throughput.
Even PHP 7 with WordPress in cached mode only brags of ~5k queries per second. You could likely do 4x that in Node without trying -- and possibly even without caching.
> Modern
Pick one.
Please demonstrate that Yii 2 is as feature-rich as Rails 5. Thanks.
A fairly large internal php service at work just wasn't working well enough for us (for a lot of reasons), so I decided to try writing a drop in replacement in go (as in, the server would respond to `whatever/endpoint.php`).
It took about a month and a half, but the translation process was actually incredibly straightforward. Like, I automated a bunch of it straightforward. Most of my time was spent writing unit tests where the other codebase didn't have any. Maybe it was just how that php was written (totally frameworkless), but both languages seem to be fond of straight-forward imperative code, and IMO a junior developer could be just as efficient writing go as they could php.
And man I don't even like go.
Consider programmatically working with email. Nightmarish, despite the number of users.
I'm not sure what you're getting at, Working with email is a nightmare in any language, Go or Rust or language of the moment X included.
Regarding development speed, I don't know much about Ruby but I believe you're conflating speed on Rails (a framework) with Ruby vs PHP (languages). I've also seen RFP respondent development companies assert that PHP development would be faster than compiled languages, despite them having developers with both skillsets available.
No, please show me where I said that? Every program has a developer productivity factor, a library support factor, and yes a runtime speed factor. From everything I know about PHP, while not being a PHP programmer, it has both low productivity AND low performance. Many other languages offer some combo of productivity and performance that are much better.
> The amount of effort described to migrate is orders less than rewriting millions of lines of production code.
Sure, and that is why you should think very carefully about what language to write in BEFORE You write 3 million or even 100 lines of code.
> Regarding development speed, I don't know much about Ruby but I believe you're conflating speed on Rails (a framework) with Ruby vs PHP (languages).
Ruby is rails, there is no ruby without rails, there is no rails without ruby. I see almost nothing being written in straight ruby (why would you).
You should probably stop, it's quite embarrassing. It's obvious your "everything" is just about "nothing".
This is so wrong. Regardless of the fact there are very popular Ruby web frameworks out there that are not Rails (Sinatra, Grape), Ruby is immensely useful as a general purpose programming language. I use it daily for all kinds of reasons. I even use it to do my taxes. For anything where speed isn't important, and it often isn't, Ruby is useful.
I know I'm not alone. Martin Fowler, for example, uses Ruby as his personal scripting language. http://martinfowler.com/bliki/OneLanguage.html
Funniest thing I've read all day. My last web app didn't use rails at all and I'm actively trying not to use it these days because I don't need most of the features it includes and turns on by default.
This is so.. so wrong. Please take a look here: https://github.com/trending/ruby?since=monthly
You're also forgetting the time period. Many web projects used PHP and built businesses from them because that was the defacto. Web stuff pretty much meant Apache/PHP/MySQL for a time. Now there are better choices, its easy to say better choices should've been made in retrospect. Then again, that's always the case no matter what the less than ideal decision was without the knowledge of today isn't it?
That would depends largely on your developers. I know it's weird but PHP developers tend to be really productive in PHP.
If productivity == not writing the same boilerplate over and over, not so much.
Assuming you don't include the cost of converting their 3 million lines of code to a new language and the cost of learning a new language. Of cause they did need to "port" from PHP5 to PHP7, but I feel that it's cheaper than going to a completely different language.
You're not wrong, but the $1M saving is much cheaper bought than the $1.9M. PHP is a weird language though, it's easy to get started with, pretty efficient at this point, and yet somehow people use it to write ugly and sluggish code. I haven't written PHP in a long time, so this may have changed, but it almost like the language is missing ways of structuring the code in a sane way.
The whole mixing of HTML with PHP with SQL is bad form and is widely discouraged. In fact, this code is often seen with usage of mysql_ functions plus manual escaping and interpolation. This is discouraged to the point where that library has been removed.
I'm no evangelist, I prefer other languages, but with these "good parts" so to speak, the language is usable and supportive of good structure. We have had these improvements relatively late in the game but they do appear to come thick and fast nowadays.
There are many warts in the language. Sometimes I'm angered when very good ideas for progress are shot down via committee. There has, however, been improvement since PHP 4.
What I meant was mixing them together in the same piece of code. The other comments explain why: its doing too much, its difficult to maintain and reason about so its harder to find bugs, especially serious ones, and difficult to fix them.
Anything involving manipulating your data / business logic should not be embedded in a template.
PHP in your html should really be for display/rendering (i.e. looping over a list of Employee records), it should not be fetching those records itself (either by Employee::fetchAll() or especially mysql_query("SELECT * from employee") )
It is very hard to maintain or even reason about a file or make a change or secure exploitable edge cases when the application has html, css, javascript, php, and calls to the database in the same place.
Sounds like you haven't touched it in a while - it's quite different from even 8 years ago.
No I am not. I am talking about 1.0 decision. Obviously 10 years down the road with 3 million lines of code you have to compare conversion cost.
It's only unfriendly to those who don't actually know the language.
Where's this better than Wordpress (in functionality, not codebase) project in another language, for example?
Considering the extra baggage and ceremony that comes with most compiled languages, that sounds like a bad proposition, especially given that they ALREADY had 3 millions of lines of PHP working just fine.
I've always wondered on the ROI of saving server cost at the expense of velocity. After all, server cost is for the foreseeable future, but development is just once (yes maintenance, but that is very small if you stop adding features).