PHP has been removed in macOS Monterey | Hacker News Reader

PHP has been removed in macOS Monterey

developer.apple.com

404 pointsingve407 comments

Xcode 11 Release Notes (https://developer.apple.com/documentation/xcode-release-note...)

"Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for compatibility with legacy software. In future versions of macOS, scripting language runtimes won’t be available by default, and may require you to install an additional package. If your software depends on scripting languages, it’s recommended that you bundle the runtime within the app. (49764202)"

Found via https://mjtsai.com/blog/2019/06/04/scripting-languages-to-be...

Regarding Perl, rather than removing it Apple actually upgraded it – from 5.28 to 5.30 – in Big Sur 11.3. I wasn't the only one briefly surprised and bitten by it:

• https://github.com/Homebrew/brew/issues/10127#issuecomment-8...

• https://github.com/Homebrew/brew/issues/11275

I doubt they'll be able to get rid of Perl any time soon.

However, how come things break when Perl is upgraded? From what I've heard, Perl should be extremely backwards compatible. What am I missing?

Enjoy the incompatible changes section from all Perl history,

https://perldoc.perl.org/perl#History

That's bullshit. I've run exercises from the Orelly CD bookshelf more than a decade old and they just run as is.

That just proves the point you got lucky with what language features were used on the exercises.

Almost all exercises are minimal in nature. They will touch only small areas and (unless the book is based around advanced ideas) will not touch tricky / changing functionality. So I'm not surprised exercises still work.

> That's bullshit.

Dude, there is literally a link with references.

That's a link to complete changelogs.

Those aren't an "incompatible changes seection".

perldelta covers bugfixes, feature additions etc.

   foreach entry in "https://perldoc.perl.org/perl#History" do
      open entry on browser
      search for "Incompatible Changes" section
      read section contents

Writing a script in Perl to do the above is left as exercise to the reader.

Hint, use LWP.

They had to recompile their perl XS bindings, where esp. subversion is horrible to update.

For me, I had been too lazy to use Homebrew or Perlbrew since I don't develop locally per se, but I wanted `Perl::LanguageServer` for use with VS Code – which I'd installed via `local::lib` into `~/perl5/`.

Post-upgrade either various modules weren't found (because they were installed in a versioned path), or they didn't compile because the XS components had been compiled against the prior version of Perl.

Right, that's a risk you take doing local::lib against system perl.

I will often use the system perl to bootstrap https://p3rl.org/Perl::Build which makes building -one- perl for local use easier than perlbrew/etc. - and then https://p3rl.org/App::plx for managing per project environments if I need that

Perl is requires for apple to maintain their unix(tm) certification. And while they likely dont see it as core to what they want macos to become it would be an news story in the more sensationalist part of the IT press if they were to drop it. and big sur is still listed as certified https://www.opengroup.org/openbrand/register/.

Genuine question: is there anyone (corporate or not) that cares that macOS is a certified Unix?

Many care that macOS is Unix-like, I doubt anyone cares about the certification.

It's still impressive that powerful command line environment and the best GUI are offered in a same OS.

Usually it's one or the other.

It used to be, but Apple seems to have lost interest in the Unix/Open Source side of macOS a decade ago. They've abandoned GNU tools after GPLv3 (2007), haven't added anything new, and just let the old stuff limp along until it's obsolete.

Nowadays macOS needs something like Homebrew to fill the gaps. It's still slightly better than Windows + WSL, but Microsoft is catching up, while Apple seems to think that iPadOS is the future.

This new world is way better. Before we were dependent on Apple's release cadence to keep our OSS up to date. Apple officials dropping support doesn't mean they don't want these tools to be on their platform, it just means the community does a better job of managing Unix/OSS tools separate from Apple's release schedule.

That's still pretty appawling though. If Linux distros can have big release candidates and still push out package updates between releases then why can't one of the most profitable companies in the world manage it?

I'm not saying it's an easy problem to solve. Just that Apple aren't dropping support out of respect to their customers. They're doing it because it's cheaper.

Linux distros have massively different expectations of their users. And users have very different requirements from how they get and update their OSS, hence he variety of distros and package managers. Its less that Apple is unable to do this and more that Apple is in the one size fits all business, and that model simply doesn't work for solving the OSS distribution problem.

We're not talking about forking macOS for every theme change or offering alternative init daemons. We're just talking about providing a package manager for common user land tools. In fact Apple already do this: it's called "App Store". But you have to pay to have your app on there so most OSS don't bother. And here lies the problem: why would Apple run another package manager for free? For them, this is 100% a financial decision.

I'm thinking that the less value that Apple delivers to the customers, the better it is for their bottom line, don't forget, adding value costs money, plus its not like Apple fans are going to suddenly quit buying their products right?

Apple seems to be really good at maintaining their profit margin.

Apple is fantastic at creating artificial scarcity out of zero-marginal-utility.

In a nutshell, this is the correct answer. Going all the way back to when Apple's Java was deprecated and eventually removed from the shipping OS. In the moment, it's annoying, but I would rather not have to fight with preinstalled software when trying to get a newer version of (say) zsh installed.

Here, they not only realized it had become popular, but GNU licensing gave them an excuse to switch the default without much thrashing about.

The fact that I can `chsh -s /usr/local/bin/zsh` and macOS doesn't freak out is quite nice.

There's still an even better solution: Apple could start treating their operating system like a first-class programming platform, and everyone would win. But it looks like they're still dragging their feet on that one.

> It used to be, but Apple seems to have lost interest in the Unix/Open Source side of macOS a decade ago. They've abandoned GNU tools after GPLv3 (2007), haven't added anything new, and just let the old stuff limp along until it's obsolete.

There's a whole lot more to Unix and open source than GNU. macOS has current versions of many open source tools, such as zsh, awk, sqlite, tar, git, and xz.

If one is being pedantic, GNU is not even "open source" but rather is "free software," and macOS certainly is not free software.

None of that really matters when GNU is the predominant standard, though. You could tell your boss all about how great the MacOS coreutils are, but if your program doesn't compile, you're gonna be in trouble.

> GNU is the predominant standard

On Linux, sure, but not on other Unix OSes (like *BSD)

`awk` is part of GNU. And Unix™ is a proprietary product of AT&T.

They're rolling in billions with nowhere to spend it. They could just hire some more unix devs to update their tooling. Nobody wants to champion that because it'll never be a keynote bullet point.

Their tools are up to date with UNIX, hence why they keep being certified.

https://www.opengroup.org/openbrand/register/brand3668.htm

> and the best GUI

This is very subjective. I, for one, much prefer kde plasma. And there's a substantial breed of developers who would prefer a tiling window manager with good keyboard navigation, such as i3.

Powerful command-line environments are offered everywhere (wsl, Linux container on Chrome, Linux on Linux). MacOS is actually quite lacking in comparison (being limited wrt licenses and lacking a package manager). So it’s just a GUI question, and I’m not sure there is a definite lead these days.

Integration with their other hardware devices is the more important moat right now, as is hardware.

There are plenty of third-party package managers for macOS that work fine. I would prefer it if Apple picked one to officially support, but installing Homebrew takes me ten minutes and then I never have to think about it again.

I had unpleasant issues with homebrew upgrades back when I used it. It’s not exactly state of the art. (Nix works the same everywhere, though — but there are some hoops you need to jump through on macs)

It’s definitely not the best. I have my issues with it. But I’ve been using it since I got a Mac in 2014 and it has improved a lot since then, it rarely blows up on me anymore. In fact I can’t remember when last it did.

I’ve always wanted to use Nix and have tried to get started a few times. It has always ended up seeming more trouble than it’s worth.

I've used it as my primary package manager on macOS for six months, but ended up dropping it. My main reasons -

* Nix doesn't have support for GUI apps like homebrew cask does - which meant I couldn't drop homebrew anyway. * The nix ecosystem forums suggest using nix-shell for managing packages for other languages, eg. python, java - but it's been really difficult to convince team members to use nix instead of pyenv, conda, gradle etc

Neither Macport or Homebrew work "fine", but please continue.

WSL includes a package manager now?

The distro you run in wsl certainly does.

If you want to throw in WSL then include Docker on any OS

Any OSes where Docker runs that I have not covered?

The joke went over your head

That's a hugely subjective comment and there are plenty of instances throughout history of a powerful CLI and sophisticated GUI being included as part of the same OS (Xerox Alto, BeOS, NeXT, Plan 9). Linux and *BSD's have plenty of popular WM / DEs too: personally I'd rate KDE above anything commercial I've used but that's my subjective preference. Heck these days even Windows can be argued as having a "powerful CLI" with both WSL and Powershell existing, and the Windows UI has it's fair share of fans (regardless of what our own personal preferences might be).

Indeed.

Windows Subsystem for Linus sure has been a game changer!

It was impressive back when OSX debuted, but now it feels like Apple is lacking in both regards. Their shell utilities are all horribly outdated/mismatched, and their UI design took a nosedive with Big Sur. Modern MacOS reminds me of what Ubuntu felt like 10 years ago: it's a confused and scared operating system that doesn't quite know where to go from here. I mean, look at what Monterrey introduced; basically better Facetime and some new wallpapers. I'm getting the feeling that Apple has painted themselves into a corner here. They spent the past 2 decades focusing on vertical growth, only to discover that the next 50 years are going to be ruled by better interop and protocols.

Their tools are up to date with UNIX standard,

https://www.opengroup.org/openbrand/register/brand3668.htm

and in this case it's neither

Best GUI? Finder is atrocious, and overall experience is far worse than even cancelled Unity. YMMV, of course, but I hate every second spent with this 'best GUI'. The only reason I ever use macOS is because I occasionally run Sketch.

In fact, https://en.wikipedia.org/wiki/Amiga_500

End-users? Probably ~0.

But it might help Apple to win government contracts.

And who’d imagine, in 2000, that 20-ish years later, one of the most popular lines of computers would be RISC-based UNIX workstations…

The few, government workstations that aren't running Windows are probably using RHEL. Microsoft and Red Hat/IBM have much more experience than Apple at speaking "enterprise."

not in 2021, but apple made sort of an big deal about it when they started to market OSX 20 years ago.

And while you can still find an traditional unix(tm) box here and there in the dusty forgotten corners of enterprise serverooms(i am personally responsible for maintaining a few hpux boxen), unix(tm) certification haven't really mattered since Linux became serious business which happened around the same time OSX was launched.

What used to matter was that you could run the same CLI tooling in an macos desktop as on an Linux server but i don't think this is an use case apple see's as particularly important for the future success of Apple.

IMO, Apple still sees it as very important that macOS is fairly attractive for developers. Of course they’re selling lots of MacBook Airs to college students, but outside of that…

It’s not as if they want their CLI interaction to be 1-for-1 with Linux, but relatively close seems to still be a priority.

Do you have more info on that? Fairly attractive for macOS and iOS developers sure, but for me it was a happy accident that Macs also became popular for web development and Linux server admin, that it was never part of the strategy of Apple.

Companies see Mac products as more attractive for their workforce than Linux-based workstations. Having printers, wifi, other products seemlessly work, since Apple devotes time and money ensuring that, improves productivity, generally, and lowers costs in (in terms of Helpdesk staff and time spent diagnosing and fixing systems integration). So, developers and admins make use of what's offered, as it is a middle-ground between stability and functionality.

While it may have been a happy accident, it's a pretty big market.

Precovid, on any conference I went to, professional or academic, the amount of Apple laptops was insane. I'm sure they're running things locally or on Linux servers, but the fact that they work pretty well between them is important.

For anecdata, I've worked at two companies in a row now that have used exclusively Macs because it's simultaneously an acceptable platform for serious dev work and still user-friendly to tech illiterate interns.

I just don't see them making any decision that does not make the MacOS CLI less useful with each and every release since at least the big cat series, and the user pattern is changing with those changes.

IT's an trip the classic macos took before it and i think there is an signficance in apple returning to the MAcOS branding thats subly hinting that the days when OSX was an relatively open unix is ending.

I can't consciously buy a Mac if Apple is going to treat Linux like competition. One is free software, provided by volunteers for free, and the other is a desktop OS ran by the largest company in the world. It costs Apple nothing to respect the predominant standards, so why can't they do it?

Maybe they don't care about you as a customer? Apple has never pretended to cater to everyone.

They aren't for you. Move on.

I agree, Macs aren't for me. But if Apple wants to increase their market share (hint: they're one of the most-traded shares of all time), they should start listening to their detractors. Especially for their desktops, where MacOS barely constitutes 7% of the desktop market share. Apple has been selling computers for nearly 5 decades, and their market share is still pitiful. Hell, if Google is selling more computers than you, something is seriously wrong with your computer.

Again, Apple is not interested in catering to you. Clearly. I think they're pretty happy with where they are, and catering to the demands of the "make it like Linux" crew are laughably irrelevant. I have no idea why "most-traded shares" is pertinent -- yeah, they're a super, ridiculously profitable company. Your commentary on their "pitiful" computer sales are not cogent.

The Google bit is particularly goofy. No, "Google" doesn't even appear on the charts (you know -- the charts which Apple usually is within the top 2, often leading). Chromebooks do, sold by a wide variety of sellers, as a schoolhouse special. Their great for what they do.

> It costs Apple nothing to respect the predominant standards

Actually, it would cost them a lot, due to the GPL. Sure, they could try and pull a Google re: Java/Oracle feud, but I doubt they will and for good reason.

That’s the only reason my employer hands out MacBooks. If it stopped being something that used the same CLI tooling as our infrastructure, it would be Dells all around.

Ironically, Dell ships it's XPS "developer editions" with Ubuntu, which is likely much closer to your infra.

I believe it's a compliance thing for government contracts.

It would be needed to POSIX compliant (even Windows had compliant) but not UNIX(R)

I mean, I do. I'm sure plenty of businesses love having a standardized spec across their devices, too.

Perl isn't required by or even mentioned in the Single UNIX Specification.

Yes, but Perl still has a warning banner when you run it (at least in Big Sur and Monterey):

% perl -de1

WARNING: This version of perl is included in macOS for compatibility with legacy software. In future versions of macOS the perl runtime will not be available by default, and may require you to install an additional package.

They've actually been warning users since Catalina (if not longer) when the following are run:

python

irb

php --version

tclsh

For PHP, it also shows up in Apache's server string:

Apache/2.4.46 (Unix) PHP/7.3.24-(to be removed in future macOS) mod_perl/2.0.9 Perl/v5.30.2 on hostname

Personally, I've been hoping they'd do this for a while since it's annoying having two versions of each interpreter installed (the system one that can't be updated and the one I installed myself via Mac Ports). Anyone who uses these languages much probably already has a package manager installed. I think they should leave Perl, though, since it's as much as Unix system utility like awk or sed as a programming language.

I find the MacPorts approach to be very developer friendly and I wouldn’t really want to use a “naked” macOS install as my work machine. MacPorts makes it look like a very credible BSD workstation.

I really have no issue with Apple trimming down the surface of the OS to a minimum.

While the warning shows for python2, it doesn't show for python3, implying that it's here to stay for now:

  % /usr/bin/python

  WARNING: Python 2.7 is not recommended.
  This version is included in macOS for compatibility with legacy software.
  Future versions of macOS will not include Python 2.7.
  Instead, it is recommended that you transition to using 'python3' from within Terminal.

  Python 2.7.16 (default, Mar 25 2021, 03:11:28)
  [GCC 4.2.1 Compatible Apple LLVM 11.0.3 (clang-1103.0.29.20) (-macos10.15-objc- on darwin
  Type "help", "copyright", "credits" or "license" for more information.
  >>>

  % /usr/bin/python3
  Python 3.8.2 (default, Dec 21 2020, 15:06:04)
  [Clang 12.0.0 (clang-1200.0.32.29)] on darwin
  Type "help", "copyright", "credits" or "license" for more information.
  >>>

Python is to Unix/Linux/Mac what PowerShell is to Windows. It's here to stay.

No it’s not. And it won’t

I am pretty sure bash is the powershell of Unix/Linux/Mac

bash is more akin to cmd/batch then Powershell.

there is a TON more you can do with powershell than you can with bash. Plus object pipelines are superior to text pipelines

You can also install Powershell on Linux. So I would say Powershell is the Powershell of Linux

you can install bash on windows too.

I don't think powershell is even the powershell of windows. You get some of the better sysadmins using it, but working in the c#/windows world I see developers rarely touching powershell, certainly nowhere near as often as you'll see Linux develops writing a shell script. I wouldn't be surprised if C# was more used for "scripting" purposes than powershell, it usually ends up shorter and more readable anyway.

That's because it's not part of the base OS:

   % /usr/bin/python3
  xcode-select: note: no developer tools were found at '/Applications/Xcode.app', requesting install. Choose an option in the dialog to download the command line developer tools.

Note how despite not coming with the OS, `python3` is still placed in the Apple-only `/usr/bin/` directory. And a binary exists at that path either way, it's just a stub by default. Because none of this is confusing at all.

I don't like how Apple handles this. If you have the developer tools installed, it's not especially obvious what is part of those tools and what is actually bundled with the OS. And so it's not surprising that some scripts I've come across will silently break in semi-odd ways without the dev tools.

Also, why is Python a developer tool, but Perl isn't? Or ZSH, for that matter? Does the distinction actually make any sense?

> Note how despite not coming with the OS, `python3` is still placed in the Apple-only `/usr/bin/` directory. And a binary exists at that path either way, it's just a stub by default. Because none of this is confusing at all.

There's long been problems with this on UNIX systems. For a long time there's generally been three categories of software to track (OS provided, third party managed, manually compiled/installed), and two different locations to put them (/usr, /usr/local. / is different and has/had other constrains and reasons behind usage).

OS provided packages go into /usr, stuff a user manually compiles and installs goes into /usr/local, but where does a third party package manager put stuff? It's not OS provided, but it is packages and maintained, so /usr seems valid. At the same time, it's user installed, so /usr/local seems valid. Both make the other used of those locations more complicated to reason about.

> Also, why is Python a developer tool, but Perl isn't? Or ZSH, for that matter? Does the distinction actually make any sense?

Possibly because some are used by the OS to actually do things for the OS (not sure if Apple finally got rid most those dependencies or not).

The problem of the OS shipping a component for it's own needs that gets used by others is a decades old problem at this point. It's complicated because if it's available users to use, they'll use it, and when the OS wants to update or change it in some way it can break user assumptions. If users update it system wide, they can break OS assumptions.

> but where does a third party package manager put stuff?

/opt

> The use of /opt for add-on software is a well-established practice in the UNIX community. The System V Application Binary Interface [AT&T 1990], based on the System V Interface Definition (Third Edition) and the Intel Binary Compatibility Standard v. 2 (iBCS2) provides for an /opt structure very similar to the one defined here.

* https://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/opt.htm...

MacPorts uses /opt/local for example.

Yes, that's where I would suggest putting it, but the reason projects don't is either because they aren't aware of it, feel it's a bit more convoluted to make sure you update where PATH is set, or that /opt is generally used for singular applications, not an extended hierarchy such as /opt/local (which is actually a truly weird name, /opt/macports/ with /opt/macports/bin, /opt/macports/lib, etc would make more sense). It makes sense to use /opt from an "application" point of view, but I think the problem is many of these package managers see themselves as more than that, and as pseudo-system components, which clouds their reasoning.

The LFS spec you linked to is actually ancient at version 0.65, the latest is 3.0 and available here[1]. It's a bit "do what you want", but it really expects the "local" part of /opt/local that MacPorts uses to be some sort of identifier for MacPorts.

That said, it's the Linux Filesystem Hierarchy, so it only applies to Apple stuff inasmuch as it's common practices for UNIXes in general. And it's not like the major Linux distros follow it fully either. They're happy to break from it where it preserves some historical layout their OS has had that they think is easier for their users/admins.

1: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html

The reason for zsh is simple enough: Terminal is a standard Mac app, and there are some system maintenance things an ordinary user might do which require the command line.

So there needs to be a shell, and that's zsh now.

Apple switched to zsh because they're allergic to later GNU licenses and the version of bash they were shipping was absurdly out of date.

Yes, that's the practical reason. But what's missing is a conceptual reason, something that makes it easy to remember what is and is not a developer tool.

Possible approaches that would be less confusing than what we have today:

1. Ship Python 3 with macOS.

2. Ship all of the command-line developer tools with macOS, including clang et al.

3. Bring back the Snow-Leopard-era /Developer folder, and put developer tools there.

4. Put developer tools in /usr/developer, or /usr/local/developer, or /usr/local/Apple, to balance both UNIXness and clarity.

5. Don't ship Python at all. The Python foundation already distributes a .pkg installer for Mac. If xCode needs Python, follow your own Human Interface Guidelines and put it in the Application bundle.

All of these approaches have downsides, but I still think they'd be clear improvements over the current situation. Which is to say, I want Apple to figure this out!

It isn't an allergy.

At the time the GPLv3 was written, the GPLv3 was deliberately crafted to put commercial companies into a conflict situation.

(A) Give up selling audio with DRM (DRM did go away) (A) Give up selling video with DRM (A) Give up using HDMI as an output port (A) Give up using digital signatures to secure the integrity of software

-OR-

(B) Give up using GPL v3 software, GCC, Bash

Pretty sure most customers actually want many of the things in (A) and a minority actually care about (B). The items in (B) can be post-installed by those that really want it. Sure those in (B) have a loud voice, but, HN, are they really representative (democratically a majority)?

How would you make the choice between (A) or (B)?

I would bet that if a subeoena for FSF/GNU email was issued there would be a lot of messages related to manipulation and coercion for licensing and re-licensing. The sort of stuff, when associated with companies turns into scandal, lawsuits and monopoly investigations. (GCC almost got to be what could be considered a monopoly compiler)

I do believe that open software has a place and is a really good choice. My opinion is that the GPLv3 is completely toxic, spawned from negativity and is ultimately anti-open source. I will never release any software under the GPLv3.

> Give up selling audio with DRM (DRM did go away) (A) Give up selling video with DRM (A) Give up using HDMI as an output port (A) Give up using digital signatures to secure the integrity of software.

Does GPLv3 really prevent an OS from doing those things? I think it would just prevent it in the same executable as GPLv3 software?

I don’t actually understand Apple’s “allergy”. On the iPhone I’m sure they object to the Tivoization clause (which coincidentally is why I like to use GPLv3), but I’m pretty darn sure macOS doesn’t fall afoul of anything...

Python 3 is required for the ability to install coremltools which makes it a developer tool.

Python 2.7 might be there because old software is there for compatibility reasons for software possibly for mathematical software that never really gets updated. Removing it in future versions makes sense because of the fact that if you haven't updated it won't work on ARM Macs.

The best way to make someone upgrade is to deprecate and then remove access. At minimum the worst case scenario is they roll their own and install Python 2.7.

python3 is a developer tool because it is the extension language for the lldb debugger. For example, I have python3 scripts for formatting my custom C++ data types, and that formatting also works in Xcode's visual debugger (which is presumably using the lldb API).

Previously, lldb's extension language was python2. This changed a release or two of Xcode ago. At that time, to use lldb scripts with that new release of Xcode you either had to run on Catalina (which added python3 to the existing python2) or install your own python3 and point lldb at that. This actually was what pushed me into moving to Catalina on my development system, because the Unicode handling would be much easier in python3.

As I understand it, Monterey and the Xcode that is released for it move the necessary python3 installation from the operating system itself to Xcode. I'm fine with that.

(I would not be fine with Apple telling me I have to go waste my time figuring out how to install a suitable python myself, when I never had to before. And indeed, many of their own developers may be like me and know a little Python but are in trepidation of the env thing.)

The way it was before meant that if they wanted to update python they had to release a new version of the operating system. This is clearly an imposition on the vast bulk of macOS users, who are not developers.

Nit: It’s not that /usr/bin/python3 gets replaced. It’s always a stub, but the stub execs the real python3 if found.

#!/usr/bin/python

How exactly is the above supposed to work when /usr/bin/python doesn't exist. If Apple chose to break the #! contract by doing something else, how would you feel about that?

The scripts should be using #!/usr/bin/env python

This answer is both a great answer, but also a terrible one.

This answer implies all "python" binaries across all operating systems and distributions for all time, are backwards and forwards compatible, no work needed. Guaranteed 100% equivalent.

What about Python2 v.s. Python3?

This isn't true and cannot ever be. This happens for other scripting and interpreted languages.

This approach means that the burden of choice and setup is transferred 100% to the person running the script. If you have 2 scripts that require different dependencies, then you will encounter this problem. I think it is this that encourages folks to include hard coded paths to enumerate explicit dependencies.

Lots of the "package" managers for these scripting languages also don't deal with this very well. They advocate a "do it my way" or "do it yourself". Different languages do it different ways.

Ultimately, the person wanting to run the script, just wants to make it run -- they will follow the instructions to make it work and along the way will make "global" changes -- which will impact what will happen for any other script in the future. This will likely be diverged from anyone else who has a "base install".

The above is mostly about my observations with using Ruby, not Python. However, few attempts in using pre-packaged complex python "recipes" has always resulted in similar conflicts.

> This answer implies all "python" binaries across all operating systems and distributions for all time, are backwards and forwards compatible, no work needed. Guaranteed 100% equivalent.

Practically speaking, how does using env versus the absolute path make this any better or worse? You as the script author don't know what version of Python/Ruby/Bash/etc lives in /usr/bin. Maybe you could do some kind of automagic detection based on the user's OS, but any such assumptions are likely to go stale over time.

All env does is give users a choice about where to put their binaries. The versioning situation is a real problem, but I don't think using env makes it better or worse.

Totally agree. I think anyone developing with these tools would too. It's not as annoying as say, RedHat, but out of date "system" versions are just obnoxious.

I don't know if any "native" apps have leveraged them, though. That would be the real risk of disruption.

Also, as someone who never uses PHP, I'd really rather not have it on my machine. Scripting languages are a pretty big attack surface, even if it's just to pivot after initial compromise. I'd rather not have one there that's not being used.

I'll also make the inflammatory statement that people should just use sed and awk in shell scripts and leave Perl for when they really want to write Perl.

It is weird to me the number of times 90's Linux Distros used Perl for things that are easy in awk, awk for things that are easy with cut, and other commands for things that are easy with POSIX shell baked-in facilities. I guess I'm just a shell snob.

cut usually doesn't do what you want it to do. Most of the time you want to split on sequences of whitespace (which may or may not be tabs, it's not easy to tell from the output of the program). cut doesn't let you do this, which is a shame, as it would've been a sensible default. It also does weird things like print out the whole row if there's no instance of the separator on the line.

So because you can't trust cut to do what you want, you'll probably reach for something like awk '{print $3}' instead.

Yeah, after I remembered that `cut` exists shortly before needing to grab some fields of an input, I thought "oh, I'll use `cut` instead of `awk`". And lo and behold, `cut` couldn't do the thing I wanted. Why learn two tools when one will do? The only reason I can think of is the principle of least privilege, but if you can convince me it applies, I'll convince you should write a single tool that adheres to it instead of using countless tools for any given transform/privilege pair.

I tend to start writing in bash/sed and going on to regret it as the script gets more involved and needs a refactor in perl.

Most of the time the script doesn't get more complicated and it's fine with cut/sed/wc etc, but at some point it tips the balance and I grumble to myself.

Perl was invented to replace the shortcomings of hacking together sed + awk + shell, eg. multi-dimensional arrays.

Only if the said script is less than a dozen lines

> since it's as much as Unix system utility like awk or sed as a programming language.

Even those tools suffer from Apple's lack of fucks given. I often have to replace included system commands with the homebrew equivalent because Apple's is missing some common functionality.

I wish Apple would just adopt homebrew as a firstparty package manager.

I'd plump for Macports or pkgsrc long before Homebrew.

Homebrew should first come up with basic functionality... like you know not assuming the OS will only have one user account ever. I was quite shocked when I found this out about the oh so amazing package manager.

Before someone shares some bizarre workaround: no thanks.

The last time I bothered with it, it complained about my use of `sudo` but wouldn't run unless I was logged in as admin - not a temporary bump, just logged in as an admin. Sudo isn't alright but running as admin is…? I really can't work that one out.

It also broke so I uninstalled it. When I need to I go straight to their formulas and install by hand, as a non-admin user.

The issue (in my experience) is that neither Homebrew nor Macports provide a "full fat" package management experience like pacman or even apt. Not only are they missing packages, they're missing features and are loaded with outdated builds. If Apple made a first-party package manager that didn't suck, I'd probably have a Mac on my desk today.

Homebrew is a piece of crap. There's no away to install specific versions of software (unless you dig through the git repo and install using a commit hash). It has a scorched earth policy of wiping out dependencies willy nilly. One time I installed Python 3.8 and it wiped out the version of openssl used with Python 3.7 I used for a client project.

You can actually `brew search python@` to see the available versions (major/minor only, not patch) and then `brew install python@3.7` to install an older version. Caveat is that this depends on someone having made a separate formula, under the correct versioned naming scheme, and uploaded it to homebrew. There doesn't seem to be a python2 formula, for example.

I think it's a difference in philosophy? Brew does a "good enough" job for the most common use case, supplementing Apple's janky *nix environment with commonly-needed tools, without a built-in package manager. It doesn't try to do complex simultaneous versions... in my (admittedly limited) experience, if you need to do that, you either do that in something like a project-based setup (npm/composer) or in a VM/container with its own packages.

In your situation, when you have multiple pythons running in the same environment, how does anyone given script know which one to call? What's a better way of doing this?

MacPorts did receive official resources from Apple for a long time. Then they stopped.

Apple did toss some ARM machines (DTKs I believe) to the Homebrew project.

You could use homebrew to install powershell.

I can’t tell if you’re joking or this is actually possible. Is it?

https://docs.microsoft.com/en-us/powershell/scripting/instal...

From the horse's mouth

You can also install it on Linux if you wish.

> for compatibility with legacy software.

The way it is written, it sounds like they are trying to hide the fact that said "legacy software" is part of the (new) system itself. Otherwise they wouldn't need to include it in the base install.

> Python, Ruby, and Perl

The order they use for the languages hides the fact that, at least for Catalina, Perl is by far the most used scripting language by core elements of macOS, even more than the shell. Check it by yourselves:

    file -b /{usr/,}{s,}bin/* |cut -d\  -f1,2|sort|uniq -c|sort -n|tail

     13 setuid Mach-O
     23 a /usr/sbin/dtrace
     50 a /usr/bin/perl5.28
     53 a /usr/bin/perl5.18
     81 POSIX shell
    116 Perl script
    954 Mach-O 64-bit

Conclusion: Apple is a Perl shop.

What they could do is use an internal, non-user-usable runtime for their own perl scripts and allow the user to install their own one.

And of course compile their scripts into executables or something.

That is actually truly unfortunate, I think. While I understand the issues with lagging versions of system-installed languages, I think there is a comfort and educational value in having them available as part of the system for anyone to access without having to go fetch it.

It "lowers the friction of curiosity".

(And, it allowed our shadow IT custom request system and automation package to be built in 2014. I hope RHEL never takes this away).

I'm inclined to agree with you. When teaching someone programming, there's something comforting about telling them they can just open up a command prompt and type "python" (or irb, perl, etc) and start programming.

I recently wrote a short Ruby program to help my not-computer-literate-at-all mother automate a task that would've taken hours and hours to do manually. She's barely comfortable using GUI programs, but because Ruby was already installed and I was able to give her clear directions she was able to run the program in Terminal.app without much trouble. It would've been frustrating as hell to remotely get her set up with homebrew (or whatever the new hotness is in package managers nowawadays), install the right version of Ruby, fix any $PATH shenanigans, etc.

(There was still some trickiness because her included version of Ruby was super old and couldn't install gems because it used an old version of SSL/TLS, but we were able to figure out a workaround)

That's good, too many package assume you have python installed in macos and go looking into the wrong folder.

Or default python2 breaking stuff that assume you have a recent install

Bummer about Perl, because a stint with a slower machine taught me just how slow Python is. My Lua scripts were often done faster than Python starts up—even though the scripts were doing file i/o. So, for anything like personal productivity scripting, Python is bad. However Lua requires managing the runtime and modules—and I was thinking about dusting off Perl, since it's pretty fast and is just always around like Sh while not being garbage at data structures and code organization.

Does this mean MacOS is finally going to get a real package manager?

Hear me out, everyone here is talking about web developers and people who write the language. That’s the least import demographic and most unaffected segment of the user base.

Dropping PHP is irritating because PHP is actually a really good shell scripting language and it’s universal availability on macOS made distributing simple CLI tools for Mac written in PHP as a simple script or a bundled PHAR easy as pie.

I have a decent number of macOS specific tools I distribute as PHP, many 10+ years old, and I can guarantee almost none of my users have any idea what PHP is let alone how to install it.

Counter argument: removing languages from OSX is good, because built in languages are the source of a lot of friction in development. The installed version necessarily lags behind what most developers want, and having a tool chain completely separate from whatever manager you’ve installed really sucks.

For end users, the interpreter can be bundled with the application, that is much more stable for everyone.

Python developers I know get their interpreter installed. This is vs people in college I know that are dabbling in Python or people starting with it on a professional setting.

I currently have over 5 different python versions installed to be able to test against them. The different software I work gets deployed to different environments and I have all those versions installed locally to test.

For end users, it doesn't matter as long as it works. The less moving pieces, the better. A bundled interpreter in the OS gives a stable platform to develop against.

The interpreter can be bundled with the application, of course. But now you have n different interpreters with their own php.ini files and their own set of things to change. Upgrading the application means overwriting those files and causing more pain when they have to figure out why something stopped working.

> I currently have over 5 different python versions installed to be able to test against them

That's absurd. Five versions of the same language. Each with their own package folders. That's at least 15 GB.

This is a luxury and consequence of infinite compute resources.

It's a reality of pragmatism when different projects target different versions of the interpreter and there's no guarantee that different versions are not breaking some behaviour.

... and if you're talking MacOS laptop and desktop ecosystem, it's a luxury you have and should take advantage of.

> That's absurd.

How come?

It's pretty practical. I'm a developer. I deploy to multiple targets so I have them all. I test against them. Simple enough.

To talk to the point of the link here, what I distribute to MacOS I only have to worry about 1 interpreter because it's the one embedded on the OS (and at work, I can guarantee the version). The problem for me is Linux and whatever is bundled on the version of the distro that's currently running.

> This is a luxury and consequence of infinite compute resources.

It's a consequence of what I deploy to. If I only had 1 target and could guarantee it, I'd only need one.

Newer programmers have accepted this as "normal". It only started becoming this much ridiculous cumulative upkeep in the past decade or so. It's lazy. Lazy on behalf of the Python maintainers. And you keep accepting it instead of pushing back. You could have only one version, but you've been brainwashed to think having 5 versions of python on your machine is normal.

I'm not dissing version releases, just the adoption and deprecation. I wrote DirectX drivers for years, and going from DX3 to 5 to 7 meant backwards compatibility, and it was a PITA, but releases came out every two years and were deprecated shortly after so we didn't have vast quantities of exponential regressions. OpenGL was rock solid by comparison. The former was trial-and-error by MSoft, the latter was well thought out by consortium.

> You could have only one version, but you've been brainwashed to think having 5 versions of python on your machine is normal.

Is the strict requirement of a single Python version really that much better?

From the cost of testing, absolutely. By definition 5 version is 5x more testing. But since most python code is just crap thrown onto githubs and stackoverflow, who cares if it is regressed. But for devs trying to write solid, long-lived code, their cost of testing skyrockets. Python's LTS plan is not strict enough, and releases too frequent. As exhibit A, I give you their attempt at deprecating python2.

Cost of testing is simple. Just launch the tests.

Regarding deprecating and moving away from Python 2, this has been discussed ad nauseam and the issues have been recognized around it. By the way, this wasn't a language issue, but an issue managing it.

Having said that, do you have any opinions or anything to discuss around the current plans?

Well, I'm one of the brainwashed zombies then, because I'm also running several versions of Python to comply with various dependencies of projects.

> Newer programmers have accepted this as "normal". It only started becoming this much ridiculous cumulative upkeep in the past decade or so.

Tell that to users of OpenSSL for the past two decades. Have fun when your dependencies use a different version. And yes, 0.9.7e is not compatible with 0.9.7g because semantic versioning be damned.

Sure, Microsoft...

And how many versions of .Net Express are there installed on computers?

I'm a developer, not a user.

I develop for multiple platforms and targets. Not just one OS and implementation. That's why I, as a developer, need many. A user doesn't.

I'm okay with API's breaking and think that it's good and that's why things get versioned out.

I've got 3 different Python versions installed with pyenv and they only take up about 900MB.

I have no idea on where the 15GB either comes from. I also use pyenv and pyenv-virtualenv and my ~/.pyenv is not close to that.

> A bundled interpreter in the OS gives a stable platform to develop.

But it wouldn't be stable. Or it would be, but it would be hopelessly out of date.

Apple can either keep the bundled interpreters on the same version forever, or they can update it with the OS. Do the former, and it becomes hopelessly out of date. Do the latter, and software updates randomly break stuff.

Either the language developers need to actually keep their languages stable, or everyone else just needs to get used to keeping multiple versions around.

>Or it would be, but it would be hopelessly out of date

I think you need to define "out of date".

Out of date for me means not receiving security updates and stale. I think you mean not the latest version and stable for me is better in a production environment.

Google example, look at Debian stable.

> I think you need to define "out of date".

Well, look at this way—the latest consumer version of macOS still comes with Python 2.

So...

    $ /usr/bin/python
    
    WARNING: Python 2.7 is not recommended.
    This version is included in macOS for compatibility with legacy software.
    Future versions of macOS will not include Python 2.7.
    Instead, it is recommended that you transition to using 'python3' from within Terminal.
    
    Python 2.7.16 (default, Dec 21 2020, 23:00:36)
    [GCC Apple LLVM 12.0.0 (clang-1200.0.30.4) [+internal-os, ptrauth-isa=sign+stri on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> exit()

but wait, also,

    $ /usr/bin/python3
    Python 3.8.2 (default, Apr  8 2021, 23:19:18)
    [Clang 12.0.5 (clang-1205.0.22.9)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> exit()

I think we should take the lines,

    >    This version is included in macOS for compatibility with legacy software.
    >    Future versions of macOS will not include Python 2.7.
    >    Instead, it is recommended that you transition to using 'python3' from within Terminal.

For exactly what it says. It's included for compatibility with legacy software and should be transitioned from it to another version... the other version that's bundled with it.

Nowadays, it's included for compatibility with legacy software. Initially, it was included for current software.

How do you stop the latter from becoming the former? When do you make the switch?

And remember, `/usr/bin/python3` wouldn't exist on your system (as more than a stub) if you hadn't installed the developer tools.

> For end users, it doesn't matter as long as it works.The less moving pieces, the better. A bundled interpreter in the OS gives a stable platform to develop against.

I can understand what you wish for. But what you wish for is very far from what we’ve had so far. Time to accept reality.

For end users the OS can be bundled with the application, that is much more stable for everyone.

Sarcasm doesn't make a poor point better.

Is it really sarcasm? I have often seen workstations pre-installed with an OS and some specific software sold as « bundle ». ie in medical domain, cnc, video…

Electron is wildly successful, it's not a poor point at all.

In the HN bubble, sure.

I bet I can find several users of Slack or Visual Studio Code who haven't even heard of HN.

Don't forget Spotify, WhatsApp desktop client, Skype, discord,

I think that's one place where it's divided and contended. People here are pretty vocal and critical of electron.

Yeah, I've used PHP for a decade and have always never used what comes with MacOS. Always installed a newer version.

    /usr/bin/php --version
    WARNING: PHP is not recommended
    PHP is included in macOS for compatibility with legacy software.
    Future versions of macOS will not include PHP.
    PHP 7.3.24-(to be removed in future macOS) (cli) (built: Dec 21 2020 21:33:25) ( NTS )
    Copyright (c) 1997-2018 The PHP Group
    Zend Engine v3.3.24, Copyright (c) 1998-2018 Zend Technologies

so, 7.4 or 8?

I'm still using 7.x due to limitations.

7.3. Played with version 8 on a Docker instance. Will wait.

That's 100% my take on this. If Apple leaves it in the build, then Apple ends up having to support it to some degree.

As long as it's trivial to install after purchase, the removal of this sort of thing is in no way concerning to me. When I've written things natively on my Mac, I've almost ALWAYS had to go get an updated version of perl / python / ruby / whatever to get current.

Especially considering that open-source projects provide this service for free. It blows my mind that Apple, The World's Most Valuable And Affluent Company, refuses to invest in a couple package maintainers for their "world class" operating system. If Apple ships it, they have an obligation to keep it up to date, especially since utilities like this pose serious security risks when left untouched.

Windows solves this for python by offering to install it from the app store the first time you use the command, and then keeps it updated.

Better solution: Apple stops treating MacOS like a toy and gives it a proper package manager. I'm tired of hearing people float workarounds for a problem that can be solved by just holding Apple accountable for once.

> problem that can be solved by just holding Apple accountable for once

good luck with that

Apple will do a package manager, once they work out how to bolt on an "app store" on it.

If those are the parameters, you can safely abandon hope now.

Easy, they will follow the trend of cargo install and make it available via Swift package manager.

'brew' works really well, no need for them to reinvent the wheel.

Really well is an overstatement. You shouldn't have to wait several hours to do a brew upgrade.

Do you have a package being built from source instead of bottle?

Brew upgrade takes less than ten minutes or so for me. Things that influence this will be the amount and size of your installed packages and whether they have prebuilt binaries ("bottles") or if you need to build them from source. The latter is on your package maintainers.

If there were no need to reinvent the wheel, there would be no brew. macports (and fink) predate brew. The wheel is in the eye of the beholder.

I use brew primarily only for packages that are only available on brew. I’m moving to nixpkgs for my packaging needs as soon as the M1 support drops.

Oh, Apple has a package manager - it's called the App Store. Opensource developers are just stingy and refusing to pay Apple $99 every year that Apple desperately needs to support it. /s

Or... Apple upgrades the scripting languages regularly? I mean, they make updates that that gigabytes without changing anything, and then it's a problem to update PHP that is a couple of Mb? I don't think so...

Sure, so what about those who are one or more versions behind?

I also remember having a lot of installation headaches when starting out as a developer because the preinstalled version conflicted with the version I was trying to install.

This seems like a net positive change to me and I hope they can keep dropping these built in languages.

Was this an issue with things preinstalled and trying to install your own or with trying to use your own after installing your own?

Wondering if it was really an issue with 2 interpreters or more of an issue with how the system works. More specifically PATH variables, shebangs and prioritizing your custom one over the system one.

Apple sells a couple hundred thousand computers that simply have to run a browser and show Facebook, for every one that has to have current PHP installed.

If you're developing anything and don't know how to configure your tools, I'm not sure what to say.

Do you understand the setup and configuration of every language of every tool you use? That seems impractical.

I use scripts written in Ruby reasonably often without _any_ understanding of how the Ruby ecosystem works. I just want to run the tool, and the tool happens to be written in Ruby.

PHP consists of an environment that can change the behavior of the program catastrophically just based on one configuration value (e.g. magic quotes). No one should be writing shell scripts using this language, especially if running on an uncontrolled machine.

Magic quotes were removed from PHP entirely back in v5.4… and we’re now on v8.

It’s just as valid a language for shell scripts as any other.

As indicated by “e.g.”, that was given as an example. There are countless other parameters that change the behavior of the language. If you’re deploying code that has to run on someone else’s computer without supervision, it shouldn’t be a shell script at all, this is why we have compiled languages.

> There are countless other parameters that change the behavior of the language.

I call bologna.

If you stick to built-in methods and avoid extensions, really the most breaking thing someone is going to do is turn off `allow_url_fopen` off, and you can either work around that or just complain to the user that you need it and `exit(1)`.

> If you’re deploying code that has to run on someone else’s computer without supervision, it shouldn’t be a shell script at all, this is why we have compiled languages.

This is the most frustrating comment in this thread, imho. The _ideal_ is all code being distributed as readable source. Binaries are at best a sad compromise in the name of performance.

Why would you _desire_ the code you run to be an impenitible black box? I'd far rather run a script I can see what I'm actually doing to my machine instead of a binary.

> the most breaking thing someone is going to do is turn `allow_url_fopen` off

See [1]. "If PHP was compiled with --disable-url-fopen-wrapper, it won’t work." ... "But it will be printed if scream.enabled is set in php.ini." ... "exactly where it goes depends on display_errors, again in php.ini." There's so much variability in what an arbitrary PHP interpreter might or might not have support for, especially from 10 years ago.

> I'd far rather run a script I can see what I'm actually doing to my machine instead of a binary.

Then why not ship the source, along with an interpreter binary to run it in isolation? This is one of Lua's main use cases.

> Binaries are at best a sad compromise in the name of performance.

I disagree with this at a fundamental level because of the fact that binaries are what can be used by a computer. Anything that runs, is ultimately a binary, even if parts of that binary are generated dynamically. By adding a dependency of the environment (system PHP), it adds a layer of magic and unknowns.

[1] https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

> If you’re deploying code that has to run on someone else’s computer without supervision, it shouldn’t be a shell script at all, this is why we have compiled languages.

Why? It's more complicated, you need to compile different version for different operating systems and different architectures, if you have to update something you have to recompile it and typically to recompile it you have to install a development environment, versus opening the script and editing it.

Fair enough, good points. Really what I should have said is that if you're running on an untrusted system, it should be in an isolated environment (sandbox, container, etc.) which would preclude using a shared system binary. Statically linking your own executable would be another way to satisfy that constraint.

Yes. "php.ini" is a pain to have for script language.

> php.ini has entered the chat

PHP as a scripting language has to be the least relevant reason for retaining it. How is PHP remotely comparable to Python, Perl or Ruby for scripting. Not saying you can't do it but there are better options.

> How is PHP remotely comparable to Python

Faster.

> Perl

More readable and writeable, and probably more popular in the past fifteen years.

> Ruby

Again faster.

I never thought those reasons would ever be valid until PHP 7.

PHP long had decent performance, since version 4 iirc when it borrowed the bytecode approach from Perl and afterwards afaik was pretty much on par with it. Remember that even with FastCGI the vastly prevailing model of execution for PHP is to start the script just from the bytecode cache every time and destroy everything when it ends. Long-living async apps like with ReactPHP never became any kind of popular, and still PHP is likely the most popular serverside environment on the web (if only because of Wordpress).

Perl and PHP are both likely way better for personal productivity scripting than Python or Ruby, in terms of not waiting for them to get going already. Personally I would like it very much if Lua became as popular, though the absence of proper `null` is bothersome for data exchange.

If you're going to compare Perl with Ruby make it Perl + Moose then redo your benchmarks. Otherwise it's an apples to oranges comparison as Ruby has built-in OOP. Ruby was built on top of the best bits of Perl and with its blocks and metaprogramming it is arguably the most advanced scripting language. Python fails to match Perl and Ruby due to its half-assed lambdas.

A correction: just checked startup time of PHP vs Perl on Mac, and Perl is a lot faster, so turns out it's not quite ‘on par’.

> More readable and writeable, and probably more popular in the past fifteen years.

You're confusing PHP's general popularity for web development with it's popularity as a command-line scripting language. There's no way PHP is more popular than Perl for non-web scripting. Unlike Perl, PHP was never designed as a general purpose language.

Try writing a PHP script which has to parse command line options. It ain't pretty. Python, Ruby and Perl were designed for this. PHP was not.

PHP is extremely fast for scripts written in raw, procedural PHP but its shared nothing design makes it a liability with large frameworks such as Laravel and Symfony. In many tech empower benchmarks Django and Rails are listed ahead of Laravel.

> Try writing a PHP script which has to parse command line options. It ain't pretty. Python, Ruby and Perl were designed for this. PHP was not.

Worked just fine at the job where we had a ton of serverside daemons. You're saying like splitting a few strings and putting them in a dict is black magic, and as if Python, Ruby and Perl don't use some libs for that, which (hopefully) evolved over some time.

> its shared nothing design makes it a liability with large frameworks such as Laravel and Symfony. In many tech empower benchmarks Django and Rails are listed ahead of Laravel.

A wild arbitrary goalpost appears! Even if Python is in any way comparable to PHP in ongoing execution (which I would like a lot but can't believe due to having some experience with that), we were talking about scripting, for which startup time with slim code matters, not ongoing performance with big frameworks. Cold startup time of Python is bad.

Checked now for good measure: turns out PHP 7 from MacOS isn't much faster than Python either from the system or from Brew, on a “Hello world”. However on a machine with a slow CPU PHP takes the lead; and especially PHP 8 is more than three times faster than Python. This vaguely contradicts my past experience on Linux, where I was never able to make Python as fast—maybe something iffy is going on specifically on Mac.

(However Perl does beat PHP by a lot, and even beats Lua on the slow machine—seems my latent hopes of using it for scripting were right, and I'll mourn its disappearance even more.)

Benchmark on Mac(or Windows) is hard.

You really have to know how it works to know what you're actually benchmarking, and if the numbers are even remotely related to what they would be on Linux. Unless the plan is to actually use in on Windows/Mac, ofc.

Option-parsing libs in Python, Ruby and Perl exist for a reason. There's more to it than "splitting a few strings and putting them in a dict" but if you don't know what you don't know stick with PHP.

> PHP is extremely fast for scripts written in raw, procedural PHP but its shared nothing design makes it a liability with large frameworks such as Laravel and Symfony. In many tech empower benchmarks Django and Rails are listed ahead of Laravel.

That's not a flaw of PHP, it's the only correct design for a largely stateless and request-based thing like a web page. The flaw is the second-system effect of people thinking they needed a "framework" instead of a library, and producing something that can't have reasonable performance.

I benchmarked Laravel, Django and Symfony a year ago in a rather minimal setup on all three. From what I can remember, Laravel was a good amount faster than Django, and Symfony a bit faster than Laravel.

Take this and a basically every other benchmark with a huge grain of salt as the frameworks have quite different functionality enabled/installed out of the box.

Faster? LOL! Need speed? Use a compiled language. I rarely see a tool written in, say, python slow for what it was written for. From a user point 5ms vs 9ms in irrelevant.

With PHP the speed should not be CPU related, but instead IO. PHP IO is HORRIBLE, and a default setup using framework <insert here> usually peaks around 300-600 req/sec which is almost laughable in 2021.

Not that it really matters, but for CPU stuff numpy is multitudes faster than a PHP counterpart. Pypy also usually is lots faster than PHP for a given task.

300-600 req/sec with a default setup? That seems a bit low, unless it's a very slow framework or machine. Most frameworks are slow, but not that slow. I think ~2K+ rps was what I got when I did a comparison last year.

But, PHP IO is slow? What do you mean by that? A lot of things in PHP is basically just a wrapper for C, and it's really fast.

I'm really interested in why you think IO is slow.

The way PHP is built (start and die) on each execution. Compared to anything else, thats "running" PHP needs to do more work on each startup. This is also why its impossible to build a websocket server in PHP (without hacks like reachphp).

this is one of the main reasons PHP IO (read req/res) is slow. You can search for benchmarks if you so choose, and a basic setup for PHP is usually in the 300-600 req/sec range.

Convert to go, distribute binaries instead :)

I totally believe you that PHP is a great general purpose scripting language to deploy mac CLI tools with, but this definitely feels like a https://xkcd.com/1172/ moment.

There is zero arguments for having PHP bundled as default with the OS. It always ends up being an old PHP version, crippled with bugs, and now apple has one more thing to worry about in the update release cycle.

If someone really wants to still keep on using PHP its just a brew install away.

Suggesting "just" brew install php as in original post is silly to me. You have to install homebrew first, which is a non-trivial task requiring root access.

It should be trivial to anyone needing it, and by extension anyone needing tools you usually install with homebrew. Unless this is the case you should not need PHP in the first place.

PHP is a pretty insane language though. I've started using Deno / Typescript for my scripting purposes and it is just a way way better experience than anything else I've used (and I have been searching for ages).

Pretty much every other option falls down in some way:

* Dart, Rust, Node etc. don't let you use just a single file like Python does.

* Python is very slow and it's type annotation system is better than nothing but is still the worst I have used.

* Everything except maybe Go requires you to list dependencies in a separate file, which rules out single-file scripts.

Deno is easily worth the installation effort, especially since it's so easy to install. You'd be really mad to stick with PHP.

Oh come on. PHP is not a good scripting language.

I get it, it sucks that PHP has been getting badmouthed every time it's mentioned but let's not overcorrect.

Should be fine since the MacOS preloaded versions are not what you want anyway, most of the time.

In PHP you really need to know what version you are working with, otherwise weird stuff happens.

Totally agree, almost everyone using PHP for their work will have installed their own or be using docker or homebrew

That's not a big deal. I imagine that the average OS user doesn't need Apache and PHP. People who do web development use Docker, because for any serious development you'd want your environment to match live one. And there's still an option to use brew or MacPorts to easily install all those programs.

I do web development without docker, and yes it matches the live one.

You're an endangered species. I find it pretty funny how so many developers jump through so many hoops to avoid developing on the OS that's actually running the application in production. Apparently wasting many gigabytes of RAM on unnecessary virtualization, suffering from extremely slow IO, and constantly bashing your head against file permissions/network configuration/whatever else is so much more productive.

(Please don't waste your time replying with "I can't use X because of Y". The world does not need any more of these anecdotes. We've heard it all. If you don't want to be a part of the change, downvote and move on.)

Nah, just an old dog that has seen the pendulum swing too many times, and has more to sell to employers and customers than CV driven development.

Docker is about 5 years time to become irrelevant, replaced by the next big thing(TM) in cloud deployments.

Is this sarcasm? That sounds more like an indictment of Docker or Vagrant than anything else.

With the right tooling and a good understanding of your tooling you can easily get away without docker or the like. Don't get me wrong, personally I avoid installing as much as possible and prefer containers, but it's not necessary if you have the knowledge, and the tooling. Especially with a scripted language like PHP that has most plugins bundled in most distributions.

> jump through so many hoops to avoid developing on the OS that's actually running the application in production.

lolwut? Most of us have been using homebrew longer than docker has been popular, often codebases older than that, too. If anything, it takes far more hoop jumping for the average user to run a full 1:1 VM on OSX.

Same. Homebrew on my Mac and self compiled on Gentoo.

I also maintain a WSL Ubuntu setup to provide support for our windows developers. I suppose WSL is a VM.

WSL 1 uses picoprocesses, an idea taken from Drawbridge project [0][1], so not quite the original POSIX personality from NT, whereas WSL 2 just runs Linux on Hyper-V as guest, with some additional drivers for interoperability with Windows.

[0] - httpss://channel9.msdn.com/Blogs/Seth-Juarez/Windows-Subsystem-for-Linux-Architectural-Overview

[1] - https://www.microsoft.com/en-us/research/project/drawbridge/

Wow, another Gentoo user!

One great thing about Gentoo is that you can have multiple versions of packages like PHP, so you can run legacy and the newest, at the same time, on the same system, without having to deal with docker.

How? Is it because you compile it yourself so it's easy to specify an alternative prefix? How easy is it to use the version you want? (e.g. working on two projects simultaneously - say fixing a bug on production while otherwise working on compatibility with the new version).

The compiled binaries have a suffix, and you are able to select which binary you want for the default. So, `php` is set to say, `php74` or `php8`.

The suffix also applies to the config files and init scripts.

As far as running two versions on the same webserver, you just have to set up the config for each version to be on different ports or sockets.

Also, to clarify a bit, this is all using the Gentoo package manager, so you do not have to manually compile the packages, or manually create the symlinks.

> The live one

I think this might be why there's a split, I use docker but I don't work on just the one site

I also don't work just in one site.

In fact, thanks to consulting across .NET, Java and C++, targeting mobile, desktop and Web, I have plenty of tools installed and configured for each project.

Fair, failed hypothesis there then.

How painful is that when you get a new computer?

Go through the respective installers, done.

One day downtime at most, thanks to IT images.

No need for super beefy hardware just to keep Docker happy.

I believe most macOS PHP developers use Homebrew. Some in combination with Laravel Valet for easy version switching and local domain management.

Docker is horribly slow on macOS. I'd wish that on no developer. We had to use docker for one project, but quickly decided to just run the tests in Docker and let the developers figure their environments out by themselves.

If you wonder why that is, it's because Docker for Mac actually runs the Docker engine inside a Linux virtual machine.

That means that whenever you call Docker, it has to copy your "context" to the virtual machine, then actually run the Docker invocation inside the VM. This gets slow and annoying very fast for even 10MB "contexts".

"Context" is anything in your working directory, more or less.

This is trivially worked around with volume mounts and properly configuring VM / container resources.

The overhead should be incredibly minimal.

It is a waste of time though. Just use Linux.

I don't think they can really use Linux on Apple hardware.

At least not as professional developers that don't want to fight the hardware, the OS <<and>> their development project.

So get a ThinkPad? Or a surface pro, or a Dell, or a Chromebook, or a system76?

I guess you missed the latest news about those devices with 20 hour battery life and the performance of a Intel device weighing twice as much :-)

I doubt anyone would need to work anywhere near 20 hours without being connected at all. The vast majority of people work on desks with plugs.

Hey, where are you going with that goalpost? Put that down again.

Probably not, but if your are doing some heavy work the battery will last significantly longer.

I don't know why doing development in Linux is a unpopular opinion.

I've been using Linux on my workstation and laptop for the past 20 odd years and I very much prefer it to the MacOS environment on the company issued Macbook.

> I don't know why doing development in Linux is a unpopular opinion.

It's not.

Doing development in Linux is not an unpopular opinion.

People who do develop in Linux telling everyone else to develop in Linux because not developing in Linux is Wrong and Bad, however, tends to be unpopular.

This continues to baffle me. I have an Apple laptop, I run macOS on my laptop, but I do all my development on a cloud VM.

I'm surprised to learn that there are developers out there, that have the cash for Apple hardware, but don't have the cash or connectivity to not run more than an IDE locally, with everything else happening remotely.

My devices (laptops, tablets) are all glorified thin clients as far as development work goes. The meat never happens locally.

Am I a rare case? Is there reasons why this isn't palatable to most people that I'm missing besides cost + connectivity? Are most people genuinely still not got the option of decent connectivity (either fixed or wireless or a combination of the two)?

> don't have the cash or connectivity to not run more than an IDE locally

It's not about lack of money. I prefer developing everything locally because it feels snappier to me, even with a good internet connection, or even a local server. It might not make a difference to you but that's what I prefer.

Agreed. I also like being able to know I can do some work even if disconnected, or traveling, or... just not needing to manage more external services.

Thanks for the responses, it's why I'm asking, as I genuinely don't get it.

I think my view stems from the days of having to re-install my windows workstation every 6-12 months in order to regain decent performance, so moving as much as I can to be on a 'different host' (usually a local linux server) to minimise the pain of backups/restores when rebuilding the workstation.

Cheers!

Developing in a cloud VM is painful in other regards, specifically with regards to IDEs. Basically your options become to use a local IDE, with slow access to your files (not fun when PHPStorm needs to re-index your vendor directory), or to use a cloud IDE (none of which I know of are particularly good for PHP, nor as snappy as running your IDE locally).

Of course, you can just use a text editor instead of an IDE, but once you get used to being able to jump to definitions, get method signature autocompletion, refactoring, syntax checks etc, it's kind of hard to go back to just a text editor.

I’ve found the best middle ground is to use a Mac and then mostly develop in a local VM. Snapshots/etc are wonderful, and they can be transferred from machine to machine, so “setting up my development environment” is as simple as “install Parallels.”

You definitely do not have to re-install Windows every 6-12 months for decent performance. Just don't install every doodad and hopefully don't have corporate IT pushing 10 management applications running in the background.

> I prefer developing everything locally because it feels snappier to me, even with a good internet connection…

oarsinsync’s IDE is sending each keystroke from his local computer to a cloud machine, where the source code lives. That source code compiles, executes, is tested in the cloud. Is this the setup you’re comparing with?

The theory behind this is sound: “When the size of the program is smaller than the data, move the program to the data.” In this particular instance, the code edit keystrokes are smaller than the total amount of source code. If the complete source code, packaged or compiled program has to be moved to the cloud anyway, it saves a lot of data transfer to just move the edits.

This assumes you’re running your application in the cloud, and the trade-off is that you need a reliable network connection, otherwise you might find yourself unable to edit when the network is down.

I use "cloud" as a catch-all that covers local and remote VMs, that are all built using standard templates. My local VMs are LAN-local, not host-local. My remote VMs are all <10ms away.

My particular workflow involves running my IDE locally, and having files hosted remotely. My IDE is plenty snappy, running my code is plenty snappy, but I'm slowed down by a need to commit + push changes to a repository.

I have it on my stack to do something like syncthing to keep a local + remote cache without needing to explicitly go through version control, but I suspect that'll just shift the latency out of my workflow, and trip me up in different ways.

You can just rsync local code to remote machine. All the benefits from local machine snappiness, without local compile hassles.

I believe when latency is a concern then the calculous skews much more in the direction of providing feedback locally based on the data. For instance a reasonable strategy could be to make updates to the file locally in the ide in order to provide immediate feedback as the user types, but then send those updates to the server where other higher latency features such as code completion or diagnostics are run. Sadly I have yet to see such a setup.

Interesting point. That would be a cool setup!

Since you didn't list anything specifically, what do you find beneficial about developing on a cloud VM? And what is your setup?

I do my dev locally. It's so much faster and I have a dynamic IP so the work of setting up a private VPN or resetting the firewall every day would drive me mad. I've been thinking about setting something up so I can do dev work outside during the nice weather on a highly portable but underpowered laptop, but so far my un willingness to go through the effort of setting it up exceeds my desire to have it set up. (In the past I've handled this quite fine with a powerful laptop. But right now my powerful laptop has zero nanoseconds battery power and the idea of discarding an otherwise working laptop bothers me on environmental grounds. It's approaching it's fourth year of life, but I can't find anything that obviously exceeds its specs.)

It also means I just don't have to worry about things when the internet goes down. Back in the olden days of working in an office (at a company where most people took the work at home option), I can remember how often the other staff would ask me "is the internet down" and my answer would be "I don't know, let me check". My home internet connection only seems to go down for the moment the the IP changes, but office internet connections seem to be subject to IT staff that need to constant change something, upgrades, who knows what the excuse is today.

However, I do my "local" work on a virtual machine or a docker container. I use GNU/Linux as the dev OS and as the test/production OS, but that's because I'm using what I'm comfortable with - there's no technical reason I should do it. My co workers have been quite productive using MacOS and Windows. This probably depends on your language environment: if you're using a JetBrains ide for your inspections, I think it's not hard to be OS agnostic. But when I've used LSP servers, they've typically expected to run locally, and similarity helps.

FreeBSD once had Docker working through the Linux compatibility layer. No virtualisation. I always thought would have been really cool to see that ported to macOS.

That depends a lot on weather the freeBSD compatiblity layer is kernel or user space as MacOS contrary to common space does not use an freeBSD derived kernel but one derived from the CMU mach64 project, and yes i know jobs said otherwise but he was never a trustworthy source for anything.

I think macos actually uses an different binary executable format then the elf64 one shared between linux and freebsd, so the kind of binary level compatiblity that linux and freebsd share might not be shared between macos and freebsd.

Another common slow down is bind mounts. Each file system operation is an RPC request between Docker for Mac and the Linux VM.

I’ve never been super happy with Docker for Mac. I did a pretty deep dive into figuring out why it’s so slow with no satisfying conclusion: https://stackoverflow.com/q/58277794/30900

This is also true for Windows. WSL2 made containers faster, but FS is painfully slow. Sounds like the best thing (apart from switching) is running Linux in a VM (Hyper-V does OK) and having IDE, Docker and all the data in there.

> WSL2 made containers faster, but FS is painfully slow.

If you keep your code base in WSL 2's file system it's really really fast. Even thousands of tiny asset files will get picked up and compiled through multiple Webpack loaders in ~100ms on 5+ year old hardware.

What I really had an issue with was the timespan between modifying a file in an editor (running in Windows) and the change being actually present in the container. I had to restart tests way too often because the old code was executing, which was really annonying, as sometimes you can't really tell if it failed because of the old code, or because the implementation was wrong.

The problem here is the delay between Windows and WSL2, once the files are in WSL2, it's fine.

I may give it another chance, though. Thank you.

> If you wonder why that is, it's because Docker for Mac actually runs the Docker engine inside a Linux virtual machine.

True of Windows too.

Doesnt more recent Docker versions use HyperKit?

Correct but it’s still a virtual machine.

I think I see your point, so it's not like the old explicit Boot2Docker mechanism but you are not running containers natively, right?

It’s not like Docker on Linux, where there are cgroups and everything just zooms along.

Not when using Windows containers.

Another problem is that bind mounts are slow; we put data into volumes if it's accessed often.

It used to be very slow, but I think they fixed it for the most part some months ago.

It is certainly no longer a problem for my dev work since a certain docker version upgrade.

Use :delegated in the volume mount to speed stuff up.

Alternatively, if you are running Docker Compose, you can use two mounts and a volume. I'm assuming your application is a standard Symfony/Composer application, checked out in $HOME/Projects/foo:

1) $HOME/Project:/var/www

2) some-volume:/var/www/vendor

Then, once the containers are created, run composer install inside the container, and then either run it again on the host or copy the files over using docker cp so that your IDE picks up the dependencies.

For more complex stuff such as Drupal where you also have to account for web/modules/contrib, web/themes/contrib and the likes, you'll need to do the volume trick once again for each Composer-installed folder.

The result will be that the tens of thousands of files that Composer installs and each request requires will be inside the Linux VM without any performance impact, whereas the dynamic files you are using for development will be instantly available in the VM.

Long term I'd really wish if Docker for Mac/Windows could use inotify, on-demand synchronization plus a boatload of caching to get the performance issues under control. Oh, and while we're at it, it really really sucks that "host.docker.internal" is only available on Macs - you need that one to get xdebug to connect back to the "host", so you need two separate Docker Compose files, one for Mac developers and one for Linux developers.

Sigh.

The fact that Docker runs in Hyperkit/virtualization is not really the culprit for the slowness. That makes it a bit slower than native docker but virtualization is pretty good these days. The real problem is filesystem access. If you keep your volumes inside docker, it's pretty fast. Alternatively, you can try using NFS:

https://www.jeffgeerling.com/blog/2020/revisiting-docker-mac...

> for any serious development you'd want your environment to match live one

Not sure what you mean by "serious", but I get paid for doing webdev (Rails) on an ARM Mac and we deploy to x86 Linux boxes and our only environment is Gemfile.lock, yarn.lock and roughly the same DB version. I don't remember ever having problems with that.

Package-manager solutions tend to have a similar effect.

The "non-serious" sort of development mentioned was more where you'd be dealing with a large number of tools without any builder-tool to ensure uniform versioning.

I got paid for years doing webdev before I achieved anything that I would think of now as "serious development". I'm sure I'll look back in another 5 years and think the same about my current self.

I'm not meaning to say that you yourself are not a serious developer, nor that webdev is not "serious development", but if you do this long enough you will encounter a problem that happens in production that can't be reproduced in your dev environment.

Yes, it's a good idea to have your development environment mimic production as closely as is practical, even if it's not something that you currently practice.

My objection to that is that in the long run it will make the source code less portable and thus limit my options and also may increase the risk when doing future upgrades.

I prefer if my team develops on different operating systems or Linux distributions and point realeses, not only for early catching of weird behavior but also usually this will in the long run eliminate any environment assumptions in the source code and thus create a cleaner code base.

If it is necessary to replicate an exact production behavior I have staging for that.

>I got paid for years doing webdev before I achieved anything that I would think of now as "serious development". I'm sure I'll look back in another 5 years and think the same about my current self.

Maybe your definition of "serious development" is whatever is around your current level instead of something objective?

I'm not sure that there's such a thing as an objective definition of "serious development", and my response clearly puts a spotlight on the subjectivity of the term, does it not?

Better get ready to have M1 Servers if you want a development environment to mimic production as closely as is practical.

Not true at all. You can do serious development using a virtual environment in Python.

Using Docker during development is not required and in fact not always ideal.

But then if you are doing serious development, you should also be comfortable with Homebrew. Being a Ruby developer myself, I never used the bundled interpreter! This news is not that relevant. Obviously these runtimes are included because some packages or libraries need them, but I'd not depend on them for development.

Correct, Homebrew should be a breeze to a serious developer.

"People who do web development use Docker"

A patently false generalization.

There are many reasons to avoid using Docker, besides the fact that it is a dumpster fire managed by a failing company.

The new M1 macbooks couldn't even run Docker, which was enough to get the last holdouts of my dev team to switch to just properly managing their local environments.

Docker can be useful, but more often than not it is a crutch used to make up for the fact that many web developers don't really know how to properly manage their machines.

> The new M1 macbooks couldn't even run Docker

Docker has worked on M1 Macs since... mid-December of last year. Less than a month after they were released? Why was anyone on your "dev team" using M1 Macs within weeks of launch? At that point, even installing things with Homebrew required compiling everything from scratch. Not a very great use of developer time.

> more often than not it is a crutch used to make up for the fact that many web developers don't really know how to properly manage their machines.

This is like saying that an electric starter is a crutch, and Real Drivers relish the opportunity to spend 20 minutes using a crank starter to "properly" start their car's engine every time they need to go somewhere. No thanks. Like using a crank starter, managing a bespoke local environment is not some incredible skillset, even though you seem to be giving yourself a nice pat on the back for it. It's simply a questionable use of developer time, and doubly so if all of your production environments aren't identical.

Why is "dev team" in quotes? Seems like an odd thing to get pedantic about.

We have a BYOD policy, and several members of my team opted to get the new M1. They were junior devs who didn't know better not be early adopters. I agree that it was a huge waste of time, and Docker was a major contributor to that.

Your analogy about starters doesn't really make sense. We aren't the driver, we are the mechanic, and we should know how the engine works in its entirety. Managing a local environment is a skill set, and frankly it is a skill set that many developers lack.

You can keep using docker if you want, I don't really give a shit. Its dead end tech that will be replaced in a few years by some new startup, while the *NIX systems using it will still be there and the developers reliant on docker will have to learn a new ephemeral skill set.

Why are you assuming devs who use Docker don't know how to manage a pretty simple LAMP setup?

It's easy, docker is a bit easier if you have multiple environments to deal with. If docker is gone in the next few years (lol) then we'll use the next one if it's easier too.

> We aren't the driver, we are the mechanic, and we should know how the engine works in its entirety.

I do agree with this though, which is why I once built a server from scratch (as in physical parts) and put a website on it to find what I was lacking in "full stack"* -> installed the OS -> install and configure nginx, php, mysql, mail, sftp, bit of Zabbix to monitor the whole thing -> built a website to go on it -> made it live. Just for a laugh. At the time the only trouble I had was CSS :)

But aye, no skillset if docker dies haha

* Which later turns out doesn't include any of the build/install/OS/monitoring apparently. Full stack my arse.

Yeah I do use PHP but I'd rather put things on myself than have a bunch of preinstalled stuff potentially needing security updates

Also considering Mac's still on like bash v0.0.4 or something I'd rather be able to install the latest version of stuff as and when I need it (or use docker anyway making the whole thing moot as you say)

off topic: WHY does mac's `rm` not support the -rf flag being at the end of the command dammit. I don't trust myself putting it up front haha

> People who do web development use Docker

This kind of HN elitism bothers me. PHP built its reputation on quick 'n dirty hacks which were easy to deploy on cheap hosting not by aping the infrastructure of some tech giant with fleets of servers, which is what Docker was originally designed for. The average PHP dev relying on the version which comes with the OS is most certainly not using Docker. Most home broadband upload speeds make Docker a non-starter.

I love PHP but this makes good sense. Better to install it afterwards and get the package/version you want. Reduce footprint of OS.

Yep, macOS is not an all-batteries-included Linux distribution. It doesn't need to ship with any programming language runtime that isn't strictly necessary for the OS itself to work.

Windows doesn't come with PHP, Python, or Ruby preinstalled, either.

In fact windows made a big effort to remove all the unnecessary components (IIS, etc) to reduce the average attack surface, and offer them as additional features instead.

Thankfully Candy Crush made the cut! /s

Yep. And for that matter, why does a Linux distribution need them, either?

In the age of CD-ROMs shipped with magazines, sure including a 'blessed' version of most programming languages made sense. Saved the average Linux geek from needing to hunt down a separate (physical!) package for PHP or whatever.

Now, the same reasoning applies to Linux as to MacOS. Unless the OS itself relies on them (Perl?), including some random version of various PLs makes as much sense as including a bunch of shareware games.

Including programming languages makes it easier for kids and other beginners to get started programming.

Removing general-purpose languages from operating systems makes a certain kind of sense, but it also pushes further in the direction of computers being devices for consumption, not creation.

Most Linux distros don't come preinstalled with PHP, Ruby, or node, either. You have to install it using the package manager, and you can use the exact same package manager to pull down different versions from different repos.

Honestly I wouldn't mind if some distros ditched the "blessed" version altogether for non-system languages. I can't remember the last time I used the default PHP in CentOS, it's always grossly outdated. But distros like Debian have a policy of packaging any open-source program they can get their hands on and keeping them up to date, at least when it comes to security fixes. It's their choice if they want to provide that service to their users, and many users like it.

I regularly set up servers using the stable PHP packages. If you sell a setup to a client then you want to provide an "expiry date" for the setup when the OS goes EOL. Stable packages kept up to date with nothing but security patches makes sure whatever you set up will run for X years without you having to worry about features being deprecated.

There's no need to have those versions pre-instaled though. As long as they can be installed with apt/yum then those who need them can install them.

One reason is that so many packages depend on them. Python and Perl is big in Fedora-based systems, for example.

But even for the non-critical software, packaged WP needs PHP, packaged Vagrant needs Ruby etc.

As for enterprise Linux, many customers relies on this packages, because they get reviewed and gets security patches on system updates.

MacOS shipping with ruby/python etc allowed rich development tools like TextMate which became the template for modern text editors going forward to exist.

But I guess MacOS is more of a frontend for Electron apps now so it's less important when the logic is to just bundle everything needed in 1GB+ executables.

I was with you until that last sentence "Reduce footprint of OS" ... if you've seen the updates from macOS recently then a small footprint is not on their table (at all).

Probably even more reason they wanted to remove it along with the other scripting languages. All of which are better suited to be installed by the user to get the correct version they need.

Might be different departments working in different directions :)

Tragically this means the photo of my elePHPant plush will no longer be installed on all new Macs, nor be prevented from being uninstalled by System Integrity Protection.

(I'm not joking. PHP contains some very small PNG logos displayed in phpinfo(), one of which is an Easter egg that only appears on certain dates.)

EDIT: Ah, the Easter egg logo was changed with PHP 8. Well, some other elePHPant gets to be sad instead. :p

This is the prompt I got running php in macOS11:

  $ php --version
  WARNING: PHP is not recommended
  PHP is included in macOS for compatibility with legacy software.
  Future versions of macOS will not include PHP.
  PHP 7.3.24-(to be removed in future macOS) (cli) ( NTS )
  Copyright (c) 1997-2018 The PHP Group
  Zend Engine v3.3.24, Copyright (c) 1998-2018 Zend Technologies

PHP is not recommended... wait, what? I can somehow understand the lowercase version / command, as in - we're phasing it out. Get it somewhere else. But giving the thumbs down to one of the most popular web dev languages out there is - I'm at a loss for words really.

It's just a generic "this is deprecated and will be removed, don't rely on it" message, not a comment on the language...

But it is in such case a strong confirmation about how people are losing conscience of language (not a good thing to sacrifice, in terms of priority - it is very related to thought pollution), and awareness in general, and awareness, attention and quality as values. A progress towards "shallow as a new normal".

I reference that in my post: lowercase “php” would refer to the command. Uppercase “PHP” to the language.

Looks like the same is said for Python, Ruby, Perl and all other scripting languages on MacOS too.

Apparently Apple prefers compiled binary for everything.

Am not complaining. The included Apache/MySQL servers were too old and I had to install those anew. But that always collided with the stock installed one.

It's good that Apple getting rid of those. Install what you need afresh.

Or they just don't want to maintain/update those components because there are much better and up-to-date ways to install them.

> Looks like the same is said for Python, Ruby, Perl and all other scripting languages on MacOS too.

I just ran a version check on Python (2 and 3), Ruby, and Perl, and none of them said anything to the tune of "will be removed soon". (MacOS 11)

There's a different comment here in this discussion from someone else that quotes the relevant text. Check that. Running the commands won't. But said elsewhere.

>Apparently Apple prefers compiled binary for everything

If you're an Apple exec it's hard to ignore that iOS succeeded fine with just bundling everything into self contained apps. They definitely see this is as the future and the old model as the past.

It's not the best way to phrase it.

> WARNING: PHP is not recommended

haha, I know it is a generic warning, but that is pure gold :D

Like gold? This is where the rainbow leads to: https://www.reddit.com/r/lolphp

I love that "I don't like this thing so I'm going to surround myself with it" subreddits exist

People are weird.

I had many blasts reading posts in that sub.

PHP 7.3.24 was released just two weeks before macOS 11's general availability.

If their policy is to freeze whatever version they could get their hands on at release time and ignore security fixes afterward, I would say good riddance. Third-party repos would do a much better job.

I am teaching a web-development course with PHP at university. Since PHP was preinstalled on MacOS in a ancient version, it was extremly hard for freshmen to get their mac prepared for the exercices. Windows users had a very simple start, basically just downloading and extracting a zip file from php.net... This seems to be good news for me, however most students have older macs so this will propably take some time to take effect...

Why couldn't they just install a newer version of PHP though?

On MacOS most of the files that makeup the system are now write protected (not just the file permissions, but something called "System Integrity Protection" or SIP). So you can't overwrite them. You can add a new install, but then you have to know how to change your $PATH to view that location first. That is just one more thing you have to know.

Apple did start to have a binary in the default location that was really a chooser that would respect per-user settings and re-direct you (exec) to the "right" install, but they seemed to have backed off on that.

But that's normal. On any OS you shouldn't be replacing OS files and instead you should be prepending to PATH.

Why are universities still teaching PHP? Is this a “programming” class or a specifically a PHP class that they offer for people who want to learn that particular language?

Why do you believe that PHP isn’t worth learning?

Please don’t frame your personal opinions as assumption-laden questions. If you think PHP isn’t worth it, then say that directly and openly. Framing your belief as a loaded question is not conducive to good discussion.

PHP was the back-end language for my 'web development' classes.

What language would you pick for that?

As a self taught, PHP was much more friendly to start with than anything else. Ruby and Python are close and would be better except that underestimates the learning hurdle with OOP and learning about libraries, etc.

Why are there still trolls on the internet?

Simple answer: https://w3techs.com/technologies/overview/programming_langua...

‘brew install php’ works across most ages of Macs and provides consistent paths for config files across deploymentd, in case that’s useful.

The real tragedy is that Apple hasn't taken over and bundled brew with the OS (or come up with their own blessed CLI package manager).

If Apple doesn't want to be in the business of keeping Python up to date, I can't possibly imagine them wanting to be in the business of keeping one thousand Pythons up to date.

MacPorts, which is older than Homebrew and better designed, used to be an Apple project.

That also requires installation of Homebrew. Not like it's the end of the world or anything but it's still another step to go through for someone that's just starting out in webdev. Back in the day I remember all-in-one LAMP stack apps for Windows that made it very, very simple to get going (and if I recall didn't require admin permissions either).

In my experience, Homebrew is usually the simplest route and should be the first choice for people just starting out. It's one simple "extra" step at the beginning that saves you from multiple, more complex steps later on.

It sure does, and that's certainly a drawback versus a solution that's preinstalled — but if someone is going to become a webdev on a Mac, they will be unable to depend on preinstalled scripting languages and so any manner of instruction that requires a working go/node/python/ruby/perl installation will be forced to either use Homebrew or to handcraft replacements for Homebrew.

I would consider teaching students the skeletal basics of Homebrew to be a valuable pillar of their ability to perform webdev workplace duties using a Mac.

I would consider teaching students the deep details of trying to build their own python and ruby on Mac to not be a valuable pillar of their ability to perform webdev workplace duties using a Mac.

So I don't see how there's any alternative to Homebrew, not if they want to prepare their students for today's reality. "Use what's preinstalled with a Mac" is no longer a viable solution, and in my best judgement Homebrew is the minimum work necessary to get them from zero to ready. If there are alternatives that are as simple as Homebrew to have students deploy and maintain as a teacher, we'd all love to learn more about them.

This causes so many issues if you have installed php already... Stackoverflow is full of problems...

Good thing it's being removed in three months, then :)

I don't even understand why they included PHP in macOS to begin with. Perl? Python? I can understand, they are used by millions of projects and tools. But PHP? I've never seen a single CLI tool written in PHP, except the Phoronix Test Suite.

Well, don't forget macOS also used to include Apache.

It still does.

  % httpd -v       
  Server version: Apache/2.4.46 (Unix)
  Server built:   May 22 2021 02:05:58

on macOS 12 beta.

On MacOS (when it was still capitalized), "I can program for the web from day 1 on Mac, cool!" probably made sense 20 years ago.

I mean, it was far better than on Windows where you need to install some bundled package from a third party to just get hello-world running.

i use PHP CLI tools all the time, they exist. composer as an example.

Composer is a dependency manager for PHP, so it doesn't really count.

Sure, if you want to pick and choose what to count. Regardless, there are many, saying there are not just shows you aren’t a php dev.

This makes it sound like it's personal against PHP, but really apple removing these baked in languages is a great thing. I've run into so many problems with the builtin python install, especially with SIP. Not so much fixing my machine (I always use a venv), but other peoples. This is just fixing a bad mistake.

I consider this a decent workaround:

  alias php='docker run --rm -ti php:pick-your-version'

I write a fair amount of PHP on Linux and I haven't had php actually installed for years.

Yes back in the day whenever I used php it never had all the modules I wanted.

Not a big miss.

Brew install php

I guess this is a more niche version of tabs vs spaces, vi vs emacs, etc, but I’m surprised that HN (maybe the dev community in general?) mentions and seems to favor homebrew so much over Macports.

I’ve always used the latter, seldom had any problem with it, and found the community great when I did. I prefer it because it installs everything related to it in its own directory totally separate from the default OS, in one place. I find that more organized. There’s been times where there was no homebrew equivalent for a macports package. Also I remember hearing (if I’m not mistaken) that macports was used more internally at Apple(?)

In any case I’m surprised it’s not more 50/50. It seems more like 95% of macos package manager mentions are homebrew.

MacPorts got a lot of contributions from Apple people over the years, but I would be surprised if it was more popular even inside Apple these days.

> I’m surprised that HN (maybe the dev community in general?) mentions and seems to favor homebrew so much over Macports.

I'm surprised that you're surprised. I use Macports but almost everything I encounter gives Homebrew install instructions up front (Macports is rarely mentioned, even if there is a port available).

Additionally, I find that while the docs for advanced Homebrew use are poor, they do at least have the basic everyday usage well-documented up-front. Macports approach of providing long, detailed & comprehensive contributor-oriented API docs and almost nothing simple & accessible for daily users makes it really intimidating for new users trialling it.

Won't homebrew be need to be re-written in a compiled language now and embed a ruby interpreter after Apple removes scripting languages (except Perl) ?

Then people can go back to Fink, which existed before Homebrew (and MacPorts) and actually worked better. Literally the only reason people moved to Homebrew is that a bunch of Ruby on Rails developers bought Macs and Homebrew was written in Ruby while Fink was Perl scripts over dpkg.

I’m more surprised than you are. Nix is rarely mentioned at all, despite being better in most ways.

I looked on MacPorts for some of the software I use, but none of it is not available there. Does it only have packages for open-source, command line applications? If so, it's not going to compete with Homebrew.

I always liked that macOS gave you a version of these scripting runtimes. Not a great one, not the latest one, but one. Being able to run a quick Python script without installing things on someone else's computer was always convenient. It'll be sad to see these all go.

I use Python scripts every day, dozens of times a day, on Mac OS. I’d still prefer not to have Python integrated. Having multiple random versions floating around on the system (v2 plus a random v3 if you have Xcode installed) has been way more of a headache than it’s be worth.

I would much rather just have Mac OS come without Python and set up pyenv myself.

As someone who works with PHP on Mac OS, the installed version was nothing more than annoyance you have to deal with if you're using the actual runtime. Otherwise, used Docker and ignored it.

See, this is kind of the opposite situation, because you can bother to install a good Python that suits your needs. I’d just like a Python for the times I am at my mom’s computer and need to write a quick script, and I don’t want to install anything just for that. For conflicts: I wish Apple let you uninstall the “system” versions. But I still would like to keep them.

Wow! Today I discovered PHP was lurking in MacOS the whole time.

What was it used for? CUPS? something else?

Built in web sharing

It was used for Web Sharing, actually disabled since Mountain Lion edition, https://www.cnet.com/how-to/how-to-enable-web-sharing-in-os-...

And httpd.

I used it as a quick html server as an alternative to the Python “simple” ones, which always had some issues for me.

Useful when coding small demos:

  php -S localhost:8000

python -m SimpleHTTPServer 8080

That’s Python 2. In Python 3 it’s

    python -m http.server 8000

On MacOS, it seems that python 2 is still the default so the right command is :

python3 -m http.server 8000

It's strange that this comment chain is trying to teach agys about how to use SimpleHTTPServer when their comment says they tried it and it didn't work for them.

Thanks :)

Both Python (v2 and v3) servers work more or less but they have an issue: the first page load takes about 30 seconds on my machine, usually. I never figured out why exactly and that’s why I started using the PHP server.

Big list of http static server one-liners: https://gist.github.com/willurd/5720255

As a full stack developer who works on tons of PHP and Laravel projects…I don’t care. It’s the 3rd thing I install on every new machine: Firefox, Homebrew, then latest version of PHP. This will have an effect on developers who create tools that rely on PHP but I’m not sure how big of a market that I’m really is so ok.

Good. The installed version just gets in the way if you're a PHP developer.

No one should use system PHP anyway on macOS, It is an old and insecure version.

I would recommend installing PHP via brew https://github.com/shivammathur/homebrew-php

What does this version have over https://github.com/Homebrew/homebrew-core/blob/master/Formul...?

Exactly same as core tap for currently supported PHP versions i.e. 7.3 to 8.0. Builds with security patches backported for PHP 5.6 to 7.2.

I never really understood why Apple included php, ruby, and python (and others?) on Macs. Mac was never advertised as a "batteries included dev environment" nor were any core applications relying on those languages (minus python, at least from what I understood). So why include it instead of asking the developer or engineers to bundle/install it?

I know Linux often relies on python and perl scripts, so it makes sense to include them in the base system. But there's no reason to include them in the base system if they're not used.

You pretty much don’t want third-party apis/tools/apps bundled with an OS.

It may seem convenient at first, but:

- updates are subject to the release schedule and priorities of the OS — which are unlikely to match yours are all your apps. - when you end up going your own way anyway, you have to fight the OS over how to manage tools that it’s also trying to manage.

Whether it’s PHP, Vulkan, or whatever, you do not want it strictly tied to the OS.

Can we remove all of the BSD subsystem and replace it with busybox please? Way less surface area for vulnerabilities and it’s more likely to be up-to-date if there’s only one binary which needs updating.

busybox is not an option because of the GPLv3. http://landley.net/toybox/about.html might be one.

Man what a drag, it's a real bummer a multi billion dollar cooperation can't just rip off open source projects.

They do contribute quite a bit to OSS.

GPL has a lot of other considerations when mixed with proprietary code however which makes it a very unpragmatic choice for commercial software companies who may be bound by multiple licenses.

Ah, yep. You win. licensing is definitely the reason.

Guess it’s time to re-implement busybox in Rust with a non-viral license!

(sorry, I misremembered. busybox is actually under the GPLv2)

That’s excellent news. The included scripting languages in macOS have always been a nuisance to deal with.

I agree that they keep something like python2 around for scripting, but that’s about it. Having to get around the included languages is a bitch every time I’m trying to set up a development environment.

Echoing others here, I honestly prefer this than dealing with outdated defaults built into the OS. More often than not they just get in the way.

The real bummer is for newcomers. It's going to make getting started much more of a headache since they first need to learn how to setup a local environment.

if you need it, you can install it.

this, to me, is a non-issue. I certainly don't need my desktop system to ship a php binary when the language itself is a fast moving target these days.

You know what I'd rather Apple do? Ship proper control group and namespace support within XNU so it can be containerized. People have been asking for this for a while:

https://unix.stackexchange.com/questions/113471/cgroups-anal...

Are you sure this is not already provided by launchd?

I really don't know but I see you alluding to this six months ago:

https://news.ycombinator.com/item?id=25447490

I’m hoping if I ask enough someone will figure it out for me.

I’m a little surprised to see the resistance against this. I remember wishing it wasn’t bundled with the OS a decade ago. I used the languages, but never the version that came with the OS.

Apple dropped Samba and wrote their own SMB client due to their fear of GPL v3.

Do they still use CUPS for printing ???.

Given that Apple have owned CUPS for close to 15 years, yes they still use CUPS. The author left Apple in 2019 and now maintains a fork.

I think that this is fine because if you need it you can easily install it with brew.

Didn't know about it. I either used Laravel or MAMP.

I used PHP for many years and products. But currently I hold the opinion that Python-Flask is more powerful for server-side operations.

How easy is it to transition to Python/Flask from PHP for someone with limited experience in Python?

I found that the learning curve is pretty much same. I struggled the most with setting up the wsgi file. But online documentation is really good because many people are using it.

I wonder if they'll remove wish. I always thought it was really cool that you could just sit down at any mac and hack out a quick app prototype in vim/wish without installing anything.

It's not a big deal at all. We can use docker.

why I'm downvoted. I'm not php hater :\

This is big. No, this is HUGE.

It was there this whole time?! Thank dog it's gone.

Most professional engineers are using some sort of virtualisation (docker or vagrant) with the language inside it.

I never use the OSX standard version of PHP or Python

> Most professional engineers are using some sort of virtualisation

source?

It sounds like they continue to boil the frog slowly. If you look back 10 years and compare the Mac OS then and now, would you have accepted the change in one version? Probably not. This will continue until Mac OS and iOS are unified and to develop for this new OS you need a hardware dev kit. MS will probably try the same but will not succeed since they don't control the hardware.

The only thing that's happened over the last 10 years is Apple execs saying they're not going to do that, not doing it, and then people saying they're going to do it next year and not apologizing when it still is not true.

Did it correctly identify PHP as a virus?

PHP was included with macOS? Wasn't that a huge security risk?

Normally you try to keep a system as small as possible, especially regarding scripting languages, so an attacker has as little tools as possible available.

I doubt any attacker is going to think "oh no, no PHP here, going to have to use Python!". If your security relies on not having an interpreter installed, something is badly wrong.

Script execution is blocked by default unless you turn off Gatekeeper.

It was often a not up-to-date version and not updatable without a macOS update, but it wasn't used much, or even at all: I don't know any system script that would use it, and any web developer would use another setup anyway.

So since it's not used (in a webserver for example), it's not as much more a risk than shell scripts I guess.

Security risk no. But it's a maintenance mess to have bunch of runtimes sitting around for no great reason.

Reply on news.ycombinator.com