Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Moving from Go to PHP Again

dannyvankooten.com

Post reply on HN
Print view View original

71–80 of 371 posts

Re: Moving from Go to PHP Again

#71

Post by chx »

vesak wrote: post #67
chx wrote: post #38

Earlier quoted context omitted.

Does it? If you declare strict, use strict comparison operators and typehint your arguments and returns, what more care do you need? These are not particularly onerous, the strict declaration is trivially templateable in any editor as it's the first line, you'd write types in any language and getting used to only use === !== and forget == and != is ... easy?

What's the equivalent of === for in PHP?

Use for numbers and strcmp for strings. A strict type > would be very weird because besides returning TRUE and FALSE it'd need to throw a TypeError, I guess?

Re: Moving from Go to PHP Again

#72

Post by gnarcoregrizz »

acomjean wrote: post #44
ggregoire wrote: post #39

Any idea why PHP has such a bad reputation compared to other interpreted and dynamically-typed languages such as Python?

Its a quirky little language and the early versions weren't great. The language can be inconsistent in places, and embedding php in the html made for a rapid though sometimes trying experience. Its keeps backward compatibility which keeps those quirks in there. (though with new 7 series php versions older stuff is starting to break.) Someone wrote an article with a title like "php a language with terrible design" tha…

"and embedding php in the html made for a rapid though sometimes trying experience."

Funny, that is React/JSX's biggest sell

Re: Moving from Go to PHP Again

#73

Post by zepolen »

trixie_ wrote: 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.

Except in reality once you want to use non /whatever/file.php as urls - you're back to implementing a router

> PHP files can be deployed independently, swapped out or updated live. Intuitive, simple, powerful. Can be as easy as editing a php file in notepad and dropping it on a ftp server. Deployed.

Except in reality, you don't want to deploy directly after editing a file since it's like deploying to production, you're gonna have a bad time.

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

Except in reality, that just leads to a bunch of spaghetti code with no separation of concerns and impossible to maintain.

> Can extend itself as it runs. For example Wordpress, running off of php files can download plugins to its own server (which are just more php files) to instantly extend itself. Without restarting or redeployment. (What other web platforms can do this?)

Except in reality, this only works with php apps that have an integrated package manager and even then it leads to problems when a version is incompatible both in php or plugin dependency.

> Amazon lambda may have more in common with PHP in terms of discreet deployable units of functionality. What's old is new again.

Except in reality, serverless lambda is a terrible idea:

1. lock in to a specific platform with limited visibility tools and a dependency on a 3rd party when shit doesn't work

2. when functions change you run into function incompatibility chaos and no smart way to handle that mess

3. the "scalability" win is a lie, it's just deferred to whatever data storage service you are using - which ends up blowing up because while serverless scales, the db doesn't

4. addendum to 3, the statelessness of lambda means you can not use local caches to increase your throughput - increasing your hardware requirement

> Compiling/deploying an entire system to change a single endpoint feels backwards after using PHP.

Except in reality, you are notified of a bunch of potential bugs right there and then, instead of "maybe" finding out about them at runtime especially since PHP will by default consider a non defined variable just an empty string and display it as such on the page, and it's not until Joe User notices it that you'd ever find out.

Re: Moving from Go to PHP Again

#74

Post by zepolen »

jszymborski wrote: post #31
benatkin wrote: post #12

Earlier quoted context omitted.

Flask is a good alternative to Django for building web apps with python on the backend. If I'm using react or vue with a JSON API, I don't need the form support in symfony or django.

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

Setting up and monitoring those apps are as simple as apt-get install uwsgi and writing 10 line /etc/uwsgi app.ini config file.

Deploying is as simple as touching a reload.wsgi file.

Re: Moving from Go to PHP Again

#75

Post by agnivade »

oconnor663 wrote: post #58
12298765 wrote: post #52

Earlier quoted context omitted.

I'm curious, what is painful about it? I came to Go from mainly C++, Java, and Python background, and I feel like it's the best of all 3 (to me). It's compiled and really fast (like C++), it has a great set of libraries and community interaction/support (like Java), and it has simple syntax that is clear and quick to understand (like Python). It's not a perfect language (nothing can ever be), but it's become my favor…

Personally I found it too easy to accidentally forget to check an error, or to shadow a named error return, or to create a nil error that doesn't compare equal to nil. Also to write a method that appears to mutate the receiver but which in fact copies it.

> I found it too easy to accidentally forget to check an error

Use https://github.com/kisielk/errcheck for that.

Or prefer https://staticcheck.io/ for a larger set of checks.

Re: Moving from Go to PHP Again

#76

Post by viraptor »

trixie_ wrote: post #64
viraptor wrote: post #60

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.

These are things very specific to PHP. Yes, there are language-specific gotchas in many environments. But I'm criticising specific things that do exist and that I've seen causing issues in real deployments. Things that make PHP accessible make it also an excellent footgun.

Re: Moving from Go to PHP Again

#77

Post by nprateem »

gnarcoregrizz wrote: post #72
acomjean wrote: post #44

Earlier quoted context omitted.

Its a quirky little language and the early versions weren't great. The language can be inconsistent in places, and embedding php in the html made for a rapid though sometimes trying experience. Its keeps backward compatibility which keeps those quirks in there. (though with new 7 series php versions older stuff is starting to break.) Someone wrote an article with a title like "php a language with terrible design" tha…

"and embedding php in the html made for a rapid though sometimes trying experience." Funny, that is React/JSX's biggest sell

React can't execute arbitrary database queries.

Re: Moving from Go to PHP Again

#78

Post by ggregoire »

gnarcoregrizz wrote: post #72
acomjean wrote: post #44

Earlier quoted context omitted.

Its a quirky little language and the early versions weren't great. The language can be inconsistent in places, and embedding php in the html made for a rapid though sometimes trying experience. Its keeps backward compatibility which keeps those quirks in there. (though with new 7 series php versions older stuff is starting to break.) Someone wrote an article with a title like "php a language with terrible design" tha…

"and embedding php in the html made for a rapid though sometimes trying experience." Funny, that is React/JSX's biggest sell

Not really comparable tho. In React, the JS in the HTML is to make loops and conditional rendering, i.e. presentational logic, like in any other templating system. In PHP, you can embed business logic and database accesses in the HTML.

Re: Moving from Go to PHP Again

#79

Post by Double_a_92 »

pasta wrote: post #68

I agree with the author. Symfony 4 is the best PHP framework at the moment. Trying both Laravel and Symfony I think there is no need for Laravel (anymore). Laravel just has too much magic that will bite you later on. The only thing you should skip in both frameworks are 'annotations'. But this is easy to do.

> Laravel just has too much magic that will bite you later on.

Especially when that is not explained in the docs or just in a very vague way...

I tried improving the docs by pointing out where magic (e.g. fix naming conventions) is needed and where not, but the mantainer just turned that into vague mush again (after he had even agreed to the changes).

Also if you need any more details that are not in the docs, everyone points you to paid video courses that assume you have a Mac...

That honestly leaves me with a bad taste im my mouth after trying laravel :/

Re: Moving from Go to PHP Again

#80

Post by noir_lord »

chx wrote: post #38
the_duke wrote: post #10

Earlier quoted context omitted.

Symfony and Laravel are really nice. It's still a horrible abomination of a language that invites bugs and requires A LOT of care to not produce buggy code, though.

Does it? If you declare strict, use strict comparison operators and typehint your arguments and returns, what more care do you need? These are not particularly onerous, the strict declaration is trivially templateable in any editor as it's the first line, you'd write types in any language and getting used to only use === !== and forget == and != is ... easy?

There is an absolutely phenomenal static analyser for PHP called enhanced inspections EA (free version and commercial very) that will flag == when === should be more appropriate (among many other things).

For people not using Intellij (or wanting a tool that can be used as part of commit/deploy setup there is phan which is well executed).

I've mocked PHP for a long time (been using it for various day jobs for over a decade) but they've made massive strides in the last 2-3 years to the extent where used properly it's approach 'not a bad' language status.

Post reply on HN