9 ms·
Mago: A fast PHP toolchain written in Rust
- CiaranMcNulty 1y agoIt's good to see more focus on static analysis. With Phpstan and Psalm already in the space I'd like to see more differentiator features than 'written in Rust' - there are certainly advantages to that, but the disadvantage of not using PHP is it's harder to get contributions from the community using the tool. Cool project overall!
- dzonga 1y agoseems rust's biggest win was improving other languages toolchains and bringing increased productivity to those languages.
- retrocog 1y agoNot a bad win so far, right? One hand washes the other and both wash the face.
- ainiriand 1y agoDo you really think that this is Rust's biggest win or are you just joking/trolling?
- IshKebab 1y agoTo be fair it is pretty significant. Especially uv. I don't know anything about PHP's existing toolchain but I do know that Python's is a horrifying mess, and uv basically fixes it. It's a small thing in the Rust community but it's pretty huge in the world simply because there are so many Python developers (and also because of the extreme magnitude of improvement). Probably wouldn't have happened without Rust.
- 3eb7988a1663 1y agoThanks to Rust, there are heaps of next generation CLI utilities that have come onto the scene in the past decade. Cross platform by default, UTF8 aware, more likely to be multi-threaded, simple distribution, and most importantly - improving on some unfortunate legacy API decisions. Ripgrep, fd, tokei, Just, zellij, uv, and so forth. Porting languages has given the opportunity to remove some of the cruft decided on a whim in the 70s. None of these are world changing, but they do make life easier than the originals.
- johnisgood 1y agoWhy is it "thanks to Rust"? They could have been written in any language.
- Aeolos 1y agoYet they were not - why is that?
- johnisgood 1y agoWhy are you asking me back? I wonder why, too. Now, you can give me a reply for why you think that is, which you could have done without this comment, or you can just keep adding noise to this thread. Up to you.
- 3eb7988a1663 1y agoTo replace a historical C tool, you cannot compromise too much on the original constraints. Replacement has to be equivalently fast and no runtime. Which means even if you made a great design in C#/Java/Python/whatever, that is going to be a deal breaker for some. Safety is (somehow) not a compelling enough argument vs battle-tested. Rust (or Go) are about the only popular languages around that can meet the spec. That Rust will always be theoretically more performant than GC Go makes it the more attractive option for re-imagining some of these bedrock utilities.
- johnisgood 1y ago
- testdelacc1 1y agoNot the biggest, but definitely the most visible to people who aren’t dialled into Rust news. For example, many people use Android but they wouldn’t know or need to know that their Bluetooth stack is written in Rust. Whereas anyone who uses Python would have heard of uv and why it’s much faster than other tools.
- wavemode 1y agoI don't think it's strange at all to call this Rust's biggest win. Adopting Rust-based tooling has sped up development and lowered CI costs for millions of JavaScript and Python developers. I can't think of anything else Rust has been used for which has had a larger direct impact on people's everyday lives.
- smt88 1y agoYou're wrong because it's also incrementally replacing individual, high-risk components in Windows and Linux. But even if you're not wrong, a major mission of Rust was to be a safer C/C++, and language tooling used to be dominated by those languages.
- tredre3 1y agoAll the language tools that are being displaced by newer rust replacements were definitely not written in C/C++. They were/are written in the host language (js/java/python/php/ruby).
- tialaramex 1y agoWhich is striking right? Nobody went "Oh, I should write C++ to speed up my Python tool", or if they did we don't know about it because they're still trying to understand the six thousand lines of template spaghetti their compiler spat out due to a typo in one line of their code.
- giancarlostoro 1y agoI am waiting for someone to build a modern scripting language in Rust that has the popularity and rich tooling and capabilities of Rust as a result.
- testdelacc1 1y agoLike Gleam?
- scotty79 1y agoIt doesn't have imperative constructs I think. So half of developers or more are out front the get go.
- giancarlostoro 1y agoI was thinking similar but more like a Python or Lua but all in Rust.
- ekidd 1y agoThere are two deep capabilities that make Rust, Rust: 1. Banning shared, mutable data. You can't change data that other code might be reading. This is a huge win for threading and multiple CPUs, but it's a dramatic departure from other popular languages. 2. Knowing how data is laid out in memory. This is classic "systems programming" stuff, and it's also present in C, C++, Zed, etc. This usually goes along with making memory allocation visible (though not always in C++). This is a big win for performance. If you wanted to build a "scripting language" version of Rust, you could probably lose (2). Languages like Haskell are even stricter than Rust, but they hide the details of memory layout. But then you need to decide whether to keep or lose (1). If you keep it, your language will have good threading, but users will need to think about ownership and borrowing. If you lose (1), then your language won't feel very much like Rust. It would be an interesting intellectual exercise! But actually turning it into a popular scripting language would probably require the same luck and the same 10 years of work that most successful languages need to get real traction.
- coolsunglasses 1y ago
- muglug 1y agoIt is very cool that this exists, but the PHP community lacks the resources to see a non-PHP tool thrive. Tools like Sorbet (C typechecker for Ruby) or tsgo (Go-based successor to TypeScript's typechecker) are only viable because big profitable companies can back them up with engineering hours.
- retrocog 1y agoInteresting. Do you have any thoughts to share along the same lines about FrankenPHP?
- muglug 1y agoIt's cool that it's part of the PHP foundation, but it's not all that complex. FrankenPHP has >100 contributors, including 3 very frequent ones, and about 17k lines of Go. Mago has 11 contributors, with just 1 very frequent one, and about 135k lines of Rust.
- hu3 1y ago> PHP community lacks the resources to see a non-PHP tool thrive. Why do you think so? The PHP Foundation has raised over 2 million USD in contribution and has over 500K in their balance currently according to: https://opencollective.com/phpfoundation https://opencollective.com/phpfoundation PHP has some well funded groups using it like Wordpress, Wikipedia, Laravel to name a few. And recently the PHP Foundation started officially sponsoring a Go project, FrankenPHP. https://thephp.foundation/blog/2025/05/15/frankenphp/ https://thephp.foundation/blog/2025/05/15/frankenphp/ So PHP looks like a friendly and well supported community to foster tooling made in other languages.
- muglug 1y ago> The PHP Foundation has raised over 2 million USD in contribution and has over 500K in their balance This is great, but it is still dwarfed by the amount Microsoft has spent on TypeScript and also by the amount Stripe has spent on Sorbet. 500k is roughly comparable to the amount my previous company spent (grudgingly) to keep me employed and working on PHP tooling for a couple of years.
- Raed667 1y agoLove seeing some Tunisian representation here ! Kudos on the project !
- anta40 1y agoI initially thought this was a PHP implementation in Rust.... but it's not Will Mago implement a PHP runtime? Absolutely not. The PHP runtime is incredibly complex. Major efforts by large companies (e.g., Facebook's HHVM, VK's KPHP) have struggled to reach full parity with Zend Engine. Achieving this as a smaller project is infeasible and would lead to community fragmentation. We are focused on tooling, not runtimes. https://mago.carthage.software/faq https://mago.carthage.software/faq
- ivanjermakov 1y ago> The PHP runtime is incredibly complex Say this to the team behind Ladybird browser: https://awesomekling.substack.com/p/how-were-building-a-browser-when https://awesomekling.substack.com/p/how-were-building-a-brow...
- lillecarl 1y ago80/20, also they're not implementing JIT and such because of complexity.
- peterfirefly 1y agoThey have the benefit of a project leader with many years of browser implementation experience AND much lower performance goals. (Items 5 and 3 on the list in the linked page.)
- password4321 1y agohttps://www.peachpie.io https://www.peachpie.io compiles PHP to .NET.
- VoidWhisperer 1y agoIsn't this more transpiling than compiling?
- tialaramex 1y agoNot really? .NET has a "Common Language Runtime", which you can think of as analogous to the Java VM or to Beam. A transpiler might read PHP and spit out C, or Java or some other existing programming language, spitting out the code for a virtual machine doesn't make you a transpiler unless you're going to argue that all compilers are just transpilers, it's like one of those "Actually goats are fish" arguments. OK, but now the word "fish" is useless so why go to this bother ?
- darkamaul 1y agoSo I guess this is `uv`, but for PHP? If it has remotely the same success, that would be a huge win for the ecosystem!
- aszen 1y agoNo its different, php already has a good package manager, this is about formatting, linting and type checking
- techtalsky 1y agoIt's more like `ruff` for PHP.
- Einenlum 1y agoPHP already has a pretty good package manager. But it would be great indeed to have a tool to install different versions of the runtime, on top of a Ruff equivalent
- cynicalsecurity 1y agoAll of this already exists and each separate product is actively developed, keeping up with all of the changes in PHP. This toolset looks too ambitious.
- lucideer 1y agoAstral did something similar for the Python ecosystem (Rust-inspired tooling built in Rust, replacing a lot of pre-existing - bad - tooling) & the impact has been revolutionary. Python had some of the worst tooling of any popular language & now has some of the best. Composer is one of the best package managers in any language ecosystem but beyond that, other PHP tooling, while technically well maintained, aren't particularly great at what they do. It's an ideal starting point for positive disruption.
- bornfreddy 1y agoWhat is wrong with phpstan?
- SXX 1y agoI really wasn't using Composer for last couple of years. Did it already stopped eating 2GB RAM for any project that use framework like Laravel? Composer is a good tool, but it's resource usage was abysmal.
- 10us 1y agoYes it did. Composer 2 is way lighter and faster
- gocartStatue 1y ago2G of ram at build is not that outrageous, however yes, with composer2 (released like 7 years ago?) it uses less ram. Also the frameworks got less bloated and more modular
- CR007 1y agoBS, compare projects like Infection vs whatever you have to fax to a guy running Ruby.
- idoubtit 1y agoThe README is quite ahead of reality: it never mention that Mago is still beta software. A roadmap to a first release was created 5 days ago, https://github.com/carthage-software/mago/issues/405 https://github.com/carthage-software/mago/issues/405. I've just tried to apply it to a medium-sized project, and it spitted tens of thousands of errors where phpstan and psalm don't see any. At first glance, it's because Mago does not parse phpdoc. In its current beta state, Mago is meaningless for all the big PHP projects, which are its main target. Mago might succeed, but I wouldn't bet on it. Its main selling point is that it promises to be faster than the usual static analysers-linters (phpstan and psalm). But if it does not reach feature parity with them, the speed gain probably won't convince PHP projects to drop the standard tools. Since phpstan and Co keep evolving, keeping feature parity will require constant work. And PHP is more niche than Python or JS, so contributors mastering Rust and PHP will be fewer, compared to phpstan/psalm which are written in PHP.
- eider 1y agoI pulled one of classes from my project that does not depend on anything external and fed it to their demo site. It threw up bunch of errors complaining that RuntimeException is undefined. It seems it doesn't understand built-ins unless you prefix them with \, even though they are imported properly with use statement. This is pretty core issue to lack support for. Calling it "beta" is actually giving it a lock of slack, I'd say it's closer to being proof of concept.
- azjezz2 1y agoMago author here. The online playground is running a very old version (~0.20.0 from months ago, which did not even have a static analyzer) and gives a poor impression of the current tool. That's on me to fix or take down. The issue you saw with built-in classes like `RuntimeException` was absolutely a bug in those early alpha versions, but it has been fixed for a long time now. The analyzer has matured a lot since then. The current beta is stable enough to be the sole static analysis tool for a couple of extremely well-typed projects: - https://github.com/azjezz/psl/ https://github.com/azjezz/psl/ - https://github.com/carthage-software/cel-php https://github.com/carthage-software/cel-php I'd definitely encourage trying the latest release locally to get a real feel for it. Thanks again for the write-up!
- NietTim 1y agoSeen this around quite abit over the past few days. I wish the github landing page/readme would actually substansiate why this is better beyond it being written in rust which seems to be the main argument for the tool right now. I make my money from PHP, I preffer stability.
- ajsnigrutin 1y agoYears before it was "... written in ruby", now ruby lies forgotten and rust is the new language of the week.
- loeg 1y agoBut what does it do?
- quotemstr 1y agoHow many hours and dollars get wasted on reimplementing the same basic concepts over and over for this or that language runtime?
- azjezz2 1y agoHours? A lot. Dollars? A couple hundred for the logo.