macOS deprecating scripting language runtimes, including Python, Ruby, and Perl

https://developer.apple.com/documentation/macos_release_notes/macos_10_15_beta_release_notes#3318257

by undefined1 • 7 years ago

435 409 7 years ago

developer.apple.com

exabrial2• 7 years ago

I think that's ok, most everyone installs homebrew

sys_64738• 7 years ago

Including macOS developers!

jeremyjh• 7 years ago

How do you install homebrew without Ruby?

AlexeyBrin4• 7 years ago

You basically rewrite the current Ruby installer in a shell script that will download a Ruby version from Homebrew ...

exabrial2• 7 years ago

Pkg file...

robin_reala• 7 years ago

Right, but homebrew is written in Ruby. So there’ll need to be some more bootstrapping stages to install a recent Ruby first. Although it looks like they’ve got a plan: https://twitter.com/machomebrew/status/1136249501252038662?s...

mixmastamyk• 7 years ago

They should choose a package manager.

wahern2• 7 years ago

It's called the App Store.

Reedx• 7 years ago

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• 7 years ago

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• 7 years ago

How is homebrew installed?

ihuman2• 7 years ago

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?

olliej15• 7 years ago

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.

ihuman2• 7 years ago

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?

AlexeyBrin4• 7 years ago

On Linux, the Homebrew installer is a shell script that invokes curl https://docs.brew.sh/Homebrew-on-Linux. I guess, they can rewrite the current installer that uses Ruby with a shell version for macOS too.

DividableMiddle• 7 years ago

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.

new_realist2• 7 years ago

Does OSX offer reasonable container technology? chroot?

wedn3sday• 7 years ago

Singularity recently released a (non-fully featured, but still useful) mac version.

pram• 7 years ago

macOS has a native hypervisor framework, Docker and xhyve uses it.

https://developer.apple.com/documentation/hypervisor https://github.com/moby/hyperkit

m4633• 7 years ago

I think apple fundamentally does not understand containers.

All the interesting container stuff is on other platforms.

It might be out of fear, maybe because apple doesn't want macos to be virtualized.

It would be really nice to have say the current xcode in one container and a dev xcode in another. It would be nice to farm work out to a lot of machines.

or a dockerfile like: FROM macos:10.14

RUN installer xcode... RUN xcode-build myproject

Gaelan2• 7 years ago

I imagine you could get pretty far with sandboxing+chroot, but it wouldn’t be docker. You’d definitely be able to prevent stuff in the container from getting out, but I’m not so sure you could reproduce docker’s “VM-like” (I.e. the inside of the container is ~identical to a normal Linux machine, with no need to make stuff compatible) quality.

Waterluvian2• 7 years ago

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.

arvinsim2• 7 years ago

Learning how to install Python and Pip should be part of the learning process for newbies.

AlexeyBrin4• 7 years ago

AFAIK, macOS comes with Python 2.7 and without pip. For any serious, modern, Python development you need to install Python 3 yourself.

benatkin3• 7 years ago

Not true. It's better for them to install it themselves so they know exactly what they're using, and so they type python for python 3 and not python3.

dcosson2• 7 years ago

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.

sametmax5• 7 years ago

Not only pip is not provided, but virtualenv neither.

The alternatuve to the current decision is for apple to assign people to keep updating python and provide previous versions as packages like linux distrib does. But it has never been the way they do business.

erikpukinskis3• 7 years ago

if you're doing anything serious for production then the environment should be containerized.

What do you mean?

__full_pint3• 7 years ago

I’m not OP but:

When you build and package things for production you should create an environment. This ensures the packaging the right versioning of requirements for build.

Say you build using the system version but use packages based on another version. It may work for you but probably won’t work elsewhere.

ynx• 7 years ago

at the very least, virtualenv (for Python) to isolate the library dependencies from the system libraries.

rurban2• 7 years ago

The problem is not doing anything serious. Of course this would need an updated language runtime.

The problem is doing something simple, like an installer. bash => zsh: fine. You can still install with the old /bin/bash. but for many cases a shell is not enough, and then you have to compile something statically for a trivial dynamic task. Which makes the download 10x larger. Not cool.

tlrobinson• 7 years ago

It seems like there’s an opportunity for a lightweight statically-linked scripting language. Something between Go and Python.

olliej15• 7 years ago

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• 7 years ago

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• 7 years ago

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.

cwp• 7 years ago

Not true. Apple spends an enormous amount of effort on backwards compatibility. For example, they wrote a JIT compiler to be able to run 68k code on PPC. They did the same for the PPC to Intel transition. They maintained the "Classic" ABI and binary formats for years after the move to Mac OS X.

It is true that Apple doesn't maintain backward compatibility for a long as Microsoft does, but that's not the same thing as not caring. They put the effort into making transitions as smooth as possible for users and developers and getting through them quickly.

olliej15• 7 years ago

That's simply wrong.

Apple maintained 68k compatibility for years after it migrated to ppc. That's a completely different hardware architecture

It maintained classic compatibility for years after it moved to osx. That's a completely different kernel and basic system architecture.

It maintained PPC compatibility for a few years after transitioning to intel.

It supported 32 bit x86 for a number of years after the entire line was 64 bit capable.

Apple does care about compatibility, it just isn't as beholden to the past: it's much more willing to say "this is bad, so we're deprecating it, eventually it won't exist/work".

But they work to not break any software until the feature being used is actually removed.

It is considered a high priority bug if someone changes behaviour of a function or object in a way that isn't backwards compatible. All APIs are essentially statically vetted to ensure they don't change, including things like struct layouts and sizes.

That said, it kind of misses the point to respond to "Apple and MS care about backwards compatibility" in this context to say " I don't think Apple spends anywhere near the amount of effort MS does on backwards compatibility". The point is that if you care at all then libraries and services that are unwilling (or even hostile to) abi stability cannot viably be shipped in any publicly facing way as part of your platform.

jmkni2• 7 years ago

32 bit Windows binaries will even run on the ARM version of Windows.

kpcyrd• 7 years ago

If you're referring to the python2->python3 change, this was a pretty important one. Having a string type that isn't required to have valid encoding is an awful idea.

olliej15• 7 years ago

And rather than just accepting that was what you had and accepting that you occasionally had to deal with that (as JavaScript did), they decided to cause a decade of problems that aren’t going to go away just because they’ve now declared python 2.7 dead.

bshipp3• 7 years ago

I don't know if I completely buy into that argument. API's on the bleeding edge are often prone to breakage because the development frontier is in constant flux.

However, software that neglects to update also tends to breakdown as libraries change to reflect new knowledge.

If you're developing software based on someone else's library you are implicitly accepting the demand to modify your software to maintain currency with those underlying requirements. It seems a bit far-fetched to expect that you only have to write the software once without having to maintain it.

olliej15• 7 years ago

What I'm saying is that that is a choice on the part of the library developer.

You can make APIs that are ABI stable (literally that's the entirety of the Microsoft and Apple platform APIs, and plenty of open source libraries as well - Qt and GTK for instance). You can also explicitly choose not to (which I believe includes OpenSSL).

Basically if a library or application is not or cannot provide a stable ABI, it cannot be used be a platform where the default update model does not include the possibility of recompiling all software. Essentially such a model would require Apple and Microsoft to have the source for all apps, and be the primary/only distribution point for all of them as well - note that this is host most linux distributions operate: any given update can result in an arbitrarily large portion of all software for the system being recompiled.

maheart• 7 years ago

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?

If you're a FOSS developer with limited time and man power (and if you're lucky, limited budget) maintaining backwards compatibility is hard. So hard, that new features and bug fixes might have to take a back seat to it. Also, I'm almost certain that developers would rather be implementing new features, and fixing bugs, ahead of maintaining backward compatibility. It's much easier to show a new feature or a bug fix, than it is to show how backward compatibility was maintained.

Also, the big users of FOSS, projects like Debian (and Ubuntu) and Fedora, will rebuild their entire systems when new versions of software are released/integrated. This reduces the maintainer's requirements to keep ABI compatible.

yjftsjthsd-h• 7 years ago

rebuild their entire systems when new versions of software are released/integrated

Yeah, the ability to rebuild the entire system from source whenever you need it has resulted in those communities just not caring about a number of things that really do matter on proprietary systems; it's also part of why Linux doesn't have fat binaries (why bundle multiple architectures together when everybody can just grab or build each one themselves?).

mutt2016• 7 years ago

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

azinman22• 7 years ago

Except it’ll be the latest, and then easily updatable after that.

Expect package installers that make the whole thing easier and more secure (signed packages vs a curl | /bin/sh)

dwaite3• 7 years ago

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.

rgovostes4• 7 years ago

Good point. Hopefully the Homebrew installer script will bootstrap this for you. They already build and distribute binary packages, they probably can easily download the existing Ruby package and execute it.

nicky02• 7 years ago

You install Brew every day?

AceJohnny24• 7 years ago

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

rgovostes4• 7 years ago

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.

AceJohnny24• 7 years ago

MacOS Forge has been deprecated for years (2016?), all its hosted projects have moved off. I don't think Apple has done anything for MacPorts since then, so I wouldn't consider it a current endorsement.

selectodude• 7 years ago

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

briandear2• 7 years ago

That isn’t semi-official. I know of not one ruby dev at Apple that uses MacPorts. That’s not to say there isn’t one, but they are rare.

saagarjha22• 7 years ago

MacPorts was started by Apple engineers as part of OpenDarwin and then spun off into a community project like the rest of the projects on macOS Forge, and just like the other projects it is still worked on in part by Apple engineers.

thrower123• 7 years ago

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.

dwaite3• 7 years ago

This is a great move.

It will be two lines of code and two minutes to install the interpreter you need, and you will no longer be tied to a global, possibly ancient system version.

Likewise, you won't have your own installed applications break on update because (for example) python2.7 was EoL and dropped from the OS.

Installing your own instance of python or ruby should be two lines and about two minutes assuming a decent internet connection.

zapzupnz2• 7 years ago

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.

wahern2• 7 years ago

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.

olliej15• 7 years ago

... but you have to install these in Linux as well? Python, ruby, etc are not required for Linux to run and for a long time we’re not installed by default (I don’t know if they are these days because the regular fresh install dance for Linux just has me autopilot through installation of all the things that are inexplicably not included, which historically included python).

There are many reasons that people choose to use a Mac, mostly when people say “Linux” in this context they mean: posix shell, and the ability to run most other posix software (eg most Linux commandline apps).

It’s not because it has every interpreter on earth installed by default. In fact as others have said the current status is that the system installs of python and ruby are old because updating them breaks software. The solution is to make them not part of the OS so if software does want to use an interpreter they don’t lock the shipping version again.

Linux doesn’t have this problem because it’s assumed that your update process comes from a central repository of all the apps so if you (say) update python you also pull recompiled updates of all the apps you have that depend on python. Software installation on a Mac is generally not all from one source, and even if it were Apple doesn’t have the ability to recompile other developer’s apps.

LeoPanthera• 7 years ago

Macs are not and have never been Linux. Or a “better version”. They are a Unix with some resemblance to FreeBSD.

itslennysfault• 7 years ago

I think it's fine. Linux distros don't typically come with this stuff, but they do come with package manager (unlike OSX), but it's nbd to install one.

I recently switched to linux after 10+ years of MacBook Pros because I'm disappointed in the hardware quality post 2015. I used to die-hard argue that they were worth the price tag, but now I can't do so in good faith so I got a Dell XPS about 6 months back and love it. Cheaper and superior hardware. There is a bit of learning curve for using linux as an every day work machine, and there is a couple days of setup to get things working just right and achieve parity with OSX features I love (quick view, screenshots, keyboard shortcuts, etc), but once I got everything configured I have no complaints.

pjmlp2• 7 years ago

None, if you want Linux, get Linux.

macOS is an evolution of NeXTSTEP and has its own way of doing things, based on BSD, Mach, Objective-C and Swift APIs.

ytch• 7 years ago

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).

NelsonMinar• 7 years ago

So what about shell scripts?

saagarjha22• 7 years ago

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

markstos2• 7 years ago

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!

briandear2• 7 years ago

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

snowoutside• 7 years ago

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• 7 years ago

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

andoriyu• 7 years ago

Just rewrite it in rust.

drivingmenuts2• 7 years ago

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

month13• 7 years ago

Could also just use bash to bootstrap an environment, like how RVM does.

dsl2• 7 years ago

You already need Xcode to get Homebrew working, and that will most likely be the vector by which optional scripting languages will be installed.

chunsj• 7 years ago

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

bla32• 7 years ago

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.

olliej15• 7 years ago

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).

bla32• 7 years ago

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.

mproud• 7 years ago

You don't have to use brew. And if you aren’t a developer making software, you don’t need to do anything.

If you are a developer, there are many ways to get the software you need for development. Apple is saying they’re just not going to provide it on client machines by default — which is probably fine because honestly, more often what happens is the version Apple has on the machine is old or missing newer parts anyway.

I guess you could argue Apple should make their own package manager, but they just don’t want to spend the time and energy on that when they want to focus on Mac and iOS software rather than UNIX software.

gerbilly• 7 years ago

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.

ken3• 7 years ago

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.

drivingmenuts2• 7 years ago

A different solution, and possibly better, would be to run Unix/Linux in a VM rather than worrying about it being native in the system.

If I'm not mistaken, current best practice is to somewhat isolate third-party developer software anyway, using homebrew, a VM or other solutions (not sure about Docker - don't use it).

I can see where it would be an issue with developing for MacOS or iOS, but third-party web development doesn't really need anything that is installed on the system, and in my experience, it's actually better not to base it on the MacOS default packages.

Wowfunhappy6• 7 years ago

Homebrew installs its own binaries in a way that they won't interfere with the macOS-supplied versions. It doesn't use a container or anything like that. Certainly not a full-on VM.

Maybe I'm old-fashioned (feels weird to say that as a 25-year-old, but here we are), but I quite like not having everything be in a container all the time.

zerkten• 7 years ago

A different solution, and possibly better, would be to run Unix/Linux in a VM rather than worrying about it being native in the system.

Just like WSL 2.0 (https://devblogs.microsoft.com/commandline/announcing-wsl-2/)?

thristian• 7 years ago

...just as they port them to Microsoft Windows.

Just as they ported them to MacOS Classic back in the day.

rgovostes4• 7 years ago

I'm sure that others here are well familiar with other officially certified UNIX operating systems[1], but given many widely used Unix-like systems not on the list, I don't think Apple gains anything from the certification. Moreover, it probably is deleterious, forcing them to adhere to system designs that made sense in the 70s and 80s.

1: https://www.opengroup.org/openbrand/register/

Wowfunhappy6• 7 years ago

I'd be surprised if Apple spends all that much money/effort on official Unix certification, precisely because I doubt Apple would bother. How many customers are choosing macOS over something else because of the Unix certification? In a world where Linux exists?

(This discussion, of course, has nothing to do with whether or not macOS adheres to Unix principles or compatibility.)

JohnBooty2• 7 years ago

    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.

tty23002• 7 years ago

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.

paulcarroty4• 7 years ago

Ruby on Windows is a nightmare.

The same stuff with Node.

ken3• 7 years ago

But macOS uses '/' as a directory separator already. They're not going to arbitrarily change trivia like that -- at least, not short of killing the concept of a filesystem altogether. (True, if anyone was going to do that, Apple would, but APFS is brand new. That's not going anywhere.)

Apple isn't changing things just for the sake of change. They're removing 1970's-isms where they hold back the platform. Languages like Ruby/Python/Perl also clean house, from time to time, to remove old cruft. I can't imagine any legacy feature of macOS that Apple would want to deprecate which would make it more difficult to maintain a good port of Ruby/Python/Perl. These are regular general-purpose programming languages now, not just Unix scripting languages.

Yes, Unix has been one of the developer systems of choice for the past couple decades, but it wasn't always so, and it hasn't been the only one. I hear more developers than ever using and enjoying other systems like Windows (Powershell) today. Even Linux today is pretty far from traditional Unix. I just don't see perfect Unix compatibility as a necessary component like it was in 2001.

dragonwriter• 7 years ago

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.

I haven't done Rails for a while, but when I did Rails (including ActiveRecord and all its other components) Just Worked o bWibdows (lots of the peripheral ecosystem of Rails and Ruby more generally was a nightmare, but Rails itself was great), and overall the Ruby (outside of Rails) experience on Windows has gotten better with Ruby installer + DevKit, which hasn't closed all the gaps but does mean that even libraries with C extensions frequently just gem install and work on Windows; I'd be surprised if Rails itself had gotten worse in this area.

jmkni2• 7 years ago

The Windows Subsystem for Linux fixes a lot of these problems, you can even point VS Code at Ubuntu now on Windows and avoid CMD entirely.

Stratoscope• 7 years ago

file paths (forward slash vs. backslash)

Windows file APIs have always supported forward slashes in file paths, even before there was Windows. This goes all the way back to MS-DOS 2.0.

jjgreen• 7 years ago

Ruby on Windows is a nightmare.

It hurts when I do this ... [punches self in face] ...

e12e2• 7 years ago

Ruby on Windows is a nightmare.

Nightmare? No. Suboptimal? Yes.

We're running some legacy rails 3.2 against oracle db on windows, and it works well enough. It sure is a lot more pleasant on linux, though.

Biggest challenge on windows is to get a c compiler working/get binary dependencies working. Other than that, you need a version manager (same for other platforms really, unless you're aiming to shoot yourself in the foot).

Ruby on windows is definitely not great, but "nightmare" is a bit much.

Gaelan2• 7 years ago

I think you’re overthinking this. The vast majority of Ruby/Python programmers have been installing their own copies themselves, because Apple was pretty slow in updating them (Ruby is usually a few minor releases behind, Python is still 2.7 IIRC). People will just keep doing that, and nothing will change.

They may or may not be moving off Unix, but this isn’t evidence of that.

indigo747• 7 years ago

As a counter-anecdote, the built in Ruby interpreter in Mac OS X Tiger was the way I learned to program and how I got interested in programming. I don't think a bare Ruby interpreter is the best way to get into programming, but Apple hasn't been great at encouraging programming among kids. As a kid, its development tools were totally baffling, where Ruby was much easier to understand.

wyclif6• 7 years ago

Right, I think most developers know that it's a bad idea to mess with the old, unmaintained system versions of Python, Ruby, or Perl. Almost everyone I know uses Homebrew to install the bleeding edge versions separately, and that will save you a world of pain.

For Python folks, just install pyenv/pipenv and you can easily maintain `system` (Python), Python2.7x, Python3.7.3, &c as separate environments. For Ruby people it's rbenv.

blablabla123• 7 years ago

And it's to be appreciated. When installing my own Python version, I'm worried it might interfere with system tools that might be written in it.

ken3• 7 years ago

This alone isn't evidence of that, but it's not the only data point we have. We've got 20 years of observations. They dropped X11 (and didn't use it for the main display in the first place), created new process APIs (like GCD and background tasks), deprecated standard libraries like OpenGL (and don't support Vulkan), designed their own programming language, etc. All of these point in the same direction.

What will be left? Will it still be "Unix" in any meaningful sense just for having a C compiler and running an old version of Bash? Microsoft Windows did that, too.

jpz• 7 years ago

The main issue here is that they don't want the hassle and responsibility of breaking everyone's software each time they release a new system-level python.

They have a problem deprecating python2.7 as it is, the smartest deprecation is not to release a python3+ version at all.

You see a similar issue with python on Debian. Python 2.7 is still the system python for all of the Debian tree, and it is very challenging to migrate to a new version because of the huge impact it has.

That's not to say MacOS won't be a place where python is happy to run - just that Apple don't want to dictate a specific version of it in their releases (i.e. developers/users/applications should install one.)

jypepin2• 7 years ago

One good thing about programming on Mac is the UNIX environment which basically works just like on Linux. Makes it great for finding questions/solutions that work (vs on Windows for example).

Do you see that changing as macOS gets away from UNIX? That would probably be a bad hit on apple if Linux becomes then the de facto programming OS when Apple drops UNIX

a-ogilvie• 7 years ago

What makes you think Apple has any plans to move away from Unix?

toyg7• 7 years ago

if Linux becomes then the de facto programming OS

It is already. Deployed any production service on macOS, of late? Windows and MacOS both, are now forced to run Linux compatibility layers (Docker, WSL...); the Mac one just happens to be thinner because of the choices made at NeXT back in the day.

pmarin• 7 years ago

Ruby/Python/Perl is not UNIX.

tannhaeuser• 7 years ago

I don't see this anti-Unix stance at all in what Apple is doing here. The "P"-languages that shall not be named were never part of Unix/POSIX, and arguably violate Unix principles in that they want to establish a language-centric ecosystem when the Unix userland is about small, language-agnostic programs working together.

coldtea4• 7 years ago

and arguably violate Unix principles in that they want to establish a language-centric ecosystem when the Unix userland is about small, language-agnostic programs working together.

That was never a real consideration where distros/vendors are concerned (UNIX or Linux). Just a nice-to-have goal for the command line userland (and even that, more back in the day).

simonh• 7 years ago

Would you say that RedHat doing almost the exact same thing[1] means they are moving away from being Unix-like as well? This is just an idea who's time has come.

You might be right about OSX and it's derivatives moving away from being so unix-like, but by itself this is just sensible housekeeping they would have to do at some point anyway. It's just not reasonable to expect them to include and maintain deprecated language runtimes indefinitely.

[1]https://developers.redhat.com/blog/2019/05/07/what-no-python...

0xCMP• 7 years ago

So is google with chrome os first and then with fuchsia

t0astbread• 7 years ago

Weird, I thought the Unix-likeness was a huge selling point of macOS ("the most user-friendly Unix on the market")

agumonkey• 7 years ago

for the tech crowd that's for sure, but how much is it for their overall market ?

YeGoblynQueenne2• 7 years ago

> (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.")

I have a historical question and I wonder if anyone in this thread has the answer: why did RMS (and, presumably, by then his cycle) had to wait around for Linus Torwalds to write a kernel so they could have one for GNU? RMS in particular has a reputation as a legendary hacker. Was he not able to write his own kernel?

bitL• 7 years ago

There is GNU/HURD that was supposed to be the kernel. However, its development hit roadblock when microkernel design ended up extremely difficult to debug. Sometimes you can't predict real complexity from the architectural drawing board and prevailing hype in academia, pointing to microkernels as the future at that time. Linus just wanted to implement his own, simple UNIX kernel, based off proven principles, without doing original kernel research.

megous• 7 years ago

https://en.wikipedia.org/wiki/GNU_Hurd

NoOn3• 7 years ago

They tried it's GNU Hurd.

e12e2• 7 years ago

In addition to sibling comments, remember that Linus announced Linux as:

"Hello everybody out there using minix -

I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. (...)"

GNU couldn't use MINIX due to the license (unlike minix 3), and as I recall, the bsd's were also in somewhat unclear license terms.

Gnu made the libc, compiler and various userland tools - but no-one did a" simple get it working"-kind of kernel, and then Linux came along.

I suppose part of this might be because in early gnu days, most gnu hackers used university Unix machines - not personal 80x86 for development.

If you bough sun hw you got Solaris. Only if you bought a pc clone would you be wanting a "real" os...

knolan• 7 years ago

I disagree. MacOS is hugely popular in academia. A significant amount of researchers use MacBooks as it allows them to have the best of both worlds by having a machine that runs MS Office for preparing proposals and dealing with Admin as well as a UNIX system that lets them ssh into whatever workstation or cluster they’re running jobs on. Sure Windows is catching up in this regard but MacOS has had the advantage of being a much nicer experience.

Getting your products into Universities is a great way to maintain market share. This is true for software like Matlab and even for banks where most students will keep banking with the same bank for decades.

znpy• 7 years ago

This. I've asked a macbook at work specifically for this.

I can have an Unix workstation while still being able to run Outlook, Excel and Powerpoint.

I don't want to use Windows and I don't want to use that pile of crap that LibreOffice is... The mac was a good compromise for me.

Geezus42• 7 years ago

I would like to believe that the people who use those features would make the much simpler switch to Linux but with the new WSL and (ridiculous) terminal I know a lot of them will be persuaded to transition into the special hell that is Windows.

shereadsthenews2• 7 years ago

Civ IV will never work again. RIP.

Marsymars• 7 years ago

As a huge fan of Civ IV, I've found the macOS version pretty janky. I have a generally better experience on my Mac by just using Steam In-Home Streaming from my Windows box.

mthoms• 7 years ago

Why is that?

nottorp• 7 years ago

It uses the system python? I doubt it.

shereadsthenews2• 7 years ago

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...

lenkite• 7 years ago

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

yellowapple• 7 years ago

Or a shell script.

Godel_unicode5• 7 years ago

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.

pcr910303• 7 years ago

Well, python 2.7.5 isn’t ‘modern’ python... AFAIK :-)

Godel_unicode5• 7 years ago

Not sure what that version number has to do with anything...? The Microsoft package is 3.7

Edit: 3.7.3, specifically.

grumpydba2• 7 years ago

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• 7 years ago

On what system can you install python without Internet access?

jzl3• 7 years ago

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• 7 years ago

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.

jzl3• 7 years ago

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. :)

dsl2• 7 years ago

I understand it as scripting languages will be installable options, but Python 2.7 will not be one of them.

zmmmmm2• 7 years ago

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.

saagarjha22• 7 years ago

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.

zmmmmm2• 7 years ago

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).

bayareanative• 7 years ago

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.

TimTheTinker10• 7 years ago

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.

jarcane• 7 years ago

Homebrew is not the only package provider for MacOS.

reikonomusha• 7 years ago

Would Apple be in the wrong simply being opinionated about using Homebrew?

frou_dh• 7 years ago

I reject the persistent meme that iTerm2 is somehow essential.

Apple do a great job with the builtin Terminal.app

wyufro3• 7 years ago

Just that the prompt automatically goes on a new line makes iTerm2 so nice though. As well as the built in timing of commands, jump to previous prompt, double click selects matching parentheses, etc. it's those little details.

aloer• 7 years ago

iTerm is amazing when using many spaces because of the hotkey overlay.

Projects and project parts are separated via spaces but I never want to have to find the right terminal for a process, instead I use a single window with animations disabled (to show immediately) and excluded from app switcher via settings so that it will only ever show up when i press alt-space no matter which space I'm on.

Together with tabs and native panes it works just great and requires very little setup

TimTheTinker10• 7 years ago

I agree, Terminal is great. But I prefer iTerm because it supports split panes (including saving/restoring a particular configuration) without tmux.

Cthulhu_• 7 years ago

I'm not a big fan of Homebrew or Macports myself, they both feel kinda hacky. Wherever possible I prefer installation packages from the official site.

I think / hope Apple will do their own package system, maybe as part of the app store, for developer tooling like that. If only for improved security.

Traster2• 7 years ago

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.

saagarjha22• 7 years ago

I think the second you start auto-favouring one particular tool you're in trouble. Why iTerm2? Why not Alacritty?

Because iTerm2 is an excellent Mac app? I don't understand your aversion to favoring one tool over another: macOS itself is a tool that I prefer to use over Linux because it's nicer, just as iTerm2 is nicer than Alacritty.

skohan3• 7 years ago

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?

konart2• 7 years ago

iTerm is a great choice and Alacritty does not have tabs. And tmux is not always an alternative.

PS: also a quake-like mode.

TimTheTinker10• 7 years ago

My point wasn't so much a plug for iTerm2 or anything else in particular. The purpose of a dev setup app would be to (a - primarily) provide a great default dev environment for curious kids, and (b) pave the way for some of the most popular dev configurations.

I know homebrew and iTerm are pretty popular, and that there are other popular options as well. Why not list the top n in each category, in randomized order, with short descriptions and "learn more" links?

Every time I start work on a different Mac, it usually takes me at least 30 minutes to set it up. It would be nice to have a quick button to set up command line tools, iTerm2, homebrew, zsh, and git. Making such setup available from an app would not only speed up the process, it would also gives the dev environment visibility to newcomers and "first class" status from an IT perspective.

Aissen• 7 years ago

They already favored ruby, python and perl over other (less popular) interpreted languages. Ditto for favoring bash, then zsh, etc.

pmilla1606• 7 years ago

I know this isn't exactly what you're talking about but I've found it invaluable: https://github.com/atomantic/dotfiles

It's a script that installs all kinds of useful stuff and sets some - in my opinion - nice options. I just recently started a new job and I had a brand new Macbook Pro up and running (as in: ready to start working) in less than 30 minutes.

A good tip is to fork it and modify it to your liking. At a new computer you can then just pull down your version and install away.

The only default that's missing is Sublime Text.

teach• 7 years ago

So the ironic part is this script would no longer work after these deprecations because installing Homebrew requires a Ruby interpreter[0].

Obviously these things are fixable but a whole lot of people are going to have to do a lot of work to workaround having _no_ scripting languages installed by default on a fresh Mac.

[0] https://github.com/atomantic/dotfiles/blob/master/install.sh...

makecheck• 7 years ago

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.

panpanna• 7 years ago

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)

reid• 7 years ago

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.

Traster2• 7 years ago

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".

lapnitnelav2• 7 years ago

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

willyt2• 7 years ago

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.

k__• 7 years ago

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

Gives other languages a better standing too :)

donatj2• 7 years ago

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.

alerighi• 7 years ago

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.

toyg7• 7 years ago

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• 7 years ago

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

nickthemagicman• 7 years ago

brew install python

problem solved?

usermac• 7 years ago

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.

api• 7 years ago

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.

musicale2• 7 years ago

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.

kazinator• 7 years ago

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.

macOS deprecating scripting language runtimes, including Python, Ruby, and Perl

Related Stories