Live data from Hacker News

Moving from Go to PHP Again

dannyvankooten.com

241–250 of 371 posts

Re: Moving from Go to PHP Again

#241

Earlier quoted context omitted.

Incompetent people will create incompetent things regardless of the tool. Simpler tools lead to simpler messes while complicated tools lead to complicated messes. I've seen an attitude that people think they can inoculate themselves from inept programming by using obtuse frameworks as if martin-fowler-speak acts as a drill sergeant making disciplined coders out of the herd. But after 20 years of bouncing around start…

You won't get 4 folders with 26 files handling simple tasks like uploading images to an S3 bucket (saw this huge mess just last week and guess what?! It's broken. I know, surprising right?) You can see right here on HN anytime a post comes up about using a cloud provider someone advocating putting a layer of abstraction over the provider’s SDK to prevent “lock-in”. As if the CTO is going to one day move their entire…

A poor abstraction is always a poor abstraction, but a good abstraction can not only isolate your components from change but also provide a better interface.

I'm not going to write raw HTTP requests to S3 in every place in my code that I need to read/write objects from there. What I'd rather have is a simple abstraction with methods like get(id) -> obj and put(obj) -> id.

Re: Moving from Go to PHP Again

#242
Symfony 4 is much more lightweight than previous versions. If you create a new symfony 4 project with composer you just get an empty project with just a hand full of dependencies. First time I tried out the v4 (coming from 2.x & 3.x) I thought that the installation did not work properly because stuff like twig (for templating) and other things were missing.

The whole integration in composer with the symfony flex component makes developing even easier than before: https://symfony.com/doc/current/setup/flex.html

Re: Moving from Go to PHP Again

#243
post #32

Earlier quoted context omitted.

Not sure about the OP, but for many Go is the only compiled language they ever used, so they get to attribute features to Go that aren't that unique of it.

> for many Go is the only compiled language they ever used That, or it can be read as "in the family of web-friendly languages". The only other "fast" language widely used for the web is Java.

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

Re: Moving from Go to PHP Again

#244
post #150

Earlier quoted context omitted.

Unless it is mounted noexec why would you risk setting the exec bits on files that are writable by the webserver?

The exec bit is also important for accessing sub/directories. Although for that you should use X instead of x…

Of course. I actually regard this as a fairly major issue with the Linux permissions model. Far too many people do as the GP and accidentally set all the files to executable. Cleaning up after someone has done this on a nested set of subdirectories is quite tedious.

NB if anyone has ever run: chmod -R u+x . or equivalent and you run chmod -R u=rwX the files will stay executable...

You can always use find to set all files to +x and directories to -x but then what if some of files needed to be executable?

Re: Moving from Go to PHP Again

#245

Earlier quoted context omitted.

You won't get 4 folders with 26 files handling simple tasks like uploading images to an S3 bucket (saw this huge mess just last week and guess what?! It's broken. I know, surprising right?) You can see right here on HN anytime a post comes up about using a cloud provider someone advocating putting a layer of abstraction over the provider’s SDK to prevent “lock-in”. As if the CTO is going to one day move their entire…

A poor abstraction is always a poor abstraction, but a good abstraction can not only isolate your components from change but also provide a better interface. I'm not going to write raw HTTP requests to S3 in every place in my code that I need to read/write objects from there. What I'd rather have is a simple abstraction with methods like get(id) -> obj and put(obj) -> id.

Seeing that you can still use the same SQS API from 2006 and that in 2018 AWS still supports SOAP of all things for S3 (https://docs.aws.amazon.com/AmazonS3/latest/API/APISoap.html) , I would much rather be able to just look at the SDK to see how something is used than having to try to debug through an abstraction that the “architect” who was at the company years ago, put in a custom Nuget package trying to abstract the API and imposed s “standard”.

Yeah I have been through that before where the architect of the company wrote his own bespoke ORM, logging framework, etc. and he was the only one who knew how it worked.

Re: Moving from Go to PHP Again

#246
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.

The main thing Laravel had going for it was good marketing.

Re: Moving from Go to PHP Again

#247
post #212

It's interesting that he names Symfony 4 as one of the main reasons he uses PHP again after he already used PHP with Laravel. I have a lot of discussions with friends in the startup scene about the topic of Laravel vs Symfony. So far it's a head to head race. I have yet to find a good 'Laravel vs Symfony' comparison page. Yes, there are tons of 'SEO optimized articles' with this title. But I find them all rather unin…

Those SEO pages are horrible. I had the same problem. But there are multiple reasons I choose Symfony 4 over Laravel. And if you want a code comparison then this small example: Laravel: class User { } Symfony: class User { private $id; private $name; public function getId():?int { return $this->id; } public function setName(string $name): self { $this->name = $name; return $this; } public function getName():?string {…

I don't use laravel anymore, but I had a live template that would generate getters and setters that wrote to set_attribute. As long as you maintained the convention of doing this, you could use autocomplete with getters and setters to accomplish this.

You could also hint these with / @var */ there are ways around it but yes it isn't ideal. I really liked doctrine, perhaps I was using it wrong, but having everything in annotations was pretty nice since migrations etc could run off of it.

With doctrine I ran into issues with performance, which you can alleviate with extra lazy etc, it also hydrated what appeared to be massive objects, which you had to use a custom debugger because print_r'ing one with the recursive references etc caused some crazy issues. I have since moved on from PHP, but if the project calls for it, I have no problem using laravel. While not ideal, it sure is productive to build an API in. I wrote a project in lumen, which is/was a subset of laravel built for APIs, and that was okay to work in. No clue if it still exists.

Re: Moving from Go to PHP Again

#248
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…

Routing is a feature because you can express more complex semantics. Most php apps depend on Apache specific .htaccess files to handle redirects and other routing, and it becomes a mess quickly.

PHP files can be swapped out live because many CGI wrappers don't cache anything in memory, which means at high strain you start dealing with disk load, file locks, etc.

There are many other languages which also don't require compilation, often at the trade off of less performance. Some really clever languages let compilation be an optional step.

A single layer means your frontend logic, data models, and database access all run the risk of being one giant mess. Sure other languages run that risk too, but it's especially prevalent in PHP.

PHP can extend itself - it can also be used to download attack vectors and execute them directly on the server with no concept of code signing. Other languages offer powerful facilities for remote updates if they're desired, but that's usually not the best approach for Web.

You can edit other languages with notepad too.

Being able to deploy a single endpoint to a live server and hoping it doesn't cause problems sounds like terror.

Re: Moving from Go to PHP Again

#249
post #133

Earlier quoted context omitted.

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.

I haven't touched symphony from 1.2 but laravel was a lot simpler to use, especially for begginers. no stupid yaml files, the need to definine everything in yaml before. simpler orm and so on.

When people talk about symfony now they usually mean version 2. Symfony 1 is not comparable to Laravel.

Re: Moving from Go to PHP Again

#250
post #49

Earlier quoted context omitted.

Yup :) You very much just `git clone` a Laravel project, point Apache/NGINX (with PHP-FPM configured) to the `public` folder and all you need to do is run database migrations (for the majority of basic deployments).

I inherited a Symfony2 app and it was a bitch to deploy. It definitely had an asset pipeline. php app/console cache:clear --env=prod --no-debug php app/console assetic:dump php app/console cache:warmup --env=prod --no-debug chown -R apache:apache . # fix owner chmod -R u=rwx,g=rwx,o=rx app/cache # fix cache perms apachectl restart # bounce Apache, otherwise it can throw segfaults

This is sort of a how to not do things:

1. chown -R apache:apache . # Now the webserver will have write access over the whole application!

2. chmod -R u=rwx,g=rwx,o=rx app/cache # Now all files in cache are executable and writable by the webserver!

3. apachectl restart # graceful might be better here.

Securitywise 1 and 2 are not good things to do.

Post reply on HN