Live data from Hacker News

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

developer.apple.com

341–350 of 450 posts

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

#341

Earlier quoted context omitted.

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.

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.

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

#342
post #181

Earlier quoted context omitted.

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

In A/UX you could use both.

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

#343

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…

> Ruby on Windows is a nightmare. Any software on Windows is a nightmare. Nothing works as it should, least of all MS's own crapware.

Perl and CPAN works well enough on windows :-)

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

#344
post #132

Earlier quoted context omitted.

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.

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.

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

#345

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…

> Ruby on Windows is a nightmare. Any software on Windows is a nightmare. Nothing works as it should, least of all MS's own crapware.

Hint, not every OS is an UNIX clone. Thankfully.

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

#346
post #306

Earlier quoted context omitted.

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

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

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

#347

Earlier quoted context omitted.

> not requiring root permissions is a feature Not requiring root to install software to system directories is a security bug, not a feature. In a practical sense Homebrew elevates you to root and in the process messes up the permissions of a /usr/local, which, being on $PATH, opens users up to vulnerabilities.

Nonsense. You are using users in plural. Macs are not typically used as multi user machines. Certainly not by developers. And when they are, so what? Technically, the permissions are only changed for the user that installs homebrew, which requires root access to change the permission, and not for the other users. If that's a problem for you, configure it to install stuff elsewhere. Also, /usr/local is completely empt…

> You are using users in plural.

Because I am talking about people who use Macs in general?

> Macs are not typically used as multi user machines. Certainly not by developers.

There are developers who share Macs: not everyone can afford to have a computer to themself. But that's still beside the point: regardless of the number of humans using the computer, Macs still have multiple permission levels, and there is always a "root" with more permissions than you.

> configure it to install stuff elsewhere

Yeah, this tends to break if you actually try this. Homebrew explicitly tells you that this is not well supported.

> Also, /usr/local is completely empty on a fresh OSX installation and the whole point of homebrew is to have the stuff you install with it on the path.

Yes, but there are better, and more secure ways to do this. What you should be doing is require sudo to install to a directory that is global and automatically on $PATH, or install locally to ~/bin (for example) and then put that on your $PATH. The way Homebrew does it, where it changes the permissions of /usr/local's folders, is bad because it opens the door to attacks when system software running as root picks up binaries from $PATH (which you have now changed ownership and permissions of to be writable by your user) making any code execution bug instantly become a privilege escalation attack. This isn't the first time I've had this discussion, so I have more detailed explanation which links to an actual example of this being exploited in practice: https://saagarjha.com/blog/2019/04/26/thoughts-on-macos-pack...

> The only vulnerability is the single user of the laptop being an idiot.

Aside from the fact that the security hole exists regardless of me doing something stupid, I'd like my software to work as well as possible in the face of me being an idiot ;)

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

#348
post #255

Earlier quoted context omitted.

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

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

#349
post #216

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…

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

> struct layouts and sizes

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

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

#350
post #142

Earlier quoted context omitted.

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.
Post reply on HN