
macOS deprecating scripting language runtimes, including Python, Ruby, and Perl - Reedx
https://developer.apple.com/documentation/macos_release_notes/macos_10_15_beta_release_notes#3318257
======
ken
Not surprising at all. It's become clear that what they've been doing with iOS
all along is bootstrapping a new operating system. They started with Unix, not
because Unix was optimal for what they wanted to do, but it's what they had
and it worked well enough. Copland and Taligent and the rest failed because of
Second-System Effect, which Apple was smart enough to avoid.

(As RMS wrote in 1983, "Unix is not my ideal system, but it is not too bad.
The essential features of Unix seem to be good ones, and I think I can fill in
what Unix lacks without spoiling them. And a system compatible with Unix would
be convenient for many other people to adopt.")

Whereas such features as "background tasks" were simply a natural consequence
of the architecture of Unix, Apple didn't expose that on iOS. Now they've
finally gotten around to designing the background task subsystem they really
want, and it's not just an emergent property of the generic Unix way. It's
built for protecting battery life and privacy. It happens to be built on Unix
processes (right?), but that's just an implementation detail for them.

They've been gradually deprecating Unix for 20 years, and designing the OS
they want. iOS and its App Store allowed them to kill off large sections of
the old interface at once. I fully expect inside of 5 years for all of Apple's
operating systems to drop "UNIX" certification and become almost
unrecognizable as "Unix". They've got enough market clout now that people will
port Ruby/Python/Perl to a non-Unix macOS, just as they port them to Microsoft
Windows.

~~~
JohnBooty

        They've got enough market clout now that people will 
        port Ruby/Python/Perl to a non-Unix macOS, just as 
        they port them to Microsoft Windows.
    

Ruby on Windows is a nightmare.

To be specific, Ruby itself (the core language and core libraries) are pretty
good on Windows. Great choice for a scripting language, or whatever else you
want to do.

But libraries like ActiveRecord, Rails and their myriad dependencies are very
very hit or miss on Windows and there's not a lot of support when things go
badly.

A lot of the issues are simple - like dead simple. Lot of gem authors don't
bother to make things like file paths (forward slash vs. backslash) system
agnostic. Or the gems depend on compiled binary stuff like Nokogiri or
ImageMagick and those are always a bit of an adventure on Windows.

If MacOS drifts farther away from Unix they will cease to be the platform of
choice for many developers currently using it today.

~~~
tty2300
The funny thing is I have been a rails dev for years and didn't even know it
didn't work on windows because I have never tried and don't know any dev ever
using windows.

~~~
kowdermeister
That just proves you live in a bubble :) I never got into RoR because it
sucked so much on windows and every single tutorial was OSX focused. I just
sticked to alternatives that worked.

~~~
ffdjjjffjj
So which companies are actually doing RoR development on Windows? Do they also
deploy to Windows Server (?) in production? I guess I live in multiple bubbles
because I’ve worked for tech companies in several different major metros and
I’ve never heard of this as a mainstream thing.

~~~
kowdermeister
It is not like that. My point is that there's a barrier to entry to RoR that
you should own a Mac. I gave up because my home setup is Windows based and I
won't change it for the sake of a hyped framework or tool.

But none of this is surprising considering where RoR is coming from, I'm not
sad or upset about it either :)

~~~
tty2300
You don't need a Mac. RoR works perfect on Linux as well.

------
snowoutside
With brew as the de-facto package manager for macOS this is a great move.
Having Python and Ruby bundled with macOS is confusing when trying to install
"regular" versions of the software through brew or other methods. Because the
default installation can't updated without updating the OS, the system
versions are not useful for most developers.

~~~
cprayingmantis
The down side to that is that ruby is currently required to install Homebrew.

~~~
drivingmenuts
There will be a .pkg for that, if there isn't already.

~~~
george_perez
They seem to package a portable ruby already.
[https://twitter.com/MacHomebrew/status/1136249501252038662](https://twitter.com/MacHomebrew/status/1136249501252038662)

------
DividableMiddle
This has been a topic brought up internally at Apple many times over the past
decade. Glad to see it finally moving forward. Although I see the benefits to
having a system-version of these packages.. if you're doing anything serious
for production then the environment should be containerized.

~~~
Waterluvian
Python and pip just being there is a huge advantage for newbies. I really
think that part of programming is constantly ignored because all the decision-
makers are not newbies.

~~~
dcosson
It's honestly terrible for newbies. If they try to use it, there's no pip
included. So then they easy_install all their libraries which installs things
into different places than most python devs will be used to. Or they
easy_install pip first. But even still, everything is installing to system
paths, so when they try to install things it fails with permission errors.
They find a stack overflow post that says just "sudo" everything and they go
to town. And there's no way to reset anything when it gets borked either
because it's the system install.

Compare that to "brew install python". Now you have the most up to date
version, with the right permissions for your user, that you can always brew
uninstall and reinstall later if you need a different version or a clean
install.

~~~
wyclif
_you can always brew uninstall and reinstall later if you need a different
version_

That is the wrong way to do it. Just install pyenv/pipenv to manage different
Python versions. It's dead simple to maintain system Python, Python 2.7x, and
Python3.7.3 that way.

~~~
willio58
Wrong way? I’ve used this method successfully for years.

~~~
wyclif
Sure you can do that, but why would you want to install and re-install
different versions of Python depending on what you needed at the moment? Pyenv
manages all that nicely. You can have 2x and 3x side by side without having to
reinstall and uninstall anything.

~~~
Sean1708
> You can have 2x and 3x side by side without having to reinstall and
> uninstall anything.

You can do that anyway, `python` is always Python 2 (except on Arch where
`python` is Python 3 and the Python 2 executable is `python2`) and the Python
3 executable is called `python3`. `pyenv` is more for keeping multiple minor
versions of the same major version (e.g. Python 3.6 and Python 3.7) around at
the same time.

~~~
wyclif
_`pyenv` is more for keeping multiple minor versions of the same major version
(e.g. Python 3.6 and Python 3.7) around at the same time_

Actually, it doesn't have to be multiple minor versions, it can be any
version–major or minor. It can even be Iron Python or Jython. Anyway, the
point is that it's smart not to touch system Python on macOS. So when I run:

`$ pyenv versions`

My output is:

`system

`2.7.16

`* 3.7.3 (set by /Users/wyclif/.pyenv/version)

Dead simple and easy to use. Much better than overwriting and reinstalling
when you need a different version for a specific project.

------
TimTheTinker
I think this is great, but at the same time, auto-installing homebrew ought to
be an option (perhaps enabled by default) when installing the “XCode command
line tools”.

Better yet, offer a “developer setup” app that sets up the command line tools,
homebrew, iTerm2, updated bash/zsh, and more.

Apple would do best to pave the cow paths developers have already worn into
macOS, especially when it comes to command line utilities. A dev setup app
would just make it quicker/simpler and pave the way for newbies to get into
development.

~~~
Traster
I think the second you start auto-favouring one particular tool you're in
trouble. Why iTerm2? Why not Alacritty? iTerm2 is more popular now, but 5
years down the line when someone else has come up with a iTerm2 replacement
how is Apple meant to decide to switch? Where does Apple draw the line on
which tools to add and which to leave out?

It sounds like what you're really asking for is something like Ninite for mac,
which I think frankly is safer to stay as a 3rd party thing, rather than Apple
getting super-involved in choices that are going to be very user taste
specific.

~~~
skohan
Yeah I don't see the need for any of this to be provided by Apple. I want the
platform I'm working on to be minimal and agnostic, and let me worry about
what tools I'm using and how.

If there's really demand for some kind of base developer toolkit, why not
leave it up for a 3rd party to put together some kind of installer to set it
all up for you?

~~~
TimTheTinker
> why not leave it up for a 3rd party to put together some kind of installer
> to set it all up for you?

Because a potentially interested 4th grader likely won't ever know such a
thing exists.

And even if she did, the teacher likely won't let her download and install it
from the internet. But if she asks for permission to run a "Install Command
Line Tools" app in /Applications/Utilities/ and check the "Install homebrew"
option (or "Install MacPorts" \- I really don't care either way... perhaps
provide options for both), that's far more likely to get a "yes".

~~~
skohan
In my experience kids are very tech-savy. I don't think the 4th grader who
can't discover homebrew without a system setting for it is going to be able to
do much with it once they've got the terminal open.

~~~
TimTheTinker
Kids can only get savvy with exposure. Those lacking certain privileges (like
having a computer at home) likely haven’t had any of that exposure.

I was only able to learn BASIC and the DOS command prompt because I was in a
multi grade classroom, and an older boy (5th grader) whose mother paid for him
to have programming lessons taught me on the classroom computer.

The teacher had no clue about any of that... she only knew I started spending
“too much time” on the computer.

------
jzl
I'm trying to understand how these two points reconcile. "Future versions of
macOS won’t include scripting language runtimes by default" and "Use of Python
2.7 isn’t recommended as this version is included in macOS for compatibility
with legacy software. Future versions of macOS won’t include Python 2.7.
Instead, it’s recommended that you run python3 from within Terminal." If
Catalina is the last version with any scripting languages at all, why bother
with the second point? Or will python3 still be available in the future
despite point 1?

~~~
jaabe
As I understood it, scripting languages will still be available to the user,
they just won’t have ancient versions preinstalled. Of course that also means
you can’t rely on them being installed at all as a developer.

Which means you should start bundling the stuff you need to run your app, and,
they’d like you not to use the same ancient batteries as they have previously
made available, because, well they are ancient.

~~~
jzl
Ok, I guess it's worded vaguely enough to allow for the possibility of
optional installation ("by default"), even though they don't outright promise
that they'll offer a way to install it. (I interpreted it in the same way as
"macOS doesn't include Photoshop by default".) Having it come from the app
store doesn't seem totally appropriate since it would need to do more than
dump a bundle into /Applications, like making some /usr/local/bin symlinks.
Maybe they'll allow themselves that exception.

"they’d like you not to use the same ancient batteries as they have previously
made available, because, well they are ancient" \--> Right, I couldn't figure
out if that's all they meant. Valid point or not, it doesn't seem appropriate
to make it in the context of those notes. If you're going to make me bundle
the language anyway, don't _also_ give me a lecture about which version to
use. :)

~~~
wtallis
I suspect they plan to distribute the scripting languages the same way they
currently handle the command line developer tools package, where the OS offers
to download and install the package the first time you try to run one of those
tools.

~~~
jzl
I just don't see the win of that over supplying the thing with the OS in the
first place, _unless_ the commands to do it are a nascent versioned ecosystem
along the lines of brew, apt, etc.. It seems like the whole point of not
supplying them with the OS is to make the versions less tied down. If there's
some opaque command to get an arbitrary version, that's not going to help
anyone.

------
olliej
Probably the right call - many of them don’t have abi or api stability
guarantees, or in the case of python needlessly broke backwards compatibility
that is still causing pain today.

Apple used to ship an incredibly old version of OpenSSL because people used
its API which was not ABI stable. Even getting rid of it was a nontrivial
amount of work.

The lack of care about API&ABI stability in developer facing open source
projects (interpreters, libraries, frameworks, _commandline arguments_ ) is
still bizarre to me: why make your work hard to use/update? People ship out of
date libraries because updating requires changes beyond just pulling a new
binary requires more work than the gain will give them.

It’s part of why companies like Apple and Microsoft care so much about
backwards compat: they want people running the most recent OS possible, and
they don’t want people to avoid updates. Every time an update breaks something
for anyone, they hold off updating in future.

On the other side, developers don’t want to invest time and money into a
feature that they don’t think will work/cause their app to crash in future.

~~~
userbinator
_It’s part of why companies like Apple and Microsoft care so much about
backwards compat_

Compared to (former) Microsoft, I don't think Apple spends anywhere near the
amount of effort MS does on backwards compatibility.

You can create a single .exe that will work on any Windows starting from
Windows 95 - nearly 25 years. In that timespan, Apple changed CPU
architectures twice, and their OS architecture once. If you're willing to
restrict yourself to 32-bit Windows, which can run Win16 and DOS apps too,
then it goes back to the early 80s.

~~~
valleyjo
Completely true. Apple only cares about back-compact down to a few older major
versions. So often the big projects (like modern apps, Windows 10 S, etc)
Microsoft does fail or struggle to gain traction IMO because of the blessing
and curse of their back-compat requirements.

~~~
nicky0
I think Apple has the right formula. The do put the effort in to maintain back
compat to a certain point, but they also aggressively deprecate and remove
within a few years of the arrival of a replacement technology. So you get the
benefit of things not suddenly breaking, with the benefit of the whole
ecoystem moving forwards. If that means old unmaintained software is left
behind, then so be it. The right balance I think.

------
Reedx
Seems like a good move. Less cruft and don't have to deal with managing
versions between the one you want and the one already on the system.

~~~
xmichael999
I can't recall using the built-in version in ages, it is pretty much always
homebrew before you even start. So I think this is a great move.

~~~
rrix2
How is homebrew installed?

~~~
grzm
[https://brew.sh](https://brew.sh)

~~~
aquabeagle
Right...

    
    
         /usr/bin/ruby -e ...

~~~
george_perez
Homebrew comes with a portable Ruby in the install script.
[https://twitter.com/MacHomebrew/status/1136249501252038662](https://twitter.com/MacHomebrew/status/1136249501252038662)

------
AceJohnny2
Fucking _finally_! Between this and deprecating Bash [1], I'm glad macOS is
dropping all these obsolete packages it's been including (Emacs soon?). Their
antiquity mean they're more of a hindrance to proper development than help.

Now, if they'd officially endorse one open-source packaging solution as an
alternative, I'd be fully satisfied.

[1]
[https://news.ycombinator.com/item?id=20090193](https://news.ycombinator.com/item?id=20090193)

~~~
rgovostes
MacPorts has or had semi-official status. It was hosted by macOS Forge, which
was an official Apple site that included other projects such as XQuartz. I'm
unclear on the current status.

~~~
selectodude
Its a shame MacPorts kind of died on the vine. It just seems so much cleaner
and less hacky than Homebrew.

~~~
AceJohnny2
It's not dead! [1] I use it daily, and it's working just fine. For example,
check out the (centralized) list [2] of Ports files that define the packages.
You can see it's pretty lively

But your perception that it's dead is certainly symptomatic of an issue for
the project.

[1] yes yes Monty Python

[2] [https://github.com/macports/macports-
ports](https://github.com/macports/macports-ports)

------
bla3
I don't understand why everyone is so excited about this. I don't like using
brew. I use a Mac because things just work. It was annoying that the system
versions were old, but most of the time they were still workable. To me, this
is another (admittedly small) thing I liked about the Mac that's going away.

~~~
olliej
The problem is accruing security flaws (increasingly difficulty to back port
fixes), and also the problems that come up when you install a different
version (lots of Software just assumes it can use the same system python,
which causes issues when it isn’t the archaic version).

~~~
bla3
I'd prefer if Apple took care of security fixes instead of some third party.
And they could ship newer versions if keeping the old ones secure is harder.

~~~
olliej
The problem is that updating to a new version isn’t possible if it breaks
existing software - what happens is that the end user experience is “I
installed these updates and Apple broke my program” so don't update in future,
and tell others not to as well.

The only way to stop the OS from including out of date software and libraries
is to not ship them if they don’t have stable abi.

That’s what Apple is doing: it can’t reasonably ship them and keep them up to
date, so it is going to stop.

~~~
jdsully
Doesn’t removing them have the same issue? “My software dependent on this
ancient python no longer works - because there’s no python anymore”

~~~
olliej
Yes, the difference is that now Apple is shipping a new version that will have
the same problem in a years time, so instead of one compatibility event
there’s a new one.

The app developer also now has a problem - their binary only works on one OS
revision so they have to start shipping the same code, just compiled
separately. The only safe solution is to ship with their own embedded version.
Which is also the correct solution to the interpreters not being part of the
platform.

------
ihuman
Does this include AppleScript and the Javascript runtime for AppleScripts?
They reference Script Editor in the section above, so I'm assuming they're
safe.

Also, what's the best way to install homebrew if you don't have a system-level
ruby? The current installer is a ruby script. Is it possible to get some sort
of ruby-bootstrap that can install homebrew and a homebrewed ruby?

~~~
olliej
No - the problem with the misc other interpreters is that they don’t provide
sufficient binary stability for Apple to simply include the newest one in
every update (which I suspect they would happily do).

They’re not removing the commandline (although moving to zsh? :-/), or banning
interpreters.

They’re just not including them built into the os anymore.

As for the AppleScript and JavaScript questions:

Apple makes the runtimes for those, and makes sure they remaining binary
compatible. Take a program that linked to (and used) the javascriptcore api to
add js support. Something compiled 10 years ago will run without
recompilation. Thats the bar for stability.

~~~
ihuman
I think you read more into my question than what I meant. I was asking
literally about the best way to install it was without a system level ruby.
Once you have homebrew, you can install ruby; but what about before that?
Download and install ruby from ruby-lang.org, install homebrew and a brewed
ruby, then uninstall the one from ruby-lang.org?

~~~
azinman2
I’m guessing home brew will end up creating a packaged installer than includes
a home brew upgradable ruby

~~~
saagarjha
I'd think a script that you pipe into a shell with admin privileges is more
likely ;)

~~~
anamexis
Same difference, really.

~~~
saagarjha
No: you can sign and notarize packages.

------
alerighi
Good thing, python2.7 is deprecated and no longer receives security updates,
and a lot of Linux distributions (Arch and Fedora for example) plans to remove
it from the main repositories at the end of this year, so having it installed
doesn't make sense.

Even the perl and ruby version installed is old, and nearly nobody uses perl
or ruby at this day. Maybe perl is still used by some programs and scripts,
for example TexLive relies on perl, or ruby is used for brew. But you better
installing more updated version yourself so removing it is not a big deal.

There is no meaning to keep old script interpreters installed, if you want to
use them you probably want to install a more modern version, if you don't need
them it's better to not have them.

~~~
toyg
_> python2.7 is deprecated and no longer receives security updates_

Let's not go overboard - 2.7 will get security updates and patches until the
end of December.

 _> nearly nobody uses perl or ruby at this day._

Well, except for homebrew of course, the Ruby-based package manager nearly
"everybody" uses...

~~~
Longhanks
Homebrew (after installation) uses its own, bundled ruby runtime and will
finish removing any dependency on system ruby long before Catalina is publicly
available.

[https://twitter.com/MacHomebrew/status/1136249501252038662](https://twitter.com/MacHomebrew/status/1136249501252038662)

~~~
toyg
I know, but this wasn't the case when it started. Besides, I believe the
parent's point was that nobody uses ruby or perl for _anything_ anymore,
regardless of whether it's preinstalled or not. Which is obviously silly when
looking at homebrew's internals.

------
exabrial
I think that's ok, most everyone installs homebrew

~~~
jeremyjh
How do you install homebrew without Ruby?

~~~
exabrial
Pkg file...

~~~
foobiekr
encoded and embedded in a bash script, more likely.

------
Godel_unicode
It's interesting to me that this is happening in the same month that Microsoft
made installing modern Python as easy as typing Python and then clicking
"install". One more piece of evidence that Microsoft cares about developers
more than Apple does.

~~~
grumpydba
> It's interesting to me that this is happening in the same month that
> Microsoft made installing modern Python as easy as typing Python and then
> clicking "install".

You still need admin rights and an internet setup. Linux is still king.

~~~
Sharparam
On what system can you install python without Internet access?

~~~
grumpydba
On Linux you don't need to install it it is there by default on all major
distros.

------
willyt
Most of my Python/Ruby stuff requires additional packages to be installed and
so would need to be bundled anyway if I wanted it to be easily transferred to
a vanilla machine so I don’t see what the big deal is. I got into programming
through wanting to automate something really boring with AppleScript and I got
into Ruby (wow that was amazing compared to AppleScript) through wanting to
program sketch-up which has a bundled interpreter. When I wanted to use Ruby
for other cool stuff, the Ruby website recommended I installed my own so it
didn’t mess with the system install. I doubt there are very many people who
get into programming by accidentally typing Ruby at the command prompt. Most
will come to it via a the getting started page for the language they are
interested in or because it’s bundled with the software they use for their
job.

------
bayareanative
Not a big deal. Anyone doing serious development at scale would mirror
production anyways (12factors principle). Plus, who uses Apple's obsolete junk
anyhow? For a very long time, homebrew and macports has solved Apple macOS not
rolling releasing terminal-based packages. Teapot tempest.

------
kazinator
Of course; why would they want to maintain this crud and its dependency hell.
If the slightest thing is wrong, this or that application breaks. An
application should include the correct version of everything it needs to do
its job, period.

Only problem is security: with multiple applications including their own
dependencies, some of those dependencies will lag behind in their security
updates. You can't just get a single fix for your Python run-time and fix it
in all applications at once.

------
panpanna
In the mean time, ARM publishes educational C code that requires 3 different
scripting languages to compile...

(Eralier versions of mbed build system needed python, JavaScript and one more)

------
markstos
Interesting that some version of Python will still retain a default status,
while Perl and Ruby are both being removed from the default install.

Congratulations, Python 3!

~~~
briandear
That’s because no ruby developer ever depends on system ruby. It superfluous,
not a vote for python.

------
makecheck
I did like being able to distribute an entire app with a download of just a
few _megabytes_ , relying on a highly stable system Python (literally worked
for 10 years).

And these days with smallish SSDs, I find myself desperately freeing up disk
space surprisingly often. I’d rather not have every single app be 100+ MB when
I know deep down that the things should be tiny.

------
api
I think people are reading more into this than is there. They're just not
going to ship their own (outdated) versions of these anymore because they're
not needed in the core OS. You can just "brew install" them, which most people
who actually use them do anyway because the stock versions are too old.

------
musicale
I guess it is the macOS way for every app to be self-contained and include all
of its own libraries.

But I miss the idea of shared libraries; not only can they potentially save
memory and disk space, but it makes bug fixes easier because you can fix the
shared library without having to update every app separately.

------
reid
Sounds like these runtimes will still be available via a separate download,
similar to how Git and other CLI tools download when you first try to use
them. Not a big deal. Makes it easier for folks who want newer versions and
avoid any strange behavior with coexisting with the built-in runtimes.

~~~
Traster
Yeah, one of my pet peeves is logging in to a new system and being like "Which
version of Python am I going to have to try and avoid invoking today".

~~~
lapnitnelav
Nothing quite like a bit of snake dodging to start your day.

------
mutt2016
Wait.. So I'll have to install Ruby before I can install Brew? Ok. Ruined 2
minutes of my day.

~~~
dwaite
I expect homebrew to switch to installing their own local ruby via a zsh.

They already install their own local ruby today, but use the system-ruby as an
entrypoint.

------
gerbilly
It might be nicer if they curated more up to date versions instead, but of
course it's easier to remove things than to carefully manage dependencies.

I'm not a big fan of brew however. Last time I checked it didn't seem to work
well when switching between users.

------
usermac
And I have a 4+ year old Perl script I use daily. Yeah, yeah, I know I can
install Perl myself but when I distribute it I was expecting it, Perl, to be
there—never mind that it is an out-of-date version—I wrote it accordingly.

------
donatj
Not that Apple even supports Widgets anymore beyond their continued vestigial
existence, but it was always nice back in the day to have the power to call
out from widgets to scripting languages for more power.

------
ytch
I thought it is reasonable. IIRC, my MacOS 10.14.5 has python 2.7.10 built-in
(I've install home-brew on it, but I guess it is the Apple built-in version),
it is too old (Release Date: May 23, 2015).

------
chunsj
Oh, please remove them ASAP or include the most recent version of them.

------
lenkite
Ok, this means homebrew needs to be compiled to a native binary!

~~~
yellowapple
Or a shell script.

------
shereadsthenews
Civ IV will never work again. RIP.

~~~
nottorp
It uses the system python? I doubt it.

~~~
shereadsthenews
It absolutely does and macOS has already broken it several times. This I guess
to some extent demonstrates the folly of having one.
[https://forums.civfanatics.com/threads/how-to-get-
civ4-bts-w...](https://forums.civfanatics.com/threads/how-to-get-civ4-bts-
working-on-el-capitan-and-sierra.549923/)

------
k__
They were often outdated anyway, so it's no big loss.

Gives other languages a better standing too :)

------
NelsonMinar
So what about shell scripts?

~~~
saagarjha
Apple will have to ship with a POSIX compliant shell if they'd like to keep
their UNIX® certification.

------
nickthemagicman
brew install python

problem solved?

------
thrower123
So, what's the point of using Macs as a better Linux, if they are continuing
to strip out the parts of Linux that are useful? Might as well use WSL or
Cygwin and save a bunch of money.

~~~
zapzupnz
You do realise that the reason these things are being stripped out is because
macOS includes hideously _old_ versions for backwards compatibility with older
software that depended on them, right?

There is no real loss here; no sane users would use the built-in versions due
to their age. It has been preferable to download and install newer versions
for a long time, this changes nothing.

And if it's fine to spend a tiny amount of effort to install WSL or Cygwin on
Windows, then it's surely also no effort at all to install Homebrew or
MacPorts (or other) — with the benefit of not working in a contrived, separate
environment.

This comment betrays a fundamental lack of understanding of modern developer
workflows in macOS and feels just slightly like a troll comment from someone
who likely doesn't use macOS to begin with.

~~~
wahern
> And if it's fine to spend a tiny amount of effort to install WSL or Cygwin
> on Windows

Well, plenty of people use macOS precisely because it was like a more
consistent Linux out-of-the-box. Apple will lose a ton of mindshare; indeed,
they _are_ losing a ton of mindshare. They've been slowly deprecating things
for years, now, and leaving the rest to rot, and open source developers are
increasingly drifting away.

About 10 years ago macOS and Apple hardware started becoming the preferred kit
for open source developers, and this showed--Apple kit was seen everywhere in
Silicon Valley and eventually became the default kit given out by big software
companies. That was all because of macOS' Unix personality. That's all going
to change over the next several years.

I was surprised when WSL 1.0 debuted. By making Linux _native_ on Windows, it
solidified Linux' position as the dominate server-side platform. I'm not at
all surprised they're ditching it for WSL 2.0, which is just Linux in a VM
with a networked filesystem, precisely what people have been doing for about
15 years, keeping it solidly second class--like running Windows on macOS.

~~~
linguae
I personally believe that the reason why Apple is losing mindshare among some
software developers, particularly in Silicon Valley and in academia, has less
to do with particular choices regarding macOS and has more to do with Apple's
hardware situation, particularly regarding the keyboards on Apple's recent
laptops. The keyboard situation has led some developers to consider
alternatives to the MacBook Pro, which often necessitates needing to consider
non-Mac alternatives. PC manufacturers have been offering some really
compelling alternatives to the MacBook Pro such as the Microsoft Surface line
of tablets, the Lenovo ThinkPad X1 Carbon, and the Dell XPS 13 and 15, among
other computers. Those frustrated with Apple's long delays in releasing
updated Mac Mini and Mac Pro models have also considered switching to PCs, if
they haven't already.

On top of this, the introduction of WSL in Windows 10 has made Windows a
compelling option for many people who use macOS as a Unix that doesn't have
the driver issues of Linux/*BSD and happens to support Microsoft Office, Adobe
Creative Suite, and other commercial software packages. Provided that they are
not hardcore Unix systems programmers, if they want a Unix-like userland with
support for Microsoft Office and Adobe Creative Suite, why not try WSL?
Despite my preference for macOS, I've used WSL on my work-issued computer as
well as on my personal Dell XPS 15, and I must say, I'm very impressed with
it. No more having to mess around with PuTTY or with virtual machines to do
Unix work on Windows. While I am personally more productive in macOS than in
Windows even with WSL, I know quite a few former Mac users who are very happy
with Windows 10, thanks to WSL.

Now, software engineers who primarily work with Apple frameworks and
technologies probably won't be satisfied with Windows. But software engineers
who use macOS primarily as a convenient Unix with support for commercial
software packages might want to give Windows 10 and WSL a try. Now, personally
I'm still turned off by certain lingering "Windowsisms" (insert gripes about
telemetry, ads, mandatory updates, and the UI here), but for many people
Windows 10 is now a compelling alternative to the Mac.

------
zmmmmm
How deep you are willing to go with conspiracy theories ...

If one was planning to kill off all non-approved software on an OS, what would
you do first? Remove all the runtimes that can execute unapproved software of
course. Then you are free to impose signing as a requirement for applications
and a mandatory app store, and reap the 30% rent tax forever more.

Is Apple doing that? Of course, we can't tell. There are lots of good reasons
to do this that aren't evil. The best evil plans are indistinguishable from
good plans but just happen to have evil outcomes that are in your interest.

~~~
saagarjha
It is trivial to package a scripting runtime with an App Store application; so
trivial, in fact, that a number of apps _for iOS_ do this already.

~~~
zmmmmm
That doesn't really contradict anything above. It still remains true that if
they were planning on removing ability to run unapproved applications from
OSX, the first step would be to take out the ability to do that which is
installed by default. Restricting what App Store applications can do would
come later (and be controlled by policy rather than technical limitations).

