This has nothing to do directly with this blog post, but just wanted to say that Scott Hanselman is probably the best that could have happened to .NET of all things. Better than Linq and async/await together. He's an amazing speaker and his blog is a great resource for everything around .NET. Can highly recommend to watch and follow this guy!
This is really about Peachpie, an open source PHP to .NET compiler. (Edit: the title has now been updated) From the comments on the article, here's a set of benchmarks showing Peachpie with a significant performance advantage over PHP 7 in a number of benchmarks: http://www.peachpie.io/benchmarks. That said, it's still hard to get excited about PHP.
Be careful with microbenchmarks. From my experience, there tends to be very little correlation between performance improvements on microbenchmarks and real applications. If you improve performance on the microbench suite by a factor of two, you definitely will not get a factor of two on real applications -- more likely, it will be something like 2%.
Basically, if the benchmark is not testing end-to-end performance on Wordpress (or similar), then it's a useless benchmark.
The classic example of this would be that, before PHP 7, Zend spent a lot of effort trying to make PHP use JIT. It improved the results on microbenchmarks a lot, but made negligible difference to real-world code, IIRC.
Good point. In case of Peachpie microbenchmarks - that time it was the only pieces code that could be compiled ... We'll try to update benchmarks for more complex solutions.
We have a huge PHP codebase we may be interested to bring into the .NET world. I have looked at Peachpie but I wonder how well it works in the real world and what the long term prospects are.
Has anybody used it? The PHP code is full of questionable code which somehow works in PHP but I am not sure if it's possible to map PHP's behavior into .NET..
Disclaimer - Peachpie dev.
Some of the weird PHP constructs will never work - by purpose. In such case it will be reported in compile-time or at least in run-time. However, there is always a way of slightly changing the original code to make it running on .NET.
For example one CLR limitation - `yield` cannot be in a catch block. Two workarounds - compiler can generate a crazy state machine or user can just move the PHP yield outside the catch.
Error handling is a big issue - in PHP every notice and warning can be handled in user code, in .NET we use Debug Assertions or exceptions. But .NET has threads and async which shares one thread by more requests, so in case of error we just don't know what request has to handle the error. We would have to pass some request context object to every function in runtime in order to be able to let the correct request's error_handler to handle the error - or we just assume warnings and errors should not happen and crash when it does.
Garbage Collection - for performance reasons (and sanity) we let .NET GC to do its job. But unlike PHP's GC it is undeterministic and does its job on a different thread. For now, __destruct is not handled in Peachpie yet cause there are more ways on how to simulate PHPs behavior.
Changing existing closure's $this to anything - well.. besides it would make type analysis useless, it totaly violates strong .NET method access checks.
It's says they actually get WordPress running before releasing it. Not that I want to undermine project achievements, but WordPress likely going to work even on PHP 5.2.x that almost 10 years old.
'Sort of running' and stable enough to deploy into production are different things. I really want this to work but I am a little nervous about committing to it.
It was running with modifications at the time, but now runs unmodified. I suggest to get in touch with the team to discuss your specific case at info at iolevel dot com.
The previous version of Peachpie, Phalanger, had several clients with huge codebases who successfully used it to migrate their apps or interoperate with C#. Peachpie works the same way.
Glad Scott noticed this. It's definitely appealing (at least in theory) for people worried about self-hosted WordPress security.
Most recent HN discussion dug into the tech and also the rationale behind transitioning in either direction: https://news.ycombinator.com/item?id=13753445 (404 points/164 comments/Feb 2017)
To me it seems similar to running Ruby on the JVM (JRuby). Perhaps you like php but have a lot of .net code to interop with. I bet writing business logic in C# and web tier code in php could possibly be a satisfying experience.
A dotNet asp.net (Webforms, etc) to PHP compiler would be more useful.
Now that asp.net is end of life, these sad people are looking for ways to migrate their aging asp and asp.net code base to elsewhere. The only supported option is the incompatible new asp.net core on dotNet core - out of the jungle into the jungle.
Microsoft has been steadfast that it will support the .net 4.x for foreseeable future and improvements and newer versions will come, given that 4.7 is on the way, I see no grounds for the claim webforms are being deprecated, the guidance has been MVC is the recommended solution, but WebForms were always supported.
It would be helpful if you can provide some source for this.
Many parts of ASP.NET are a part of the Microsoft .NET Framework, these include ASP.NET Web Forms, Controls, Modules, Handlers and more. For more information see .NET Platform Support.
Support for .NET 4.5.2 follows the lifecycle policy of the parent operating system. It is supported as a Windows component on the latest required operating system update for Windows Vista SP2, Windows 7 SP1, Windows Server 2008 SP2, Windows Server 2008 R2 SP1, Windows 8.1 Update, Windows Server 2012, and Windows Server 2012 R2.
Products Released: Windows Server 2012 R2 Standard
Lifecycle Start Date: 11/25/2013
Mainstream Support End Date: 10/9/2018
Extended Support End Date: 10/10/2023
Service Pack Support End Date: [empty]
Notes: Mainstream and Extended support for this product has been extended to provide customers with the standard lifecycle transition timeline. For up to 6 years of additional support beyond Extended Support, please see the Premium Assurance website.
.NET 4.7 shipped earlier this year and includes Web Forms support. Looking at the support lifecycle page, I can see how the order of answers calling out .NET 4.5.2 at the top might be confusing. The last answer on that page (
What is the Lifecycle Policy for the different versions of the .NET Framework?) is the one I think you want - it indicates that .NET Framework 4.7 ships with Windows Server 2016 and Windows 10 CU (1703), which pushes you out to 2022 (minimum, every release keeps resetting the clock) for Mainstream Support.
[disclaimer: Microsoft employee, .NET Foundation staff]
