Live data from Hacker News

Moving from Go to PHP Again

dannyvankooten.com

301–310 of 371 posts

Re: Moving from Go to PHP Again

#301
post #64

Earlier quoted context omitted.

> Each PHP file is an endpoint. As opposed to having routers in code or client side SPA routing. Which becomes a security issue due to accidental endpoints or uploads becoming endpoints. Or becomes a mess of imports. Either way, PHP frameworks often end up with a central router anyway. > PHP files can be deployed independently, swapped out or updated live. Which means some people try to do that the naive way and end…

You can create a mess of code, open security holes, and/or be hit with ‘gotchas’ in any web framework. PHP is much less complex than most.

You can create a mess of code, open security holes, and/or be hit with ‘gotchas’ in any web framework

Yes, but the holes and gotchas are worse when they are baked into the language. The thing that Golang gets right, is that the developers are willing to eschew features to avoid gotchas. It's like other languages are sports cars with sexy lines and fancy features that everyone wants, but have to spend more time "in the shop." (An analogy for in the debugger.) Golang is more like a base model Toyota Corolla with a manual transmission.

Not sure what PHP is like. Maybe some sort of modder car. Like Perl and Ruby, PHP grew by readily adding features in response to demand. In that way, it's the opposite of Golang.

PHP is much less complex than most.

That depends on what level you're looking at. PHP is one of those languages that has a lot of complexity baked into it in the form of language design warts. In order to make it a nimble language, you have to ignore/eschew parts of it, and stick to some "good parts."

Re: Moving from Go to PHP Again

#302
post #133

Earlier quoted context omitted.

As someone who was about to ditch the PHP ecosystem 6 years ago for something like Rails... frameworks like Laravel absolutely changed the PHP ecosystem. Also since the release of PHP 7.0, core development seems to have really picked up with good stuff in every release (7.3 was just released a few months ago).

I just do not understand the fascination with Laravel. When the first version of Laravel was released Symfony was already lightyears ahead. The only thing Laravel had going for it was that you could take more shortcuts, and it was a pain to integrate into any IDE if you wanted decent autocompletion.

Laravel is not what it used to be either -- Laravel 5 is far more capable/usable than Rails or Django. It's ecosystem is vaster, much stronger community, better docs, faster -- pretty much every state it's better than it's competitors.

Not an end-all be-all, but worth noting: https://github.com/topics/framework

Re: Moving from Go to PHP Again

#303
post #173

Earlier quoted context omitted.

I really don't see what makes php a spaghetti mess. Spaghetti code is a skill issue, not a language issue

No, I am speaking about the ecosystem. Large, industry-grade projects developed in this language. What standards did Wordpress set a few years ago? Huge, disjoint sets of files spread throughout the themes folders. How much time does it take me to understand which of these files is causing the error? Do you still upload your code via FTP directly to the web server? Do you still reset the code cache for the PHP in ord…

> Do you still upload your code via FTP directly to the web server?

It's pretty rare that this is even an option, since no one in their right mind would set up an FTP server with access to anything important.

SFTP? I don't see why not. No need to make things more complex than is necessary.

I don't remember any particular problems with code caching when I did PHP development, though maybe you use a different caching tool than I did. Also, Wordpress is its own beast, and is generally reviled by most everyone, expecially PHP programmers.

Re: Moving from Go to PHP Again

#304

Earlier quoted context omitted.

However, deploying a Flask/Django/Rails app still is usually less fun than deploying a PHP app of the same spec written w/ Symfony or Laravel. Configuring a service to monitor gunicorn, which itself took a bit to configure, before I begin configuring NGINX or Apache... it's really a pain in the butt. LAMP/LEMP stacks just... are

So ease-of-install beats code quality, code readability, security, future maintenance and better tooling. Dang. LEPP (nginx, PostgreSQL, Python) stack seems to me an all-around better stack for most of the deployments people use LAMP for.

If you compare it to a generalized Lamp stack, sure. Compare it to Laravel, and you have no solid basis for "code quality", worse readability, it's Fortune 100-levle-secure, future-maintenance -- Laravel is more active than any other community out there, and has significantly more tooling.

https://github.com/topics/framework

Re: Moving from Go to PHP Again

#305

Earlier quoted context omitted.

no, seriously, the old dynamic script as program requiring a web server needed to be configured properly to avoid leaks of a thousand faces .. thanks but no thanks I'll be flask-ing

Just use Laravel and its eco-system, it's just as easy or easier to setup than Flask and easily production ready. This is an old-take on PHP and no longer true in 2019.

I know about laravel, but that above comment mentioned LAMP era as golden .. you know

Re: Moving from Go to PHP Again

#306

What IDE do people use for PHP these days? Editing PHP in a standard text editor is a pain because most don't supporet "Go to definition", or "Find all refernences" (Two killer features of Visual Studio)

Most of my work on a daily basis is PHP (Laravel) and I use Visual Studio Code as my main driver.

It's pretty good with Python too, which we have a little bit of (mostly Flask apps).

Re: Moving from Go to PHP Again

#307
post #13

Each PHP file is an endpoint. As opposed to having routers in code or client side SPA routing. PHP files can be deployed independently, swapped out or updated live. No building/compiling of the php files needed. A single layer as opposed to 'modern architecture' where there's client side back/front end layers, api layer, logic, validator, data access, and ORM layers. Can extend itself as it runs. For example Wordpres…

> Each PHP file is an endpoint. As opposed to having routers in code or client side SPA routing.

Not if you're using... literally any modern framework and deploying it properly. This hasn't been the case in years except for common legacy stuff like Wordpress.

Re: Moving from Go to PHP Again

#308
post #19
post #11

Earlier quoted context omitted.

Hm, I hate to be on the bandwagon, but why WordPress? One of the things that has made PHP become what it is today is a focus on good software engineering and the introduction of language features that are required by that. WordPress did not keep up on the engineering front and there are so many amazing options out there now for well written, well engineered platforms. Even in pre-built blog platforms. You're not alon…

I am completely out of the loop here. All I know is that I really disliked Wordpress and really-really disliked Drupal back in the day. Can you mention some of the better alternatives? Once in a while a PHP CMS is what I gotta deal with and I dread it, because of the said systems.

FWIW, Drupal is way better now.

Re: Moving from Go to PHP Again

#309

Earlier quoted context omitted.

And java is a memory hog quite painful to deploy and tune.

Yes, launching a new server/executable in java is a PITA dur to the JVM warmup (at least it was a few years ago, don't know whether they improved that point or not).

Don't forget that you also have to install and update the JVM. We admins don't like that.

Re: Moving from Go to PHP Again

#310
post #264

Earlier quoted context omitted.

And java is a memory hog quite painful to deploy and tune.

Memory hog only by those that don't know what they are doing and happilly new everywhere. Yes it is hard to tune, but not so much different than playing with C or C++ compilation switches, across each compiler that is being used in production.

> Memory hog only by those that don't know what they are doing and happilly new everywhere.

Go uses an order of magnitude less memory for most type of workloads though. Also you don't tune c++ binaries delivered to you. You have to tune the JVM's option to death for big apps. I can't count the number of incidents "solved" by raising the Xmx param.

Post reply on HN