Live data from Hacker News

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

developer.apple.com

181–190 of 450 posts

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

#181
post #172

Earlier quoted context omitted.

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 ve…

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 li…

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

IIRC, HFS actually uses a ':'.

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

#183
post #77

Earlier quoted context omitted.

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

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

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

#184

Earlier quoted context omitted.

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…

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.

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

#185
post #123

Earlier quoted context omitted.

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…

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

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.

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

#186
post #59

Earlier quoted context omitted.

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.

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

#187
post #76

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 s…

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

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

#188
post #76

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 s…

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

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

#189
post #183

Earlier quoted context omitted.

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

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

#190

Earlier quoted context omitted.

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.

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. I too have used it nearly daily for over 15 years.
Post reply on HN