Что если не Go?

I'm convinced the reason so many successful projects use PHP, is not because of any inherent nature of the language. I think it's the people who use it. They just don't care. A successful project needs to be started by someone that cares just enough, but not too much.

If you're programming in PHP, you're not running around talking about «convention over configuration» giving talks, or trying to make your code beautiful. It's a garbage language, and you know it. But it allows you to get something up and running, so dang quick. You're failing while the other guy is still updating his gem file. You're advertising while the other guy is trying out some fancy new deploy script. You're incorporating feedback while the other guy is just starting to get to work. When he finally fails, he's used up half his runway, whereas you, the guy who didn't give a fuck about your code has gotten past that first failure, and are finally getting some traction.

C и C++

Предельная простота, позволяющая читать даже самый стрёмный чужой код

C++

Это троллинг такой?

PHP is defective by design. There is simply no apology for PHP flaws:

1. Inconsistent lexical scope, where assignment acts as declaration and all variables have function scope, serving as major source of PHP bugs and impeding functional programming, because in PHP anonymous functions require awfully verbose constructions, like `function($y) use ($x) {`. Compared to Scheme/Racket, which uses `let` for everything, PHP's global scope is completely separate entity and requires explicit use of `global` keyword to access variables. PHP has no package system, so global namespace becomes unmanageably cluttered. Moreover, referencing nonexistent variable isn't even an error, so any typo produces untraceable bug. Finally, PHP allows non-string variable names: $a=array();$$a='broken'; print ${array()}; 2. Inconsistent standard library: for example, shuffle(123) would return false, instead of logging error and halting execution, before more damage is done; same for accessing array beyond bounds, which is even worser than C/C++, where such access at least produces segmentation fault. Despite null also being valid JSON object, json_decode returns null on error, welcoming bugs if user forgets json_last_error. Functions sizeof, count `print` and `echo` duplicate functionality, while `print` for some reason always returns 1. Moreover, PHP arrays are implemented as hash tables, so there is no way to get their real size or iterate by indices at all. PHP standard library basically indulges hard to trace bugs, exploits and backdoors, because almost any PHP feature is fragile and poses security danger. Inconsistent function naming: underscores (isset vs is_null), abbreviations (call_user_func vs create_function), uncertain parameter order (in_array($needle, $haystack) vs strpos($haystack, $needle)), redundant aliases (disk_free_space vs diskfreespace, strcmp vs ==), misleading names (addslashes and stripslashes, which deal with backslashes). PHP's one unique operator is @ (actually borrowed from DOS), which silences errors. 3. Broken and non-portable type system: PHP stores integers in a platform-dependent format, usually 64-bit or 32-bit signed integer, equivalent to the C-language long type. Even worse: big integers are represented as floating point numbers, so 9999999999999999999==10000000000000000000. Confusing automatic type coercion, where FALSE=="", FALSE==0, array()==FALSE, array()!=0, «1e3»==«1000», «0x10»==«16» «a»+«d»==0, 123==«123broken», «4.2»==«4.20», «6»==" 6", «x»==0", NULL<-1, NULL==0. Be prepared to a lot of instant bugs, like if(strpos($h,$n)) {...}, because 0 gets converted to FALSE, behind your back. Due to broken `<` sorting is nondeterministic. 4. Inconsistent garbage collection, performed only when you tell PHP to do it or passing specific junctions. In some cases memory lost until program halts, which unnoticeable with small one shot page generation scripts, but poses a major handicap for general purpose programming using PHP, when code must run for days.

5. Discrepancy between literals and variables, growing from variables being objects themselves: given $a=«foo», var_dump($a instanceof stdClass) works, but var_dump(«foo» instanceof stdClass) produces error; same with array literals: $a[0] works, but array(1,2,3)[0] fails. Array assignment always involves deep copying, which is confusing and bad for performance. Function may be called via variable, containing function name, leading to badly designed and insecure code, welcoming exploits, especially when function name comes from use input.

6. Fugly syntax: every PHP variable requires `$` prefix, which looks even scarier when combined with `&`, required to pass objects by reference, so be prepared for quirky perl-ugly code, like &$o[i++] and !--$$i. The syntax has 1375 conflicts and 6 unused terminals, reflecting that implementors had no understanding of LALR(1) parser generators or robust language design in general, because with that many conflicts, the chances are slime that the parser is actually doing 100% of what was intended: for example «a».2 produces an error, but «a».«2», «a» . 2 and 1 . 2 parse as string concatenation, while 1.2 and .2 parse as numbers, worser 0x0+2==4, but 0x0+ 2==2 so meaning of operator depends on spaces around it. Usual `{` and `}` braces can be interchanged with `:` and `endif;`, which is aggravated by the fact that PHP syntax treats { and ${ as separate tokens (T_CURLY_OPEN and T_DOLLAR_OPEN_CURLY_BRACES), making PHP syntax bigger and even less regular: PHP has around 70 keywords, including echo, eval and exit, which in well designed languages implemented as functions. Appending to an array is done with $foo[] = $bar.

7. No multithreading support possible, because PHP is full of global and implicit state. mbstring uses a global character set. func_get_arg and friends look like regular functions, but operate on the currently-executing function. Error handling have global defaults. register_tick_function sets a global function to run every tick.

8. When faced with criticism, all PHP apologists spit generic arguments, starting with banal ad-hominem, which speak for themselves: «all languages are turing complete», «languages are just tools», «no language is perfect», «good developers can write good code in any language», «PHP was never intended to solve problem X», «PHP isn't the problem, bad programmers are», «products X was built using PHP, so PHP is good enough», «there are two kinds of languages: the ones complained about and the ones nobody uses», «PHP is free, hosting is available, PHP programmers are cheap», «clients don't care what language is used», «PHP has great community, we are like family», «if you do X then problem Y would be less noticeable», and a myriad of variations. The best examples of PHP apologetics, like https://news.ycombinator.com/item?id=4177516 , contain gems in the lines of «Sometimes you don't care if a function succeeds» - in other words, PHP community doesn't care if their code succeeds.

9. PHP is Jewish language, developed by Israeli company with unclear agenda. It is entirely possible that PHP is just a trojan horse and real goal was to produce exploit-happy environment, which Israeli intelligence agencies could leverage to advance interests of Israel. Being originally a collection of CGI scripts designed for building a 'personal home page', PHP indulges messy, unmaintainable code: spaghetti SQL wrapped in spaghetti PHP wrapped in spaghetti HTML, replicated in slightly-varying form in dozens of places.