Live data from Hacker News

PHP in 2021

stitcher.io

181–190 of 309 posts

Re: PHP in 2021

#181

Earlier quoted context omitted.

> You can do this with one PHP file , one a super cheap hosting , with code that is simple and clear. This. PHP is basically Functions-as-a-Service over commoditized virtual hosting. Maybe we need a toolchain that can transpile down to PHP, starting from more common languages with better development workflow.

> with better development workflow What languages have better development workflow? I'm myself biased towards repl-driven development with Clojure, but for example Rust's or Go's development workflow is a lot worse than PHP. PHP: write file to disk, reload webpage/run curl Rust/Go: write file to disk, compile file, run binary, reload webpage/run curl The popularity of PHP is not hard to understand when it comes to ea…

>> Go's development workflow is a lot worse than PHP.

I beg to differ.

- Runtime errors are more common in PHP and that's a good enough reason for me to say that PHP dev workflow is worse.

- You also seem to miss some common errors when the PHP assets are missing. Suddenly the compile con becomes an advantage for Go.

- Different servers (apache, nginx, etc) give you yet another thing to configure.

From my very old past experience, PHP development gives you more headaches than Go.

Re: PHP in 2021

#182

Earlier quoted context omitted.

Look at the abject failure of Discourse. If it had been written in PHP then it would have completely replaced all current forum software. But the devs there hate PHP and went for a modern stack which is all but impossible to install except for tech professionals. In other words, they chose a tech stack which suited them as developers, and not which suited the end users of the software. End users love PHP because you…

End users love PHP because you copy the files into a folder. That's certainly how people deployed web apps built by other people a decade ago, but these days isn't it more common to use something like Docker? Deploying a containerized app should be pretty much the same no matter what language it's written in. And Discourse does have a Docker container ( https://github.com/discourse/discourse_docker ), so I'm not sure…

The absolute minimum amount of knowledge needed for this sort of thing is how to get files onto a server. Lots of people capable of that have absolutely no idea what Docker is or how it works. Lots of people know what it is, and what it does, but have not ever actually used it (like me!). If I was going to install some server software, and saw Docker, it would put me off — great, I have to learn Docker now?

Docker probably is a better way of doing things, but it’s another layer.

Re: PHP in 2021

#183

Earlier quoted context omitted.

> with better development workflow What languages have better development workflow? I'm myself biased towards repl-driven development with Clojure, but for example Rust's or Go's development workflow is a lot worse than PHP. PHP: write file to disk, reload webpage/run curl Rust/Go: write file to disk, compile file, run binary, reload webpage/run curl The popularity of PHP is not hard to understand when it comes to ea…

>> Go's development workflow is a lot worse than PHP. I beg to differ. - Runtime errors are more common in PHP and that's a good enough reason for me to say that PHP dev workflow is worse. - You also seem to miss some common errors when the PHP assets are missing. Suddenly the compile con becomes an advantage for Go. - Different servers (apache, nginx, etc) give you yet another thing to configure. From my very old pa…

> - Runtime errors are more common in PHP and that's a good enough reason for me to say that PHP dev workflow is worse.

Seems you just know more Go than PHP, which is fine of course. No language has "more runtime errors" than other languages, just developers of varying skill-levels in that particular platform

> - You also seem to miss some common errors when the PHP assets are missing. Suddenly the compile con becomes an advantage for Go.

And you don't get errors when assets you use in your Go program is missing? Only difference is that PHP compiles when you hit the webpage, instead of a separate step, so you'll get the error when trying to load the page, not when running "go build".

> - Different servers (apache, nginx, etc) give you yet another thing to configure.

Just like in Go, you don't have to use a separate server in order to develop. Just fire up the PHP development server that PHP ships with.

Re: PHP in 2021

#184

Earlier quoted context omitted.

> with better development workflow What languages have better development workflow? I'm myself biased towards repl-driven development with Clojure, but for example Rust's or Go's development workflow is a lot worse than PHP. PHP: write file to disk, reload webpage/run curl Rust/Go: write file to disk, compile file, run binary, reload webpage/run curl The popularity of PHP is not hard to understand when it comes to ea…

>> Go's development workflow is a lot worse than PHP. I beg to differ. - Runtime errors are more common in PHP and that's a good enough reason for me to say that PHP dev workflow is worse. - You also seem to miss some common errors when the PHP assets are missing. Suddenly the compile con becomes an advantage for Go. - Different servers (apache, nginx, etc) give you yet another thing to configure. From my very old pa…

> - Runtime errors are more common in PHP and that's a good enough reason for me to say that PHP dev workflow is worse.

With type hints you can eliminate a lot of runtime errors these days.

> - You also seem to miss some common errors when the PHP assets are missing. Suddenly the compile con becomes an advantage for Go.

When using Composer, specify the extensions and the PHP language level you need in "composer.json", and it will barf during deployment at the composer install stage.

The only thing Composer can't check is configuration parameters (e.g. max execution time, memory limit).

> - Different servers (apache, nginx, etc) give you yet another thing to configure.

Not much anymore, at least Debian and Ubuntu integrate all three major web servers (apache, nginx, lighttpd) pretty much out of the box.

Re: PHP in 2021

#185

Before you call me a troll, know that I worked with PHP for two+ years maintaining both legacy codebases and writing new code with Laravel. My question is: why would anyone want to start something new with PHP in 2021? Is there anything that it does better than any other language/ecosystem? I feel like the community is full of (but not exclusively composed of—there are some gems like Caleb Porzio who write good stuff…

> that I worked with PHP for two+ years maintaining both legacy codebases and writing new code with Laravel.

might seem like trolling, but from what I've seen, Laravel encourages bad developer practices such as static code etc, while Symfony encourages good OOP practices. so Laravel in itself is attracting specific audience with different priorities than Symfony, so it may explain your main complaint about PHP code which cannot be treated as same. I mean Laravel is written in PHP but it does not mean that same code practices are used in other frameworks/projects.

Re: PHP in 2021

#186
post #141

Earlier quoted context omitted.

> I appreciate Laravel and Symfony, but PHP in 2021 has traded the feeling of being a cargo cult version of Perl for the feeling of being a cargo cult version of Java. As a Symfony dev I agree. And the process to convert PHP into a Java-esqe Kotlin-esque language is continuing. Why not use a different language if you like it rather than change PHP? > If I do write a new project in PHP, it's probably not going to be w…

" the process to convert PHP into a Java-esqe Kotlin-esque language is continuing " My observation is also that PHP is growing too much in language size. Depending on one's viewpoint, this can be seen as either matching the feature and syntax bloat of other languages, or taming the language to make it "saner".

The beauty of PHP is that you can still choose how complex you want your application to grow - and that you can adapt if needs change.

You can do everything from a one-file hacked together shell scripts (which I love to do because bash is just plain annoying sometimes, especially for stuff that has to work on OS X and Linux with their not-so-small differences in coreutils) to enterprise-style architected software in Symfony or Laravel.

Re: PHP in 2021

#187

Earlier quoted context omitted.

Indeed, there's nothing like just logging in to a linux box you got access at school or pay $1/mo for and typing 'nano public_html/index.php' - stuff Just Works. Trying to get a python/ruby framework working in the same env, without root access? Whoooo boy. 20 years in the business and I still refuse to do that crap. FastCGI and the like just never work properly the first time in shared hosting. You need virtual envi…

idk if we're talking about ease of getting started Heroku kinda made it as easy as it can get (started with Ruby but now supports all languages).

You still need Heroku for that while there are a literal boatload of PHP shared-hosting providers.

Re: PHP in 2021

#188
post #171

Earlier quoted context omitted.

You can ask the same for any language, not only PHP: - Why would anyone want to start something new with Ruby? - Why would anyone want to start something new with Elixir? You can choose any reason to pick a language, do you want a language with a lot of demand in the job market, learn Javascript, you will see a lot of frontend open positions, even more React open positions if you want to specialize in something. Do y…

> Ruby It has a very mature web dev ecosystem around Rails. It: is quick-to-learn, is OO to the bone, is FP where is fits with the OO, is easy to read, has little quirks. Personally I'd go with something with stronger types, no "null" and proper sum types. But if you are cool with dynamic typing: Ruby is a great choice. > Elixir Ruby-like syntax (some advantages just mentioned) and BEAM runtime. Yields very scalable…

> is quick-to-learn, is OO to the bone, is FP where is fits with the OO, is easy to read, has little quirks.

Exactly same applies to PHP - without FP part but in exchange one is getting enormous, gargantuan ecosystem of libraries, developers, hosting, language oriented and designed to rapidly deliver result and easiest deployments out there.

Todays PHP is good, may be not trendy and hip right now, elitists may snark a bit but it's good language to deliver products.

Re: PHP in 2021

#189

It is a great language to put food on the table. Especially in Europe it is still the dominant backend language. If you want to have flexibility on where you work it is a good language to know. You have the productivity of a scripting language but still great static analysis tools that help you out. It really fills a sweet spot that no other language does. Yes, Node has Typescript but then you have a super slow compi…

> PHP is only a bad choice is you have really complex requirement and need a high level of reliability, which most Web projects don't. I think Haskell fills a good niche here. It is really underestimated.

Actually I find PHP projects to be more reliable to host than stuff written in Java, the lingua franca of business projects. Constant worrying about heap sizes, garbage collection, resource leaks or your entire server crashing because of some exception somewhere... you don't have anything like that in PHP (with the exception of memory_limit, which is fairly rare to hit in a decent hoster), simply because of the shared-nothing architecture of PHP.

Re: PHP in 2021

#190

Before you call me a troll, know that I worked with PHP for two+ years maintaining both legacy codebases and writing new code with Laravel. My question is: why would anyone want to start something new with PHP in 2021? Is there anything that it does better than any other language/ecosystem? I feel like the community is full of (but not exclusively composed of—there are some gems like Caleb Porzio who write good stuff…

I feel like yelling “die” each time I see “php”, but on the other hand - man, those were simpler times when we were pushing a feature after feature instead of talking about overly engineered architectures and nuances of super complicated runtimes of the current pls
Post reply on HN