Scripting languages have been removed because bundling them created problems. Apps would rely on the system version so an OS upgrade that, for example, moved to Python 3 would break apps.<p>The solution is to bundle your own runtime, or install with homebrew if you’re a dev.<p>I really don’t see Apple removing the UNIX utilities and terminal.app any time soon. Of course if they do I’ll be in the market for a new OS.
If you explicitly manage your scripting language versions, none of what you’ve described is a problem. Instead, your post reads from a perspective of fear, uncertainty and doubt that doesn’t line up with developer experiences.<p>As for iOS, it is not the same as macOS and should be considered separately. I’m not sure why you’ve equated the two (different use cases), but maybe you are genuinely (and unnecessarily) worried.
Sadly, I think a more representative title would be "How long will UNIX survive?". macOS is the only widespread version of UNIX left, and as it converges with iOS and loses its command line ecosystem, it will be the effective end for UNIX.<p>Ignoring the parallel universe of Mainframe computing, server UNIX has been replaced almost completely by server linux. The Free/Open/Net BSDs are knocking around both desktop and server spheres, but they are not common. Desktop macOS is the only recognisable strain of UNIX you are likely to encounter.<p>I agree with the point made by the OP of course, and I've swapped my MacBook to Ubuntu for this reason.
It seems like there's no ex-Apple weighing in. I worked there ~5+ years ago now & the OS-bundled versions were such a pain that even internally we were avoiding them. I'm not 100% sure but IIRC the issue with having python bundled is the OS is that the specific version then became required to ship meaning we were stuck on ancient versions of Python2/Python3 internally (& same for Ruby probably) to make sure that externally people relying on specific behaviours stayed functional. Additionally having them (or at least Python) installed at the system level caused all sorts of havoc in terms of interplay with other Python versions installed via homebrew if you weren't super-careful with how your paths resolved (& sometimes even then). Finally, externally most Python shops would end up installing Python via other means (e.g. homebrew) to make sure they're using the latest version & using virtualenvs which are best-practices & what we ended doing internally for our scripts too. The title & article is pure FUD - there may be reasons to worry about whether macOS remains UNIX (I'm personally not too worried) but "they're no longer pre-installing scripting languages by default" is so far from that it's laughable.<p>NOTE: All of this is my own personal opinion & viewpoint and in no way should be construed to represent any secret internal knowledge of Apple's internal reasonings & whatnot (I have none)
I recently took a late 2011 Macbook Pro and installed Ubuntu 19.04 on it.<p>* It was easy. I don't know what to add except it was easy.<p>* It is fast. I now consider Mojave bloatware, although I didn't know it at the time. It appears that there are now so many things running in Mojave that my old macbook could not handle it. With Ubuntu 19.04 it is FAST. And what can you say? Except imagine what 19.10 would be like on a faster CPU. Not that I need it, but ...<p>* Its fun. Probably this is a function of how fast it is, but also most things just work very nicely. I'm fond of 19.10 in a way that I have not been fond of my macbook since maybe Sierra.<p>* I miss Apple-C and Apple-V for cut and paste and I miss iterm2, but that is all.<p>* The only thing I need a mac for is ios development and for that I plan to get a mac mini, but otherwise the run from an Apple II, through a Mac SE and an iMac has ended for me.<p>* Oh, and you can run wine and windows stuff really easily on 19.10.
It's <i>possible</i> that in a post-Catalina Mac world, Unix scripting languages -- at least the ones currently included with the system, e.g., Ruby, Python, Perl -- that Apple will use the same mechanism that they currently use for git and some XCode-specific command line utilities: when you type the command, you'll be told the application isn't installed and it'll offer to download it for you.<p>Even if that doesn't come to pass, I'm not <i>super</i> concerned about this. Which isn't to say that I'm serenely unconcerned, but as people have noted, there are ways to install and manage these without them being provided by the OS vendor, and probably most Mac users here have been doing just that for a long time.
I use MacOS heavily for command-line heavy programming work<p>> Future versions of macOS won’t include scripting language runtimes by default, and might require you to install additional packages.<p>This sounds sensible to me. For ruby, python, node etc you need specific versions for different projects. I literally never use the OS's python -- that's a private matter for the OS and if it doesn't need Python any longer then fine. (rbenv, pyenv, nvm etc help with managing versions)<p>> What bothers me the most though is that Apple has removed the man pages from their online documentation.<p>I recommend installing the coreutils package from Homebrew and using that over the BSD Unix utilities.<p>I also (perhaps controversially?) would recommend using --help over man pages where possible for the simple reason that you are probably fallible, like me! Us mere mortals tend not to have a clue whether the man pages we're looking at are for the executable we're invoking or not, and staying on top of man pages involve staying on top of a bunch of environment variables and weird directories that date back to the hairier days of UNIX. With foo --help, you are always 100% sure that it is giving help for what the executable "foo" resolved to.
> Python, Ruby, and Perl<p>Oh, the irony! If the FBI released a lineup of suspects in the case of who killed Unix, those three names would be right at the top, with Perl as the ringleader* .<p>Besides, Unix isn't Perl, Python or Ruby. It's an OS turned API in the form of POSIX. BeOS was Posix compliant and could build and run Unix software. Even plan 9 can build Unix software using APE, the ANSI Posix Environment. Apple just doesn't feel like paying distro package maintainer.<p>* See #8: <a href="https://interviews.slashdot.org/story/04/10/18/1153211/rob-pike-responds" rel="nofollow">https://interviews.slashdot.org/story/04/10/18/1153211/rob-p...</a>
If you're looking for a unix-based OS on which to develop software, and want a slick GUI on top of it for browsing the web, I encourage you to consider Chrome OS.<p>It is extremely secure, easy to use, and simple, and has allowed me to develop software on it like it is a linux machine.
I ported pacman to OS X more than 10 years ago. I’ve been handling it by myself for my own usage since then as Arch OS X, then ArchMac. I had a couple of Darwin specific patches, and I started ramping up to build stuff on Catalina first since that’s current and what free CI for FOSS are moving to. It feels like I’m close to a release compatible with Catalina but I keep on hitting strange weird bugs that did not happen when building on previous macOS versions, and keep having to work around stuff. What was a stable enough platform is now a significant pain even for trivial stuff. The last one is an obscure bug where a file existence test seems to return bogus results (there is no file in the package cache dir, yet pacman does not go through the download step when such a file is missing, and fails with a NULL pointer assertion as the later state is inconsistent. Same source code works with flying colors when built on a previous darwin). With some time I could probably add yet another patch to fix that, but I’m left wondering if it’s really worth it now, as if the trend continues as it did for the last three versions darwin20 will be even more painful to support, if at all.<p>ArchMac is not the only one impacted, e.g<p>- nix found a workaround to install on /nix but it’s a pain involving APFS volumes and synthetic.conf<p>- homebrew relies on ruby which will be removed in a future version<p>- with the impending Damocles sword of notarized binaries it will be a serious pain to do package management<p>And that’s just the most structural ones. Death by a thousand cuts isn’t far off.<p>The X of Mac OS X has been dropped for some time now for branding reasons, but reality seems to come to terms with that symbolic move.
At no point in my life has it ever been hard or regretable to install Linux on anything. I hear talk about trackpads and Bluetooth not working, but I've never experienced this at all. Maybe it's because I use i3 and vim but it just seems like if you want a development environment what more do you need besides a working terminal and a robust package manager which every distro has out of the box. Mac has always just seemed like a gimmick to me and after getting one at work I just find that at best it feels like a bloated freeBSD. If I wanted Unix there are plenty of superior alternatives and if I want to get work done I install Linux.
> What bothers me the most though is that Apple has removed the man pages from their online documentation. [..] So far, the best we can get is doing a search on the open source repository… until that goes away.<p>...Or you can just use the `man` command, which still works fine.