Live data from Hacker News

Moving from Go to PHP Again

dannyvankooten.com

111–120 of 371 posts

Re: Moving from Go to PHP Again

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

This is pretty much a laundry list of anti-patterns for modern web development.

Non-atomic deployments? Not using Composer to manage dependencies? No separation of concerns? Editing files directly on the production environment?

I get that it's nice for beginners, but they're not benefits for professionals. We have better ways of doing things than Notepad and FTP.

Re: Moving from Go to PHP Again

#112
post #22
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…

Plain PHP files work that way. But what if you use a framework (even an in-house one)? Does this holds true?

Generally, no. Almost any framework has build steps these days, at least `composer install` to get all the dependencies, and usually also special web server configuration, so you don't expose all your PHP files to the web, only the index.php entry point.

Re: Moving from Go to PHP Again

#113
post #94

Earlier quoted context omitted.

So.. what you're trying to highlight is that a language is supposed to make up for the incompetence of the person using it?

Of course. That's the only reason to invent languages: to take care of stuff people are not good taking care of, and move the work to the computer, allowing us to work on the level that we're good at taking care of. Else we'd all be using assembly. There's absolutely no pride or glory in doing things nicely and securely that the computer could have automated in the first place. Anything the language allows that it co…

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 startups I've never seen the intended results actually happen a single time. Not even close. Not once. Never.

Instead it leads to larger, less maintainable, more convoluted messes that have to be trashed quicker. Giant ceremonial cargo cult style monstrosities with huge circuitous logic - 4, 5, maybe 6 layers, a router calling a controller, calling a service, calling a provider, calling an event model, which runs a single if statement ... as if that's how we protect ourselves against incompetence.

These approaches just lead to wasteful projects where they end up rewriting the whole thing in whatever the framework/language de jour is instead of writing easily maintainable, quickly understandable code that's designed to work for the next 10 years. I've talked to many programmers who are embarrassed by the language they are using ... wtf is that?! They've turned programming into fast fashion.

Then people like to ask what someone's favorite language is, usually when they first meet them, as a social cue, as if we are a bunch of highschool kids following pop music. I mean what on earth... we're supposed to building the future here, not running around like a bunch of spastic fanboys from platform to platform, just to mess everything up all over again in bold new ways using slightly different syntax.

The best thing to do is give people the least abstract thing with the fewest conformity requirements ... essentially make it open ended and then the messes are easier to spot and easier to fix. 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?)

Anyway, new shiny fancy tools with GoF buzzwords won't ever fix incompetence, it'll only make it worse.

Re: Moving from Go to PHP Again

#114
post #54

Earlier quoted context omitted.

That chown looks super suspect. Usually you wouldn't want the webserver to have write access to the web application it is executing; that's how you get backdoored.

This is my concern with things like the Wordpress auto updater, but it seems the trade off is not having to worry about manual patch management. Security vs convenience as always.

How I've been running multiple wordpress installs for years:

user: $sitename - the 'owner' of the whole hosted dir. rwX

user: $sitename-PHP - the user that php-fastcgi or whatever runs as, r-X permission on the dir, and write permission on the content uploads directory, but CANNOT write to any plugin install dirs, or upgrade php files.

user: nginx - can read all files except the wp-config.php file, which is limited to only the $sitename group reading it.

then use wp-cli to do automatic upgrades every few hours, and a localhost-only ftp server for wordpress to do plugin installs with. When you try to install a plugin, it asks for a ftp username, host as password. You put in the $sitename user, '127.0.0.1' and $sitename password, and you're set. Those login details are never saved anywhere, so the admin has to put them in each time (or their browser stores them).

Works pretty well for me.

Re: Moving from Go to PHP Again

#115

Why do so many companies keep moving to go? I tried to like it, but it was just so painful to write.

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…

Go has GC and a runtime so you can argue it's not really close to C/C++/Rust at all and much closer to AOT Java.

Re: Moving from Go to PHP Again

#116
post #43

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

To keep it simple, it was originally created as sort of a helper instead of a full-fledged language, and just kind of grew into that. As such, its early years were plagued with architecture, security and performance issues, as well as many "gotchas" that could wreak havoc on amateur programmers that tended to gravitate to the language. Couple that with the fact that the maintainers drug their feet in implementing mod…

This sounds a lot like JavaScript

Re: Moving from Go to PHP Again

#117
post #103
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…

Gorm is not bad but I don't think it is an alternative. To start with, the association requires some extra work to save/update which you have to do manually. In doctrine, this is done already. Documentation, maturity, and community behind doctrine are a lot better.

Re: Moving from Go to PHP Again

#118
post #94

Earlier quoted context omitted.

Of course. That's the only reason to invent languages: to take care of stuff people are not good taking care of, and move the work to the computer, allowing us to work on the level that we're good at taking care of. Else we'd all be using assembly. There's absolutely no pride or glory in doing things nicely and securely that the computer could have automated in the first place. Anything the language allows that it co…

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…

>Incompetent people will create incompetent things regardless of the tool

Which is neither here nor there.

For one, it ignores the pragmatic issue, that very competent people (the very people that built the foundations we all work on even) will still make lots of mistakes, even trivial ones, but with severe consequences (e.g. buffer overflows) when the languages don't prevent them.

If only it was just "incompetent people" that made mistakes...

>But after 20 years of bouncing around startups I've never seen the intended results actually happen a single time. Not even close. Not once. Never.

You weren't looking hard enough. Every day millions of programmers don't make "buffer overflow" errors for example, that otherwise they'd have made, because they work in languages that don't allow them.

And they'd have made those mistakes regardless of their programming chops. The best programmers, people that run circles around you and me, still make those mistakes.

Re: Moving from Go to PHP Again

#119

PHP is the same but with speed improvements in 7. But even without that the sheer number of high traffic sites built on PHP and proven scalability cannot be ignored or its ease of use and setup. All talk of accessibility and ease for new users often comes off as posturing by some tech folks who then proceed to rubbish any efforts at achieving it and the compromises involved. It fits in nicely with the 'contempt cultu…

which is precisely what's wrong with websites such as HN / Stackoverflow with their opinionated ironic so called programmers who sit on the internet all day with opinions on the "real world" without actually living in or contributing to it and knowing exactly how it works.

Re: Moving from Go to PHP Again

#120

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

None of these other answers get to the real point.

The entry level language gets the reputation of the code written on the platform.

That's why basic, flash, php, Java, and JavaScript all had bad reputations at one time.

You can knock on any sufficiently complex language, it's actually really easy.

Python, for instance, gives different numerical results between 2 and 3 for the code "False - 3 * True / True / 2 + 3 * False" (-1 and -1.5)

Making things look absurd isn't hard.

Post reply on HN