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

271–280 of 371 posts

Re: Moving from Go to PHP Again

#271

Post by apta »

agnivade wrote: post #75
oconnor663 wrote: post #58

Earlier quoted context omitted.

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.

    fmt.Println("foo")
I don't see errcheck complaining there

how about (taken from here: (https://www.reddit.com/r/programming/comments/ak305l/goodbye...):

    r1, err := fn1()
    r2, err = fn2()
    if err != nil {
      return err
    }
err check doesn't complain either

Re: Moving from Go to PHP Again

#274

Post by lukifer »

argd678 wrote: post #14

Is there any way to test php code the same way a compile phase does in other languages to catch obvious mistakes from hitting your users?

It's obviously not as comprehensive as compiled or strictly-typed languages, but you can use "php -l" as a linter to catch obvious parsing/syntax bugs. I use this script to check our whole codebase before deployment:

> find . -name "*.php" -print0 | xargs -0 -n1 -P8 php -l | grep -v "No syntax errors detected"

Re: Moving from Go to PHP Again

#275

Post by eeZah7Ux »

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.

PHP has a terrible track record for security.

Re: Moving from Go to PHP Again

#277

Post by gknoy »

ryanmccullagh wrote: post #273

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)

I've always been a fan of JetBrains' IDEs (Webstorm, Pycharm), so I would imagine that their PhpStorm is similarly excellent. (Each of the ones I mentioned are language-specific subsets of IntelliJ.)

Re: Moving from Go to PHP Again

#278

Post by 52-6F-62 »

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.

Eh, maybe for something simple.

In a complex product (as in, most professional settings or large services/web sites) the PHP I've seen is grossly complex, and not intuitive—especially WordPress deployments.

Dev teams have to perform all kinds of gymnastics with the PHP code to get it to do what they want, and it's just a flat out nightmare that I've made sure my boss and colleagues know that I have no desire to work with it.

It always ends up a house of cards and full of vulnerabilities so that something is regularly getting exposed that allows at least editorial access. Security issues that should otherwise be no problem.

God knows how many other vulnerabilities exist. Every single server I've ever had has had bots and crawlers polling for common PHP files in an effort to exploit them, should they exist.

I just don't like having even the chance that my back-end source could, for want of a single character, spill out to a web page upon request.

And then there's performance...

Anyway for simple things, sure. For things that don't require much security, sure. For anything else... it's not for me.

Re: Moving from Go to PHP Again

#279

Post by jdpedrie »

mg wrote: post #181
superasn wrote: post #124

Earlier quoted context omitted.

You are 100% right about that. I've nearly tried almost all PHP frameworks, quite extensively I may add and at the end of the day I found that the less framework I use the better and faster my dev is. Now I just use packages from composer as needed and never ever use them anymore. For me Laravel was a nightmare to use with Vue. Both template engines (blade, vue) use moustache tags so everything has to be declared ins…

Interesting. Coding without a framework is rare these days. I would like to hear more about how you do the basic infrastructure stuff usually provided by a framework: Routing Templating DB abstraction

PHP's package manager makes it really easy to pull in components a la carte. Similar to OP, I rarely use a large framework like Symfony or Laravel. I have a base application I wrote which I like, and I layer components I trust and whose API fits my preferences as I require them.

Additionally, the PSR project has standardized a lot of APIs (HTTP request/response, logging, cache to name a few), which means if a package conforms to PSR, you get interop out of the box and can quickly swap implementations if needed.

Re: Moving from Go to PHP Again

#280

Post by brightball »

mg wrote: post #181
superasn wrote: post #124

Earlier quoted context omitted.

You are 100% right about that. I've nearly tried almost all PHP frameworks, quite extensively I may add and at the end of the day I found that the less framework I use the better and faster my dev is. Now I just use packages from composer as needed and never ever use them anymore. For me Laravel was a nightmare to use with Vue. Both template engines (blade, vue) use moustache tags so everything has to be declared ins…

Interesting. Coding without a framework is rare these days. I would like to hear more about how you do the basic infrastructure stuff usually provided by a framework: Routing Templating DB abstraction

This is actually something I have been predicting for PHP for a while. Frameworks are beneficial when languages don’t have built in support for the core needs of your task, so those needs a built into the framework and abstracted away.

With both PHP and JS this isn’t the case, which is why you see SO many frameworks for them: all of the parts are already there so the frameworks are mostly just rearranging things. Ruby, Python, Go, etc are general purpose so the frameworks provide a lot more support.

PHP’s biggest hang up for years was lack of name spacing for good module support so EVERY framework had their own version of every core feature you’d need abstracted around its framework naming schema. Can you imagine every framework writing their own database drivers...because that was happening.

As soon as Composer was released it was only going to be a matter of time before the ecosystem started to clean itself up from 9 different ways to install shared code.

Glad to see it’s happening.

Post reply on HN