Ending PHP Support, and the Future of Hack (hhvm.com) 429 points by dcgudeman on Sept 13, 2018 | hide | past | favorite | 264 comments

 Another day, another weird dogmatic "static vs dynamic" discussion, with inaccurate comments like "the dynamic hype is dying", or "static is making a comeback" or "static is not really relevant anymore".Are people really that unfamiliar with the history of computer science? There's no hype, there's no comeback; both static and dynamic languages have existed for over six decades. Both styles have been around as long as computer science has been a thing and will continue to exist as long as programming is a thing.
 >both static and dynamic languages have existed for over six decadesFor a long time however, if you wanted a mainstream (well supported, large ecosystem) language with static typing, you pretty much had to deal with languages like Java or C++, with their pretty limited type systems and other unrelated design choices that may not appeal to you. It was either that, or going full dynamic. Or some niche language with poor library support.These days there are plenty of popular languages where you can get all the benefits of static typing with far fewer compromises (Kotlin, Swift, Rust, Scala, TypeScript, etc.) AND a more expressive type system. So the field has definitely changed.
 Kotlin, Swift, Rust, Scala, and TypeScript still have small user bases. Java, C#, and C++ are the most prominent static-typed/compiled languages. I see no evidence the first 5 listed are eating into say Python, PHP, and JavaScript.
 The type system of Kotlin is pretty much the same as that of Java (the only addition is that of declaration-site variance, which essentially allows you to elide some of these annoying wildcards at the use-site).I'm not familiar enough with the others, but I have A LOT of doubts. Only Scala's type system is clearly more powerful/expressive than Java.Also, through templating, C++ type system is made quite expressive.
 Compared to Java, Kotlin also adds nullable types and sealed classes. The built-in syntax for lambda types could also be considered a part of the type system. Or the fact that inline lambdas let you use non-local returns (https://kotlinlang.org/docs/reference/inline-functions.html#...) where the explicit inline can be considered a part of the type.As for the others, check out for example TypeScript's mapped types (https://www.typescriptlang.org/docs/handbook/advanced-types....), or Swift's extensions (https://docs.swift.org/swift-book/LanguageGuide/Extensions.h...).Considering that Java or C++ don't even have sum types, it's not exactly a high bar to cross.
 Fair point for nullables, although that is already possible through annotation processing (see the checkers framework) - but there is a good faith argument that this isn't "core" enough.The syntax for functions and inlining are not part of the type system. Inlining especially, is a useful language feature, and has to be checked at compile-type, but is unrelated with types.Sum types, really you can have that with just inheritance (base class with package private constructor + final sub-classes). What Java lacks is a nice way to pattern-match/switch over types (which Kotlin does nicely with flow typing), but again that isn't really the type system (although it does make the type system nicer to use, certainly).
 >Fair point for nullables, although that is already possible through annotation processing (see the checkers framework) - but there is a good faith argument that this isn't "core" enough.It also wasn't available in a practically usable form until relatively recently (when talking about history), so my very first point about the timeline of languages still stands. Plus it adds even more verbosity to an already very verbose language.>The syntax for functionsI meant function types, e.g. the variable val a = {} has a type () -> Unit, which is a real type in Kotlin.Of course you can achieve a similar thing in Java with SAM interfaces (including all the weirdly named ones in java.util.function), so I'd call that the same level of expressiveness.I don't see why inline wouldn't be a part of the type system, when you can have a function argument (that is itself a function) that either- can be passed into anything that expects a function as an argument - as long as the rest of the type matches of course (a non-inline argument)- can only be invoked or passed into another inline function (an inline argument)Conceptually, this has some parallels to C++'s const-correctness ("any matching pointer can go here" vs. "only a non-const pointer can go here", "this function cannot be called via this pointer" etc.), which is generally considered a part of its type system.It's just a matter of definition really.>Sum types, really you can have that with just inheritance (base class with package private constructor + final sub-classes).The person that uses those classes (I'll call them consumer), e.g. writes a function that takes the base class as an argument, then has to be aware of the internal implementation - the compiler won't help you there. If someone else who maintains that part of code adds a new subclass, you'll have an unaccounted for possibility and there is no way to safeguard against that (unless you redesign the whole part of the codebase using crutches like the visitor pattern).There is no good way to express "this value can be one of these types, but no other" in Java's type system from the consumer's point of view (only from the producer's). I may not be using the correct terms here but hopefully you get what I mean. As far as the Java compiler knows, you are not really expressing a sum type, and that comes with the mentioned negative consequences.
 This is RISC vs. CISC all over again where there was no winner, they just cross-bred and mutated so much you can't tell them apart any longer.Dynamic languages get statically compiled. Static languages have dynamic features. The line is far from clear.If there's any greater cycle it's that in the end all the good ideas get shared and successful strategies get cross-pollinated.
 I don't think there are enough backend web developers in the world to support vibrant communities for both PHP and Hack.Unless Facebook's prepared to invest a lot in community-building, Hack and similar FB projects will go the way of VBScript and Silverlight.
 HHVM will stick around simply because Facebook has the resources to maintain it by themselves for only themselves indefinitely if they need to. Agree about the "vibrant communities" part though.
 As a heavy React Native and Flow user for years, the disadvantage of projects such as those is that they actually are pure and true open source Github projects in the original meaning: The owner produces something for themselves and then shares it.What is the disadvantage then? Well, it is not a product, meaning the external users are not the main target of the project.The project owners have no incentive to implement anything they don't need themselves, or to fix any bugs that don't impact their own developers. It works fine if your own needs happen to be as close as possible to the ones of the project owner, if you patch stuff you need yourself, and if you don't expect anything from the owner in general.Especially when I compare Flow and TypeScript (I use the first quite heavily, the second occasionally, filed lots of bug reports for both) the difference between them is quite substantial. For TS Anders Hejlsberg himself answers bug reports, and they listen to what the community wants. In the Flow issues you'll find Facebook employees - but not the actual owners (or if there is one they remain hidden). If the Flow team implements something Github users ask for it's almost always only because the need for it happened to also developed inside Facebook.I have learned the hard way that "open source" is not sufficient, it should actually also be a product (meaning the owner cares a lot about external opinions). That's most important for things like core libraries and tools like those add-on Javascript type systems, not so important for "leaf node" dependencies in your project, like a library that does something specialized.
 > I have learned the hard way that "open source" is not sufficient, it should actually also be a product (meaning the owner cares a lot about external opinions).There are open source projects that succeed because, aside from being good enough, they also have big corps behind them: TypeScript, Dart, Go, Flow, Kotlin, etc.But there are also open source (often free software) projects that succeed because they're great and are community-focused and community-supported: Python, Haxe, Julia, etc.
 > they also have big corps behind them: TypeScript, Dart, Go, Flow, Kotlin, etc.I talked about just that, no? About two of that list specifically, even.
 Ah. Ok. Thank you. I see my reply was sloppy --- sorry. It seemed to me that you were suggesting that being open source plus being productized was required for project success, and my thought was:1. wait, there are more axes than just license and productization, and2. there are other values on those axes that can lead to success (not just open source + productized)Here are some separate axes I see:* open source (Apache2, BSD, MIT) vs free software (copyleft (GPL, LGPL))* corp-backed vs not-corp-backed* community-driven vs closed-style-development* core devs have a very solid vision of project direction, vs being more open to change and/or direction taken from contributors* amount of productization: are the main target users the core devs themselves or external users* overall quality of the languageSome armchair comments:+ you risk lock-in by going with corp-backed languages+ you may see more community involvement with free software projects, whereas more corp involvement with open source+ high productization often means a very low contributor to user ratio+ although quality doesn't necessarily win, it sure is nice.
 > (meaning the owner cares a lot about external opinions).I actually like this about FBOS. I’ve found that I appreciate their vision and direction on the projects I use (React particularly, I love their stewardship there, but also Relay, where yeah issues and suggestions are ignored but that’s fine because I like what the team does and the slow pace). I appreciate that they’re not pulled this way and that way by the community and its whims. That’s why I don’t dig Apollo for example, which seems to be one of these community projects that almost exists more for the community than for the product and tries to be everything to everyone and in the end is not something I appreciate technically or even as a community. Of course Relay docs suck but hey it’s open source! I’d rather use a really strong product like Relay than a weaker product like Apollo, even if it means having to learn some internals.
 But they recently got better as I found out a few days ago! Yes those docs often miss some critical ideas/apis/etc. and everyone on the issues seems to already know about somehow and how they're supposed to be used.
 Slightly off topic, but do you have any Relay resources you recommend, both for client and server best practices?
 I don't know any particular resources.I think the core document is the Runtime Architecture[0]. After that, it really helps to know ES7 Observables, which I learned by studying the little implementation that's included in Relay[1], but apparently is also at the core of Angular. Then you can either use the runtime architecture directly, or the pre-built React components that are included in Relay. If you use the pre-built components, you need to understand the division of labor between the QueryRenderer[2], which fetches data from your server and puts it in the store, and FragmentContainer[3] which lets you render data from the store with React.
 IMO the only company that has been able to successfully "productize" a language/programming environment is Microsoft, and that is because companies were paying a LOT of money for these tools a decade or two ago.
 You're overlooking Borland, Metrowerks, Micro Focus, etc.If you're thinking of companies that are still making shit-tons of money productizing programming languages/environments today, Microsoft is the major player, but it's a battle even they are losing. They just open-sourced .NET, their programming bread and butter.
 > will go the way of VBScript and Silverlight.So it will either die off quickly or be extremely popular and stick around for 20+ years?VBScript is just as old as PHP and was the primary scripting language on Microsoft products for a solid decade. It was in everything from Office to IIS and still ships with every copy of Windows.Silverlight is just a framework and was only in active development for 5 or 6 years before being killed off.
 Isn't VB for Applications (Office) a different thing than VBScript?
 VBScript is a subset of VBA IIRC
 Sorta but not really.You can write a single piece of code that's valid C, C++, C#, and Java but that doesn't make them the same language or subsets of one another.VBScript started out using the same conventions as VB and a subset of the syntax but it was never really related to it beyond that. There are different flavors of VBScript as well. CScript is a console variant, WScript for window environments, and ASP for IIS Web Development. They're mostly compatible but not entirely. When classes were introduced, they weren't immediately available across all the variations and still aren't IIRC.It's all very confusing though ultimately I don't think that it contributed to the negative connotations about it. Being associated with VB was ultimately what tainted it.
 Those are two different things. VBScript was the Macro language used in Office Products. There is also an SDK for VB/VB.NET for developing plug-ins and other tools that's completely different.
 Visual Basic for Applications (VBA) was what is used in Office Products and that is modeled after Visual Basic 6, not VBScript. VBScript was used mostly for Classic ASP development (both front end and backend).
 You could use vbscript for, well, scripting. Essentially taking the same position / purpose as batch files on windows. Pretty sure that still works. I wouldn't do it anymore, personally, but I'm almost positive it's still functional.
 You could, but I believe most of VBScript use came from web dev. I have the fortune of working on a classic asp site at work now.
 The thing is that the enterprises seem to be okay with them being the only user of their open source projects. Don't ask me why they then decide to do open source projects in the first place, but that's what I'm seeing.
 I had a client with a proprietary programming language for data warehouse management, they had a very hard time hiring people who wanted to work on that stack from a career progression perspective.I imagine, at that scale, that opensourcing is a big win because you can have a proprietary stack, but still hire people that already know it, or won't be reluctant to invest a few years of their life into working on it. You also don't have to pay as much for educating new hires as you would for a totally closed proprietary stack, and new people faster become productive. Hiring contractors that work with that stack on a short notice also becomes easier. For a large co, these kinds of benefits might be more than enough to justify cleaning up the code enough to opensource it.
 On the flipside as I've seen from Google if you're already an attractive enough target for potential employees to pay the price of ramp-up the privacy of your stack serves to lock those employees that prove worthwhile into experience that's non-transferrable were they to explore other options. Granted G is special as anyone hiring knows but I don't imagine they're the only ones aware of and playing that game.
 Open sourcing their projects is good from a PR standpoint in this climate, and if anything it's a good way to share knowledge that would otherwise be kept within the company walls with those who need it (e.g. implementors of PHP/other VMs).Creating and maintaining a community around an open source project is a lot of work, and it's understandable if Facebook doesn't want to pour many resources into this particular project, even if they keep it open source.
 > Don't ask me why they then decide to do open source projects in the first place, but that's what I'm seeing.Because they sometimes get lucky, and people use it. Apple would probably have been just fine with everyone shrugging their shoulders at clang and continuing to use gcc, but clang adoption by others has been of benefit to them anyway, say.And worst case, there's no major downside to open sourcing language tools.
 > And worst case, there's no major downside to open sourcing language tools.Worst case is you didn't protect your IP and people get fired because the competition makes the money.
 This is unlikely at large corporations. Projects from bigcorp that get opensourced are the ones that don't contain private information and would be difficult to monetize (or are strategically open-sourced).
 An interesting comment I saw today on twitter[0] points out that open source development is more of a development style than a business model. Still, styles can impact the bottom line. Enterprises can gain some efficiency in process (and hiring, as others point out -- working in NIH land without amazing tooling and products to keep you there sucks if you have an inkling of what's widely done and used outside in the open source worlds) by using the model even if they are the only consumers of the final project. You also open yourself up to including other useful open source software, depending on licenses.
 I don't know about Hack specifically, but sometimes it's a dependency of some other open source project. There's little point in open sourcing code written in Hack if the underlying tools aren't available for everyone to use.
 Don't underestimate the value a company puts on pleasing it workers. From what I've seen, it's often them who push for open source (for various reasons).
 A lot of other big players used Hack (Etsy, Wikipedia and others). Don't know if they switched back to PHP7 though.
 Afaik Etsy and Wikipedia only used HHVM for the performance win and not the Hack language on top. Since Wikipedias tech stack "MediaWIki" is heavily used by PHP companies it can't be using Hack features.Slack came out with a blog post a few month ago, writing that they use the Hack features on top of HHVM. That is the only one besides Facebook that I know of (there are probably more)Edit: Source for Etsy using PHP 7 now https://speakerdeck.com/wcgallego/hitting-the-turbo-button-u...
 Hack is going to be deprecated when it comes to MediaWiki, they're recommending PHP7."MediaWiki 1.31 requires PHP 7.0.0 or later. Although HHVM 3.18.5 or later is supported, it is generally advised to use PHP 7.0.0 or later for long term support. "
 hack is going to become incredibly widespread before slowly dying off due to market forces?
 You could argue that it already did become incredibly widespread (as php) then died off slowly due to market forces.
 I wouldn’t say Hack was ever popular as a language. The HHVM certainly had popularity as a runtime for PHP until the speed increase of PHP7.
 I seriously can't remember any (incredibly) widespread use of Silverlight – could you elaborate? The only instance I noticed it was with a video streaming platform.
 Biggest use of it that I'm aware of was Netflix. This was really just done for DRM reasons.
 I don't think Silverlight had a mass amount of public use (Flash and Applets were still available at the time - so there was no pressing need).But MS really did earn a lot of bad will from their dev community who had been pushed to learn yet another framework which ended up dead.I rarely even use my PC anymore. I basically then it on once a month to download the gigs of updates. It's interesting that Silverlight still listed at the top of optional updates.There must be a few businesses and schools who bought into the hype and built their internal app on SL.
 My previous employer sells a legal review & production solution with a Silverlight UI. I left half a year ago, but if all is well they have just finished reimplementing it in Angular.
 The management console of the AV software we use at work is built in Silverlight, but that is about the only instance of Silverlight I have ever seen.
 Silverlight is used simply because MSFT grant the use of their DRM license, unlike Adobe at the time.
 With PHP7, HHVM became largely irrelevant. It had played a great role and contributed to the PHP's maturing immensely though!
 This is really interesting, I've seen this pattern somewhere. IMHO, CoffeeScript had a really similar effect on the development of JavaScript / EcmaScript, but then, it quickly started going extinct. Same with IO.js vs. Node.JS, which was eventually re-integrated into the main line.It's interesting how apparently sometimes you just need to step aside to break old conventions and demonstrate new capabilities, but eventually, you'll need the support of the community to pull it through: Plus, it's always a gamble. Python barely made it over to v3 after 10 years. I'm not sure if Perl will ever cross the gap or if Perl 6 fragmented the community for good.Just some random thoughts though on the dynamics of open source, I'm glad for the experience of PHP at the beginning of my career, but I wouldn't touch it or any derivatives any time again having free choice. Too much Heinz™ design: Grown, not made.
 These fork-like efforts are able to take the risk of the experimentation without putting the mainline project at risk, and their successes allow the supporters within the original project to point to it as a viable path and gain the needed mindshare to pursue something achieving the same goals.It's a similar model to larger corporations allowing innovation to occur in startups and then buying them out once the model or technology is proven to a degree.
 I think CoffeeScript made transpilers mainstream (though it wasn't the first) and i appreciate that (having a sane language like clojure in your browser is amazing), but damn that syntax was confusing more often than not. Sometimes less is not more.
 My thoughts on this from practical experience at Perl conferences and Open Source conferences in general: many (former) Perl 5 programmers are looking forward to finding a use-case to use Perl 6 for a project in their environment. And some have done already, and put the result in production, which may be specifically easy with micro-services using Cro (https://cro.services).Of course, there are (former) Perl 5 programmers who still think Perl 6 is the sole reason for Perl's demise. These are fortunately very few, but alas also very vocal.
 It really boils down to the implementation. Also, you need community support. What really helped HHVM mature is that by using PHP for something large scale, they were able to see its shortcomings. Most other forks are not driven by that. As such, their upsides are questionable, or they just offer some performance boosts, that are achievable even without the trouble of forking.
 Speaking of fragmentation, we still have 3/4 of users on PHP 5.x, and support for v5.6 (the last 5.x release) is coming to an end soon!
 And honestly the jump from php 5.6 -> 7 is pretty painless. Its probably the lack of tests for a lot of old 5.6 software that gives people fear of upgrading. php development has gotten a lot better.I think support for 7.0 is ending soon too.
 Yes. It reaches the end of its support at the end of this year, and PHP 7.1 next year.
 Rasmus Lerdorf actually acknowledged HHVM's role in numerous occasions, especially with reference to the development of PHP7 (Edit: sorry I tried to find a link but no luck so far).
 Well, Hack has a lot of advanced features that is missing from PHP7. Proper data structures (vector, map, set, etc...) including immutable ones, generics and variance, async/awaitable, etc...I would love love love for all these to be in PHP.
 We'll probably get them eventually, it looks like the typed properties RFC is going to pass this time around.Which is great for me :).
 Yeah, at a previous job we used Hack around the time PHP7 was released and switched over to PHP7 pretty quickly.Performance and type checking were the only benefits over PHP5 and with those (mostly) gone, you were just left with all the downsides like all the good tooling for PHP being incompatible with Hack and, and general compiler/interpreter errors that were never getting fixes.
 I mean, I think people are somewhat missing the fact that it's not like these worlds are separate or competing. Some people have worked on both PHP and HHVM, and it seems like they've always acknowledged that they have different goals. From the comments in the post of the Hack announcement (before PHP7):Q: Do you imagine a future where Hack will merge back into PHP (like PHP 7), in the same style that Beryl & Compiz then rejoined? Or does the team intend for the two to always be adjacent-yet-separate?A: HHVM developer & PHP runtime developer here. I've got hands in both runtimes and all even I can say is: Maybe. I think the most likely outcome is that PHP will adopt some of HHVM's additional features, but remain a separate project. IMO that's a great outcome, since we'll both likely drive the other to be better.EDIT: Source, https://news.ycombinator.com/item?id=7436557
 HHVM can be more experimental than PHP so there's still potential that new features in HHVM get considered and merged into PHP, kind of like Fedora/Redhat or Neovim/Vim
 Very true, especially as type hinting for properties looks to be coming in PHP 7.4!
 > On the other hand, you risk ending up in local optima.This would only be a risk if the difference between the local optimum and the global optimum is large, but there is no evidence to suggest that is the case (and a lack of evidence for a big effect is usually evidence against it). To be more precise, no one has been able to find a drastic productivity boost among apparently reasonable alternatives, so either there's a plateau or no one has found the global optimum. Either way, as things stand, there is no such risk.A risk that does exist is failing to create a viable development environment or simply not having the resources to even attempt it. As others noted, this is a big risk (or an almost guaranteed failure) for small organizations, but hardly one for a very big one.
 On the contrary, certain kinds of technical debt are only paid off in full, not in increments. Supporting entire languages, for instance: experts, toolchains, dev environments, packaging systems, core libraries, telemetry libraries, etc.The large difference between a local maximum and a goal is clear. The question is whether the cost to get there is acceptable.
 > This would only be a risk if the difference between the local optimum and the global optimum is large, but there is no evidence to suggest that is the caseAgreed, it's been elusive for the software engineering community to objectively assess and quantify productivity effects of software tool chains, in particular in comparable stacks.Comparison of programming languages or stacks is not what I was (trying to) talk about though. I have no idea whether hack compares well to $RANDOM other toolchain. I am curious as to whether a continued incremental investment in PHP made sense, compared to choosing a whole stack and propping that up to meet your requirements. Even assuming your final PHP-based stack is identical to whatever else you'd have chosen, the paths do have differences in effort.The local optimum in that context is that it's locally optimal to just add that one feature to your existing solution vs investing in a different solution that in the long term will cost you less to build and maintain.I don't have an answer to that question though, as I'm not familiar with the effort required or comparisons made. I think it's a genuinely hard call to make. Even post hoc and with all the knowledge it'd be hard to judge, as you need to discount effort by the relative risk factors.  The overall business impact on using php vs any other language is clearly huge. No other language is split into a separate market for developers and VC capital. JS hate couldn't stop its use completely for any company that needs a website, Java will likely be running something whether you develop your API in it or not, only php hate combined with php's only role in the stack being high but substitutable can eliminate it from businesses and developer mindset with prejudice at some companies and make it the dominant language at others.  Very few entities have the resources that do what Facebook (or Google or Microsoft) have done, in creating an entire new language (or languages) that suit their particular needs, and in a relatively short time (hack was being used within facebook very quickly). Twitter certainly doesn't have those kinds of resources, but they do/did have the resources to migrate to a language with an existing developer community and existing tooling.  Duly noted the desire of Hack to have more "typing". It seems that as soon as projects growth beyond a certain size, everybody starts wanting to add that.I wonder what would be the optimal lifecycle for long projects. Obviously, "start with dynamic language X until you reach 10^n lines of code, then fork X and add types to it" doesn't work for smaller companies :-(  I feel like dynamically types programming languages had a huge hype period, and then all the startups we saw write in their dynamic languages later ended up adding types, because maintainability is simply SO much easier when you have a good type system and the compiler can help you. I say that coming from a road starting at PHP, then moving to Python, JavaScript, Java, Haskell.Funnily enough, strongly statically typed languages are not bad at all for the early prototyping stage. In fact, I would argue that they are much better, but you have to switch your approach from slapping some functions out, to instead slapping out some ADTs, that form the basis of your app.A lot of good advice for Haskell is given in this thread https://www.reddit.com/r/haskell/comments/7sr8k7/fast_protot....One important thing to note though, is that I honestly don’t think this will work well, unless the language has at least type inference and support for ADTs, newtypes (or, tagged types) and pattern matching at the minimum. Less than that, and you end up fighting the type system, instead of letting it be your help and guide.  > and then all the startups we saw write in their dynamic languages later ended up adding types, because maintainabilityMaybe because they weren't startups anymore?Honestly I don't understand the deal with type errors in simple web apps : every input is a string which is parsed into the correct type. After this, with good naming and conventions operations should be obvious, e.g. why would you try to do a mathematical operation between a customer's name and it's account balance?To me it looks like these days the hype is copying whatever big names are doing regarding maintainability without having nearly the same constraints (static typing, huge frameworks, ...).  > why would you try to do a mathematical operation between a customer's name and it's account balancethat's a straw man to js typing, and never a problem in practice. What's more often happening, is that you change the structure of some object in your store somewhere, that's passed around a lot. And you forget to update the usage one of those places and stuff break runtime.  "What's more often happening, is that you change the structure of some object in your store somewhere, that's passed around a lot. And you forget to update the usage one of those places and stuff break runtime."This is the big reason I tend to even prototype a system with a statically typed language, if it's going to take more than about a week. Dynamically typed languages have the characteristic where they seize up after a week or so of development, it becomes impossible to fit the full graph of who is calling who in your head anymore, and from that point on, you tend very strongly to do defensive code changes rather than good ones, e.g. "this function used to take a string, but now it takes a dict with three parameters, but I'll still keep the code for if it gets passed a string because maybe something is still doing that". Then when the time finally comes to do a big refactor, you're often darned near rewriting from scratch.I've lost track of the number of times I've refactored something successfully in a static code base of several months age by just continually running the compiler until it's done complaining, and how often I start a refactoring that seems to be going really well until the compiler points me at some bit of code and I realize that what I'm doing right now is actually fundamentally flawed in some way I'd forgotten about. In a dynamic language you tend to just power through those and put in sub-optimal solutions.Plus, at least in my experience, if you do this consistently, it often is practical, feasible, and correct to just "ship the prototype", because whereas with dynamic code I would have a messy prototype with half the methods taking an unclear combination of values, with the static type-based process I've written something quite production-ready, with cleanly-defined interfaces.  My experience in going from being very insistent on static typing and moving to Ruby (after lots of hesitation) is that you run into lots of type errors, chances are you also have uncaught logic errors in code your test suite isn't exercising. E.g. the above example would presumable be caught if you actually tested all the code acting on the account balance, even without a single test to explicitly test the types.That goes irrespective of if those type errors are caught at compile time or runtime - if those errors aren't caught by your test suite, odds are you have a problem that static typing will not fix but writing more tests will. In either case my response to type errors these days is to consider it a bug in the test coverage.(I'm sure some will argue that typing in languages like Haskell avoids this more than others, and that might be true, but languages like Haskell are too hard to work with for most people to ever get mainstream traction; I'd love to see more experimentation in making more advanced type systems more accessible, though)  It is true that all type errors can also be caught by additional tests. But is this the most efficient strategy? I would think that letting the compiler find certain classes of errors should be cheaper than writing and maintaining tests for these error classes.  Indeed, as these are error classes unit tests aren't even very good at.It can't be repeated enough: Types are universal quantifiers, tests are existential quantifiers, you'll realistically never get even close to the guarantees of a type system with tests alone.If your unit tests are on a level with your static type system, you have basically rebuilt the static type system in your unit tests.(And pitting unit tests against a static type system is a false dichotomy, it's good to have both.)  My point was that you rarely need to write test to catch type errors. You write tests to determine if a unit of code works as expected. In doing so you tend to exercise the conditions that cause type errors as a side effect.Let's say foo() internally calls bar(). If I pass a given valid input to foo() it passes the wrong type to bar(). If I pass another valid input to foo() it passes the wrong value but of the right type to bar().If you ensure full test coverage of foo() you will catch both. Type checking in your compiler will only cover the first case, so you still need the same test coverage anyway to have confidence in the code.  Full test coverage of foo() is hard to prove. Have you exercised every argument possibility, every exception that could be thrown and every global/class/instance var reference? Working with Ruby most of my career, my experience is probably not.A good type system is much more thourough and let's your tests focus on behavior.  That's what you have coverage checkers for.And you don't need full coverage. Aiming for full coverage is a folly - you aim to cover the API surfaces you're actually using. If you still get lots of runtime errors something is very wrong with how you test your code.> A good type system is much more thourough and let's your tests focus on behavior.The problem is no languages I'd be willing to use have a good type system that actually covers much.  > The problem is no languages I'd be willing to use have a good type system that actually covers much.This is basically down to opinion, and I can't argue with it. I've collaborated on Ruby projects for about 10 years, I love the language, but my experience says a large code base, with test coverage, regularly breaks on things that most type systems wouldn't allow.Dependencies often cause subtle breaks like this, even in big, common ones.On top of that, this requires paranoia to avoid breaking callers. With a good type system, you can largely discard that paranoia.  > e.g. why would you try to do a mathematical operation between a customer's name and it's account balance?Types like int, float and string are rather impoverished. Much more common mistakes are:- One the numerical side, trying to perform arithmetic with different units of measure ( https://en.wikipedia.org/wiki/Mars_Climate_Orbiter ) or with different representation sizes ( https://en.wikipedia.org/wiki/Cluster_(spacecraft)#Launch_fa... ). These sorts of errors are trivial for machines to identify, if we let them (e.g. https://docs.microsoft.com/en-us/dotnet/fsharp/language-refe... )- On the textual side, type errors are widespread and cause a large proportion of security vulnerabilities ( https://www.owasp.org/index.php/Top_10_2007-Injection_Flaws ). Again, they're trivial for machines to identify, if we let them (e.g. http://blog.moertel.com/posts/2006-10-18-a-type-based-soluti... )  > After this, with good naming and conventions operations should be obviousWhy on earth rely on people for this when you have a machine available for you, that can automate all this? A good type system is invaluable for both on-boarding of new people, refactoring code, and maintaining a codebase.Why would you not want to make sure you could never call the wrong REST endpoint[0] for example? Etc, etc...  "One important thing to note though, is that I honestly don’t think this will work well, unless the language has at least type inference and support for ADTs"I think this is spot on. That was my journey as well. I started using Python in around 2000 because I didn't had to write type of every local variable and declare every little structure. (For example, you want to return multiple values in a tuple? Better declare it as structure or object.) For a long time, Python was my favorite language.Eventually, I came to Haskell and it became a new favorite. I think the "hype" of the dynamic languages subsided largely because of the two important developments you mentioned (which are now in some form a standard in any new language that is being developed).  I still use -defer-typed-holes or even -fdefer-type-errors when writing haskell fairly frequently, though.  i personally started to find dynamically/optionally typed languages troublesome to read -- i have to do type deduction in my head, which just feel burdensome.as simple and easy as python feels without static typing, a handful of files of python is my tolerance level before i start to hate it  Likewise. I come from a mostly C background (embedded), but now Python is especially popular in my close circles. I liked it at first, but over the past five years I grew to despise it for anything more than a single file, 300 loc program.In stark contrast, I’ve been playing around with Unity/C#/Visual Studio and my productivity with this tool stack is through the roof. There, it is rare that I create code which doesn’t fill its intended purpose the first time around. It’s all so easy, and InteliSense makes the quite verbose typing not felt. The tooling and safety is magnificent.  Types are documentation that the compiler (or interpreter) forces you to write and keep consistent, and that your editor can easily understand (:  Yep. A lack of typing puts an upper bound on the complexity of the code that effectively limits the line-count and relegates the language to 'glue' status. The reason is simple: typing functions as guard rails and guard rails are what keep you safe on the road when you are driving for 1000's of km. They have no function if you just putter about town at low speed.High line count projects almost always gravitate towards languages with such safeguards built in because otherwise the accumulation of subtle errors leads to too many runtime issues, and typing takes care of whole classes of bugs.IMO any mechanism that shifts that time of bug catching to development rather than operations should be preferred, ditto for any mechanism that forces a program to end when an undefined situation is detected, the closer to the root cause the better.  >A lack of typing puts an upper bound on the complexity of the code that effectively limits the line-count and relegates the language to 'glue' status.I disagree. I work(ed) at two of the more famous Python shops: Yelp and Reddit. These companies have many millions lines of Python code combined. Also FB was mostly a PHP shop until they started Hack in 2014, 2 years after they IPO'ed.Testing and monitoring can be used to combat type errors. Runtime type errors still happen occasionally, but honestly these are some of the easiest bugs to squash.I think you might be conflating static typing with strong typing when you infer that Python has "lack of typing." Python has a dynamic, but strong type system.I've coded professionally in many other languages (C, Java, Rust). I think C and Java have the worst ROI when it comes to type systems. In my opinion if you're going to use a type system on a new project today, then use something that provides stronger guarantees like Rust or TypeScript (and lowers the burden by inferring or deducting many types).Python isn't perfect, but it's still the first tool I reach for anything web, ops or data science related.  And bricks will fly if you add enough engine to them. It's all a matter of resources and what is the optimal path. That FB was a success even though it was built in PHP is not a testimony for PHP, it is a testimony for the engineers at Facebook who were able to pull that off despite PHPs obvious shortcomings. The fact that they built their own in-house compiler for the language speaks volumes in this respect.Yelp and Reddit also have above average resources to throw at the problems they try to solve.Python is the first tool of choice for quick solutions to immediate problems for me as well, but that does not make me blind to its obvious shortcomings.  You’re completely discounting that PHP has qualities that may have helped early Facebook grow. In fact one the engineers did a talk about exactly that.  The language that you start in may not be the most appropriate tool in the longer term. Facebook grew so fast they did not have enough air to switch, hence their incredible investment in making PHP better.Look, I've built I don't know how many websites in PHP, and my company still earns a lot of money with a tool I threw together in a day or two in it so I have nothing but admiration for what it can do. But you'll be the last person to hear me argue that there aren't better tools for the majority of the jobs at hand. We are all looking forward to the day that it can be retired, but in the meantime we will definitely keep using it and we will continue to pray to the PHP gods. It is a very productive little language that has a ton of warts and some serious issues, but it does have a niche and it is useful.  That's a fair point, I'm sure there are ways to build things that have the benefits of PHP today that may not have been as abundant back when Facebook was starting out.  I work at Pivotal, arguably one of the most test-obsessed companies in the world.Tests and types are not direct substitutes. My view these days is that types become more valuable as a codebase grows. I have worked on Ruby on Rails codebases where, quite frankly, I found myself wishing it out loud was Java on Spring Boot. (Many of my peers in Labs are flatly enthusiastic about Kotlin on Spring Boot, FWIW)In the same genus as the "just use tests" argument is "business logic only belongs in the app, not the database". Yeah, well, it turns out that no amount of testing is a substitute for constraints and transactions.  Yes, in my experience on coding PHP & Java is that everything is so cumbersome in Java with little gain coding wise (there are of course other benefits with Java)Hard to move code around, comment out code, prototyping, create samples of data structures etc.What is important on a large project is enforcing contracts, if it is on function calls, HTTP calls, database calls etc.With function calls you have type hinting in many dynamic languages, with that you can catch most type errors & avoid writing some tests.How the types work within the function body is quite irrelevant.And statically typed languages have recognized this by adding var, auto & what not.  > Hard to move code around, comment out code, prototyping, create samples of data structures etc.With some IDE skill, this is easy in Java, but then developers get used to this way of developing caused in no small part because of the language and think that features of the language (like static types) enable and entail the IDE features (auto-refactoring, intellisense, code generation), rather than the IDE features being developed partly in response to the limitations of the language.Dynamic languages often have a tooling problem, at least from the perspective of Java developers, but often you don't even need those heavy IDE features to get equivalent or better work done and so tooling suffers or isn't evangelized much. A coworker complained he can't just find callers of a JS function (unless within the same JS file) with eclipse; I pointed out that vim trivially does this after generating ctags and demoed it... Still, in lots of code bases that aren't in Java, I find myself needing to know "who calls this" not as often. Besides, old school find | xargs grep or ag work to find that info usually too. Even better, if it's a Web Service name, a string-based tool will find the usages on both the client in JS and on the server in not-JS.Meanwhile there have been dynamic languages like Common Lisp that have IDE features like debugging built-in to the standard language itself, there are strong types that implementations can and do use to produce optimized machine code (not just correctness -- and you can verify an optimization with 'DISASSEMBLE, another standard function), modern implementations like SBCL have at-compile-time warnings for type issues or typos or whatever, and ancient tooling (slime) has things to tell you who-called-what, etc.  I wouldn't think that you run into type errors often with a mature code base. But that's because you have to deal with this problem sooner or later. In a statically typed language, it is quite obvious what fits where. From my (albeit limited) experience with js, python and ruby, you have to invest a lot of effort into documenting and testing things like function parameters, which would be completely unnecessary in a language with static typing, even if that language has a boring, Java like OO type system.  When you test expected function behaviours, sufficient type testing tends to fall out of that pretty much for free - if your test suite is testing function parameters for the sake of testing function parameters and not for the sake of verifying it gets the right output, then the test suite is deficient.  > Testing and monitoring can be used to combat type errors.I agree, though IMO this is another upper-bound. You can only test and monitor so much before resources and performance start becoming a bigger issue.I think companies can definitely go without types if they have solid documentation and a good review system to both prevent bugs and help with onboarding.  What is the upside of having no types, though? We're out of C land and modern advanced typed languages offer generics, type inference, interfaces and inheritance. You can pretty much do whatever you need without ugly casting or compromising your data structures.Dynamic typing solves things you have in C, not so much in C#.  In my experience: Far less up-front specification, far fewer names/concepts, fewer lines of code, far fewer of those "oh, this should work, but how do I wrestle the type system into understanding it?".Now, there's a continuum here.When designing the main data store for a project, you want to iterate on that and get it just right.Or if you're working on a library to be used by lots of people, it's definitely nice to be able to specify things that lets the compiler help people get their code right.On the other hand, in almost all the applications I've worked on, there's also a much larger fraction of absolutely necessary and often complex code where each little module is working on some details. There the data structure doesn't really matter so what JSON provides (untyped arrays + simple objects/dictionaries) results in much less cognitive overhead than a fully specified and typed thing. A few black-box tests both documents and checks functionality, and also ensures that the thing keeps working after a refactor.Of course, YMMV.  Surely the most common argument was that dynamically typed languages need less lines of code to do the same thing, combine that with the time it takes to write code is roughly proportional to the size in lines, and the size of the unit tests similarly proportional, and it becomes a pretty hard argument to refute.For a long while you were comparing languages line Python to something like Java, and it was pretty much a no brainer - the argument was right. But nowadays if you compare something like Javascript to Typescript, it's not near so clear. Type inference is really biting into the size advantage line dynamic typing had over static typing.The other thing is the claim 1 line of statically typed code of takes as long to write as 1 line of dynamically typed code. It's true as stated, but change it to "correct line of code" and it's not true. You don't have to write tests for type declarations, and statically typed code has less bugs after it's accepted by the compiler / interpreter, so while the writing takes the same amount of time the testing and fixing takes less for statically typed languages.The final advantage of dynamically typed languages is statically typed languages just need more head space - just ask someone who has used Rust. Granted Rust with it's explosion of types caused by lifetimes is a bit of an extreme case, but it's still true for most languages. But it's not so true for the Typescript vs Javascript comparison, and I suspect really careful standard library design might make this mostly go away too.  > A lack of typing puts an upper bound on the complexity of the code that effectively limits the line-count and relegates the language to 'glue' status.That's an opinion, not a fact.> IMO any mechanism that shifts that time of bug catching to development rather than operations should be preferredThat's probably true of an existing product, but that's not the only concern in product development.  The optimal lifecycle is to start with the same language you'll finish with. You can rewrite and refactor as much as you want, but you never need to rewrite the entire thing from scratch in one shot and get it right.The funny thing is, with microservices it shouldn't really matter what language each service is written in as long as the services can talk to each other, but most companies end up using the same language for everything because it's easier to hire people who know the same language and can work on multiple projects.  We started with two languages on our microservice backend. It is definitely an up-front investment. But it pays off in several ways:- our service infrastructure is really language-agnostic.- our design discussions are on an abstraction level above the language level. (of course there are language-specific implementation strategy discussions, too.)- while it is a bit harder to find suitable developers, I think we attract a very valuable subset: people who are not tied to their favourite language, and don't shy away from learning new things.  Also because if you use the same language it's easier to re-use code and interface definitions.  Yeah, going down this path usually leads to a tightly coupled, monolithic-in-practice system of "microservices" which are effectively developed and operated like the previous, monolithic system was, but with added overhead (both runtime and dev-time) on top for a layer that fakes loose coupling, with the sole actual reason for existence of this layer being that it allows people to call this abomination of an architecture "microservice-based".  The software architecture equivalent of Security Theater... Decoupling Theater  But PHP today is a typed language. One of the new features of PHP 7.1 are Nullable Return Types http://php.net/manual/en/migration71.new-features.php  How does it compare to TypeScript?I met a few PHP devs who were hating on JS, because PHP was mature now and had static typing, etc.  A similar strategy on a smaller scale could be gradual typing, for example Typescript. For me personally, clojure + spec seems very inviting.  Yeah, I'm really excited to see people exploring gradual typing. Like dsign, I've noticed that I really like flexible languages like Ruby and Python for early work, but once something is big enough, I start to miss the things heavier languages give. I'm sure it will take us a decade to work it out, but it'll be fun getting there.  Indeed, this seems to be the best way for a small code base that gradually grows in scope and criticality. It allows rapid development early on and better stability later in the project.I'm really glad that Python is making good progress on this front.  I think this might be a historical accident. What typed language could ppl use? Java, C++ mostly? They’re (for me) both a horrible mess. I think ppl will start using these “new” typed languages from get go: TypeScript (or Flow+JS), Hack, there’s likely more space for these. A high level, both functional and imperative, expressively-typed with type-inference language is going to dominate mid-term. Or still put differently, everyone’s learning from Haskell while not using Haskell.  Type systems have improved greatly in the last decades. There are now many statically typed languages that have type inferrence, generics, and other goodies. Likewise many dynamically typed languages have added support for type annotations (typescript, python, and now apparently php). The resulting code is more or less comparable in terms of verbosity and readability. IMHO the minor overhead of documenting your types is well worth the improved readability and resilience against whole categories of bugs that should not be allowed to exist in any software system. There are very few good reasons to not want that.The trend seems in any case for people to have tools in their pipeline that transpile and verify code. E.g. most javascript code gets shipped in minified form. If you are doing that, you might as well run a transpiler, some sanity checks like linters, code analyzers and type checkers. Many people do exactly that. Those type of tools benefit a lot from having more typing information available. Hence the popularity of things like typescript and recent additions to ecmascript of things like classes.Once you have that, the step to a full fledged statically typed languages is the logical next step. It seems the hack people have reached that point.  I think this goes for a lot of problems in society, not just programming. We fix this and that until it's too complex to overview, then we virtualize or put a black box over it. When that doesn't work any more, we rewrite from scratch, discovering the same bugs and problems we had the first time around.Recent xkcd visualization: https://xkcd.com/2044/  But the open source code smaller companies produce is working for the 10^n fork crowd I assure you. Choose the best tool for the job and build for throwawayability.  Poor Wikipedia will need to migrate back to php7 runtime which still could be complex despite of language compatibility.  Wikipedia was always a PHP software and just running on HHVM for the performance gain, not for the Hack language. The underlying MediaWiki software is used outside of Wikipedia a lot, always on the PHP not HHVM stack. I expect its only a project for their operations team and should be managable.  Could you tell more about MediaWiki use-cases outside Wikipedia? I know there is a lot of open-source projects which has MediaWiki installed for documentation (i.e. Arch Linux). Are there any usage in "internal documentation" software (like alternative to Confluence)? Why they have chosen the MediaWiki not other software which can be easily self-hosted / deployed on a premise?  MediaWiki is indeed very easy to self-host. I've been running several instances for the FSF and Sugar Labs.From the sysadmin perspective, it's a dream app to deploy: just unpack (or git clone) the latest release in a directory, point Apache (or Nginx) at it, and continue in the guided setup process (which involves creating a database, typically MySQL).Updates are also painless: there's a php maintenance script which updates the schema. I've kept MW instances for ~10 years without running into any problems.Things get a little more interesting if your add a ton of extensions, or badly maintained ones.I wish I could say the same of Django and Rails apps!  I dont know much about that, but in a previous job 6 years ago we saw mediawiki in quite a few non technical companies used as internal doc system  Interestig fact that Wikipedia runs on hhvm! But I guess since php7 appears to be as fast if not faster nowdays then it's probably the right move anyway.  MediaWiki has to support PHP 7 for the community of wikis outside Wikipedia that use it. If they dropped PHP 7 support they would be making MediaWiki a bit of an insular project.  Or Facebook could sponsor their development on hhvm and use that to promote hack lang.  Then every single third party extension developer would also have to move to Hack. Knowing what I know about certain extension developers that will never happen and a hard fork of MediaWiki will occur.  Diverging from PHP was a good move as PHP 7 has largely caught up with HHVM in terms of speed. That's really neat that Facebook invented their own language to meet their needs. Will have to mess around with it further sometime.  Agreed, Hack appears to be a move to fork into a PHP-esque language that FB engineering feels will be better for their software lifecycle goals and needs:- Handle numeric boundary cases in a more intuitive way.- Is Typed.- Replace reference parameters in favor of a new keyword, "inout".- Change package management and testing framework to be less annoying and more streamlined. This will be yarn (from npm, as in the one written in Javascript), and their own custom flavor of testing framework, hh-test, to replace PHPUnit.I wonder how many existing open-source PHP projects will remain compatible with HHVM? The post seems to indicate compatibility will not be a priority and that it's a fully breaking change. If this is true, it seems the "empty cocktail room" effect will be a major challenge and problem. Jane: "Hey, you can do this project in PHP or Hack." Alice: "Okay, I'll go with PHP because there's already a shitton of good libraries that might be useful to me or that I already know."  I.e. Why would you use a language with few open source libraries over a very similar language with exponentially more?When I want types, I can already use Go, Java, or even Typescript, just to name a few terrific options. These days it seems like a no-brainer to me.The effort seems like a lot of trouble to go to just to shave off some annoyances / "rogue hairs".Curious if there's an angle I'm missing.One argument for making it an open-source language / project and trying to eventually grow it could be so FB can more easily hire folks who are already know the Hack language. Marke: "I'll do it in Hack because my only dream is to work at Facebook!"  May not be that many Marke's out there.  Laravel, to name one, broke HHVM compatibility a while ago (or perhaps more accurately no longer included it as a target platform). In my experience, trying it out every year or so with an existing project, there were always compatibility issues with HHVM, most often in C modules but also a few odd corner cases in pure PHP.As far as I know once PHP 7 came out HHVM fell much further behind (as far as the PHP language goes, no idea how Hack is doing).  My company has 2 big projects running on HHVM.Most of the library we used to start our projects (symfony, mongodb to name the biggest) dropped the HHVM compatibility in the middle of development, I can tell you this was a good lesson for me: never take a technology where big vendors drop compatibility.Having to debug a production error with an HHVM library (which support was dropped), find a fix and then seing it was fixed in the official PHP library 6 months ago hurt a lot...Another point not in favor of HHVM, it's maintained by them, the roadmap is only known to them and the number of HHVM alternatives to big libraries is near 0.We are gradually moving away from HHVM (and PHP in general) in favor of NodeJS and TypeScript.  > Why would you use a language with few open source libraries over a very similar language with exponentially more?Fewer unvetted libraries from a security and code quality angle.Not saying it's good from a general engineering angle, but in an environment like Facebook which can afford to over-engineer, the third party dependency risk mitigation is a good side effect.But my argument here is a pretty polarizing one as it implies security-through-obscurity. I promise I'm not; I'm just pragmatic about how many abandoned or poorly maintained open source libraries end up being relied-upon regardless of how that challenge is solved-for in CI/CD.  I see what you're saying, and question the assumption that a higher percentage of Hack libraries will be high quality.You raise a valid concern, and also this issue cuts both ways.The FB libs have a good chance of being well-maintained. This will be true for PHP and Hack, alike.The rate of library neglect will be approximately equal between the two languages.The real question is: What does the data say about project / library neglect? I'd guess neglect rates may correspond inversely with language popularity.Languages with fewer people writing code in them will have more opportunity for abandonment and neglect.Who wrote and is relying on the library seems like a better candidate for predictor of proper future maintenance compared to language flavor.  > Languages with fewer people writing code in them will have more opportunity for abandonment and neglect.This would be true in the public space.I don't know if it holds when the language is internal to the company and people are incentivized effectively to keep them up to date.  Oh, there are plenty of people like this: Bob: "I'll do it in Hack because I long Time ago swore off PHP, and Hack sounds like an interesting language."  Agreed. I think there will be some genuine interest in a PHP-like language that drops some of the cruft and adds a few modern tweaks. Plus, having a large company that uses it everyday will help.  Hmm, I don't really get it. But I suppose I don't really know if I bought the value proposition of HHVM in the first place.  Since PHP picked up the slack, diverging from it makes complete sense. When HHVM was released, PHP's implementation had a ton of issues, but now it's doing a lot better. However, even with PHP 7, the language itself is still riddled with confusing behaviors that will likely remain for a long time. They may as well break away from the cost of maintaining backwards compatibility and leave that to PHP, while they fix deep issues with the language and add features like typing.I still don't see myself using it, but it seems like a reasonable path forward for someone who wants to modernize a large PHP codebase and would like features like type safety.  hhvm had some performance advantages over PHP 5. They are largely gone with PHP 7 AFAIK.  Right, this is part of what I don't get.PHP is open source. Instead of building a way to compile PHP and then a VM, and making all the adjustments necessary for Hack, why didn't FB just spend that energy submitting a patch to make PHP faster?Now I also don't know if I buy that MAX_INT + 1 and pass-by-reference is a pressing enough use case to break compatibility. I'd be open to hearing why, but I'd be starting from a position of skepticism.  The people who initially developed HPHP (the PHP-to-C++ transpiler) were not the same people who initially developed HHVM (the VM/JIT). I was one of the people who started the HHVM project, and we recognized early on that we must base our work on HPHP to have any hope of eventually replacing HPHP on Facebook's production systems. Indeed, had we chosen otherwise, our project would certainly have failed. It took us three years to initially ship HHVM, and HPHP's ancillary ecosystem dramatically diverged from PHP during that time. Furthermore, the people who initially developed Hack were yet another team, and they based their work on HHVM for much the same reason as HHVM was based on HPHP.In an ideal world of perfect cooperation, perhaps all these projects would have been enhancements to PHP, but a chain of independent rational decisions produced very different results.  Has anybody written up the history? I'd be fascinated to read a blog post series on all that.  > why didn't FB just spend that energy submitting a patch to make PHP faster?Several reasons. First, it's not that easy. It took years of work by some very smart people to get the jump from PHP 5 to PHP 7, and Facebook needed the performance much earlier that this way could deliver (and it wasn't at all certain that it would deliver at all). Second, Facebook needed their own language anyway to be able to add stuff they - with their particular use case, which is dissimilar to the use case of the vast majority of PHP users - need and for the model they use to run servers and operations. So for Facebook having something that both delivers performance that they need and is under their total control and can be made to do exactly what they need it to do makes a lot of sense.> Now I also don't know if I buy that MAX_INT + 1 and pass-by-reference is a pressing enough use case to break compatibility.It's not about that, that part is small change. The point is they don't want to be restrained by what PHP does, but want to have their own way with HHVM. Which is very understandable, they have their needs and they found a way to support them. Of course, for the open source community might be better if Facebook continued to support PHP - but if for Facebook it makes more sense to do their own thing without worrying about being compatible with PHP, then that's what they should do.  I'm not super well informed about this but if I remember it's because FB would have had to play nice with the community, make RFCs or whatever it is they use, discuss with the community and then the biggest hurdle: vote.by making hhvm, it allowed them to move at break-neck speeds with absolutely no reason to ask for permission.The social aspect of it probably turned them off at a corporate level, if that makes sense. Where as throwing more hackers at the problem was totally in their wheel house. IMO.  why didn't FB just spend that energy submitting a patch to make PHP fasterThe maintainers wouldn't have to accept it, and there are plenty of devs in the community that would have issues with Facebook code making it's way in to the core of a language. If the patch wasn't accepted then Facebook would have to have forked PHP anyway. Rather than bother with the politics and PR downside of their code being rejected, they went straight to creating a fork. It may have been the less optimal technical solution, but like so many technical decisions it was really a business decision in disguise.  Well, the compiler was its own thing and had very different goals. I'm sure that wouldn't have flown for most use-cases and from what I've read it was used only for running production code because compilation took a while.HHVM also adds a lot of syntax to make Hack. And moreover I don't doubt Facebook wanted the option to remove backwards compatibility in the future. Issues like MAX_INT and pass-by-reference don't seem pressing enough if you're using the language, but if you're building a compiler or VM small language quirks will be the one exception that break whole potential optimizations and/or ways of architecting things.Facebook is not concerned with backwards compatibility because they can just change their source code, but PHP is, in order to remain relevant to the community. I honestly think trying to work on the same VM would've caused more issues in the long-run.  I think they did submit changes to make php faster, by making those changes. I think those issues are just a few of many terrible gotchas hiding in the language they can move past by focusing on Hack.  Perhaps they need a bit more control over the project? PHPs voting system is a bit weird, in the past a lot of great proposals had been voted against. If there was no for a few individuals investing a lot of personal time and energy to push for votes many of the features that are now highly praised in PHP7 wouldn't even be there. I can only presume that this is not a very good solution for Facebook, as they probably need a way to have a better control over the roadmap...  They want to break backwards compatibility. That would arguably be a bad thing for PHP as a language. It's apparently something they need for themselves though. The only choice that isn't being a bad citizen is to break away from PHP.PHP. Can freely being in any improvements that fit their model, but the goals of the two projects are no longer compatible.  > Now I also don't know if I buy that MAX_INT + 1 and pass-by-reference is a pressing enough use case to break compatibility. I'd be open to hearing why, but I'd be starting from a position of skepticism.This is an example of a change that will be made, not a rationale for the decision.  HHVM and the work of Hack is what made PHP Great again. ( Or more like bearable )PHP 7 along with laravel can get you some insane development speed. And I argue Hack, and PHP7 is actually want made PHP's downfall stabilise. The community saw their ecosystem has a way going forward and more improvements to come. Rewriting your app in different languages and frameworks is hard, no sane person wants to do it.  Article from Marco Arment about exactly this, from 2014.  From the outside looking in, the most interesting part of the post is the note about their new release cadence:> As we expect the language to evolve rapidly, we strongly recommend using the regular releases instead of the LTS releases for large projects; while this does mean you need to upgrade more often, both us and our users have found that it is generally easier to catch up on 2 months worth of changes 3 times as often than 6 months of changes in one go. We will also be re-evaluating the length of our release cycle; one possibility is that we will move to releases every 4 weeks, with these releases being supported for 6-8 weeks.That cycle will work for FB where they are constantly iterating and also have early insight as to where the language is going before they get there but for anyone on the outside or for slower moving projects, that cadence seems fairly punishing.Is that a big change from how they release now?  This is bad news for Slack, I would think. I believe they went all in on HHVM + Hack, which is going to be increasingly incompatible with 3rd party packages now.  Is it possible they could find inefficiencies in their codebase to make up the performance difference with regular PHP? Or maybe they'll just need to add more servers to make up the difference?  Adding more servers stops being a good option after a certain point. If you're a small company running on 20 servers you can increase your performance by 5% if you add just one more. Install it in one day, boom.If you're running on 200,000 servers, a 5% increase is 10,000 servers. That means opening a new building in your data-center, making sure your recruiting team has resources to hire enough staff for it, then hiring that staff, negotiating contracts with the power company, the component suppliers, building permits, hopefully you have enough network capacity otherwise you'll have to expand that too, etc.It's many months of work and a lot more expensive than hiring a handful of engineers to tackle performance and maybe build some libraries in-house.  I think it depends on whether the improvements facebook hopes to achieve by dropping support for php outweigh the drawbacks of losing 3rd party package compatibility  Depends on how feasible a Hack -> PHP7 transition would be.  If it was just typing it would be easy. If it's Hack collections and async/await...not easy at all  Do you think dynamic types was a mistake? Almost all popular dynamically typed languages have some sort of type hinting. All new promising languages have chosen to be statically typed.  I think using dynamically typed languages is a mistake today, but that it probably made more sense a few years ago. What changed:- More developer familiarity with type systems that aren't Java and C++. Type inference.- Better languages in general, which give more flexibility and power without writing a bunch of hard-to-type code.- Moore's law is dead, so the poor performance of your dynamically typed language actually hurts. Not to mention how atrocious many dynamically typed languages are at threading in a multicore world.- Projects are much more complicated, so it's even more important that things glue together well.  No, the problem is not dynamic typing, the problem is enforcing contracts.With type hinting on function parameters like in PHP you can get the best of two worlds, flexibility & enforcing contracts.  Dynamic types weren't a mistake, but they were overused IMO. It's technically scripting, not programming, but can you imagine if Bash files were type hinted? For small scripts, solo projects or quick fixes, dynamic typing is great because it's fast! On the flip side, large codebases should (on the whole) not use dynamic types because of all the safety they fail to provide! As you said, most dynamically typed languages are moving towards some sort of type hinting and that's because high quality developers demand it when working on medium to large projects.  > It's technically scripting, not programmingNope. Dynamic types have nothing to do with scripting vs programming. What a nonsense!Sorry I had to:).  You misunderstood me. I agree that scripting and programming have nothing to do with dynamic types.> It's technically scripting, not programming, but can you imagine if Bash files were type hinted?I was clarifying that writing Bash files was scripting and not programming.  How is writing bash files not programming though?I understand it's historically been called 'scripting' instead, but 'technically' it's as much of a programming language as Python is, don't you think?  "Technically" of course it's just as much of a programming language, but "practically" it's normally used to kick off other programs, and is just glue meant to pass input and output between programs. FWIW, when people use Python for small automation tasks, I usually hear them referred to as scripts instead of programs. Program seems to imply that it's useful on its own, script implies that it doesn't serve a purpose besides running other programs that are generally useful.  I might be being a bit "old hat", but I thought a programming language was one that you had to to compile (such as C) whereas a scripting language was one that was interperated (such as Python). I could be wrong but there appears to be some similar lines of thought on this.  Type hinting usually matters a lot more as you scale up engineering organizations.  I've worked with C++, assembly, PHP, Ruby, Javascript, MATLAB, Scheme, SQL.. the list goes on.Honestly when it's all said and done, static typing is very low on my list of worries. Type hinting and contracts and all that stuff is nice, but the main problems in most real-world, large-scale projects are:* mutability* object-oriented business logic (rather than functional/declarative)* friction* build systems* async* drowning in inconsistenciesSome languages like Ruby have conceptual errors - for example its try/catch mechanism (rescue) defaults to using StandardError instead of the base Exception class. Which means that even though it implemented one-liners like: load 'my_file.txt' rescue puts 'file not found!'  In practice these are rarely used because they may throw LoadError (which is lower in the class hierarchy than StandardError so is not caught by rescue, and we can't say rescue Exception puts 'file not found!') so the script crashes. Each time I look deeper into Ruby, I find more and more of these idiosyncrasies that don't build from first principles, so I can't tell what problems they're trying to solve (some of its errata seems to have been inherited from Perl). So I would advise against using Ruby for new development until it has a sister language like Hack that attempts to solve these longstanding inconsistencies and move Ruby forward.In contrast, PHP has implementation errors where some methods in its standard libraries are camel case and some are snake case, or they decided to use backslash when declaring namespaces. Since these decisions have no bearing on business logic, I can largely overlook them. When people say that PHP is a fractal of bad design, I tend to agree, but do NOT agree that it's a fractal of bad engineering. In fact PHP is by far the most productive language I've ever used (at least an order of magnitude more than the next closes contender, say Javascript in Node). The only language that comes close is MATLAB, which comes from a completely different paradigm of matrix operations so simply provides more leverage per line of code.Static typing mainly becomes important when you're working with other developers, or have large/legacy codebases. If we're strictly talking about our ability to write business logic as effortlessly as possible, then the conceptual problems I've illustrated above (which pop up repeatedly across frameworks/languages) have much higher priority IMHO.Also on a personal note, I find that dynamic types tend towards rapid application development (RAD) because I often work at a high/abstract level. I find that the friction of assigning types steals brainpower from the task at hand - generally composing logical units that pass around hierarchical data like JSON or tabular data like CSV. If we stick to RAD, then building out strictly-typed/over-architected class hierarchies is generally a waste of time and expensive to maintain.  javascript has no type hinting, there's typescript but tons of people use plain javascript. Same for python (tons of code was and is being written without hints). The same goes for ruby.  I tried using hack once, spent a few days on it. It was a total disaster from a user-developer perspective. The documentation was poor and certain modules (the xhtml or equivalent module in particular) would not work due to versions or dependencies. If they are going to make a push they need to really make it easier to get up and running on.  Static/dynamic is obviously a gradient. I find it a bit sad that it always seems to be either or these days, either no types or a full blown static generic type system.I'm all for the ability to type variables and functions, as long as I'm still allowed to be exactly as precise as I feel like.Many would call that static typing, since there are types in the code that the compiler consumes. But my own attempts [0] at building such languages tell me that the result is still more dynamic than most.  I wonder how this will affect major websites outside of Facebook that rely on HHVM, such as Wikipedia. They made a big announcement when they switched to HHVM in early 2015. Have they moved over to PHP 7 yet?  They are planning to move to PHP7 largely because of this change but also since PHP7 closed the performance gap: https://phabricator.wikimedia.org/T176370  A reminder, HHVM is not Hack. you can run both type of scripts with either  Aaand Hack ist dead. At least for everyone outside fb.Not sure why fb even made it public. First baiting everyone by switching and now having full control.Not sure who would risk that dependency.  Do you mean HHVM or Hack?  Both  Sincere question, but PHP is still widely used?I remember that around the year 2002 it was almost the only choice (besides Perl) on shared hosting, but on this days its just a nasty language and with so many beautiful languages like Python GoLang and Ruby why would anyone use PHP for a new development?  Yes, and it keeps growing: https://w3techs.com/technologies/history_overview/programmin...  So who is using HHVM other than Facebook? Genuinly curious? Will be interesting to see where Hack goes altogether.  I think this is a step in the right direction. PHP's refusal to break BC in the stdlib, among other things is probably the biggest impediment to the language being more widely accepted.By breaking compatibility with PHP, Hack is going to be able to adapt more quickly and create a stronger language. Hopefully, Facebook will have the wherewithal to promote Hack to PHP (and other) developers, and grow the ecosystem as it can.  > PHP's refusal to break BC in the stdlib, among other things is probably the biggest impediment to the language being more widely accepted.PHP is one of the most widely used languages on the web. Their backward compatibility is absolutely part of that reason, too. Refusal to break compatibility may be holding it back in some technical areas, but it's certainly not hurting the language in popularity and use.  There's no reason not to break BC in 7.4. The people still running 5.3 aren't going to not upgrade to 7.4 because you fixed the array functions.  That is a completely false sentence. People develop PHP sites, launch them and expect them to work, even if the server is upgraded to the latest PHP.Breaking their code on a PHP upgrade is a great way to strand them on old unsupported versions of PHP. Not everyone has resources to change things that used to work because of some "array function" change that doesn't really make any difference.  > ... break BC in the stdlib ...(please don't abbreviate when it's unclear. You saving some typing means lots of people have to pause to parse your TLAs...)  Were you able to suss the definitions or do you still need clarity?  I guessed "backwards compatibility. Others might not.But in either case it means every single reader has to pause and make extra mental effort to save you about one second extra of typing. :)  I would have liked "Hack" to be some play on "PHP". Maybe "HPH". PHP++ or PHPPP  Which makes sense. Facebook now is big enough to sustain a programming language on its own. And for Hack, I would assume it mainly to replace where the PHP used to be, which is a shallow API composition layer, no heavy lifting stuff. To fulfill that purpose alone, one need not to have super diverse ecosystem providing all kinds of libraries, just focus on a limited core functionality should suffice.  Wasn't HHVM created as compiler or interpreter for PHP?  Yes but they added so much features that the core became hard to maintain.  Does this mean Facebook pulls its resources out of PHP?Weren't they THE big player that kept PHP alive in the last years?  PHP is still more widely deployed for small/medium websites than any other language. WordPress still powers more websites than any other single application, for example.Facebook was always an anomaly in supporting/using PHP at that scale. PHP was never a major player in very large companies...until facebook. I think this is a return to the mean, rather than a seismic shift in a new direction.That's not to say PHP isn't fading...it is. But, I don't think this is a huge hit to PHP.  The adult industry is another major player using php, pornhub for example is php based.  And, YouPorn (I think? I get all the porn tubes mixed up) was using Perl (at least they were a decade ago when I met some of the devs), though now that many of the big porn tubes are owned by the same entity, I would guess they've consolidated down to one platform.But, sure, if you go to a PHP conference or web dev conference you could meet PHP devs working in almost any industry. It's interesting how insular some dev communities are that one could get the impression that PHP is just...like...gone. As much as we may turn our nose up at it as a language, as a platform it's been a huge success, especially for small developers and web designers that do a little development.  I see.Last time I used it was 8 years ago and I had the impression it would have been gone by now if it wasn't for Facebook pouring money in it.  A gazillion lines of code running on a few million servers has an inertia that takes more than a few years of stagnation to kill, even if newer languages get a lot more hype. There's still plenty of Perl in the wild, including in some pretty mission critical deployments, and Perl was declared dead 15 years ago (with PHP being the alleged killer).Likewise, millions of people still work in Java, C, C++, Ruby, and many others, despite there being newer languages with more momentum behind them. PHP will be around for years, even if there were never a new PHP project started from this day forward (but there will be new PHP projects started after today). So, sure, it's dying, but it's not dead yet and likely won't be for decades.  Your impression is completely different from the reality.Facebook was/is irrelevant to PHP adoption. Their only effect was to increase the speed of PHP.PHP is widely used because it's really great language for web development. It's better than the other choices because of ease and rapidity of development, and because it was designed for the web, not as a regular language with web things bolted on (Python and JAVA are examples of that).It is not fading at all. Some developers think it's too easy of a language, so they discount it as for beginners only. That's about it. It's a kind of snobbery, which I'm glad to see seems to be vanishing with the release of PHP7.  "Some developers think it's too easy of a language"Good lord, who thinks that? PHP is a terrifyingly complex and difficult language. I'm not saying it's bad, it's been very successful for its intended purpose. But, it is definitely not an easy language.It's got thousands of standard functions in the global name space (admittedly, it has been recognized that this was a mistake, but it's all still in there), quite a lot of syntax, and some weird syntax that's unlike any other language, a high level of verbosity in many places (due, in part, to that whole thousands of functions in the global namespace thing, but also due to an apparent admiration for Java during a critical period in PHP development), a variety of quirks and inconsistencies, etc. PHP is a very big, very complex, language, that takes years to master. I can't see how it can be called "easy". Many other languages are much better teaching/learning languages. PHP is popular and widely discussed, which helps with learning it. PHP is also very easy to deploy, because it is the "standard" web language...you just upload your files to the right directory on most hosting platforms and you're done. That's great, but doesn't really make the language easy.  > It's got thousands of standard functions in the global name spaceThere is exactly 0 difference between prefixing a function, and putting it in a different namespace. All those functions have prefixes and are very easy to locate and understand.It's literally the difference between \foo\bar and foo_bar. It makes no difference for understanding the function.The only advantage of a formal namespace is you can "own" it, and other code can't put things in there. Not having it does not making the core language harder to understand.> quite a lot of syntaxIt's basically the syntax of C. The most complicated parts are lambda functions and references. And that's nothing. Where are you getting "quite a lot of syntax" from?Classes have a bit of syntax, but it's hardly "quite a lot", and the nice this is you don't have to learn any of it to get started.> a high level of verbosity in many placesWhere? PHP is not especially verbose. Examples?> a variety of quirks and inconsistencies, etc.There's basically just two: Comparing an empty string and the mistake with precedence on the ternary operator. Everything else confusing is the difference between arrays and Key/Value structures, and it's not really not that hard to figure out.> PHP is a very big, very complex, language, that takes years to master.It is not very big. The core language can be learned in a week. It's not very complex either - it's among the easiest languages out there.> Many other languages are much better teaching/learning languages.Not because they are easier - because they are harder!! They are more structured and you have to understand more - that makes them good to teach concepts. PHP was never intended as a teaching language.  "Not because they are easier - because they are harder!!"That doesn't make sense.I think we'll just have to agree to disagree. I believe there are many languages, including some often used for web development, that are easier (and better teaching/learning languages) than PHP in several regards. Python is the most obvious but Ruby also fits the bill.  If what you say is true, how come it is not supported by cloud providers?  In what way is it "not supported by cloud providers"?Google App Engine: has PHP runtimesHeroku: supports PHPAzure App Service: supports PHP. Experimental support in Azure Functions available.AWS: I think the only language-specific thing they have is Lambda, which doesn't directly support PHP, but it can be run on it with workarounds if you really want to.Everything exposing VMs or containers of course can run it. API client libraries/SDKs are widely available. FaaS support is limited.  What money is Facebook pouring into PHP? You think Facebook is deploying their own developers to maintain PHP?It is not so. Facebook doesn't really interact with the PHP community, except for when they published HHVM, and even that was limited.  If PHP was only useful for juggernauts like Facebook, Wikipedia, Wordpress, Magento, Tumblr, Slack, Dailymotion and Etsy, PHP would be a very obscure language. I think it's alive because it can be (and is) used by everyone.  I think smaller web dev/design shops are what keeps PHP alive. Many, many sites are built on Wordpress, Laravel, etc.  [flagged]  Outside of the HN echo chamber, PHP is still what drives a lot, probably most of the web. Wordpress alone accounts for 30% of websites [1].That translates to easy access to labor for a lot of companies. If you want a quick web app stood up, you can have your pick between a few hundred thousand hungry PHP devs or the three node.js devs that are currently considering being available for new work....'course, a lot of those cheap PHP devs will turn out some horrifyingly bad code, but that's not PHP's fault, and most businesses don't care.  I didn't look for numbers to back this, but I'm not sure node is that far behind in term of available developers (clearly not three vs hundreds of thousands), there is an enormous amount of Javascript developers today, and even those who do not use node can be ready for simple server-side development in a matter of days.Wordpress powering most of the web is not necessarily a good indicator of the popularity of the language among developers, as the whole point of Wordpress is that you do not need to be a developer to operate your website.  I may have added a dash of hyperbole in my comment for humor.  You can get$5 shared webhosting anywhere and use php. Or apt-get the php Apache module and be ready.The barrier to entry is very very low (for better or worse), and if you're careful and avoid most of the crazy, you can make really fast , low overhead, lightly dynamic pages. Of course, it also gives you more than enough rope to get yourself into a lot of trouble, and I have feelings about the modern trend of obfuscating things with frameworks and autoloads, but lots of people think they're great.
 Nearly all free webhosts run PHP too.The barrier to entry is very very lowThis, absolutely this. There's literally nothing to configure or setup beyond PHP itself. You open a text editor and write your script, save the file, drop it on the server and it's immediately ready to run. No messing around with convoluted toolchains, massive frameworks, or some elaborate "build process" just to get a "Hello world" to work.I'm not sure if it's even a majority of users, but PHP certainly appeals to those of us who like writing plain HTML in a text editor and being able to immediately refresh the browser that has it open to see the effects of changes.The language itself has its warts, but they're easy to avoid and IMHO the disadvantages pale in comparison to the extreme simplicity of getting started and continuing to work.
 be ready to what though? make another exploitable website on the internet that will inevitably join a botnet?
 Can you show some data? I'm interested to see how exploitable popular PHP frameworks (Laravel and Symfony?) and the language itself are over the years in comparison to JavaScript, Python and Ruby web stuff. Not interested in anecdotes or bad code from bad programmers (aka Wordpress plugins) being used as an argument.My company has some legacy PHP stuff that is rock solid, making money for years, survived every single audit (and PHP 7 cut our server costs by half).
 WordPress is probably the most deployed php framework and it is extremely exploited.
 Still waiting for source for all those claims. I'm not being ironic or anything but people throw things under the bus so easily it would be nice to see the data (comparison).Their numbers are huge so of course the number of exploited servers will be higher in raw numbers, but is the core "extremely" exploited or is the plugins the real problem? We should be talking about the language/merits but I'll listen to arguments about the ecosystem. Just feels really dumb to talk about things like plugins. It's like saying JS is crap because 70% of the web extensions written in JS are sold to the botnet or are pure crap. Or how a popular operating system has more CVEs because it's popular. Not sure how to explain better what I want to say so let's just leave at that.
 WordPress is heavily hampered by a refusal to break backwards compatibility. https://wordpress.org/about/requirements/> WordPress also works with PHP 5.2.4+That's a nearly eight years end-of-lifed version.
 WP plugins are where these exploits are, less so in WP core
 Having the possibility of using a cheap hosting service like hostgator (for instance) is one of the biggest advantages of using something mainstream like php.
 It's not about control it's about ease of use. You can get a cheap shared hosting account and upload your php site in minutes without configuring a thing. Not everyone wants or needs to manage a server.Think about a small business with no tech experience that just needs a basic marketing site. They download some cheap Wordpress theme, make it say what they want and upload it. Easy! Digital Ocean would be a disaster for them.
 This is 100% true, and furthermore, the process you just described is still too complicated for millions of businesses. They just make a Facebook page (or maybe a Shopify/Wix site) instead.
 I think PHP is interchangeable with PHP, ROR, and node (i.e. give me a line in any of them, and there's a one-liner in the other to do the same thing) [this wouldn't be true for something like Scala].So, presumably for the same reason somebody would do a project in ROR.
 [flagged]
 Every topic that PHP was mentioned in years has comment like yours basically reduced to "PHP sucks". Everybody already knows there are people who think PHP sucks. If you think PHP sucks, don't use it. Stop wasting your time by going to topics where people discuss things about PHP only to proclaim that PHP sucks. It's not contributing anything. Just spend that time doing something useful.
 [flagged]
 > Even though it is incredibly brokenI'll bite. What specifically would you say is broken in PHP?
 > Oh I think it is incredibly useful to warn people who are new to programming,No it's not. It's been done to death, and you are not contributing anything.
 >. It's been done to death..You are missing the point. I am not saying Php is crap for the people already who know it. I am saying Php is crap for people who are new to programming and don't know to stay away from Php yet...I thought I made it clear in the last comment.
 php stands out for being extremely simple to use for new comers
 There's a ton of basic CRUD apps and REST APIs being written in node for which the event-driven model is useless at best, and actively harmful at worst.Looking around at actual production node code, huge swathes of it could easily be written in Rails, Django, or Symfony with no real loss of performance or developer productivity. (And given the maturity of those ecosystems, probably a net gain in developer productivity. Example: ORMs aren't great at everything, but sometimes they save you a lot of time, and Node doesn't have an ORM that can compare to ActiveRecord, Doctrine, or SQLAlchemy.)
 CRUD is literally what node.js is built for - lightweight APIs that then have to do some slow operation async against a store - which they overlap requests across with an event-driven model
 I'm honestly unsure if your post is sarcastic or serious.
 Ha, I have the same feeling, even after several re-reads.
 Yes, and it doesn't have a big enough advantage for it to be picked up. Usually developer productivity and memory use (node doesn't cause memory leaks but it doesn't prevent them either) is more of a limiting factor than the execution model.Node has found plenty of use outside of what it was originally built for (the canonical examples are web servers). As far as I can tell, it's used more widely and critically as a tool for packaging client-side scripts or for client-side applications (vscode, electron, Slack).Examples of places where it seems like node would be an obvious choice, but it's not: blogs (WordPress still reigns), Mozilla's Add-ons (runs on Django [1]), Slack (very heavy user of JS on the front end, but backend is coded in PHP [1]), Zapier [2] (Python backend, though custom integrations are often written in JavaScript)
 If I would have to decide between PHP and Node on who changed the status-quo the most back in the day of introduction, I'd rather say it was PHP.
 You can do event-driven and non-blocking IO in PHP. Check out a library like ReactPHP.
 RoR changed the entire scene with convention over configuration and a total commitment to developer productivity. It's still top of the line in that regard. There's nothing out there that will get you from concept to market faster with a polished product.Even as a giant fan of Elixir, Rails still has a firm place in the "choose for a new project" bucket.
 I'd use Laravel over Rails for a new project in 2018. The community is more active and correspondingly the freebies more modern. Rails' front end story became a ghetto once SPAs became a thing.
 That’s a bit strong. I’ve extensively used both and there’s no advantage for an SPA with PHP over Ruby.If your goal is an SPA and your backend performance is a concern you’re better off with Go or Elixir than either of them.
 No inherent advantage, but Laravel shipping Vue as a default requires 0 config and the community has crystallized around it as a result, whereas Rails' Webpacker isn't a default in the install and puts the onus of choice on the developer (no convention over configuration there) for framework, structure and best practices.If you're an experienced dev, this is a nitpick. But for new users, this is a major hurdle.Edit: as an aside, I'd rather use Rails or Laravel for an api unless the backend had to be a set of microservices for some reason. Less time writing architecture, more time writing biz logic :).
 That makes sense. I can appreciate the pragmatism, especially if you're a Vue fan.
 well not everyone needs to do something just so they can be marketable to other peopleand when that isn't a concern, a stable well maintained language and framework is good enough. PHP has gone through a seemingly endless stream of vulnerabilities but if you actually patch your stuff then its fine.for a web service or site, if you set your routes then nobody would see file extensions and would never know you are using PHP, so when you throw on the trendy bootstrap GUI on top, no one is the wiser and it performs just as well.PHP may seem like an anathema solely because of its correlated and predictable use by out of touch fortune 500 companies that have vulnerabilities and horrible GUIs. But that isn't the fault of PHP.
 I know many devs who do not want to waste their days reading/watching vids about whatever the latest fad to do X is. Node and ‘modern frontend’ suffers from that a lot; many people pick PHP because although it might not be the latest and greatest thing, it works, it is stable, it is fast and you can just buy a few years old book and create something that fulfills the business case. And there are many programmers available with serverside experience for PHP (sorry but frontend JS just is not the same as serverside, so it is common to see nightmare code running in Node that was clearly someone’s ‘but I know JS so I am backend ninja now!’).Personally, since .NET Core 2.1 (latency dropped and the performance is phenomenal on Linux), which is a pleasure to write for, deploy with and very stable, I do not look too much at other things.
 Could you elaborate why/how other alternative are better? Why PHP is bad for a new project? Or PHP just doesn't sound cool to you?Of course you got downvoted (I have never used PHP but I also downvoted you) simply because you do not say any reasoning on your claim and thus there is no value in your comment.
 I think you're being naive personally. PHP has a place like everything else does and not everything needs a shiny new toy.
 People who use PHP are voting you down, because it is clear you haven't used PHP in a decade.Nice edit, by the way.
 I wouldn't either and I've worked with enough PHP to know I never want to involve myself with it again. But I can understand why it sticks, especially in organizations that want to keep costs down and get something (even with questionable quality) out the door as quickly as possible.
 PHP 7.0+ is better than Ruby imo. I enjoy it more at least. It's got type hinting, is more explicit, maps, filters, lambdas, easy setup/transferability, and more.Also, Laravel is miles better than Rails.I think any of the little dynamic programming langs like Ruby, Node, Php, Python are more about the builder than the tool
 the only logic flaw here is...if php is slightly better than ruby and whatever you think, then why not already use the languages slightly or more better than php? many languages that are miles better
 Laravel the framework is better than Rails the framework imo.To answer your question, it doesn't really matter at the end of the day.There's tools in every web language to do just about anything you need web wise. A competent programmer can switch between OOP langs and in a week or two be writing proficient code.Really it all comes down to preference at the end of the day in the dynamic OOP web world.
 Cost, availability of talent etc. It's like asking why not everyone is driving Tesla Model X.
 More

Search: