17 ms·

PHP 8

472 points by pow-tac 6y ago

DJBunnies 6y ago
React php is worth checking out. Async stuff like websockets and non blocking redis subscriptions.
- LarvaFX 6y ago
  What is React PHP?
  - richrichardsson 6y ago
    https://reactphp.org/ https://reactphp.org/ probably
  - francislavoie 6y ago
    Think of it like if PHP had Node's event loop runtime. There's also Swoole, which is like if PHP had Golang's runtime (i.e. coroutines and such).
- acomjean 6y ago
  Interesting. changes the shared nothing status of traditional php serving. https://reactphp.org/ https://reactphp.org/
  - DJBunnies 6y ago
    Daemons!
- fraktl 6y ago
  ReactPHP and all the other "async" frameworks became obsolete the moment Swoole entered the game.
  - francislavoie 6y ago
    Big disagree. They're just different. Swoole is like Golang, ReactPHP is like Node, in terms of runtime style.
muglug 6y ago
See also the splash page: https://www.php.net/releases/8.0/en.php https://www.php.net/releases/8.0/en.php
pornel 6y ago
Dupe https://news.ycombinator.com/item?id=25219870 https://news.ycombinator.com/item?id=25219870
cstuder 6y ago
Apparently some of the deprecations will make this the most backward compatibility breaking version jump of PHP since V4 to V5. (Read a german interview here: https://www.heise.de/news/PHP-8-im-Experten-Check-Der-erwartete-harte-Bruch-mit-der-Vergangenheit-4970530.html?wt_mc=rss.red.ho.ho.atom.beitrag.beitrag https://www.heise.de/news/PHP-8-im-Experten-Check-Der-erwart...) There's a long report on Wordpress and PHP 8 and it's not pretty: https://developer.yoast.com/blog/the-2020-wordpress-and-php-8-compatibility-report/ https://developer.yoast.com/blog/the-2020-wordpress-and-php-...
- tyingq 6y ago
  "There's a long report on Wordpress and PHP 8 and it's not pretty" I wonder if that's somewhat on purpose. Part of the remaining stigma with PHP is that people cite bad PHP examples from WP.
  - cstuder 6y ago
    No, I think WordPress being the most installed PHP application on the net warrants the special attention to it. https://w3techs.com/technologies/overview/content_management https://w3techs.com/technologies/overview/content_management
    - tyingq 6y ago
      Not sure I understand. I'm saying the PHP team didn't cede any deprecations to Wordpress this time. Meaning no special attention.
      - cstuder 6y ago
        Sorry, I missunderstood what you were writing. Yes, it doesn't look like they took special attention to WordPress when developing PHP 8.
  - BeyondLimits99 6y ago
    As a PHP dev this is a really fair comment. I think the other reason non PHP devs think we are in the dark ages is because when they google it, our documentation looks like it's from 2010. It's a bit of a joke really.
laszlokorte 6y ago
Php was my first language I learned 15 years ago. On that way I really started to hate it because of all it's quirks. Many of those have been fixed and nowadays I really enjoy it again and it's my goto language for any web project. It really hits a pragmatic sweetspot. It's really easy to deploy and frameworks like symfony give you all the power like rails but without the magic.
- bavell 6y ago
  Same here, started off with PHP around a decade ago and couldn't wait to move to another server-side language. Nowadays it's much nicer to work with (as long as you avoid the warts) and PHP 8 looks to deliver another slew of welcome upgrades. Only downside is that there does seem to be quite a lot of (non-trivial) deprecations which is understandable but I wonder how long it'll take for 8 to percolate into production...
  - nolok 6y ago
    Every single deprecation is a wart being removed, none of them are a python 2->3 kind of issue (it worked just fine but now I need to work to move it to the new stuff !), and it's all easily fixable in your code with minimal effort (but decent amount of time ... if you've not bothered to clean up warnings for the past decades). The cases that are not replacable easily are things that should never have been written ever.
- erikpukinskis 6y ago
  What do you mean without the magic?
  - laszlokorte 6y ago
    Ruby is extreme flexible in terms of metaprogramming in rails uses that very much. And ruby is not statically typed. So if in rails you declare an active record model with belongs_to etc it's hard to keep track of what is really happening under the hood. In php you have almost no runtime metaprogramming so the things that could happen if you read a piece of code are reduced to a smaller set of options that are easier to understand. well you have reflections but at least they are used in a more static way.
sleavey 6y ago
> 0 == 'foobar' // true That's PHP7 behaviour that's updated in 8 to return false. I'm not a PHP basher, I really like it these days, but why the heck was that example ever evaluating to true?
- belst 6y ago
  because (int)'foobar' is 0
  - acomjean 6y ago
    JavaScript and php have the === which doesn’t try casting types. Php has good documentation with examples which I appreciate : https://www.php.net/manual/en/language.operators.comparison.php https://www.php.net/manual/en/language.operators.comparison....
- nkuttler 6y ago
  Just a guess, but casting a string that's not a number to int would give you zero?
- stevekemp 6y ago
  'foobar' is coerced into a number, which fails for the obvious reason. So it becomes 0, which means the expression is "0 == 0". Terrible, terrible, behaviour but there are lots of similar examples in PHP because it evolved over time rather than being designed as-is. Some of these things are being fixed over time, like this very example, others can't/won't be.
  - scaladev 6y ago
    And people say C++ is a complicated language.
    - will4274 6y ago
      Yes because ('0' == 32) returning true makes more intuitive sense. There are languages without type coercion for comparisons (e.g. OCaml), but C++ isn't one of them.
overflow_error 6y ago
Though I still wish they officially support async I/O, this is an improvement, excited about this!
dastx 6y ago
I find it really weird that the match expression is strict comparison, but everywhere else it's loose comparison. Don't get me wrong, I prefer strict comparison, and prefer strongly typed languages because of it, I just feel that this is a strange design choice. In addition, the @ operator seems to have functionality changed, and there is plenty of other backwards incompatible changes to go along with it, and yet, one of the main reasons to not choice the @ symbol for annotation/attributes was because of backwards incompatibilities. Personally, I find the introduced syntax for attributes terrible, especially when @ is well recognised in the php community thanks to phpdoc annotations.
- nikic 6y ago
  > I find it really weird that the match expression is strict comparison, but everywhere else it's loose comparison. Don't get me wrong, I prefer strict comparison, and prefer strongly typed languages because of it, I just feel that this is a strange design choice. What is "everywhere else"? You usually explicitly need to specify the type of comparison you want by writing either == or ===. "switch" is a case where the comparison operator is implicitly "==". "match" using "===" instead is one of the primary reasons for introducing it. > In addition, the @ operator seems to have functionality changed, and there is plenty of other backwards incompatible changes to go along with it, and yet, one of the main reasons to not choice the @ symbol for annotation/attributes was because of backwards incompatibilities. Personally, I find the introduced syntax for attributes terrible, especially when @ is well recognised in the php community thanks to phpdoc annotations. The only change to "@" is that it no longer suppresses fatal errors, which was generally not an intended or useful effect. The only thing this affects in practice are error handlers that don't check for error suppression being active correctly. The "@" operator is still very much needed for certain use-cases (e.g. I/O functions may throw expected warnings) and removing it was not even a remote possibility for PHP 8, and as such also not a candidate for the attribute syntax. It is worth noting that PHP uses the same attribute syntax as Rust does.
- ojnabieoot 6y ago
  Not a PHP dev, but I read a lot of it for work: based on the example provided, I gather the PHP community accepts that the non-strict behavior of ‘switch’ was undesirable, but it would be too difficult to break the non-strict semantics in an existing construct. Likewise, the fact that ‘match’ is an expression rather than a statement encourages stricter semantics: although it’s technically unrelated to the type coercion issue, ‘match’ expressions should be easy to reason about locally, which isn’t the case for switch statements. This idea is encouraged by the fact that ‘match’ branches can’t continue across multiple lines: although technically ‘match’ could mutate some complicated global state, the intended use case is a constant or a simple function - easy to understand, and relatively gotcha-free. Gotchas should go in a ‘switch’ statement. Seasoned PHP devs aren’t going to accidentally use the brand-new ‘match’ statement without careful study, and I don’t think the inconsistency is too big of a deal for newer devs: the overall principle is that ‘match’ is safer than ‘switch’ but less powerful.
tasogare 6y ago
A lot of the syntax of new features and features themselves are very close or identical to C#, which is a good thing in my book. It’s nice to see the language evolving in a more typed direction while still being super fast to start a project with.
acomjean 6y ago
I'm pretty excited. though we've just moved off 5X at work (slow on the uptake..) I like php. It fast enough, easy to learn (we've had new people pick it up). Its my goto for web development, with some of the frameworks, it seems to have a balance of control and automation I like. Really like symfony for its forms and twig templating engine. Symfony makes a lot of things easy, but is flexible enough when you want to change something. (We like writing native db queries with pdo). It has a package manager (only 1 really, which makes that choice easier) I continue to poke around with react and view js but if I end up using one, I'll just make synfony my json serving backend.
99_00 6y ago
I've never used PHP. Now I'm learning it with Laravel for my personal project. This is after using C++ with ASP, C# with ASP.NET, Java with Spring and Spring boot at work. The promise of rapid development is the main draw.
bnt 6y ago
Really looking forward to the match expression syntax!
yetkin 6y ago
Out of curiosity, why match expressions became popular for non functional languages? Without pattern matching on datatypes via cons expression (x::xs matching) it is just another kind of switch or if/else. Why do people promote this? here a nice comment on this topic: https://ocaml.org/learn/tutorials/data_types_and_matching.html#Pattern-matching-on-datatypes https://ocaml.org/learn/tutorials/data_types_and_matching.ht... "So one Really Cool Feature of functional languages is the ability to break apart data structures and do pattern matching on the data. This is again not really a "functional" feature - you could imagine some variation of C appearing which would let you do this, but it's a Cool Feature nonetheless"
- jpz 6y ago
  It simplifies the expression of if/then/elsif/elsif/else, even if it's not total. Why not steal it?
  - yetkin 6y ago
    but why all of a sudden languages started to add this? Maybe the function itself needs to be simplified, maybe there is a design issue. i am failing to see how "if else" can be simplified via a synth sugar.
    - beberlei 6y ago
      one benefit of match over switch is that it uses === and not == internally. So it does not suffer from type coercion problems.
    - nicoburns 6y ago
      It's a switch statement that's an expression. That's a nice ergonomic improvement when you want to assign the result to a variable. Especially as it allows you to use a non-mutable variable whereas otherwise you'd have to make it mutable.
      - chmod775 6y ago
        I wouldn't compare it to a switch statement, because a switch statement - even though it looks similar - has fundamentally different control flow.
Thaxll 6y ago
Does PHP still has that weird flow where each request is its own process? afair PHP never had an http server baked in, I remember nginx with php etc ...
- kijin 6y ago
  Yes, each request is handled by its own process. This might sound weird if you're used to other languages, but it's how every language used to work in the good ol' CGI days. PHP doesn't break backward compatibility easily, and I don't think it will ever break this one. Besides, once you get the hang of it, PHP's execution model is highly intuitive and beginner-friendly. You simply don't have to worry about a whole class of concurrency-related problems. Those problems are solved in C, not PHP. Nowadays everyone uses PHP-FPM (again, written in C) which manages a pool of processes. Once a process is done serving a request, it is cleaned up and becomes available for serving another request. You can tweak the number of processes to control how much concurrency you want, or leave it to PHP-FPM to decide on its own. The process pool is much more efficient than the CGI method of setting up and tearing down a process every time, while preserving much of the conceptual simplicity. PHP has had a built-in HTTP server since 5.4, but few people use it in production because PHP-FPM is so stable and performant.
  - zexias 6y ago
    The PHP doc advices you that the built-in server from PHP should be used only for development: https://www.php.net/manual/en/features.commandline.webserver.php https://www.php.net/manual/en/features.commandline.webserver.... But PHP-FPM is the most used nowadays, for sure.
    - kijin 6y ago
      I find the built-in web server very useful for running tests. Instead of setting up Apache or nginx on every CI build, you just fire up the built-in web server and point your tests at it.
      - FranOntanaya 6y ago
Kim_Bruning 6y ago
Finally, after all these years, Named Arguments! https://stitcher.io/blog/php-8-named-arguments https://stitcher.io/blog/php-8-named-arguments
- EGreg 6y ago
  Look, 10 years ago I tried — really tried — to get the PHP team to adopt it. I am glad they finally came around: https://www.mail-archive.com/internals@lists.php.net/msg45871.html https://www.mail-archive.com/internals@lists.php.net/msg4587... Excerpt of the proposal: So why am I saying all of this? Well, PHP up until 4 had a reputation for lots of bad coding style, spaghetti code, etc. With PHP 5 and better OOP, this reputation has lessened, especially with the great libraries out there (Zend Framework, Kohana, symfony, etc.) But there is still a problem. We (or at least I) would want PHP 6's reputation to be even better, and the reputation is largely based on how maintainable and cost-effective the code is, which is written by programmers actually using PHP. Blaming newbie programmers is one thing, and may even have some truth to it (PHP is simple - thus attracts newbies) but it's always good for a language to steer you in the right direction by default, and make it easier to write maintainable code. PHP has a great opportunity to do this, by implementing a very simple change, turning all current PHP 5 code, and all code that will be written in the future, into maintainable code. Moreover, it won't break any existing code, like some other additions to PHP 6 might do. This one simple tweak will make PHP 6 code much more reusable and maintainable, just like namespace support will potentially make future PHP code more interoperable without having to write Artificial_Namespace_Class, like ZF and PEAR do.
  - Kim_Bruning 6y ago
    Thank you for your efforts back then. And now you stand vindicated!
    - EGreg 6y ago
      Somehow one guy was really sure it will never happen: https://www.mail-archive.com/internals@lists.php.net/msg48044.html https://www.mail-archive.com/internals@lists.php.net/msg4804...
meowster 6y ago
How should one start learning with PHP these days? My experience: hacked together a few PHP scripts over the years to notify me of a website change (5 minute cron job). Before that, I was a very good beginner with VB6 back in highschool. There are a couple of ambitious database-driven website projects I would like to create, but I don't know where to start. I like the KISS philosophy, and I think PHP and MySQL would fill that. Is there an obvious alternative that I'm missing? I was thinking of hoing through the w3schools PHP turtorial. Is there a better or more up-to-date resource?
- TOGoS 6y ago
  Keep hacking, learn from your own mistakes, do this for 10 years. By the end of that time you should, for example, understand why we use Postgres instead of MySQL. :)
- dagw 6y ago
  Modern PHPs shining light is the Laravel framework and the ecosystem built up around it. If you're going to start a database-driven website projects in PHP there really isn't a good reason to not use and learn Laravel (or Lumen if you want something more lightweight). That being said if you're not tied to PHP I'm not sure I'd necessarily recommend it. The obvious alternatives worth looking into are Ruby on Rails or Python with Flask or Django.
  - kyriakos 6y ago
    Laravel is good and bad for the ecosystem at the same time. I've interviewed a lot of people lately who know laravel but not php. Similarly to people who claim they know react but fail in the most basic js questions.
    - thinkindie 6y ago
      Additionally Laravel abuses patterns like singletons and in general static methods. This is really a no-no for modern PHP, in my opinion. I think Symfony had a way better impact on the ecosystem.
CraneWorm 6y ago
0 == 'foobar' // false > When comparing to a numeric string, PHP 8 uses a number comparison. Otherwise, it converts the number to a string and uses a string comparison. Why do the conversion at all? Why couldn't this just be an error? I realise there is also `===` the strict comparison that typechecks arguments, but why not make that the default?
- baby 6y ago
  > Why couldn't this just be an error? you mean crash your program? So your user finds a way to send you an int instead of a string, or vice versa, and now they can crash your webserver.
  - mgkimsal 6y ago
    technically they'd just crash that one php process, not the whole web server. :) I think the bigger 'why not' is ... 25 years of backwards compatibility.
    - baby 6y ago
      Oh right ^^ that’s actually one really cool thing about php web apps, no easy denial of service attacks
      - mgkimsal 6y ago
        (again) technically it could trigger a warning (actually, I thought perhaps it did that years ago??) It's still pretty easy to DOS the server that is passing requests to PHP. The 'shared nothing' approach has other benefits though - primarily not having to concern yourself with concurrency issues or shared memory resources. You can dive in to deep PHP and do that, but it's not something beginners need to be thinking about.
lgeorget 6y ago
I wonder what makes the Symfony Demo App not being faster with the JIT compiler (as shown on https://www.php.net/releases/8.0/en.php https://www.php.net/releases/8.0/en.php and https://susi.dev/php8-benchmark-jit-symfony https://susi.dev/php8-benchmark-jit-symfony). Maybe because Symfony already caches things very efficiently/cleverly with OPCache?
- dante_dev 6y ago
  Mostly because only cpu-intensive code greatly benefits from JIT. Serving a blog (like the demo) is not much cpu-intensive.
  - jashmatthews 6y ago
    OO heavy code and functional heavy code can also benefit greatly from JIT compilation. The PHP8 JIT just doesn't have these optimizations yet.
- mgkimsal 6y ago
  The article you link to already explains it... ? > The point is, if you look in the announcements and comments about what the JIT does you can pretty much guess why this is kind of the expected result. The JIT compiler improves performance for CPU-intensive work (for example calculating Mandelbrots) but not so much for the "default" kind of applications. We usually don't do all that many calculations.
  - lgeorget 6y ago
    Yes, I read that, but that's not really what I ask. What makes JIT improve performance only for CPU-intensive work? I don't understand the connection there.
combatentropy 6y ago
I got spoiled by PHP as my first language. It was so easy to get going. I was surprised to learn that other languages didn't work the same way, when integrating into a web server. Also it has always been rock solid. A bug in my code brought down only that request for that user, totally did not affect or even slow down responses to other users. People have attacked its syntax forever. I avoided the worst of it by learning PHP around version 4, when it was moving away from magic quotes and register globals --- and I also had the sense to see that those were unwanted anyway. But I think the main reason that PHP hasn't bothered me is that I try to use it as little as possible. Let me explain. I consider PHP a glue language, between my database and the user's browser. When you use a lot of glue, things get messy. I try to push things out of the middle layer to the edges, if they will fit. So I try to do a lot of data preparation in the database, through fancy queries, so that the data is mostly ready for the HTML template by the time it is received by PHP. It helps that my database is Postgres. For authentication, I try to lean on Apache, so that PHP would just have to consult the CGI variable REMOTE_USER. So PHP acts sort of like an extension language to Apache (even when I'm using PHP-FPM instead of mod_php). It takes the data from the database and wraps it in HTML. It takes the form submission from the user and hands it to the database (and most server-side data validation is in the database). The people attacking its syntax sound like they are writing an awful lot of PHP per app. And maybe for some things you have to, but not for CRUD apps, I think. I try to keep the middle layer as thin as possible, and I would do that whether it was PHP, Python, or Perl.
- baby 6y ago
  > I was surprised to learn that other languages didn't work the same way, when integrating into a web server Oh boy... I'm still not sure how you deploy a non-PHP webserver to be honest... every language seems to be doing something different, with php you just needed to drag & drop your files in the "public" folder.
  - http-teapot 6y ago
    > I'm still not sure how you deploy a non-PHP webserver to be honest... every language seems to be doing something different Coming from PHP and having used a bunch of different languages I can understand what you are saying. Unlike PHP, the other languages run in a process that listens on a port (80, 443 or another). The single process continuously run and handles multiple requests. Back then, I still had to use NGINX or Apache with PHP, and in retrospect I find that more difficult to understand than a script that listens on a port.
Sodaware 6y ago
I don't really like PHP, but it pays my bills. There are some big improvements in this release. Named arguments and actual attributes (instead of special tags in comments) are really nice.
carrja99 6y ago
I still love you PHP
- redvenom 6y ago
  Me too. For people on shared hosts (hundreds of small websites including small businesses), PHP is pretty much the only server-side language that you have access to (well, maybe aside from Perl).
dang 6y ago
There have been 5 major threads about PHP 8 in the last few months: https://news.ycombinator.com/item?id=24866190 https://news.ycombinator.com/item?id=24866190 https://news.ycombinator.com/item?id=24235440 https://news.ycombinator.com/item?id=24235440 https://news.ycombinator.com/item?id=24320024 https://news.ycombinator.com/item?id=24320024 https://news.ycombinator.com/item?id=24150731 https://news.ycombinator.com/item?id=24150731 https://news.ycombinator.com/item?id=23955197 https://news.ycombinator.com/item?id=23955197 A couple of those are more technically specific (to JITs and named arguments) but the vast majority are just the usual comments about PHP in general. Nothing wrong with that, of course, except that there gets to be too much of it. This is a harder problem than it seems, because popular projects always get generic discussion (btw if you hate something that's still a kind of popularity!) and the alpha and beta releases always get posted and frequently get upvoted for the same (popularity) reason. There's a longer explanation about this here if anyone cares: https://news.ycombinator.com/item?id=23071428 https://news.ycombinator.com/item?id=23071428. We downweight generic subthreads when they get stuck at the top of the page, but only sporadically, since it requires manual monitoring. (Btw, emailing hn@ycombinator.com when you notice a generic top subthread in any discussion is always super appreciated! Downweighting those is probably the biggest single thing we can do to improve thread quality.) As for why generic discussion is worse: it's repetitive and contains less information. More on that: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sort=byDate&type=comment&query=generic%20discussion%20by:dang https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor... https://hn.algolia.com/?dateRange=all&page=0&prefix=false&sort=byDate&type=comment&query=curiosity%20repetition%20by:dang https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...
- muglug 6y ago
  Thanks for the explanation – I was wondering why it jumped from the top spot. This particular post might want to get a reprieve – not because the discussion is interesting, but because the news itself – PHP 8.0.0 being released – is reasonably important.
idoubtit 6y ago
I get paid for writing PHP code, and the quality of the official PHP documentation worries me. I've searched for several of the changes introduced by the 8.0 version, and I could not find them. For instance, the page titled "Function arguments" does not mention the existence of named arguments. The last time I wanted to submit a ticket about a documentation bug, I saw that the ticket was already created months ago. I'm surprised the PHP process can introduces changes without the related documentation update.
- pbowyer 6y ago
  The PHP project is severely underresourced. One or 2 core devs are sponsored by their employer to work on the project; everyone else is volunteering, and the pool of people isn't as large as it once was. And that's for developing PHP itself. Documentation needs people too (there are many arguments for and against adding features without documentation) and the team would welcome new members.
  - CraigRood 6y ago
    Interesting, I had no idea. What could an individual like myself do to help this situation?
    - pbowyer 6y ago
      Thanks for asking! Join the php.internals mailing list. The join feature is _really_ unreliable, so that's hurdle number 1. Put up with the rudeness and insults on the list. This has got better in the (checks diary) last _7 months_. It's a bit more constructive than it was. Follow the discussions, join the documentation team, make contributions. They won't let you vote until you've done enough to be allowed voting rights. But contributing to the discussions makes a difference. If you write C or C++ there is so much you can do. There's the barrier of learning the PHP macro language (where I got stuck) but once you get past that you're one of a very select band who can contribute to PHP's source.
ericbarrett 6y ago
Facebook’s backups were written in PHP. Well, the second version was, anyway. (The first version didn’t work so well.) By backups, I mean the central MySQL databases with profile and post information; not media or messages. The “Crown Jewels,” so to speak. It was written by an engineer in a week or so and then handed off to me. I was a storage guy with some programming chops. Fewer chops than I thought. Multiprocess, forking, long-lived, server-side, I/O intensive PHP. And it worked brilliantly. Over the following years, it scaled from a backup set of a few hundred TB to many, many petabytes. I extended the code quite a bit, fixed a bunch of bugs (it was version 0 when it launched, no hate to the guy who wrote it), and added statistics for reports and coverage. The main reliability problem ended up being when we switched to HPHP, the predecessor to HipHop. Since the primary and largest customer of this code was the web front-end, changes there would often break our backend code. One I remember was changing fork() to only start a new green thread; saved $millions on the front end, completely broke backups. We ended up getting a special posix_fork() function or something from the HPHP team that restored the old behavior. Eventually I rewrote it in Python 2.7. It took me two complete attempts and then a further six months of tweaking to get it anywhere near as stable as the PHP version, even with brilliant guys like Haiping Zhao constantly re-weaving the carpet under our feet. I never did like it as much as the PHP version.
- sigzero 6y ago
  Why did you switch to Python? Surely it wasn't as perfomant and you already had a working solution.
  - ericbarrett 6y ago
    Mainly to get off HPHP and relieve both that team and ours of the constant coordination and toe-mashing. We thought “modernizing” the code would be a better investment than jerry-rigging the Zend engine back into our infrastructure. I think it was the right call. Also, with Python we could interact with other services using basic Thrift bindings, and even provide our own endpoints. With PHP, all RPCs and queries were prebuilt into our standard libraries with custom glue code that increasingly made non-Zend assumptions. Again, we could have made it work, but we would be swimming against the current. All the rest of the database management code ended up being moved to Python, and benefitting greatly, so it eventually worked out. In summary, organizational concerns.
electrotype 6y ago
I haven't touched PHP for a long time now. How is the Unicode support now? I remember having to use some special utilities to handle characters like "œ" properly.
- kilburn 6y ago
  You cannot use the "basic" string manipulation functions (strcmp, strlen, etc.) because these are not unicode-aware. However, you have the multibyte string functions family that can operate in a wide range of encodings (including UTF-8 which is the default in any sane installation nowadays). [1] https://www.php.net/manual/en/ref.mbstring.php https://www.php.net/manual/en/ref.mbstring.php
  - electrotype 6y ago
    I think I had issues even with mbstring, for some characters like "œ". But maybe I'm wrong.
    - duskwuff 6y ago
      œ works fine with mb_strlen(). What might have been tripping you up is combining character sequences: https://3v4l.org/DM4pC https://3v4l.org/DM4pC Handling those "correctly" with a string length function gets complicated in any language, as there isn't a 1-to-1 mapping between Unicode codepoints and visible glyphs.
      - electrotype 6y ago
        Yes, I think you nailed what my issue was.
      - njuw 6y ago
        In PHP grapheme_strlen achieves what you're describing: https://3v4l.org/HPOb3 https://3v4l.org/HPOb3
wackget 6y ago
Where's the best place to suggest a new feature or improvement for PHP? I've always wanted to see `foreach` get a built-in iterator/counter so you don't have to create and use a counter variable manually. Current way: $i=0; foreach ($array as $key => $value) { echo "Loop $i of " . count($array); $i++; } Possible new way: foreach ($array as $key => $value, $i) { echo "Loop $i of " . count($array); }
- deleted 6y ago
  [deleted]
- throw_m239339 6y ago
  https://wiki.php.net/rfc https://wiki.php.net/rfc IMHO that array/map data structure is one of PHP's biggest sin. So many bugs as the result of it and it makes a lot of codebases barely readable.
- mdaniel 6y ago
  For that code snippet specifically, you're actually better off pre-declaring the vars since the loop repeatedly calls `count($array)` but hopefully(!) its size doesn't change over time. Is there such a function in php like "enumerate" in python, that yields a tuple of (counter, item) for each item in the first argument to enumerate? That is to say: is it possible to do what you're asking with composition rather than a language change?
  - johannes1234321 6y ago
    Since count is it's own opcodes in the VM and php hashtables keep the number of elements around and don't have to be counted there shouldn't be much difference between reading a variable and calling count. (Since some time in PHP 7, before that count() went via function call overhead)
- kingdomcome50 6y ago
  While not quite as ergonomic as your example, it's rather trivial to extend ArrayIterator to accomplish your goal: foreach ($iter = new IndexingIterator($array) as $k => $v) { echo $iter->index(); }
rcarmo 6y ago
I can't believe nobody has pointed out (yet) that PHP is the quintessential lambda :) That said, it's been many (many, many!) years since I moved away from it, but I'm intrigued by the state of the JIT and the current coding style (last time I checked, around 6.x, it was growing to be verbose and full of backslash-adorned-namespacing).
- johannes1234321 6y ago
  "PHP was serverless before there was serverless" However there is a difference: PHP has no deployment system included. But if you build that (not too hard) the difference isn't big ... (But with Lambda&others you outsource the management)
  - young_unixer 6y ago
    > PHP has no deployment system included. SFTP? I mean, it's not included in PHP, but any linux system has it.
    - johannes1234321 6y ago
      SFTP, rsync all work, to some degree NFS also is an option. However that's just the technology. You need to build a solution around it, which monitors load and deploys the code as needed and scales down again and eventually in PHP you'd also expect that PHP Session management is integrated ... all doable and people did. The selling point of lambda is "it works" and "not your concern" (with the corresponding downsides)
- Ndymium 6y ago
  PHP 6 was never released, you are probably thinking of 5.3+
  - rcarmo 6y ago
    "Sometime before 7", yes.
- 6y ago
mrweasel 6y ago
It's nice to see the language being cleaned up a bit. PHP was the first language I learned, but the more I used and read code written in other language, the more PHP seemed like a mess, and it got worse the more features are being bolted on.
flemhans 6y ago
Already supported by my local provider, <https://gigahost.dk/en/features/php https://gigahost.dk/en/features/php>
- spaZeman 6y ago
  They are not alone in Denmark: https://www.netsite.dk/blog/2020/11/php-8-webhotel-lanceret-7-2-udgaar/ https://www.netsite.dk/blog/2020/11/php-8-webhotel-lanceret-...
TekMol 6y ago
If I understand it correctly, the next Debian version will come with PHP 7.4: https://packages.debian.org/testing/php/php https://packages.debian.org/testing/php/php Is that correct?
thiht 6y ago
It seems like an amazing release. I've not touched PHP code for at least 5 years but it makes me want to play with it again :)
richardjennings 6y ago
PHP is the poster child for the peoples syntax.
young_unixer 6y ago
If there was a language/framework with the simple PHP workflow of dropping files into a directory, but with a good syntax, we would probably be colonizing other galaxies at this point.

PHP 8

472 points by pow-tac 6y ago

DJBunnies 6y ago

React php is worth checking out. Async stuff like websockets and non blocking redis subscriptions.

LarvaFX 6y ago
What is React PHP?
- richrichardsson 6y ago
  https://reactphp.org/ https://reactphp.org/ probably
- francislavoie 6y ago
  Think of it like if PHP had Node's event loop runtime. There's also Swoole, which is like if PHP had Golang's runtime (i.e. coroutines and such).
acomjean 6y ago
Interesting. changes the shared nothing status of traditional php serving. https://reactphp.org/ https://reactphp.org/
- DJBunnies 6y ago
  Daemons!
fraktl 6y ago
ReactPHP and all the other "async" frameworks became obsolete the moment Swoole entered the game.
- francislavoie 6y ago
  Big disagree. They're just different. Swoole is like Golang, ReactPHP is like Node, in terms of runtime style.

muglug 6y ago

See also the splash page: https://www.php.net/releases/8.0/en.php https://www.php.net/releases/8.0/en.php

pornel 6y ago

Dupe https://news.ycombinator.com/item?id=25219870 https://news.ycombinator.com/item?id=25219870

cstuder 6y ago

Apparently some of the deprecations will make this the most backward compatibility breaking version jump of PHP since V4 to V5. (Read a german interview here: https://www.heise.de/news/PHP-8-im-Experten-Check-Der-erwartete-harte-Bruch-mit-der-Vergangenheit-4970530.html?wt_mc=rss.red.ho.ho.atom.beitrag.beitrag https://www.heise.de/news/PHP-8-im-Experten-Check-Der-erwart...) There's a long report on Wordpress and PHP 8 and it's not pretty: https://developer.yoast.com/blog/the-2020-wordpress-and-php-8-compatibility-report/ https://developer.yoast.com/blog/the-2020-wordpress-and-php-...

tyingq 6y ago
"There's a long report on Wordpress and PHP 8 and it's not pretty" I wonder if that's somewhat on purpose. Part of the remaining stigma with PHP is that people cite bad PHP examples from WP.
- cstuder 6y ago
  No, I think WordPress being the most installed PHP application on the net warrants the special attention to it. https://w3techs.com/technologies/overview/content_management https://w3techs.com/technologies/overview/content_management
  - tyingq 6y ago
    Not sure I understand. I'm saying the PHP team didn't cede any deprecations to Wordpress this time. Meaning no special attention.
    - cstuder 6y ago
      Sorry, I missunderstood what you were writing. Yes, it doesn't look like they took special attention to WordPress when developing PHP 8.
- BeyondLimits99 6y ago
  As a PHP dev this is a really fair comment. I think the other reason non PHP devs think we are in the dark ages is because when they google it, our documentation looks like it's from 2010. It's a bit of a joke really.

laszlokorte 6y ago

Php was my first language I learned 15 years ago. On that way I really started to hate it because of all it's quirks. Many of those have been fixed and nowadays I really enjoy it again and it's my goto language for any web project. It really hits a pragmatic sweetspot. It's really easy to deploy and frameworks like symfony give you all the power like rails but without the magic.

bavell 6y ago
Same here, started off with PHP around a decade ago and couldn't wait to move to another server-side language. Nowadays it's much nicer to work with (as long as you avoid the warts) and PHP 8 looks to deliver another slew of welcome upgrades. Only downside is that there does seem to be quite a lot of (non-trivial) deprecations which is understandable but I wonder how long it'll take for 8 to percolate into production...
- nolok 6y ago
  Every single deprecation is a wart being removed, none of them are a python 2->3 kind of issue (it worked just fine but now I need to work to move it to the new stuff !), and it's all easily fixable in your code with minimal effort (but decent amount of time ... if you've not bothered to clean up warnings for the past decades). The cases that are not replacable easily are things that should never have been written ever.
erikpukinskis 6y ago
What do you mean without the magic?
- laszlokorte 6y ago
  Ruby is extreme flexible in terms of metaprogramming in rails uses that very much. And ruby is not statically typed. So if in rails you declare an active record model with belongs_to etc it's hard to keep track of what is really happening under the hood. In php you have almost no runtime metaprogramming so the things that could happen if you read a piece of code are reduced to a smaller set of options that are easier to understand. well you have reflections but at least they are used in a more static way.

sleavey 6y ago

> 0 == 'foobar' // true That's PHP7 behaviour that's updated in 8 to return false. I'm not a PHP basher, I really like it these days, but why the heck was that example ever evaluating to true?

belst 6y ago
because (int)'foobar' is 0
- acomjean 6y ago
  JavaScript and php have the === which doesn’t try casting types. Php has good documentation with examples which I appreciate : https://www.php.net/manual/en/language.operators.comparison.php https://www.php.net/manual/en/language.operators.comparison....
nkuttler 6y ago
Just a guess, but casting a string that's not a number to int would give you zero?
stevekemp 6y ago
'foobar' is coerced into a number, which fails for the obvious reason. So it becomes 0, which means the expression is "0 == 0". Terrible, terrible, behaviour but there are lots of similar examples in PHP because it evolved over time rather than being designed as-is. Some of these things are being fixed over time, like this very example, others can't/won't be.
- scaladev 6y ago
  And people say C++ is a complicated language.
  - will4274 6y ago
    Yes because ('0' == 32) returning true makes more intuitive sense. There are languages without type coercion for comparisons (e.g. OCaml), but C++ isn't one of them.

overflow_error 6y ago

Though I still wish they officially support async I/O, this is an improvement, excited about this!

dastx 6y ago

I find it really weird that the match expression is strict comparison, but everywhere else it's loose comparison. Don't get me wrong, I prefer strict comparison, and prefer strongly typed languages because of it, I just feel that this is a strange design choice. In addition, the @ operator seems to have functionality changed, and there is plenty of other backwards incompatible changes to go along with it, and yet, one of the main reasons to not choice the @ symbol for annotation/attributes was because of backwards incompatibilities. Personally, I find the introduced syntax for attributes terrible, especially when @ is well recognised in the php community thanks to phpdoc annotations.

nikic 6y ago
> I find it really weird that the match expression is strict comparison, but everywhere else it's loose comparison. Don't get me wrong, I prefer strict comparison, and prefer strongly typed languages because of it, I just feel that this is a strange design choice. What is "everywhere else"? You usually explicitly need to specify the type of comparison you want by writing either == or ===. "switch" is a case where the comparison operator is implicitly "==". "match" using "===" instead is one of the primary reasons for introducing it. > In addition, the @ operator seems to have functionality changed, and there is plenty of other backwards incompatible changes to go along with it, and yet, one of the main reasons to not choice the @ symbol for annotation/attributes was because of backwards incompatibilities. Personally, I find the introduced syntax for attributes terrible, especially when @ is well recognised in the php community thanks to phpdoc annotations. The only change to "@" is that it no longer suppresses fatal errors, which was generally not an intended or useful effect. The only thing this affects in practice are error handlers that don't check for error suppression being active correctly. The "@" operator is still very much needed for certain use-cases (e.g. I/O functions may throw expected warnings) and removing it was not even a remote possibility for PHP 8, and as such also not a candidate for the attribute syntax. It is worth noting that PHP uses the same attribute syntax as Rust does.
ojnabieoot 6y ago
Not a PHP dev, but I read a lot of it for work: based on the example provided, I gather the PHP community accepts that the non-strict behavior of ‘switch’ was undesirable, but it would be too difficult to break the non-strict semantics in an existing construct. Likewise, the fact that ‘match’ is an expression rather than a statement encourages stricter semantics: although it’s technically unrelated to the type coercion issue, ‘match’ expressions should be easy to reason about locally, which isn’t the case for switch statements. This idea is encouraged by the fact that ‘match’ branches can’t continue across multiple lines: although technically ‘match’ could mutate some complicated global state, the intended use case is a constant or a simple function - easy to understand, and relatively gotcha-free. Gotchas should go in a ‘switch’ statement. Seasoned PHP devs aren’t going to accidentally use the brand-new ‘match’ statement without careful study, and I don’t think the inconsistency is too big of a deal for newer devs: the overall principle is that ‘match’ is safer than ‘switch’ but less powerful.

tasogare 6y ago

A lot of the syntax of new features and features themselves are very close or identical to C#, which is a good thing in my book. It’s nice to see the language evolving in a more typed direction while still being super fast to start a project with.

acomjean 6y ago

I'm pretty excited. though we've just moved off 5X at work (slow on the uptake..) I like php. It fast enough, easy to learn (we've had new people pick it up). Its my goto for web development, with some of the frameworks, it seems to have a balance of control and automation I like. Really like symfony for its forms and twig templating engine. Symfony makes a lot of things easy, but is flexible enough when you want to change something. (We like writing native db queries with pdo). It has a package manager (only 1 really, which makes that choice easier) I continue to poke around with react and view js but if I end up using one, I'll just make synfony my json serving backend.

99_00 6y ago

I've never used PHP. Now I'm learning it with Laravel for my personal project. This is after using C++ with ASP, C# with ASP.NET, Java with Spring and Spring boot at work. The promise of rapid development is the main draw.

bnt 6y ago

Really looking forward to the match expression syntax!

yetkin 6y ago

Out of curiosity, why match expressions became popular for non functional languages? Without pattern matching on datatypes via cons expression (x::xs matching) it is just another kind of switch or if/else. Why do people promote this? here a nice comment on this topic: https://ocaml.org/learn/tutorials/data_types_and_matching.html#Pattern-matching-on-datatypes https://ocaml.org/learn/tutorials/data_types_and_matching.ht... "So one Really Cool Feature of functional languages is the ability to break apart data structures and do pattern matching on the data. This is again not really a "functional" feature - you could imagine some variation of C appearing which would let you do this, but it's a Cool Feature nonetheless"

jpz 6y ago
It simplifies the expression of if/then/elsif/elsif/else, even if it's not total. Why not steal it?
- yetkin 6y ago
  but why all of a sudden languages started to add this? Maybe the function itself needs to be simplified, maybe there is a design issue. i am failing to see how "if else" can be simplified via a synth sugar.
  - beberlei 6y ago
    one benefit of match over switch is that it uses === and not == internally. So it does not suffer from type coercion problems.
  - nicoburns 6y ago
    It's a switch statement that's an expression. That's a nice ergonomic improvement when you want to assign the result to a variable. Especially as it allows you to use a non-mutable variable whereas otherwise you'd have to make it mutable.
    - chmod775 6y ago
      I wouldn't compare it to a switch statement, because a switch statement - even though it looks similar - has fundamentally different control flow.

Thaxll 6y ago

Does PHP still has that weird flow where each request is its own process? afair PHP never had an http server baked in, I remember nginx with php etc ...

kijin 6y ago
Yes, each request is handled by its own process. This might sound weird if you're used to other languages, but it's how every language used to work in the good ol' CGI days. PHP doesn't break backward compatibility easily, and I don't think it will ever break this one. Besides, once you get the hang of it, PHP's execution model is highly intuitive and beginner-friendly. You simply don't have to worry about a whole class of concurrency-related problems. Those problems are solved in C, not PHP. Nowadays everyone uses PHP-FPM (again, written in C) which manages a pool of processes. Once a process is done serving a request, it is cleaned up and becomes available for serving another request. You can tweak the number of processes to control how much concurrency you want, or leave it to PHP-FPM to decide on its own. The process pool is much more efficient than the CGI method of setting up and tearing down a process every time, while preserving much of the conceptual simplicity. PHP has had a built-in HTTP server since 5.4, but few people use it in production because PHP-FPM is so stable and performant.
- zexias 6y ago
  The PHP doc advices you that the built-in server from PHP should be used only for development: https://www.php.net/manual/en/features.commandline.webserver.php https://www.php.net/manual/en/features.commandline.webserver.... But PHP-FPM is the most used nowadays, for sure.
  - kijin 6y ago
    I find the built-in web server very useful for running tests. Instead of setting up Apache or nginx on every CI build, you just fire up the built-in web server and point your tests at it.
    - FranOntanaya 6y ago

Kim_Bruning 6y ago

Finally, after all these years, Named Arguments! https://stitcher.io/blog/php-8-named-arguments https://stitcher.io/blog/php-8-named-arguments

EGreg 6y ago
Look, 10 years ago I tried — really tried — to get the PHP team to adopt it. I am glad they finally came around: https://www.mail-archive.com/internals@lists.php.net/msg45871.html https://www.mail-archive.com/internals@lists.php.net/msg4587... Excerpt of the proposal: So why am I saying all of this? Well, PHP up until 4 had a reputation for lots of bad coding style, spaghetti code, etc. With PHP 5 and better OOP, this reputation has lessened, especially with the great libraries out there (Zend Framework, Kohana, symfony, etc.) But there is still a problem. We (or at least I) would want PHP 6's reputation to be even better, and the reputation is largely based on how maintainable and cost-effective the code is, which is written by programmers actually using PHP. Blaming newbie programmers is one thing, and may even have some truth to it (PHP is simple - thus attracts newbies) but it's always good for a language to steer you in the right direction by default, and make it easier to write maintainable code. PHP has a great opportunity to do this, by implementing a very simple change, turning all current PHP 5 code, and all code that will be written in the future, into maintainable code. Moreover, it won't break any existing code, like some other additions to PHP 6 might do. This one simple tweak will make PHP 6 code much more reusable and maintainable, just like namespace support will potentially make future PHP code more interoperable without having to write Artificial_Namespace_Class, like ZF and PEAR do.
- Kim_Bruning 6y ago
  Thank you for your efforts back then. And now you stand vindicated!
  - EGreg 6y ago
    Somehow one guy was really sure it will never happen: https://www.mail-archive.com/internals@lists.php.net/msg48044.html https://www.mail-archive.com/internals@lists.php.net/msg4804...

meowster 6y ago

How should one start learning with PHP these days? My experience: hacked together a few PHP scripts over the years to notify me of a website change (5 minute cron job). Before that, I was a very good beginner with VB6 back in highschool. There are a couple of ambitious database-driven website projects I would like to create, but I don't know where to start. I like the KISS philosophy, and I think PHP and MySQL would fill that. Is there an obvious alternative that I'm missing? I was thinking of hoing through the w3schools PHP turtorial. Is there a better or more up-to-date resource?

TOGoS 6y ago
Keep hacking, learn from your own mistakes, do this for 10 years. By the end of that time you should, for example, understand why we use Postgres instead of MySQL. :)
dagw 6y ago
Modern PHPs shining light is the Laravel framework and the ecosystem built up around it. If you're going to start a database-driven website projects in PHP there really isn't a good reason to not use and learn Laravel (or Lumen if you want something more lightweight). That being said if you're not tied to PHP I'm not sure I'd necessarily recommend it. The obvious alternatives worth looking into are Ruby on Rails or Python with Flask or Django.
- kyriakos 6y ago
  Laravel is good and bad for the ecosystem at the same time. I've interviewed a lot of people lately who know laravel but not php. Similarly to people who claim they know react but fail in the most basic js questions.
  - thinkindie 6y ago
    Additionally Laravel abuses patterns like singletons and in general static methods. This is really a no-no for modern PHP, in my opinion. I think Symfony had a way better impact on the ecosystem.

CraneWorm 6y ago

0 == 'foobar' // false > When comparing to a numeric string, PHP 8 uses a number comparison. Otherwise, it converts the number to a string and uses a string comparison. Why do the conversion at all? Why couldn't this just be an error? I realise there is also `===` the strict comparison that typechecks arguments, but why not make that the default?

baby 6y ago
> Why couldn't this just be an error? you mean crash your program? So your user finds a way to send you an int instead of a string, or vice versa, and now they can crash your webserver.
- mgkimsal 6y ago
  technically they'd just crash that one php process, not the whole web server. :) I think the bigger 'why not' is ... 25 years of backwards compatibility.
  - baby 6y ago
    Oh right ^^ that’s actually one really cool thing about php web apps, no easy denial of service attacks
    - mgkimsal 6y ago
      (again) technically it could trigger a warning (actually, I thought perhaps it did that years ago??) It's still pretty easy to DOS the server that is passing requests to PHP. The 'shared nothing' approach has other benefits though - primarily not having to concern yourself with concurrency issues or shared memory resources. You can dive in to deep PHP and do that, but it's not something beginners need to be thinking about.

lgeorget 6y ago

I wonder what makes the Symfony Demo App not being faster with the JIT compiler (as shown on https://www.php.net/releases/8.0/en.php https://www.php.net/releases/8.0/en.php and https://susi.dev/php8-benchmark-jit-symfony https://susi.dev/php8-benchmark-jit-symfony). Maybe because Symfony already caches things very efficiently/cleverly with OPCache?

dante_dev 6y ago
Mostly because only cpu-intensive code greatly benefits from JIT. Serving a blog (like the demo) is not much cpu-intensive.
- jashmatthews 6y ago
  OO heavy code and functional heavy code can also benefit greatly from JIT compilation. The PHP8 JIT just doesn't have these optimizations yet.
mgkimsal 6y ago
The article you link to already explains it... ? > The point is, if you look in the announcements and comments about what the JIT does you can pretty much guess why this is kind of the expected result. The JIT compiler improves performance for CPU-intensive work (for example calculating Mandelbrots) but not so much for the "default" kind of applications. We usually don't do all that many calculations.
- lgeorget 6y ago
  Yes, I read that, but that's not really what I ask. What makes JIT improve performance only for CPU-intensive work? I don't understand the connection there.

combatentropy 6y ago

I got spoiled by PHP as my first language. It was so easy to get going. I was surprised to learn that other languages didn't work the same way, when integrating into a web server. Also it has always been rock solid. A bug in my code brought down only that request for that user, totally did not affect or even slow down responses to other users. People have attacked its syntax forever. I avoided the worst of it by learning PHP around version 4, when it was moving away from magic quotes and register globals --- and I also had the sense to see that those were unwanted anyway. But I think the main reason that PHP hasn't bothered me is that I try to use it as little as possible. Let me explain. I consider PHP a glue language, between my database and the user's browser. When you use a lot of glue, things get messy. I try to push things out of the middle layer to the edges, if they will fit. So I try to do a lot of data preparation in the database, through fancy queries, so that the data is mostly ready for the HTML template by the time it is received by PHP. It helps that my database is Postgres. For authentication, I try to lean on Apache, so that PHP would just have to consult the CGI variable REMOTE_USER. So PHP acts sort of like an extension language to Apache (even when I'm using PHP-FPM instead of mod_php). It takes the data from the database and wraps it in HTML. It takes the form submission from the user and hands it to the database (and most server-side data validation is in the database). The people attacking its syntax sound like they are writing an awful lot of PHP per app. And maybe for some things you have to, but not for CRUD apps, I think. I try to keep the middle layer as thin as possible, and I would do that whether it was PHP, Python, or Perl.

baby 6y ago
> I was surprised to learn that other languages didn't work the same way, when integrating into a web server Oh boy... I'm still not sure how you deploy a non-PHP webserver to be honest... every language seems to be doing something different, with php you just needed to drag & drop your files in the "public" folder.
- http-teapot 6y ago
  > I'm still not sure how you deploy a non-PHP webserver to be honest... every language seems to be doing something different Coming from PHP and having used a bunch of different languages I can understand what you are saying. Unlike PHP, the other languages run in a process that listens on a port (80, 443 or another). The single process continuously run and handles multiple requests. Back then, I still had to use NGINX or Apache with PHP, and in retrospect I find that more difficult to understand than a script that listens on a port.

Sodaware 6y ago

I don't really like PHP, but it pays my bills. There are some big improvements in this release. Named arguments and actual attributes (instead of special tags in comments) are really nice.

carrja99 6y ago

I still love you PHP

redvenom 6y ago
Me too. For people on shared hosts (hundreds of small websites including small businesses), PHP is pretty much the only server-side language that you have access to (well, maybe aside from Perl).

dang 6y ago

There have been 5 major threads about PHP 8 in the last few months: https://news.ycombinator.com/item?id=24866190 https://news.ycombinator.com/item?id=24866190 https://news.ycombinator.com/item?id=24235440 https://news.ycombinator.com/item?id=24235440 https://news.ycombinator.com/item?id=24320024 https://news.ycombinator.com/item?id=24320024 https://news.ycombinator.com/item?id=24150731 https://news.ycombinator.com/item?id=24150731 https://news.ycombinator.com/item?id=23955197 https://news.ycombinator.com/item?id=23955197 A couple of those are more technically specific (to JITs and named arguments) but the vast majority are just the usual comments about PHP in general. Nothing wrong with that, of course, except that there gets to be too much of it. This is a harder problem than it seems, because popular projects always get generic discussion (btw if you hate something that's still a kind of popularity!) and the alpha and beta releases always get posted and frequently get upvoted for the same (popularity) reason. There's a longer explanation about this here if anyone cares: https://news.ycombinator.com/item?id=23071428 https://news.ycombinator.com/item?id=23071428. We downweight generic subthreads when they get stuck at the top of the page, but only sporadically, since it requires manual monitoring. (Btw, emailing hn@ycombinator.com when you notice a generic top subthread in any discussion is always super appreciated! Downweighting those is probably the biggest single thing we can do to improve thread quality.) As for why generic discussion is worse: it's repetitive and contains less information. More on that: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sort=byDate&type=comment&query=generic%20discussion%20by:dang https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor... https://hn.algolia.com/?dateRange=all&page=0&prefix=false&sort=byDate&type=comment&query=curiosity%20repetition%20by:dang https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...

muglug 6y ago
Thanks for the explanation – I was wondering why it jumped from the top spot. This particular post might want to get a reprieve – not because the discussion is interesting, but because the news itself – PHP 8.0.0 being released – is reasonably important.

idoubtit 6y ago

I get paid for writing PHP code, and the quality of the official PHP documentation worries me. I've searched for several of the changes introduced by the 8.0 version, and I could not find them. For instance, the page titled "Function arguments" does not mention the existence of named arguments. The last time I wanted to submit a ticket about a documentation bug, I saw that the ticket was already created months ago. I'm surprised the PHP process can introduces changes without the related documentation update.

pbowyer 6y ago
The PHP project is severely underresourced. One or 2 core devs are sponsored by their employer to work on the project; everyone else is volunteering, and the pool of people isn't as large as it once was. And that's for developing PHP itself. Documentation needs people too (there are many arguments for and against adding features without documentation) and the team would welcome new members.
- CraigRood 6y ago
  Interesting, I had no idea. What could an individual like myself do to help this situation?
  - pbowyer 6y ago
    Thanks for asking! Join the php.internals mailing list. The join feature is _really_ unreliable, so that's hurdle number 1. Put up with the rudeness and insults on the list. This has got better in the (checks diary) last _7 months_. It's a bit more constructive than it was. Follow the discussions, join the documentation team, make contributions. They won't let you vote until you've done enough to be allowed voting rights. But contributing to the discussions makes a difference. If you write C or C++ there is so much you can do. There's the barrier of learning the PHP macro language (where I got stuck) but once you get past that you're one of a very select band who can contribute to PHP's source.

ericbarrett 6y ago

Facebook’s backups were written in PHP. Well, the second version was, anyway. (The first version didn’t work so well.) By backups, I mean the central MySQL databases with profile and post information; not media or messages. The “Crown Jewels,” so to speak. It was written by an engineer in a week or so and then handed off to me. I was a storage guy with some programming chops. Fewer chops than I thought. Multiprocess, forking, long-lived, server-side, I/O intensive PHP. And it worked brilliantly. Over the following years, it scaled from a backup set of a few hundred TB to many, many petabytes. I extended the code quite a bit, fixed a bunch of bugs (it was version 0 when it launched, no hate to the guy who wrote it), and added statistics for reports and coverage. The main reliability problem ended up being when we switched to HPHP, the predecessor to HipHop. Since the primary and largest customer of this code was the web front-end, changes there would often break our backend code. One I remember was changing fork() to only start a new green thread; saved $millions on the front end, completely broke backups. We ended up getting a special posix_fork() function or something from the HPHP team that restored the old behavior. Eventually I rewrote it in Python 2.7. It took me two complete attempts and then a further six months of tweaking to get it anywhere near as stable as the PHP version, even with brilliant guys like Haiping Zhao constantly re-weaving the carpet under our feet. I never did like it as much as the PHP version.

sigzero 6y ago
Why did you switch to Python? Surely it wasn't as perfomant and you already had a working solution.
- ericbarrett 6y ago
  Mainly to get off HPHP and relieve both that team and ours of the constant coordination and toe-mashing. We thought “modernizing” the code would be a better investment than jerry-rigging the Zend engine back into our infrastructure. I think it was the right call. Also, with Python we could interact with other services using basic Thrift bindings, and even provide our own endpoints. With PHP, all RPCs and queries were prebuilt into our standard libraries with custom glue code that increasingly made non-Zend assumptions. Again, we could have made it work, but we would be swimming against the current. All the rest of the database management code ended up being moved to Python, and benefitting greatly, so it eventually worked out. In summary, organizational concerns.

electrotype 6y ago

I haven't touched PHP for a long time now. How is the Unicode support now? I remember having to use some special utilities to handle characters like "œ" properly.

kilburn 6y ago
You cannot use the "basic" string manipulation functions (strcmp, strlen, etc.) because these are not unicode-aware. However, you have the multibyte string functions family that can operate in a wide range of encodings (including UTF-8 which is the default in any sane installation nowadays). [1] https://www.php.net/manual/en/ref.mbstring.php https://www.php.net/manual/en/ref.mbstring.php
- electrotype 6y ago
  I think I had issues even with mbstring, for some characters like "œ". But maybe I'm wrong.
  - duskwuff 6y ago
    œ works fine with mb_strlen(). What might have been tripping you up is combining character sequences: https://3v4l.org/DM4pC https://3v4l.org/DM4pC Handling those "correctly" with a string length function gets complicated in any language, as there isn't a 1-to-1 mapping between Unicode codepoints and visible glyphs.
    - electrotype 6y ago
      Yes, I think you nailed what my issue was.
    - njuw 6y ago
      In PHP grapheme_strlen achieves what you're describing: https://3v4l.org/HPOb3 https://3v4l.org/HPOb3

wackget 6y ago

Where's the best place to suggest a new feature or improvement for PHP? I've always wanted to see `foreach` get a built-in iterator/counter so you don't have to create and use a counter variable manually. Current way: $i=0; foreach ($array as $key => $value) { echo "Loop $i of " . count($array); $i++; } Possible new way: foreach ($array as $key => $value, $i) { echo "Loop $i of " . count($array); }

deleted 6y ago
[deleted]
throw_m239339 6y ago
https://wiki.php.net/rfc https://wiki.php.net/rfc IMHO that array/map data structure is one of PHP's biggest sin. So many bugs as the result of it and it makes a lot of codebases barely readable.
mdaniel 6y ago
For that code snippet specifically, you're actually better off pre-declaring the vars since the loop repeatedly calls `count($array)` but hopefully(!) its size doesn't change over time. Is there such a function in php like "enumerate" in python, that yields a tuple of (counter, item) for each item in the first argument to enumerate? That is to say: is it possible to do what you're asking with composition rather than a language change?
- johannes1234321 6y ago
  Since count is it's own opcodes in the VM and php hashtables keep the number of elements around and don't have to be counted there shouldn't be much difference between reading a variable and calling count. (Since some time in PHP 7, before that count() went via function call overhead)
kingdomcome50 6y ago
While not quite as ergonomic as your example, it's rather trivial to extend ArrayIterator to accomplish your goal: foreach ($iter = new IndexingIterator($array) as $k => $v) { echo $iter->index(); }

rcarmo 6y ago

I can't believe nobody has pointed out (yet) that PHP is the quintessential lambda :) That said, it's been many (many, many!) years since I moved away from it, but I'm intrigued by the state of the JIT and the current coding style (last time I checked, around 6.x, it was growing to be verbose and full of backslash-adorned-namespacing).

johannes1234321 6y ago
"PHP was serverless before there was serverless" However there is a difference: PHP has no deployment system included. But if you build that (not too hard) the difference isn't big ... (But with Lambda&others you outsource the management)
- young_unixer 6y ago
  > PHP has no deployment system included. SFTP? I mean, it's not included in PHP, but any linux system has it.
  - johannes1234321 6y ago
    SFTP, rsync all work, to some degree NFS also is an option. However that's just the technology. You need to build a solution around it, which monitors load and deploys the code as needed and scales down again and eventually in PHP you'd also expect that PHP Session management is integrated ... all doable and people did. The selling point of lambda is "it works" and "not your concern" (with the corresponding downsides)
Ndymium 6y ago
PHP 6 was never released, you are probably thinking of 5.3+
- rcarmo 6y ago
  "Sometime before 7", yes.
6y ago

mrweasel 6y ago

It's nice to see the language being cleaned up a bit. PHP was the first language I learned, but the more I used and read code written in other language, the more PHP seemed like a mess, and it got worse the more features are being bolted on.

flemhans 6y ago

Already supported by my local provider, <https://gigahost.dk/en/features/php https://gigahost.dk/en/features/php>

spaZeman 6y ago
They are not alone in Denmark: https://www.netsite.dk/blog/2020/11/php-8-webhotel-lanceret-7-2-udgaar/ https://www.netsite.dk/blog/2020/11/php-8-webhotel-lanceret-...

TekMol 6y ago

If I understand it correctly, the next Debian version will come with PHP 7.4: https://packages.debian.org/testing/php/php https://packages.debian.org/testing/php/php Is that correct?

thiht 6y ago

It seems like an amazing release. I've not touched PHP code for at least 5 years but it makes me want to play with it again :)

richardjennings 6y ago

PHP is the poster child for the peoples syntax.

young_unixer 6y ago

If there was a language/framework with the simple PHP workflow of dropping files into a directory, but with a good syntax, we would probably be colonizing other galaxies at this point.