Live data from Hacker News

Taking PHP Seriously (2016)

slack.engineering

91–100 of 150 posts

Re: Taking PHP Seriously (2016)

#91
post #77

Earlier quoted context omitted.

Really depends on what the business is doing. Chewing through TBs of data every hour? Probably not a good idea to use Ruby. Doing a bunch of really heavy math? Probably not a good idea to choose PHP. Doing a SaaS service? C++ probably isn't a good choice. There are some really good general purpose languages that can fit most circumstances (Java, .Net languages, Go). However, I'd be careful to say that you could apply…

I hate to be "that guy" but I see no reason not to use PHP for all three of those things. PHP is faster than Ruby. [1] PHP from a local script does math just fine. It's the round trip of the request to a PHP server and back that you're associating with poor language performance. In a local scripting environment PHP7 is considerably faster than Python3. [2] PHP is an extremely popular language as the backend for SaaS,…

Well, if you have to chew through TBs of data every hour, don't use PHP i think? Unless you're not in a competitive business and you can pretty much throw money at the data?

I think to OC is not well formulated: If you're selling a web app or web SAAS, any language the founders know best is the best. Any other stuff, it is not always the case (but it might be!)

Re: Taking PHP Seriously (2016)

#92
post #18

The best language for a startup is one the founders know the best. Every other discussion will at best make a 1% difference.

I often hear engineers rave about lisp. Is that really such a superior language?

No, its not, but it is a fun language. I'd take a lisp job over anything if i found one. Not because it is the best language (it is not the best at anything, except maybe prototyping), but because it is fun, and interesting to work with it.

Re: Taking PHP Seriously (2016)

#93
post #65

Earlier quoted context omitted.

This assumes Google can't figure out crawling SPA.

That's correct. Generally, when I'm building a business, I prefer not to assume that Google will eventually, at some point in the future, solve the crawling a SPA site problem and finally discover my site. I'd rather get my 70%-80% organic search traffic today , with any boring server-side rendered tech stack.

I don't think I want any crawler ever hitting my API endpoints for customer lookups, scheduling, inventory management, etc - all that stuff that is the 'Application' part of 'SPA'.

Why people use js/spa/etc stuff as the basis for a content/marketing site... I don't know. I mean... yeah, I know why - mostly to expand their skill set. But there's usually no functional benefit, and usually some drawbacks, as you're pointing out.

Re: Taking PHP Seriously (2016)

#94
post #89
post #18

The best language for a startup is one the founders know the best. Every other discussion will at best make a 1% difference.

The best language has an appropriate ecosystem as well - everybody hates PHP, but it's damn easy to plug in payments and .

Not everybody. And yes, PHP ecosystem, and more specifically, Laravel's ecosystem, is incredibly rich and vibrant.

Re: Taking PHP Seriously (2016)

#95
post #13

how's PHP's websocket support? presumably if it's a thread per websocket then they're using something else to serve that?

Pretty great with https://github.com/ratchetphp/Ratchet tbh. But yeah, different runtime. Ratchet is built on top of ReactPHP which is an event-loop runtime (think nodejs). It's helpful to be able to reuse some domain code between the two if necessary, but IO cannot be done the same in ReactPHP because it needs to be async. Good news is ReactPHP has a ton of really great async libs (mysql, redis, etc.) https://reactp…

fyi on swoole, this book [1] just came out (I cannot comment on the quality, haven't read yet) which hopefully will help bridge the English documentation gap. I've been using swoole for a couple of years and google-translating my way through the Chinese wiki and git issues/comments/etc.

[1] https://www.amazon.com/dp/B0881B227S

Re: Taking PHP Seriously (2016)

#96
post #50

Somewhat unrelated comment, but the fact that PHP got so good and most people are still not willing to give it a second chance goes to show how hard it is for a language to regain market share after people left for greener pastures.

Forum share, maybe, but it's been and remains an extremely popular language.

Yes, it is a bit silly to paint it as some unloved, underrated diamond in the rough. It's hugely popular.

Re: Taking PHP Seriously (2016)

#97
post #79

Earlier quoted context omitted.

"Use an IDE" is never an answer to shitty language design. Shitty language design is shitty language design. That said, I cut my teeth on PHP and still have a fondness for it. It's especially great being able to deploy small little backend-driven pages with rsync or sftp in a pinch. I just discovered other languages and environments I enjoyed working in much better.

If there's room for Javascript, there's room for PHP. Both are sloppy, inferior languages, but both can do anything you need. And unfortunately, both have immense momentum from being first in the web game.

Ha, I was going to make a comment along these lines. I didn't mention the languages I enjoy over PHP but I can assure you JavaScript ain't one of them. I don't hate JS but as a server-side language I would pick PHP over it any day.

Re: Taking PHP Seriously (2016)

#98

Earlier quoted context omitted.

> Somewhat unrelated comment, but the fact that PHP got so good and most people are still not willing to give it a second chance goes to show how hard it is for a language to regain market share after people left for greener pastures. I guess some of the reasons why some devs would not chose PHP (horrid syntax, std lib mess, stupid error reporting system, language inconsistencies, the very existance of php.ini, overr…

> As companies move to single page applications backed by javascript and REST API, PHP CGI style classic execution model provides no advantage, when it comes to generating or serving web content I lol'd. SPAs are a fad. Apps that rely heavily on REST API and browser rendering rank terribly on Google. Create a SPA and help your customers discover your competitor on the first page of Google.

I lol'd.

SPAs are great if your customers actually want an application. Figma, AirTable, Google Sheets. These don't make sense as server rendered pages.

If you're in the publishing business and need your articles to rank high on Google, then yeah its probably not a good idea.

EDIT: Or Slack for that matter

Re: Taking PHP Seriously (2016)

#99
I'm admitting it. I LIKE PHP. It's fun and incredibly easy to work with. I have inherited messy code bases. I have inherited nice code bases. But getting it up and running is _never_ a problem that I have had.

Re: Taking PHP Seriously (2016)

#100

Long live PHP. 15 years of PHP dev work. Games, mobile apps, health care, etc. I have been unemployed for 2 days in 15 years. PHP runs %80 of the internet. Talk to anyone at facebook that wears a suit on friday -- they code PHP (and it seems to scale for them). I think I will be 90 years old hacking on PHP.If you really don't like how the arguments are passed just use an IDE. Or get stuck with real problems like a tr…

Argument order problems are somewhat over with named params: https://php.watch/versions/8.0/named-parameters
Post reply on HN