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

101–110 of 371 posts

Re: Moving from Go to PHP Again

#101

Post by dangerface »

viraptor wrote: post #76
trixie_ wrote: post #64

Earlier quoted context omitted.

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.

These things are very generic and apply to both lua and asp.

Invisible characters are a problem in every language, configuration file, file period, trying to suggest that its specific to php is just silly.

Re: Moving from Go to PHP Again

#102

Post by spdionis »

00deadbeef wrote: post #85
shittyadmin wrote: post #30

Earlier quoted context omitted.

To be clear, this just means that PHP has libsodium as an official language extension. Most modern languages have better package management than PHP and make pulling it in as a library trivial. This has nothing to do with homomorphic encryption, unless I'm missing something.

composer require some/library That's PHP's package management. What's so non-trivial about that?

And, as a bonus feature, composer install won't automatically update your lock file!!

Unlike some other package managers...

Re: Moving from Go to PHP Again

#103

Post by atsjie »

bsaul wrote: post #86

Honest question : is there any technical reason that prevents a go web framework to replicate the functionalities of symfony / doctrine ?

No.

And there alternatives. The best known is probably Revel: https://revel.github.io

For a doctrine (ORM) alternative you have for example https://github.com/jinzhu/gorm

The point about Go; using those types of tools is generally frowned upon in the community. It's overkill for most (micro)services.

But few gophers build a full-stack website in a single application.

I'm a gopher; I wouldn't want to use Revel or Gorm. I feel I'd be using the wrong tool for the job. I'd more likely use Django or Symfony when I'd need to build a full-stack SSR.

If a backend API is used by different clients (mobile apps, SPA, servers, ...) using a full-stack SSR framework like Symfony or Django doesn't make much sense anymore. You wouldn't use 90% of the framework's features. It feels like bloat.

But many websites don't need to serve different clients.

The author's decision to go from Golang to PHP makes perfect sense if he's building SSR websites.

Re: Moving from Go to PHP Again

#104

Post by [deleted] »

diamondo25 wrote: post #8
tptacek wrote: post #2

For the kinds of applications people tend to build in PHP, PHP is probably a better choice than Go. I'd still do Django or Rails before PHP, but Go just isn't designed to make serverside-rendered database-backed websites especially pleasant to write.

Rest API? Sure. Building webpages? I dont think it was made for that... Although Go templates can work, its still not as flexible as you might want it to be.

[deleted]

Re: Moving from Go to PHP Again

#105

Post by sandreas »

Well comparing Go and PHP is kind of difficult, because they are targeting completely different goals.

After some years of development, both languages have evolved a lot and they both can be used for many other things, that they haven't been designed for.

PHP was a dynamically typed scripting language to build personal homepages (Personal Home Page Tools). Today it is an object oriented, type hinted language that supports functional and object oriented programming, many database management systems and has a package manager (composer). I really like PHP (see https://github.com/sandreas/m4b-tool for a proof), but some concerns about PHP have always been (and still are):

- backwards compatibility reaching too far

- way too big standard library (see levenshtein function)

- the "callable" concept - call_user_func_array([$obj, "method"])

- mixing up too many concepts (OOP, Traits, Functional style)

- the type system (which is getting better with php 7)

- unpredictable statements - empty($x), comparisons (== vs ===) and the "mixed" type

- the "array" type being array and dictionary and...

- the $ used for variable declaration

- $this-> is still needed for calling object methods

- "." for concatenation and "\" for namespace separation

Another bad thing about PHP is, that on most web servers it is meant to be stateless, which means that you are in trouble using technologies like websockets.

Some of these things unfortunately mean that PHP often is much slower than it could be - and this is where "go" can be a successor. Performance. If you really need FAST web apps and performance is the goal, go can be a nice choice. But for getting things done in a not too complex web page, i would always choose php.

Re: Moving from Go to PHP Again

#106

Post by slezyr »

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…

Deployment of Go services is much easier.

Try to deploy any self-hosted service like nextcloud, gitea. It was a nightmare to deploy nextcloud. Also it turned to be too slow for ONE USER.

Re: Moving from Go to PHP Again

#107

Post by ddtaylor »

sandreas wrote: post #105

Well comparing Go and PHP is kind of difficult, because they are targeting completely different goals. After some years of development, both languages have evolved a lot and they both can be used for many other things, that they haven't been designed for. PHP was a dynamically typed scripting language to build personal homepages (Personal Home Page Tools). Today it is an object oriented, type hinted language that sup…

> - the "callable" concept - call_user_func_array(["object", "method"])

For at nearly 10 years now PHP has had support for lambdas, meaning for most uses `$foo()` can be used instead and with the inclusion of the spread operator it's seldom used.

Re: Moving from Go to PHP Again

#108

Post by the_gipsy »

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.

With PHP it is much easier to hit all of the above.

Re: Moving from Go to PHP Again

#109

Post by pasta »

tompi wrote: post #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.

About annotations, a new proposal has been submitted a few days ago. It's not the first time so I don't want to be too optimistic, but it looks great. https://wiki.php.net/rfc/annotations_v2

Even if this will be integrated I still think it might be a bad idea for some things because it goes into the separation of concerns principle.

A controller should not know about routes.

A model should not know about database design.

Re: Moving from Go to PHP Again

#110

Post by YawningAngel »

masklinn wrote: post #83
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. I mean that's just how CGI works, most every HTTP server still supports CGI, nothing stops you from deploying that way. Unless you're using Java or the like of course, then it's not very convenient.

You can absolutely do this in Java if you want to.

I mean, it's insane and you shouldn't, but it's eminently possible.

Post reply on HN