Live data from Hacker News

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

developer.apple.com

1–10 of 450 posts

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

#5
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?

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

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

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

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

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

#8

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?

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

#9

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.

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

#10
post #5

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.

Post reply on HN