macOS deprecating scripting language runtimes, including Python, Ruby, and Perl | Hacker News Reader

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

developer.apple.com

435 pointsundefined1434 comments

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.

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.

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.

> Homebrew installs its own binaries in a way that they won't interfere with the macOS-supplied versions

Correction: Homebrew usually installs its binaries in a way that doesn't interfere with the ones provided with the system. It will occasionally override or shadow them and things will break.

> It will occasionally override or shadow them

That's extremely rare, these days. When a conflict is possible, they just drop the new version in the cellar and tell you what to do if you really want to risk shooting yourself in the foot.

> 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/)?

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

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

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/

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

    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.

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.

In the early days of rails say 2006, it was definitely more common place... but I guess there were fewer of us back then ... I know as a maintainer of curb I have a few windows users

I started with a ruby/rails project in 2007 and after 3 days of fighting my work issued windows machine I just went out and bought a white macbook and things were up in running in an hour or two. I've never looked back.

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.

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.

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

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

it seems like you’re blaming RoR for a problem that is actually due to windows being “different”. almost every OS besides windows is a nix or nix clone and POSIX compliant or certified. so who’s really the problem here?

> Ruby on Windows is a nightmare.

The same stuff with Node.

Not sure why? Yeah there were times with damn node-gym not compiling for whatever reason. But nowadays things run pretty smooth.

paths, compilation etc. Windows isn't main server platform, so people seems like just don't care.

You can use / on Windows in node perfectly, and Windows node now installs required devtools for native modules at the end of the process.

It's pretty easy these days.

You can use it, yep, but devtools aren't enough. You'll meet a lot of issues sooner or later. Windows is second-class citizen for Node, Linux or macOS are much better - just share my experience.

Being a second class citizens is very different from being a nightmare. I've been able to build some fairly complex apps (TypeScript, Next.js, Relay, SQLite, Express) without running into any issues at all, and if I do hit a roadblock I know I can bail out to WSL or a VM.

The experience isn't as nice as macOS, but it's not terrible by any stretch.

Personally I moved to Windows about 2 years ago, have been developing node all day during that time and deploying on Linux. It's been great since about node 8. What have your issues been?

Same. Wsl is great. Running ides in wsl even works great, but with vscode, I don’t even do that much anymore. It’s like being on Linux for dev, but having Windows for power management, high dpi settings, drivers, etc. It’s working great, hardware selection is nice, games work. I’m really digging it lately.

> power management, high dpi settings, drivers, etc.

Have the same stuff working on Linux and deploy anything without VM/WSL/telemetry/etc. Guess similar situation with macOS.

Besides paths, Http_proxy settings on enterprise networks is a major pita.

i'm still using cntlm for that (as a proxy in front of the enterprise proxy) : http://cntlm.sourceforge.net/

(sourceforge is the main link, probably best to visit with ublock origin enabled)

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.

> macOS uses '/' as a directory separator already

Depends on what level of the UI you're dealing with.

> But macOS uses '/' as a directory separator already.

IIRC, HFS actually uses a ':'.

Mac OS versions prior to OS X used ':'.

Mac OS X, initially released on 24 March 2001, uses '/', like other Unix-derived systems.

Also, like other unices, OS X uses '\n' as the line ending. Prior Mac OSs used '\r' as the line ending. Windows uses '\r\n'.

but in Finder you can use "/" in filenames, and can't use ":". They got swapped if you look on the file from Terminal.

Similar, HFS+ used to provide the option for case insensitivity. Both things were built in for legacy support reasons during the transition from OS 9 to X, as with Carbon.

Macs still come with case insensitivity on by default.

In A/UX you could use both.

Pretty sure HFS doesn't actually store any directory separator. A directory, after all, is just another file, each one containing its own children. Classic Mac OS used ":" when it needed to use something as a path separator.

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

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.

I was someone who installed the first beta of Windows that included this, just to try it out for Rails. It had LOTS of problems. I filed bugs. I kept trying over the next couple of versions, and finally gave up. I tried it again a few months ago, and, again, ran into a show-stopping problem of some sort, and gave up again. Are you saying that you use it "in anger" for serious development, and have no issues?

People complain about doing Rails on Windows, and, while there's definitely extra friction, and I hate Windows in general, I have really good luck with RubyInstaller. I used to have a hard time with ExecJS, but now I just install Node (on either Mac or Windows), and I'm usually off and running.

I am using WSL more and more often nowadays and it's really good now, it works just like you'd expect Ubuntu (or other distro you choose) to work. The only thing I've had to do is turning off anti-virus real-time protection for linux subsystem.

Hell, not only VSC supports WSL. RubyMine can manage rbenv/rvm on WSL and more https://confluence.jetbrains.com/display/RUBYDEV/How+to+add+...

I've done most of my Linux development on WSL for the last year. It stuggles sometimes under certain types of heavy IO load, and there are ocsssional compatibility issues, but overall it's been impressively reliable and convenient.

I use WSL (without anger) for serious development, for about two years now and have had almost no issues.

Running 'Pengwin' (Debian) Linux via WSL, RVM using Ruby 2.4.1 + Rails 5.1.7 and Ruby 2.6.2 + Rails 6.0.0.beta3

Today, everything works just as expected, right out of the box with no effort. This includes ActiveRecord (to SQLite, MariaDB, and PostgreSQL), including Node.js / Asset Pipeline, Prawn PDF and ImageMagick integrations, uploads to AWS, email integrations, capistrano-based deployments, Heroku Gem + integration, and so on.

It's gotten to the point where we spend more time helping OSX folks figure out occasional Homebrew weirdness, than we do helping Windows folks with WSL. Especially since WSL people can almost always just re-use any Ubuntu instructions verbatim.

except when you install a native module in WSL and then try to run it from CMD. WSL is no different than having a headless VM and comes with all of the problems of one

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

> Ruby on Windows is a nightmare.

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

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

We probably agree on an objective level. I would agree with you that nearly all of it works nearly all of the time.

But that's my idea of a nightmare - when things are suboptimal and you're often scrambling for solutions on a second-class platform. When I say "often" I don't mean "every day", but in my experience it happened enough to make me swear off Rails on Windows forever.

Of course maybe 5.x is different. My experience was in the late 3.x and early 4.x days

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.

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.

> Apple hasn't been great at encouraging programming among kids

You should check out what they’ve been doing for years with Swift Playgrounds on the iPad

But that's teaching a new generation of coders a set of tools designed only for Apple. Ruby (Python etc) are open and easily available on other platforms, Swift may be in the future but it isn't now.

How about using a web browser with JavaScript?

Maybe not the best language for someone new but its widely available.

How about just a web browser?

You can run almost any language from a web browser these days:

https://repl.it/languages/

A lot of educational sites offer embedded interpreters like this.

It has never been easier to start to learn programming. The real challenge nowadays is maintaining attention...

Swift is open and available on other platforms. I can install it on a raspberry pi if I want.

https://swiftreviewer.com/2018/12/21/swift-programming-on-ra...

Once you’ve learned one programming language, it’s not hard to learn a second. It’s not terribly important what you’re first language is, and Swift isn’t a bad starting point anyway.

Huh? You can download Ubuntu builds right on their site

https://swift.org/download/

Funny. I learned on qbasic and I remember they were teaching dr racket at ubc to first year students. They were teaching java when I was in engineering and my career has basically gotten zero Mileage from that stinking heap of uncollected garbage.

One of the things that drew me to Macs as I started to learn programming in '05 was that I could simply open any macbook and type python/ruby/perl and write some code.

Different time. Now you got Homebrew

Which installs itself based on the system Ruby. Will be interesting to see how that plays out.

They just pack a statically compiled Ruby interpreter with Homebrew. Not very complex or novel. Disadvantage: install becomes more bloated (larger size).

Sure, it’s not a hard engineering challenge. However, installation instructions right now are as simple as “run this one-liner on your terminal”. That’ll have to materially change.

> Sure, it’s not a hard engineering challenge. However, installation instructions right now are as simple as “run this one-liner on your terminal”. That’ll have to materially change.

It could just as well still remain a one-liner. Every system Homebrew is installed on has Bash installed (not the latest, but still).

Instead of

> /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/in...

It could become

> curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/in... | bash

With the install script containing a payload containing the current Ruby script plus a Ruby interpreter. Still a "one liner".

> Every system Homebrew is installed on has Bash installed

Ironically, they are also moving from bash to zsh for default shell. Again not an unsurmontable challenge (just make sure the bang is correct in your scripts, bash will likely still be around somewhere in macOS for the foreseeable future) but another little hurdle to mind.

Doesn't surprise me given they dislike GPLv3 and Zsh is MIT.

Personally I try to use #!/bin/sh as much as possible, and Fish as my default shell.

upvoted for fish

As far as I'm aware they're not changing anything about which shells are installed or which executable /bin/sh points to they're just changing the default login shell for a new user, so nothing should have to change about the scripts that are (or have been) written.

Take a look at the installation instructions for the Rust compiler.

https://rustup.rs/

Like it works now with older versions of macOS and on Linux: it downloads a Ruby binary when it's not available on the host system.

But you have to download Xcode if you want a C compiler!

On the up side though, clang has made the C/C++/ObjC world a much better place.

Swift Playground for macOS? One can hope!

Technically Xcode has supported Playgrounds since before the iOS app existed, though if you mean the teaching content, it doesn't have that.

I had the opposite experience with AppleScript - the development tool (Script Editor) was simple enough for me to understand that it was the way I taught myself to program when I was 13.

(OK, I learned Logo in school when I was 7, but programming became way more interesting when I discovered AppleScript's APIs to control all the programs on my Mac).

>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

And you think a one-click download and install of Ruby would have prevented that?

Not to mention Apple also has Swift, and Swift Playgrounds and so on for kids these days.

Sure... but that was then. I too had a real hard time learning Ruby back in the day. But now if you google any Ruby or Rails how-tos they will include a one-line Brew and RBENV install.

So I get what you are saying but I think we are in a new world here.

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.

Or anaconda!

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.

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.

> They dropped X11

You don't have to be anti-unix to do that though, any reasonable organization would have done the same. I agree with the rest though.

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

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

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

The alarmist first comment in this very thread...

from the comment I am answering to

> They've been gradually deprecating Unix for 20 years, and designing the OS they want.

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

Ruby/Python/Perl is not UNIX.

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.

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

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

So is google with chrome os first and then with fuchsia

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

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

The jump from os 9 to OSX was about as significant as the jump from win9x to the NT based XP. Suddenly, multitasking stability without a huge dollop of luck was a reasonable expectation.

>> (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?

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.

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

They tried it's GNU Hurd.

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

Thanks.

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.

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.

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.

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.

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

Just rewrite it in rust.

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

They seem to package a portable ruby already. https://twitter.com/MacHomebrew/status/1136249501252038662

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

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

Correction: you need the Xcode Command Line Tools, not the whole Xcode bundle.

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.

Does OSX offer reasonable container technology? chroot?

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

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

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

In other words, nothing serious.

Does anyone actually use Docker on Mac?

Xhyve is more of a proof-of-concept than a production-ready tool.

I use Docker on Mac, and know many others who do as well.

> Does anyone actually use Docker on Mac?

What? We use it at work every day for local development, and my previous employer did as well. It has issues, definitely, but they have more to do with Docker than with xhyve.

But doesn’t Docker on Mac run a Linux VM? I don’t think it uses any of MacOS’s isolation features.

It uses Hyperkit: https://github.com/moby/hyperkit

> Does anyone actually use Docker on Mac?

I use it extensively. It is a desktop product however; it you aren't expected to put a swarm of MacBook pros into production.

Unless you want to run CD to the App Store? So fun....

Ah, but if the XServe had not died and datacenters had racks of these things, there'd no doubt be a production quality implementation by now. Shame.

I personally know of at least 3 or 4 engineering teams of 30+ developers who use it daily.

Xhyve is but one of the options for fronting hypervisor.framework.

Calling it “not serious” is quite wrong.

>Does anyone actually use Docker on Mac?

Sure, for development tasks.

Qemu has a backend too if I'm not mistaken?

A hypervisor is not exactly a container. Definitely not in the Linux sense. It may be more secure, but it is also slower.

Further, there's no decent solution for shipping a macOS container image to run in a VM. Linux, yes, Mac, no.

Finally, good luck getting your virtualized macOS app to interact reasonably with your main OS (no drag and drop, no OpenGL, etc.).

I would rather chroot.

How much slower?

Measurably slower than a LXC container, but still much faster than a full VM.

Not much slower than, say, Hyper-V or Virtualbox or other hypervisors that live alongside a general purpose desktop OS. Remember, they're using the same Intel chips and VT-d and such as anything else; as long as you have enough CPU power it's going to run fine.

IIRC the Docker implementation for OS X runs a tiny, carefully-configured Linux VM transparently in the background. This isn't that dissimilar from the Windows Subsystem for Linux from a user standpoint.

I've done plenty of Docker work on OS X; the only real weirdness is that you're running Linux in the containers and OS X outside. Eventually, though, before switching completely to a native Linux desktop, I moved deeper into the containers and would barely ever see the OS X command prompt any more.

Primarily disk access is a lot slower, even with Hyper-V. Eg. Compilation suffers from this. But tasks that don't use the disk too much shouldn't be that bad.

Our build time on Linux container is 8 minutes, but it's a few hours on macOS using docker containers. I haven't dug into it but the hypervisor seems to be single threading the normally multicore compile.

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

> I think apple fundamentally does not understand containers.

Given that Apple is (or at least was) one of the biggest users of Mesos in the world and have invited me to interview specifically on the back of the operationalization of containers, I'm guessing that the staggeringly bright programmers they've got probably understand containers.

Just a little hunch, you know?

The devops guys need to spread the love to the OS group and ship it with the OS.

Maybe it's another "you're not the target market" kind of thing.

The point I'm getting at is that folks on other platforms have lots and lots of options and apple doesn't provide any.

> apple doesn't want macos to be virtualized.

The macOS EULA explicitly allows macOS to be virtualized if you do it on a Mac running macOS.

> It would be really nice to have say the current xcode in one container and a dev xcode in another.

This is the entire point behind xcode-select. I currently have Xcode-beta and Xcode on side-by-side on my machine, and they pretty much coexist.

- "allows" not the same as supports.

- I think xcode-select just modifies a .plist.

It changes a symlink at /var/db/xcode_select_link, and all of the development tool stubs that Apple has placed consult this to see which binary to run. This is pretty much the officially supported way to switch between multiple copies of Xcode.

Can you run them simultaneously? I've never tried.

Yes, but there are some issues. For pure macOS development it's usually fine, but anything touching the simulator breaks if multiple versions of Xcode try to use it at the same time. I quickly got in the habit of always exiting Xcode before starting a different version.

Containers lose a lot of appeal once you leave the server, and Apple have explicitly abandoned the server market.

They do offer a set of "primitives" for virtualization, which can be hooked into by third-party solutions like Docker if they want to do so.

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.

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.

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

Installing the version you need when you want to run a script is arguably easier for newbies than all the error messages arising from an out of date implementation originally included with an OS.

it's not like installing python is any more complicated than any other piece of software that needs to be installed. Windows users have had no choice but to do that for decades.

> Windows users have had no choice but to do that for decades.

You're saying this like it's a good thing.

It's not a good thing or a bad thing. I'm saying it's not a thing at all.

If someone decides they want to run a custom ruby or python script the least difficult aspect of that decision is installing the interpreter. For example, I was dealing with someone yesterday who decided they wanted to learn how to write apps for Android. Without even seeing a single line of code (or even knowing which language they would have to learn!!) they had already successfully installed Android Studio and Jetbrains IDEA.

Without coming across as some gatekeeping greybeard, I think anyone who has even a glancing interest in programming would agree if you can't follow a one-line/click installation instruction you may want to find a simpler tool for the task than writing your own code from scratch.

Lots of people on just this thread, who have far more than a glancing interest, have expressed their disagreement with this exact idea.

The hardest part for lots of people in learning to program is getting over the idea that programming is for Special People, or possibly Wizards, who know lots of incantations which are beyond mere mortals. Please stop trying to convince them they're right.

Source: I've taught lots of marketing people, admins, call center techs, etc to program in PowerShell or system Python.

On the contrary, not teaching people how to install the interpreter just perpetuates the idea that it is beyond the ken of mere mortals. And that only "Wizards" should do it.

Installing the interpreter is nothing special. It should be taught as such.

Learning how to install and configure development environments is an important skill in general, but I'm not convinced having those skills as a prerequisite for exploring programming as a newbie is at all valuable.

It is valuable if they start out with python 3 instead of python 2.

I'd say that depends on what kind of newbie we're talking about.

On macOS the best config-free entry to programming is Swift and Swift Playgrounds. Everything else can have config and shell hell for further more advanced learning purposes.

You still have to download Xcode, of course.

I'm sure that my kids will certainly love to hear that they have to learn Unix in order to learn a build system in order to try out Python. It's all part of the "learning process for newbies."

> learn Unix in order to learn a build system in order to try out Python

I definitely understand that the installation process for things like python can be confusing to non-programmers, but I think this is a bit disingenuous. You don't have to learn a build system to install it; python was the first programming language I ever learned, and I used it years before I ever even had any idea what a build system is.

Good grief. What's wrong with going to www.python.org/downloads/ and clicking the big button at the top that says "Download the latest version for Mac OS X"?

If you can't even download an installer and run it, then yeah, maybe not quite ready for programming either.

Please forgive my snark, but this would be exactly my thought process as a reasonably competent computer user who wanted to learn Python.

He’s right though.

When I was six years old, learning to program involved turning on the computer and typing

  10 print “hello”
  run

That’s what I want for my kids. And there’s nothing even remotely like it in today’s world.

Open Terminal

    $ echo "hello"

seems pretty much the same to me.

Even on Windows you can open the browser console and do

    > console.log("hello")

Just for teaching basic prints, variables, loops and functions, terminal bash on macOS/Linux or Javascript console work just as well as Commodore 64 BASIC.

The problem is not that the environment is not available or setup is too difficult. The problem is that there's now way more competition from other shinies readily available (web, apps, games, videos). Even if you boot your home PC straight into a terminal, as soon as the kids find the way to a web browser it's game over. Even on 1980s home micros, if the kids got access to (pirated) games, practically none would volunterily keep on programming BASIC.

Teaching bash scripting as an introduction to programming? Surely there are laws against that kind of cruelty?

It's certainly not any worse than BASIC on 1980s home micro's. (IMO it's not any worse than Python either.)

When you were 6 years old is a different time from now. You probably did not have an always-on connection. There was probably no such thing as Web 2.0. Computers were more difficult to use. Google did not exist. The Internet was perhaps still taking off...

And then I remember that there wasn't much more to offer, because most "fun" functionality involved POKE'ing 'random' memory addresses.

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

Again the word "serious" is there telling me people are absolutely aloof to the kinds of new developers there are and what it's like to be a non programmer.

What newbie will start with Python 2.7 at this point in time? Most books and tutorials are updated for Python 3. The default Python 2.7 interpreter from macOS is useless for newbies, it does more harm than good by confusing them.

Apple could solve this problem by including python3 with macOS...

They sure could, but is it worthy to maintain an alternative package and deployment system for which you have no use yourself? Will employees be careful and committed to something useless for their jobs?

They previously deprecated Java runtime for similar reasons. And I can’t really blame them, roadmap is crystal clear now, they prefer to assign ressources to develop Swift/Swift UI and improve tooling for native code development.

I agree overall, but I do think it's a little sad that you can no longer open a Terminal and start writing Python. I think this legitimately matters in terms of increasing overall tech and programming literacy.

Mind, there's still a command line and shell built-in, which I consider far more important.

Its not like the rest of the terminal is friendly to newbies. An online ‘jsfiddle’ like environment suitable for newbies (with a bit of inline syntax hints without turning into a full IDE) would be more useful to get people to start playing with programming

Separately from including python, I've always thought it would be nice if TextEdit had some built-in syntax highlighting, that activated automatically for the right file extensions.

I'm generally against bloating simple apps, but you'd never see this unless you opened a .py file (or .sh, .rb, etc), and if you open a .py file, you probably want syntax highlighting.

You can open https://repl.it/languages/python3 and start writing Python.

with open("~/Documents/important.csv", "r") as f: f.read()

No? Oh well, I guess programming is hard, IT was right. Ok, back to excel...

You can just drag and drop the file on repl.it and it'll just work :)

Gee, thanks. My point was about discoverability and being able to Google for "read csv with Python", not whether experienced programmers can hack things together.

Majority of our users are hobbyists and novices

Presumably someone said that about python 2 back in the day and that turned out to be a pretty bad decision.

Isn't this the same as saying, we should never include any software, lest it become outdated someday?

Apple could solve this problems by including homebrew with macOS...

The young, bored but smart kid in an elementary or middle school tinkering with her computer and finding something to do. She doesn't need a book or a tutorial to tell her the "right" way. She experiments, only guided by her curiosity.

The point is that Python 2.7x is being EOL'd now. The Python that person will likely encounter in the very near future will be Python3.

per the link, macOS won't include any scripting languages by default in the future. So the bored user will be less likely to stumble upon an intresting programming language on their macs.

I don't know if that follows. I think it's likely that Apple will include a new installer upon setup that is essentially a one step 'click to install XCode Developer Tools and the following languages:' then has a list of options including Bash, Python, Ruby, Perl, &c. But all that is conjecture because we don't know what they're going to do yet.

You'd have to be very bored and unmotivated to not install a programming language if you had even the slightest motivation to program (IOW, not a normie consumer). I understand what you're saying, but I just don't see how this would be a huge barrier to entry.

There still Swift Playground, Safari JS console, not to mention old fashioned zsh/bash/ksh to tinker with. The part where the removal of the default macOS Python/Ruby/perl (which don't even have autocompletion) kills her curiosity seems far fetched.

What command-line programming language interpreters are left when those are removed? You have the shell itself, but that’s hardly enough to write anything cool.

This feels the same as when Microsoft removed QBasic from Windows 98. So many kids at home missed opportunities to be exposed to programming from them on, until a certain Terminal application appeared in Mac OS X and began to pique young curiosity again (mine included).

> What command-line programming language interpreters are left when those are removed?

zsh/bash/ksh93, tcsh, awk, sqlite3, elisp (assuming emacs survives for now) and javascript console. I don't know why you'd want to limit things to pre-installed command line interpreters though.

> You have the shell itself, but that’s hardly enough to write anything cool.

What kind of cool things do you envision the curious beginner to write, using only the current preinstalled Python/Ruby/perl, that they can't do with the remaining interpreters that I mentioned?

> What kind of cool things do you envision the curious beginner to write, using only the current preinstalled Python/Ruby/perl, that they can't do with the remaining interpreters that I mentioned?

What about the iconic 4th grader "greetings and cool things" script? Here's something like what it looked like for me (on the IBM PC in my classroom):

    5 CLS
    7 RANDOMIZE TIMER
    10 PRINT "Hello there. I'm a computer. What is your name?"
    20 INPUT G$
    30 PRINT "Hello "+G$+". You are welcome to computer land."
    40 PRINT "What would you like to do today?"
    50 PRINT "1) Make noises"
    60 PRINT "2) Make a maze"
    70 PRINT "3) Exit"
    80 PRINT "Enter your selection:"
    100 INPUT S$
    110 IF S$="1" GOTO 200
    120 IF S$="2" GOTO 300
    130 IF S$="3" GOTO 400
    140 PRINT "Try again."
    150 GOTO 40
    200 SOUND 20+(RND*20000), RND*3
    210 GOTO 200
    300 SCREEN 1
    310 IF RND>.5 THEN PRINT "/"; ELSE PRINT "\";
    320 GOTO 310
    400 PRINT "Bye."

That kind of stuff is perfect for Ruby and Python. I don't envision kids getting that far with shell scripts, awk, sqlite3, or elisp. They might with HTML and JavaScript, but that requires learning HTML as well as JS and is sandboxed in the web browser; it's also not as "Cool! Look what I can make the computer do!" as messing around in the terminal. (Note, I’m glad BASIC isn't as available anymore -- we're not getting kids into certain bad programming habits early-on, like use of GOTO. But BASIC would still be more approachable than shell scripting, awk, etc.)

Another of my favorites -- this was fun in middle school (years 6-8) when I had a spare minute or two to sit down at a random computer (maybe in a computer lab).

    10 SCREEN 9
    20 CLS
    30 COLOR 1, INT(RND*10)
    40 SOUND 20+(RND*5000),.2
    50 GOTO 30

The effect is rather striking, like someone must have really messed up the computer.

My main gripe with Windows NT was that it would go back to the NT screen saver -- I couldn't get it to stay displaying my program, because there wasn't any true DOS mode.

How would you do this on macOS with just the built-in Python or Ruby?

I have no idea... I just wanted to share something fun I did around 25 years ago.

    clear
    echo "Hello there. I'm a computer. What's your name?"
    read G
    echo "Hello $G. You are welcome to computer land."

    while true
    do
    echo ""
    echo "What would you like to do today?"
    echo "1) Say something random"
    echo "2) Make a maze"
    echo "3) Exit"
    echo "Enter your selection"
    read S
      if [ "$S" = "1" ]; then
        say $( head -n $((7*RANDOM)) /usr/share/dict/words | tail -n 1 )
      elif [ "$S" = "2" ]; then
        for i in {1..3000}; do
          if (($RANDOM>16384)); then printf '/'; else printf '\'; fi
        done
      elif [ "$S" = "3" ]; then
        echo "Bye."
        exit 
      else 
        echo "Try again." 
      fi
    done

This doesn't seem much different than the BASIC example to me. I think only the lack of GOTO in shell scripts makes this look slightly more complicated (requiring either putting all the statements in the if ... elif parts or defining functions).

I honestly don't see how a Python or Ruby version would be much better than a shell version for this. Perhaps you can show by example?

You do have a point - that's not too bad, but to my eyes it's still more arcane than Python and Ruby (spoken as someone who has written less than 30 shell scripts in my life).

I still contend that Ruby and Python are far more accessible than shell scripting, because they are very popular, especially Python, cross-platform, and less arcane.

For my own curiosity I did the simplest Python version I could think of to see how it would compare:

    import os
    import random
    import sys
    
    os.system("clear")
    print "Hello there. I'm a computer. What's your name?"
    G = raw_input()
    print "Hello " + G + ". You are welcome to computer land."
  
    while True:
        print ""
        print "What would you like to do today?"
        print "1) Say something random"
        print "2) Make a maze"
        print "3) Exit"
        print "Enter your selection"
        S = raw_input()
        if S == "1":
            F = open("/usr/share/dict/words").readlines()
            W = random.choice(F)
            os.system("say {}".format(W))
        elif S == "2":
            for i in range(1, 3000):
                if random.random()>0.5:
                    sys.stdout.write("/")
                else: 
                    sys.stdout.write("\\")
        elif S == "3":
            print "Bye."
            exit()
        else:
            print "Try again."

It looks like a tossup to me, all 3 versions have their own share of magic that will confuse the beginner. I say this as someone who reads and writes a lot more python than bash daily.

otoh, helping people start by just typing python is great!

otoh, pointing people towards messing with system python... well, it's a trap. And they will get burned, and it will be a nightmare to straighten out.

Yeah you'd be better off having a proper clean install of Python + virtualenvwrapper as your starting point.

Why would a new programmer want to start with a deprecated language?

Because they don't know it's a deprecated language.

In fact they probably don't even know what "deprecated" means.

It wasn't that long ago that Python 2.7 was the default on the Raspberry Pi. (That may still be true - I haven't checked recently.)

There's a huge ecosystem of Python 2.7 tutorials, introductions, and sample code out there. Very little of it is prefaced with "Of course you should use Python 3 now."

I bet they know how versions work though, and that 3.7 is higher than 2.7. I just googled ‘Python tutorial’ and only one of the results on the first page was for python 2. The first result was ‘The Python Tutorial — Python 3.7.3 documentation’. If some non-programmer was going to start learning python, they’re most likely going to start with google. I can’t see them digging deeper into the results because they want to learn an older version of the language.

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.

no. it's better for newbies to learn programming rather than fight with operating systems trying to set up an environment to learn programming in

If you follow a python 3 tutorial when your computer has python 2 installed on it, that's a terribly annoying way of fighting with your tools. I've seen it happen. I'd rather they don't risk it and just start fresh.

I'm gonna disagree on this one. When you're just starting, the installation process can be nontrivial and the terminal window is scary. Having less friction there makes it easier to start and build some confidence. Once you have some idea of what you're doing, you can realize that you want different versions of the language.

I think this is a better argument for Apple providing a package manager with the operating system so that installing python is as easy as typing "brew install python3". Then it'll be just as easy for newbies to learn less standard languages.

If you have a tough time installing software that has maybe a dozen words or so of instructions in a clear easy-to-read format... you really have no business learning to code until you learn how to use your computer first.

What's more scary? Copying and pasting two lines into the terminal, or working out why the hell pip doesn't work.

Always ask for python2 or python3. "#!/usr/bin/env python" probably won't ever be able to detect and run both, so no matter what you wanted there will always be systems on which you won't get it.

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.

So you're saying Apple should adopt brew as default package manager and install all system tools using brew? I could get behind that, but just dropping everything without replacement makes it harder for first-time programmers.

That, with analytics off by default. Also, Homebrew depends on Ruby, and Apple just ditched that

Homebrew installs it’s own ruby when necessary.

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.

Or conda, which I prefer to pipenv + pyenv.

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

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.

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

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

Yes but I’ve never seen someone new to programming that bothered trying to figure out pyenv or similar. Even a lot of moderately experienced devs don’t bother with it. I guess it’s hard to realize the benefits of keeping environments organized until you’ve been burned by it.

Homebrew is not perfect though - it doesn't handle multi-versions (e.g. 3.7 and 3.8 running in parallel), which were working fine with Apple's Framework mechanism. Pyenv is superior in that respect (although it's fundamentally a hack). But I agree that brew does a better job for newbies than Apple's system python.

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.

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

What do you mean?

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.

But you wouldn’t want to develop in that environment, right? You do integration testing in it, but development should largely happen in small modules, with unit tests and test data, no?

Of course you do that type of testing.

The problem comes about when someone does the following:

- creates python project

- pip install some_package

- import some_package

Turns out some package was already in the path but a different version

- proceeds to test and build with the assumption of some_package @ newer

- all tests pass

- ships project with requirements of some_package @ newer

Someone attempts to use the package but it doesn’t work.

Right, that’s why you do integration testing (manual and automated) but are you saying therefore you should do all development inside a production environment?

That’s what doesn’t pass muster to me. Why should I work on my CSS styles in an environment with the production database? It will be much slower than just working on that package in my desktop environment with just enough scaffolding the code runs.

But maybe I’m not understanding your suggestion.

OP was referring to containerizing your environment for package development.

What does connecting to a production DB have to do with any of that?

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

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.

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

The standard toolkit for this is perl. It's used in automake, most gnu utils and git. python and ruby bring nothing new to the table, besides being newbie friendlier.

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.

Homebrew is not the only package provider for MacOS.

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

Yes

I'm not sure why you are getting downvoted. I'd not like it if Apple will opinion-ate and make any package manager a default.

Package managers are for software developers. They are comfortable installing them on their own.

I expect he’s getting downvoted because he doesn’t offer any reasoning (or substance at all) along with his opinion.

The reasoning was in the question itself. Sometimes a prompt answer is a better one.

Yes, because Homebrew's practice of installing packages runs contrary to the requirements of a multi-user system.

MacPorts is sponsored by Apple, or at least used to be.

TBH it's weird they haven't built their own

They did: https://trac.macports.org/wiki/MacPortsHistory

MacPorts was originally started as DarwinPorts as part of the OpenDarwin initiative at Apple [1]. Apple continued to sponsor MacPorts by providing hosting of website, repository, and build servers at Mac OS forge [2] until it closed back in 2016. The project then moved to GitHub and their own servers.

[1] https://trac.macports.org/wiki/MacPortsHistory

[2] https://www.macosforge.org/

I reject the persistent meme that iTerm2 is somehow essential.

Apple do a great job with the builtin Terminal.app

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.

>Just that the prompt automatically goes on a new line makes iTerm2 so nice though.

Not sure what you mean here, but I don't think that's something you don't get, or can't get, on Terminal.app. In fact, that's the default...

If you have a command that doesn't print a new line, the prompt normally ends up on the same line as the output of the last command. iTerm can "fix" this.

See this is where I would rather have my terminal obey the program rather than imposing its own behavior. IMO a good terminal should be extremely minimal, and anything extra should be opt-in.

This is an option that you can enable. It's not on by default.

Don’t shells usually fix this? I know that Fish at least includes a little Unicode “return” arrow when it appends a newline.

zsh does this out of the box, and Apple is defaulting to it in Catilina.

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

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

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.

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.

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

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?

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

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.

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.

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

PS: also a quake-like mode.

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.

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

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.

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

Looks like they're ahead of this problem already.

https://twitter.com/zbeekman/status/1136250914539483136

> Once Homebrew no longer has to support a macOS with a system ruby, we can even run with a considerably more up-to-date version, modulo concerns for supporting older linux(brew) OSes. We have a portable ruby that we can use to bootstrap things.

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?

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.

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

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.

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.

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

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.

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.

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.

Those big-projects you mentioned failed to gain traction in the first place - with a tiny use-count for (e.g.) UWP vs Win32 it’s easy for MS to not take back-compat as seriously.

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.

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.

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.

> struct layouts and sizes

To be fair, this is less an an issue with non-fragile ivars in Objective-C.

Yup but OSX has a tonne of C (and unfortunately C++) APIs.

But yeah having most of the system apis being in a language that has built in dynamic resolution makes a world of difference in the difficulty of maintaining abi compat

Publicly exposed? Most of CoreFoundation and the other C APIs vend objects that are entirely opaque, and there are very few actual C++ APIs that I'm aware of–though many are written in (Objective-)C++ internally.

There are plenty of APIs that have structs in their interface, although they are always passed by reference so that the structs can increase in size, while still retaining compatibility with old software, e.g.

struct APIFoo { int a_field; }

void do_something(struct APIFoo* argument);

later on we add a new field, and that becomes:

struct APIFoo { int a_field; int new_field; }

For API compatibility you just need the source level field names to remain, and to remain the same type. But for ABI compatibility - e.g a existing compiled program - the fields must remain in the same location, so you can only add members to the end, and you can't change the alignment or padding rules.

What remains is how the API implementation knows if the argument is the size of the old api, or the new one.

The Microsoft API idiom is to have a size field that you initialize to sizeof(APIFoo). This means when you recompile you code against a more recent version of the API you'll get a modern sized struct. My feeling has always been that this approach is more fragile, as you can unintentionally increase the struct without initializing the new members. Apple APIs that need it tend to use an explicit version number, so you have to explicitly say that you know which fields you want to update - as an example you can look up JSClassDefinition (IIRC) in JavaScriptCore.

The other thing that Apple APIs will do is use a linked-on-or-after check: basically the macOS and iOS include metadata about the system version that a library or application was compiled to target. This is generally used to control legacy behaviour to handle cases where some internal logic leaked across an encapsulation boundary but the behaviour that was leaked is simply too awful to retain in general, and in the worst of worst cases code may include explicit tests for what the current application is (you can see a bunch of these in the WebKit codebase). Microsoft accomplishes similar tasks using (I think they're called) compatibility shims.

You are right however that the actual objects you get returned in macOS and iOS APIs are basically all opaque objects - looking at the JSC example, the actual API objects are opaque: so JSClassMake() takes a pointer to a JSClassDefinition, and returns an opaque JSClassRef that provides the actual API object you use to create objects.

As for C++: I would suggest you look at the nightmare that is IOKit. That's right, the kernel driver APIs are in C++. Because NEXT wrote that code in the 90s, when C++ was considered the perfect solution to all problems (e.g. before people really understood how hard C++ makes ABI compatibility)

Well aware of how C++ structures have issues with ABI compatibility, as well as the various linked-on-or-after checks ;) Note that DriverKit on NeXTSTEP, on which IOKit is based, was written in Objective-C. The switch to embedded C++ for Mac OS X was done to attract developers comfortable in the language, AFAIK.

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

32bit PPC ran on intel macOS, which is probably harder (it's basically a problem of how you map 32 registers onto 8).

The difference is that after a while Apple is willing to deprecate things. Versus a lot of open source projects that don't guarantee any stability at all, even across minor version increments. That's the problem that makes them dangerous for platforms like macOS and iOS to expose them as public API (intentionally or unintentionally - my understanding is for instance that the system openSSL was accidentally exposed publicly - and that took most of a decade to remove from the OS, e.g. most of a decade of shipping an increasingly old Frankenstein branch of openSSL)

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.

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.

Because of that, Javascript is now a pile of accumulated technical debt and it one of the worst language you can dev in. Hell, it has no type and still 4 ways to declare a variable.

In fact it's so terrible the most popular JS projects are actually project to avoid writing JS or emulate features that don't exist in one JS implementation or another (typescript, babel, JSX, webpack, polyfills, etc)

A lot of those frameworks exist to bring modern features of JS back to older implementations, and others exist to functionally bolt on a distinct type system because many people like static typing.

And yeah, JS has some old crufty things, but it also has the ability to do things nicely now. No one is forced to use old syntax, and most new code does not, but because those features have not been unilaterally removed there has not been anything like the problems python3 has produced.

Seriously: what new syntax in python three necessitated breaking python2 compatibility? Even your string example is weird because JS allows arbitrary invalid ucs2/utf16 strings despite adding actual unicode compatible APIs.

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.

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.

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

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

Thats the reason installing proprietary software on linux used to be a massive pain. The expectation is the distro maintainer packages everything for you but they only do that for things that are open source. This has changed since flatpack was created.

and it still breaks things if you've built things yourself because they're not part of your distro

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.

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.

How is homebrew installed?

https://brew.sh

Right...

     /usr/bin/ruby -e ...

https://www.ruby-lang.org/en/documentation/installation/#bui...

Homebrew comes with a portable Ruby in the install script. https://twitter.com/MacHomebrew/status/1136249501252038662

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

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.

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.

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

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

It’s not dead. I too have used it nearly daily for over 15 years.

Nope. MacPorts not dead. Use it everyday.

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.

_Ruby_ devs are going to be attracted to Homebrew because it (and the "recipe" for building every Homebrew package) is written in Ruby. The test of MacPorts is how many non-Ruby devs use it.

Whether or not anyone uses it, it is still linked from https://developer.apple.com/opensource/ and was part of Apple's open source strategy several years ago. Regarding Ruby, Apple backed the MacRuby implementation for a while but that also petered out.

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.

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.

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

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.

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.

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

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.

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.

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?

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.

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?

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

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

Same difference, really.

No: you can sign and notarize packages.

They already do.

The installer is the only thing that uses the system one. Could be ported to ZSH or Python 3.

Macports works and has updated versions of ruby.

At least for Python the standard .pkg's available from python.org have always been very useful for me. Especially since you can install as many versions as you want simultaneously since they install in separate folders. As a tester who used to have to keep installs of lots of versions this was very helpful.

I should know the situation for Ruby as well... but don't remember anymore.

Yeah I don't get the trend to install it with brew since it's so easy to use the official installer.

Package managers will keep your Python up-to-date automatically.

Sure but it's very rare to update python on the desktop (not on the server). Installing a new version in parallel is common, but once you get a 3.x rolling, you seldom have the need for a 3.x.y unless you encounter a bug or are very security conscious.

On the other hand, installing xcode is really a pain.

I try to keep the version of Python my personal computer is using up-to-date; I don't think this is a particularly uncommon thing?

It really is. Like backups. Or unit tests.

Good pratices != common practices.

Over time I’ve just migrated to using brew for everything. I’m not sure how it differs to macports, etc it’s just the one I always ended up using and it’s now just muscle memory :)

It differs quite a bit in its core philosophy with regards to how it interacts with the rest of the system and how much customizability it allows.

The system Ruby is being deprecated, but not removed in this release. By the time it’s removed, Homebrew will likely have a replacement installation process in place.

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.

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.

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

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

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.

I think that's ok, most everyone installs homebrew

Including macOS developers!

How do you install homebrew without Ruby?

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

Pkg file...

encoded and embedded in a bash script, more likely.

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

They should choose a package manager.

It's called the App Store.

You can't install Ruby/Python from the App Store

…yet.

and probably ever. It's not the right tool for the job, unless Apple really does some restructuring.

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.

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

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

Edit: 3.7.3, specifically.

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

On what system can you install python without Internet access?

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

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.

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.

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.

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)

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!

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

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.

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.

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.

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.

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

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

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

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)

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.

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.

You install Brew every day?

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.

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.

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.

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

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

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

Or a shell script.

Civ IV will never work again. RIP.

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.

Why is that?

It uses the system python? I doubt it.

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

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

Gives other languages a better standing too :)

So what about shell scripts?

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

brew install python

problem solved?

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.

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.

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.

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

Not that I'm providing any citations myself, but I'd like to see some evidence that macOS is losing mindshare because it doesn't bundle this, that, or the other by default anymore. macOS will remain a consistent UNIX out of the box, more consistent than Linux, as it still bundles the FreeBSD userland, their own additions, and make it simpler than ever get started developing — you can install Xcode from the App Store or just the command line tools with ``xcode-select --install``. Things like Homebrew and MacPorts can even install those for you if they're missing.

When using macOS, nobody is thinking "fantastic, I can't wait to use these hideously outdated versions of things" — it's a straight trip to Homebrew or MacPorts to sort things out, always, because the built-in version is categorically never the version people write scripts against. Nobody could depend on such old versions of Perl, Python, and Ruby because they were so ridiculously out of date.

Deprecating things that should already have been deprecated is not going to stop people preferring the experience that macOS still affords to developers. I don't see how that's going to change, there's no evidence to support this; if macOS has been losing popularity amongst developers, the butterfly mechanism and Touch Bar on the MacBook Pros has more to answer for than macOS itself which remains solid, reliable, and the best way to get stuff done on UNIX without the interminable fiddlyness of Linux.

Also, I think your timing and causations back to front; the release of WSL didn't solidify anything, it was already well known that Linux was the dominant server-side platform long before. WSL was and is Microsoft's way of bringing Unix-style tooling and development to the desktop, something macOS had done long before. I'd argue that WSL is still a VM of sorts; underneath it all, it's still a slimmed down version of Ubuntu that remains separate from other Windows processes. That WSL 2 will properly move into a VM will make that existing separation clearer, I believe — and yet, I can't help but think Docker on Windows is a more attractive offering in terms of flexibility, anyway.

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.

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

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

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.

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.

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.

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.

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

Reply on news.ycombinator.com