> - 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.
> 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
A type system reduces the risk of runtime errors, because it doesn't let you write code with undefined behaviour such as indexing a null. Depending on the implementation, it can even force you to handle all possible failures explicitly so that execution always completes. With languages such as rust or Haskell it's feasible to write complex code with almost complete confidence it won't hit any runtime errors, excluding resource exhaustion or machine failure of course.
On the other hand you could argue that logic errors depend on the skill of the programmer and not the language.
Right now, PHP is only missing typed local variables. Class fields are typed, function arguments are typed, function returns are typed. And local variables can be typed for static analysis purposes with `/* @var $str string */` annotation.
I'd add generics to that list, but Go doesn't have them either, so not really a point for discussion.
FYI you can get a lot of this checks in PHP too if you annotate your code. It is built in in the IDEs too so there is no extra work for you. Sure you can make errors but I do it for productivity reasons, I can perform refactoring like "Rename", "Find Usage" in PHP exactly as in Java, it is much pleasant then the situation on front end.
> - 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.
Me personally if I would be asked something like "we can;t use PHP starting from tomorrow for our backend crap, what should we use?"
I would say node or if we need to use a static language would be Java. And the choice is not about the language but about the entire ecosystem(libraries, tools, developers, documentation)
Using type hints and a good IDE there are not many type related issue slipping in the code.
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.