
New in PHP 8 - jonifico
https://stitcher.io/blog/new-in-php-8
======
ksec
At these rate of improvement, along with Laravel, may be I should seriously
evaluate moving back to PHP stack. It was only the other day Antirez, author
of Redis [1] was complaining the Ruby Stack is more complicated than it should
be. And I wholeheartedly agree.

[1]
[https://mobile.twitter.com/antirez/status/122328600521977446...](https://mobile.twitter.com/antirez/status/1223286005219774464)

~~~
core-questions
There was never anything wrong with PHP, really.

* If you wanted to scale it horizontally, it was ready to do that 15+ years ago

* No problem running it completely stateless

* Deploys are completely sane and predictable, it's just a bunch of files, and even when composer came along it didn't really change that too much

* Performant enough as far as the interpreted web languages go

* No problem writing a RESTful backend in it and fronting completely "modern" client facing tech on the top if you want

* Server side rendering since day 1

Like, it came down to people complaining about some function names / param
orders as if it were the end of the world. I think a certain subset of people
(shall we call them hipsters?) are just keen on finding new ground where they
can rewrite the same boring things instead of working hard to improve the
ecosystem of something existing.

I moved on from PHP aeons ago because it got this undeserved bad rap, but I
still follow it and would welcome the chance to run it again.

~~~
mantap
Function names and parameter order matter. That is the difference between
having to look something up in the documentation and not. Back in those days
most text editors didn't have fancy autocompletion with parameter
documentation, if you weren't sure about the order you might have to look it
up in the documentation. Having a self-consistent API that was easy to
remember was essential. _Especially_ in a language with dynamic types!

When I switched from PHP to Python it was an amazing, liberating feeling for
me that I will never forget.

~~~
stef25
It takes 10 sec to google "str_replace" and have the params presented to you.
Using a manual is an integral part of development. I don't think there's many
people who can memorize all the methods and their params, including optional
ones, nor should they.

~~~
cultus
That sounds like it takes a lot more time and mental energy than if the API
were consistent.

~~~
Piskvorrr
We have machines to do that _for_ us. As in, "press Ctrl+Q, IDE shows relevant
help." I don't value encyclopedic knowledge of every API out there any
more...especially since those I do recall are of rather, um, limited use
nowadays. Like with any language, the point isn't to cram a dictionary into
your brain, it's to communicate.

~~~
mantap
It's a red flag if the _basic operations_ (like string and array functions)
are so inconsistent and weird so as to require use of an IDE or constant use
of the docs.

------
fs2
This is pretty awesome, I've been migrating from C# and NodeJS back to PHP and
it's awesome. Want to know why?

\- Everything is either built-in or can be enabled from an OFFICIAL repository
(like functions for bc,xml,etc). No more trusting sketchy npm packages or
having to pull in a ton of dependencies that might stop working some day.

\- It's so fast and elegant to consume a (SOAP or REST) webservice. Visual
Studio insists on creating tons of files, obscure web.config settings and
other misc. stuff. PHP handles this in a couple of lines.

\- Development feels natural, every file can be a single class if you want and
there are plenty of highly matured frameworks available.

I estimate I've slashed development time in half compared to C#, less bugs and
less security issues (verified through two independent code auditors). Even
large projects are easier to work on in PHP compared to C#

~~~
pathartl
I have to disagree with pretty much everything you've written, because it
seems like you're running into issues of a paradigm shift.

If I'm going to consume a web service, I am going to write the models in C#
and let a JSON deserializer like Newtonsoft.JSON map everything. To me,
there's nothing better than having a fully modeled web service. I learn a bit
about how the service works when writing the models. I know what the data
looks like before I start working with it in my own application.

Regarding your web.config note, I guess I don't understand what you're trying
to get at. .NET projects tend to throw configuration items into, well, a
configuration file. Again to me this is far superior to doing the PHP-
industry-standard of having a config.php and chucking a bunch of global
variables into it. Putting configuration items behind a parser in a document
that you expect the user to edit is good practice.

 _Development feels natural, every file can be a single class if you want and
there are plenty of highly matured frameworks available._

Maybe this is a note more for the NodeJS space, but a single file per class is
the general guideline for C#/.NET. Additionally, I've generally found that the
.NET framework and libraries written against it tend to be of much higher
quality, are more secure, and are more production ready than most I've worked
with in PHP land.

On top of that, Visual Studio is a _wonderful_ IDE and is pretty much the gold
standard of our industry. I've not had a better experience as a developer than
being able to create a .NET Core MVC web application and hit the ground
running. I've written anything from 5 line Azure Functions to working with
100k+ line web applications and I'm not sure I could have done it without the
excellent debugger available and the very context-aware Intellisense
typeahead. In contrast, other than PhpStorm, I find PHP environments to be
extremely messy and a bit of a hack to get working properly. If I didn't have
some sysadmin background I'm not sure I'd move outside of "debugging" using
var_dump().

I was a PHP dev primarily from ~2009-2017 and have been working almost
exclusively in C# since.

~~~
fraktl
> Additionally, I've generally found that the .NET framework and libraries
> written against it tend to be of much higher quality, are more secure, and
> are more production ready than most I've worked with in PHP land

Unless you've a solid proof, this is just.. blatant lie. How did you measure
the security and quality? Was it "ok, this seems nice" or was it literally
reading the code, running the tests and hitting the lib with a pentest suite?

See, it's one thing to compare languages (which is silly) and completely
another to let your subjective feel get in the way of objective analysis.

Stating that libraries which contain more than 1 class per file are more
secure and robust is just a nice wish, but nothing more than that. It's simply
not true to the point it's funny :)

> On top of that, Visual Studio is a wonderful IDE

It sure is, top notch IDE.

> In contrast, other than PhpStorm, I find PHP environments to be extremely
> messy and a bit of a hack to get working properly.

You've PHPStorm and there's VSCode. PHPStorm is better. It works almost
flawlessly. What's an IDE got to do with environment? Why are they a hack?

I'm a dev who started with PHP in 1998. and have been using it since (among
many other languages). Reason I'm writing this (despite hating it) is to
nullify your experience as any sort of valid argument.

Unless you can provide actual, hard proof for what you wrote - it's merely how
you'd like it is.

Now, is any of that important? It's not. You use C# and you're satisfied.
That's all that matters. If some other guy says PHP is better - you know that
it's not, in your particular case. And that's great.

IMO, as a PHP dev, I consider C# an excellent language. As a sysadmin, I hate
Windows and its ecosystem from the bottom of my soul.

~~~
pathartl
> Unless you've a solid proof, this is just.. blatant lie. How did you measure
> the security and quality? Was it "ok, this seems nice" or was it literally
> reading the code, running the tests and hitting the lib with a pentest
> suite?

Yes. Additionally features of .NET binaries such as signing tends to be a bit
more favorable to me.

> Stating that libraries which contain more than 1 class per file are more
> secure and robust is just a nice wish, but nothing more than that. It's
> simply not true to the point it's funny :)

That's not what I was stating. I was stating that 1 per file is common in .NET
land and I personally believe that it leads to more organized code.

> You've PHPStorm and there's VSCode. PHPStorm is better. It works almost
> flawlessly. What's an IDE got to do with environment? Why are they a hack?

VS Code isn't an IDE, really. It's a text editor with extensions. I was
speaking more to the fact that setting up a proper development environment
with PHP is a chore. If you're using an *AMP, you've got one shared
environment across all your development projects. Things like debugging two
PHP projects at once can't happen. Edge case stuff sure. Using vagrant or
another VM solution is a super heavy way to accomplish something that should
be simple. Using Docker is nice, but has its own pitfalls. I agree PhpStorm is
fantastic. It's always been one of my favorite tools. A bunch of its editing
features are leagues ahead of VS. Unfortunately, it's not a complete solution
to a dev environment. And yeah, I'm aware you can launch `php` directly from
PhpStorm. I usually find that to be a nightmare in its own way.

Again, I started as a PHP dev and it holds a certain place in my heart. I'm
not sure I could ever find an instance to use it over any other platform,
though.

Also, you should try to give .NET Core a try. It's a pretty fantastic
platform. Like PHP, I would never choose to start a project with .NET
Framework.

------
bufferoverflow
PHP is already one of the fastest languages. Hopefully JIT will make it even
faster.

Currently it places #11 on the famous framework benchmark:

[https://www.techempower.com/benchmarks/#section=data-r18&hw=...](https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=db)

~~~
paulintrognon
I don't really understand that benchmark. How can swoole (#11), written in
PHP, be faster than PHP itself (#125)?

~~~
fraktl
Swoole hijacks network I/O from Zend Engine. Thus, it's capable of performing
async I/O while keeping the userland code the same. What the benchmark shows
is what happens when there's non-blocking I/O when speaking to the DB. PHP's
problem is its synchronous nature, but Swoole easily bypasses that limitation.

Btw. Swoole is not written in PHP. It's C++. It's compiled as an extension for
PHP.

------
mharroun
Honestly php seems like the common cold... an annoyance that is everywhere and
treated with little seriousness. However every evolution it gets better and
stronger and adapts other learnings from other languages. It really shouldnt
be treated as a joke any more.

Ps: I love php and jquery... not for any real saas systems but no other tool
set allows me to spin up and prototype full web app prototypes in sub 90 min.
As a senior tech manager php and Jquery allow me to show functional prototypes
quickly and easily get buy in from other department stake holders.

~~~
monoideism
> As a senior tech manager php and Jquery allow me to show functional
> prototypes quickly and easily get buy in from other department stake holders

I totally get it if you prefer to leverage your knowledge of jQuery, but
modern JavaScript is just as quick to use. Eg, `fetch`, `querySelector`, and
many more. Combined with modern css with flexbox and grid, and prototyping
becomes very quick.

~~~
sethammons
jQuery: include this lib, modify DOM.

Modern JavaScript: traveling menagerie of package managers, compilers, build
tools, etc. Now that is all in place, modify DOM.

At least, this is my impression from the outside. The last time I actually
wrote js was around a decade or more ago.

~~~
martin_a
As someone who is not very familiar with JS in its multitude of variations
this is what it feels like to me. Somebody told me to try Vue and while
reusability of components is surely nice to have I feel kind of lost when all
I need is a popup when a "save action" was successful.

What about jQuery? Is it still the go-to for simpler things?

~~~
monoideism
> What about jQuery? Is it still the go-to for simpler things?

Unless you need to target older browsers (like any IE, really), I'd just use
vanilla JS. Vanilla JS means no packaging or build process needed. Just create
write a JS file, reference it in a script tag in a basic `index.html`, start a
web server (like `python3 -m http`) and you're good to go.

Spend a little time learning about flexbox and grid CSS APIs, and you don't
even really need CSS framework if you're a decent designer (if not, use
Bootstrap or some other CSS framework).

If you're targeting older browsers, like IE, then yes, it's probably a good
idea to use jQuery and some CSS framework like Bootstrap.

Absolutely no need for Vue.js or React if you're just doing a very basic UI
(however, note that basic UIs have a tendency to become more complex with
time, so for that reason most JS devs start with something like Vue.js even if
it's not needed initially).

(I'm a senior software developer working in frontend development exclusively
for the past 5 years, but have been using JS since 1998, and jQuery since like
2008 - I left the software industry for a number of years after the dot.com
bust and came back a decade later).

------
esistgut
Every time I see an article about new features in PHP I search the page for
the "annotation" keyword. To be honest I find it a little bit puzzling that to
this day a large part of the ecosystem (Symfony, Doctrine, API Platform)
revolves around docblock annotations.

~~~
fraktl
Agreed. Personally, I hate annotations. This is the reason why I never
bothered with any tool in PHP ecosystem that relies on annotations. It looks
ugly, it feels ugly, it doesn't fit with my mental model - I avoid it
entirely.

~~~
flir
Agree so strongly. Executable comments. Whose bright idea was _that_?

------
piinbinary
Given how much PHP is used, having a JIT will probably save a meaningful
amount of electricity

~~~
blibble
that page seems to state that it only works in the context of a single request

unless you've got CPU bound PHP code... it seems like a complete waste of
effort

~~~
kyriakos
It's a way to promote php for other type of applications. Check swoole and
reactphp, they will be benefiting the most.

~~~
softwarelimits
Also check for memory leaks while you are at it.

------
chx
> Undefined variable: Error exception instead of notice

Well, this is where the chaff separates from the wheat. There's no small
amount of crappy code out there which will WSOD after this. Or actually print
the exception because they couldn't even bother to switch display errors on...
Of course, no even remotely sane codebase will be affected, but... Make no
mistake, this is a good change but it will cause some teeth gnashing.

~~~
codetrotter
Over time I think (hope) this sort of change will help to improve the code
that people write.

But I will not be surprised to see some people say things like “PHP 8 broke my
code”. Of course, what those people might not realize is that PHP 8 did not
break their code, the code was always broken, and PHP 8 is now going to
surface the brokenness of that code.

But even with code that people refuse to fix, this sort of change will make
the brokenness of that code more apparent to others, and so the number of
people that use that broken code will cease to grow. If not entirely, then at
least reduce in pace of growth.

That is good for the ecosystem of computing. As a proponent of correctness in
computing, this makes me happy :)

We all write bugs, but everything our tools and languages of choice can do to
help us reduce the number of bugs and the severity (impact on security) of our
bugs, the better.

~~~
userbinator
I think it's really a philosophical question what is "broken". An undefined
variable used to have a particular and also well-defined behaviour, now it has
a different behaviour.

Personally, I think a lot of these design decisions which some people abhor is
why PHP became popular in the first place. In that perspective, turning it
into yet another "big bureaucratic language" is very much against the spirit
of its existence.

~~~
koolba
Since the dawn of programming there’s been a schism as to whether undefined
means empty versus being a logical error. But deep down we all know what it
should mean.

------
cdubzzz
> The @ operator no longer silences fatal errors

Interesting. There are still some legitimate (well, “legitimate”) use cases
for that behavior e.g. with PHP’s native XML extensions.

~~~
treve
Are you sure those are _fatal_ errors?

~~~
scandinavian
[https://3v4l.org/saHj2](https://3v4l.org/saHj2)

However you could just catch Exception. Not sure why a parse error is a "Fatal
error".

~~~
gnud
A PHP parse error (of your code) is a fatal error.

A xml parsing error in the SimpleXmlElement constructor is not a fatal error -
it throws an exception.

An uncaught exception is a fatal error.

------
agentultra
Union types!

This is amazing to see. So many languages these days agree that functions are
good. Now they're all adding type systems of one sort or another.

PHP has always been a bit behind the curve but good on the developers for
pulling in a cool feature like this.

------
tylerjwilk00
# Summary of some of the new changes:

 _## Union types_

Specify multiple types

    
    
        public function foo(Foo|Bar $input): int|float;
    

_## JIT_

Just in time compiler for improved performance

 _## Static return type_

Return static of class

    
    
        class Foo
        {
            public function test(): static
            {
                return new static();
            }
        }
    
    

_## Weak maps_

Prevent blocking of garbage collection for improved memory usage when needed

    
    
        private WeakMap $cache;
    
    

_## ::class on objects_

Get class type from object like get_class($object)

    
    
        $foo = new Foo();
        var_dump($foo::class);
    
    

_## fdiv function_

When you don't care about division by zero

    
    
        fdiv($x,0);
    
    

_## Concatenation precedence_

Math takes precedence in string concatenation.

    
    
        // this
        echo "sum: " . $a + $b;
        // evaluated as this
        echo "sum: " . ($a + $b);
    
    

_## Some others_

\- Create DateTime objects from interface

\- Type annotations for internal functions

\- Variable syntax tweaks

\- Breaking changes

\- Consistent type errors

\- Reclassified engine warnings

\- Reflection method signature changes

* Note: HN pretty please get improved mark down parsing

------
guggle
I've used PHP from 1998 to 2016.

Things I remember I didn't like about/around PHP:

\- too many aspects of the language were dependent on config/php.ini.

\- it had errors and exceptions. I just wanted exceptions.

\- was not very interesting/useful/great outside web backend.

\- mb_* functions were not enabled by default

\- it had no decent REPL.

\- "reference" libraries had bad APIs or were over-engineered.

I'm not sure about the state of these issues now, but frankly I never felt the
need to look back. Good to hear there's still progress though.

------
Annatar
I expect to have some time soon and I'm planning on writing a full-blown
application in PHP, using nothing but functional style programming. Should be
fun.

~~~
timvdalen
It should! Have a look at Illuminate\Support\Collection, which you can pull in
as a separate package (apart from Laravel).

It makes doing functional stuff in PHP a lot of fun.

~~~
mpetrovich
You might also be interested in Dash:
[https://github.com/mpetrovich/dash](https://github.com/mpetrovich/dash)

~~~
Annatar
NO FRAMEWORKS!!!

------
fraktl
Judging by comments I saw and what I had my own clients tell me over the
phone/mail, it would appear that there's stigma associated with PHP, mostly
due to one super-popular blog post called "PHP - a fractal of bad design". I
won't go into rebuttal here, the author of the post did enough damage as it
is.

PHP evolved significantly since version 4. Version 5 was the "big" deal, with
good object oriented features. Version 7 brought the performance in, so we
could get rid of Facebook's crappy HHVM (thank you PHP team). Version 8 brings
JIT, however most of the workload isn't CPU bound but I/O bound.

So, here's something for PHP devs:

Swoole. [http://www.swoole.co.uk](http://www.swoole.co.uk) -> this is an
extension for PHP which brings in the same primitives available to people
using Node.js or Golang - coroutines, async I/O, channels, event loop control
and much more.

What it essentially does is turn ALL I/O from synchronous to asynchronous.
Without any code change or control structure in form of async/await or
promises. Write synchronous code, get asynchronous performance.

From my own experience (I've been running swoole in production for 18 months),
the performance gain I saw was minimum 500% to a maximum of 2000% (the numbers
aren't a joke).

As for PHP - it's a programming language. You can use it right or you can use
it badly. This rule applies to almost any language. There's no language in
this universe that can turn a bad programmer into semi-ok programmer or even
good programmer. If you haven't got the habits and knowledge, there's no
language that can rectify it. I've seen way too many people thinking the
language of their choice is to blame, but it was always the person in the
chair.

PHP performs well. Ecosystem is quite large and luckily there aren't competing
standards. Composer, the package manager, is wonderful. There's plenty of
frameworks to choose - for web and for CLI usage. Features are being added,
slowly but steadily.

I use PHP with Laravel + nginx, next to Nuxt + Vuetify + TypeScript for
frontend stuff. Personally, I really like how the mentioned tech can be
utilized to create great apps _fast_ \- with structured code, that look good
and work quick.

Edit: one of the best and most powerful features in PHP (starting with 7.4) is
the FFI - foreign function interface. The option to utilize libraries or
entire software, without the need to write PHP extensions, is what's amazing
for me (I also need it due to nature of my work).

PHP is way more powerful than people give it credit for. But I guess that's
what happens when opinions are formed by looking at titles and number of
"likes" or other meaningless numbers designed to mislead.

~~~
dana321
I like the look of swoole, first i've heard of it.

There is also a complete application server that supports php servlets,
message queue, persistence etc. that is well-supported. Its free, open source.

[https://appserver.io/](https://appserver.io/)

A team that supports Magento, Typo etc. based in Germany wrote it.

You can use either the PHP-FPM or the more interesting is the servlets,
because the data is kept in-memory - probably much in the same way as swoole
functions.

Its basically enterprise Java for PHP.

~~~
fraktl
I know about appserver.io and I would strongly advise against it (I have used
it, along with every other project that tried to use pthreads or bypass PHP-
FPM). It's not scalable. It also achieves "performance" by having the same
process(es) work on the requests over and over again, effectively bypassing
what PHP-FPM does on each request. If you set PHP-FPM up that a child process
kills itself after 500 requests processed, you'll get the same performance as
with appserver, but it'd scale horizontally. It's a toy and I would never use
it in production, the authors made a huge mistake of trying to process
requests in separate threads - my assumption is they just learned there's a
way to expose threads to PHP userland so they toyed with it.

Swoole is entirely different beast, it's like comparing a skateboard
(appserver) to intergalactic starship (swoole). It's not just about the
performance as it is about exposing OS primitives and having fine control over
I/O and processes.

Excellent find, but luckily - the current tools we've got at our disposal are
even better. No offense to people using or working on appserver, some projects
are just that - toys that help people learn more.

~~~
pbowyer
Have you any view on libev and the PECL ev library? There's been a recent
discussion on the php-internals mailing list about whether PHP needs a built-
in event based system
([https://externals.io/message/108226](https://externals.io/message/108226)) .

Having input from you with production experience of Swoole would be
_fantastic_.

------
CraftThatBlock
I'm a bit confused. I thought PHP 7 introduced a JIT, hence why it was much
faster (in some cases ~5x faster). How is it different from the PHP 8 JIT?

I always assumed that HHVM is what brought JITs to PHP originally, followed by
PHP itself.

~~~
jonny383
I believe there were attempts at implementing JIT in PHP 7 which were
unsuccessful against the timeline for release. Instead, they did other
optimizations and managed to squeeze quite a bit of performance doing this
(comparable to HHVM).

~~~
nkozyra
I think 7.1 or 7.2 was where it generally beat HHVM.

------
no_wizard
I like that 8 has some great changes coming and the JIT will be a long term
win.

I just hope the core maintainers evaluate true async/await constructs for PHP.
I also hope that the JIT leads to more significant advancement in PHP and how
it manages memory. For all it’s improvements it’s still really prone to memory
leaks easily

~~~
omnimus
PHP is synchronous (if you dont add async extensions). How would you use async
await in the language?

~~~
no_wizard
reactphp already fakes this with Promises, much the same as JavaScript
Promises. Why not make this a genuine language construct. You can even use the
async and await “sugar”.

Coroutines would also be a genuine improvement

~~~
omnimus
Sure there is also most notably swoole if you want async i would go all in.
That said it is going to be so wierd for most php programmers you might aswell
hire nodejs people and do it in node where language and ecosystem is all about
async.

~~~
no_wizard
Maybe, maybe not. The nice thing about adding constructs to a language is that
you often can _opt in_ when you do use them. Also, if you have PHP developers,
its going to take less time for them to learn async constructs in a language
they're familiar with than switching your _entire backend_ to nodejs just to
leverage those features. Seems to me like that'd be far more work and cost a
lot more.

Its not trivial to just upend an entire system.

------
kingdomcome50
I'm going to go ahead and play devil's advocate here and make the argument
that iteratively transforming PHP into a Java/C# clone is actually doing a
disservice to PHP. The reason PHP is so popular, and it's greatest strength,
is that it offers a "simpler" paradigm of development.

Many of the latest RFCs accepted (while I agree are great steps forward for
the language) may actually reduce it's foothold going forward. That is, they
are not a good fit for the community. I see no compelling reason to choose PHP
for a greenfield project if, when used in a production environment with a
stable framework, you are writing essentially the same code as you would for
Java/C#. There is hardly a feature where an ASP.NET core C# project isn't
still miles ahead of the same Symphony/Laravel back-end. Hell, with the new
Razor-Pages template, you are essentially writing "PHP" in C#... where you get
all of the bells, whistles, helpers, type-checking, generics, pattern
matching, LINQ etc that C# already offers!

IMO (emphasis on the "O") they are missing the point. I don't want my PHP
application to "look" just like a Java/C# app. I don't want a `Controllers`
directory and `RepositoryInterface`s everywhere... I don't want all of the
same ceremony it takes to develop a .NET Core/Spring app copied into PHP. What
I want is a composition of "scripts" (functions)!

PHP should focus on and develop towards it's strengths not it's weaknesses.
_Lean in_ to include. _Lean in_ to $GLOBALS. _Lean in_ to a more functional
approach. These are the things that have made PHP so dead-simple/approachable
over the years.

You want more features? Fine. Add pre-processing directives (akin to .razor).
Allow for files to truly be treated as modules. Simplify/abstract templating
into the language better. That is, instead of focusing on the kinds of
"features" that better-enable OOP (and move away from a composition of
"scripts"), focus on making it easier/better to compose "scripts". Make _that_
safer, clearer, more ergonomic. There are _plenty_ of ways to dramatically
improve PHP (as a platform) without simply updating the language semantics.
The language was _never_ the draw!

As many of the comments in this thread indicate/imply, PHP isn't chosen
because it is such a great _language_ , rather, it is chosen because it offers
an extremely convenient development paradigm. PHP is very-much "batteries
included" when compared to its contemporaries[0]. _This_ is why people reach
for it over and over again. So instead of changing the vehicle (PHP), how
about we give it more/better batteries instead?

/devil's advocate

How'd I do?

[0] I have always found the whole "framework vs raw PHP" debate in the
community a bit humorous. The "framework" crowd never seems to really
understand that, in many ways, raw PHP _is_ a framework. What other scripting
languages _automatically_ parse HTTP requests for you as part of the runtime?
Or come with a default "routing" scheme? Or offer built-in templating
semantics? PHP gives you all three out of the box.

------
jonny383
Union types look somewhat handy, especially if you're using

    
    
        T|null
    

In PHP 7, you can still do

    
    
        function foo(string $bar = null): void
    

Which is a little clunky...

~~~
EspadaV9
In PHP 7 the correct code should be

    
    
        function foo(?string $bar): void
    

Having `= null` marks the parameter as optional with the default being `null`.
Using `?string` means there is no default and you can pass in either a string
or null.

~~~
jonny383
Yes thanks. A little rusty on the old PHP knowledge off the top of my head.

------
amai
PHP and Perl are as dead as the Diesel engine in 2020. Somehow they are still
everywhere, but it doesn't feel right to start anything new with them.

------
perceptronas
Is it just me or PHP is trying to become Java? I remember 7~ years ago PHP
devs were "mocking" Java and not it kinda feels like its moving there

------
marcrosoft
PHP is looking a lot like Java these days.

~~~
celticmusic
I've seen a lot of people say this but I don't understand the sentiment, could
you explain it?

~~~
takeda
Either you haven't used Java, or didn't look at the examples in the link.

The code looks similar to Java code, how classes are constructed, extra type
modifiers, type access levels etc.

~~~
celticmusic
Or I'm surprised at the notion that types in an OO language is the minimum bar
for "turning into Java"?

That seems like a nonsensical litmus test.

~~~
takeda
Other languages that have these but they do look different.

I personally don't see anything wrong with it, but it does resemble Java to
me.

------
didip
wow, even PHP gets union types.

More languages really need to adopt union types.

------
abbiya
why does php garbage collect anything when there is a reference ? (weakmaps)

~~~
function_seven
Right now, it doesn't. If there's a reference, then the item is not garbage
collected. The WeakMaps change will allow a developer to take a reference to
something but say, "Hey, I'm caching this for now, but if you need the space,
I'm not married to it."

------
AnimalMuppet
Misread that as "new in PDP 8". I was expecting an old-school DEC story for a
moment...

------
misir
I hate php because: even if I used it for ~3 years I had to google how to send
GET/POST/PUT ... request. There are lots of ways to do that but each method
has its own issues. I'm now using dotnet core and happy with it's
orm/speed/infrastructure l/productivity/...

~~~
fraktl
This is exactly one of my points - and don't get me wrong - you're to blame
here.

Let's dissect your post a bit: you had to google how to send GET/POST/PUT TO
PHP or FROM PHP? Regardless, PHP doesn't care what you send it, you can send
JSON or base64 encoded string. It's completely irrelevant. If you used PHP for
3 years and are unaware of basic HTTP communication - how's PHP to be at fault
here? The real problem here is that you _imagined_ something, it didn't work
like you wanted it to and the next logical step is to blame the language. This
is such a bad way of thinking, I genuinely feel sorry for you.

I could pull several projects that deal with input via HTTP in PHP, and they
do it more than nicely. Issue is that you're simply - mediocre. And there's no
language that can fix it. Btw. my intent is not to insult you, even a mediocre
programmer can become a superstar.

~~~
Cthulhu_
I think most other languages and frameworks work via a more declarative API -
"if a GET request to /this comes in, return that". I had to look it up /
remind myself how it works in PHP as well the other day, and it's a bit more
involved:

    
    
        - Create a .htaccess file that rewrites /api/x/y/z to /api/index.php/x/y/z
        - Read $_SERVER['PATH_INFO'] for the /x/y/z
        - Read $_SERVER['REQUEST_INFO'] for the HTTP method (GET/POST/etc)
        - Create the response starting with some calls to `header()`
        - 'echo json_encode($resp);'
    

I'm sure all that is abstracted away in e.g Laravel though. The PHP standard
library could also do with an overhaul for modern applications for
requirements like this though.

~~~
fraktl
\- $_SERVER contains server and execution environment info \- $_REQUEST
contains request input parameter values (regardless of http verb)

That's it. It's not a lot. They're 2 super simple arrays.

PHP can also work from command line where $_REQUEST/$_POST/$_GET are
unavailable. You can also entirely ignore the existence of the above
variables. You can read from standard input and treat input as JSON - options
are endless. This merely means that the example shown is not entirely correct
- it's not "how it works in PHP". It's merely one of the ways. But the real
problem is: no one bothered to research it and you blindly assumed that's how
it works.

Laravel (Http/Kernel library) standardized the interface towards the dev and
that's great. But the input itself isn't as tied to PHP core as your comment
makes it seem.

------
mekster
I wish PHP makes the end of line semicolons optional like other modern
languages.

It saves a lot of typing when I have to trace brackets after auto completion
to add the semicolon instead moving to the next line.

~~~
giornogiovanna
In JavaScript the automatic semicolon insertion is almost universally reviled.
Why not just have your editor insert the semicolons for you if it's such a
pain to type them?

~~~
mekster
> Why not just have your editor insert the semicolons for you.

They don't insert the semicolons automatically as it can't tell if it's the
end of line or I'm about to invoke a chained method etc.

Not sure what the down votes are about as it literally increases 2 to 3
letters of extra typing just to append the semicolon after auto completion.

> In JavaScript the automatic semicolon insertion is almost universally
> reviled.

Why? There's literally no need except on a rare occasion. My IDE happily gets
rid of JS semicolons and it's far easier to type.

Ruby and Python don't need one. Just feels tedious compared to other scripting
languages.

