5 ms·

Apple is removing a number of scripting environments from OS X, so they won't have to maintain them. Not sure if they can remove Perl; it's tangled up in stand

Apple is removing a number of scripting environments from OS X, so they won't have to maintain them. Not sure if they can remove Perl; it's tangled up in standard C libraries I think, and would be hard to kill.

Someone 3y ago
> Not sure if they can remove Perl; it's tangled up in standard C libraries I think Indeed. char *cmd = "/usr/bin/perl -e 'print join(chr(0), @ARGV), chr(0)' -- "; (https://github.com/Apple-FOSS-Mirror/Libc/blob/2ca2ae74647714acfc18674c3114b1a5d3325d7d/gen/wordexp.c#L192 https://github.com/Apple-FOSS-Mirror/Libc/blob/2ca2ae7464771...) That’s to implement wordexp, a POSIX function that probably is best avoided unless you really really need it. I think the sanest implementation would move lots of code from the shell into the standard C library, but that probably has its own problems, as FreeBSD does something similar. https://man.freebsd.org/cgi/man.cgi?query=wordexp&apropos=0&sektion=3&manpath=FreeBSD+15.0-CURRENT&arch=default&format=ascii https://man.freebsd.org/cgi/man.cgi?query=wordexp&apropos=0&...: ”IMPLEMENTATION NOTES The wordexp() function is implemented using the undocumented freebsd_wordexp shell built-in command.” OpenBSD actually has the sanest approach. “The only winning move is not to play.” or, in Theo’s words, “I think we should stand up to crap and not ever impliment it” (https://www.mail-archive.com/tech@openbsd.org/msg02325.html https://www.mail-archive.com/tech@openbsd.org/msg02325.html)
- jrockway 3y ago
  This is probably a nice project to throw to a team at Apple that wants to ship something in Rust. Many years ago, you had to write the C library in C, but those days are over, and doing a bunch of string processing doesn't sound that fun. (If the code's already written, sure, keep it. But if you're writing brand new code to replace Perl oneliners, there are probably a lot of fun bugs you're going to add with a C rewrite.)
  - tedunangst 3y ago
    The problem is not the doing it in C, but the precisely matching the behavior of some existing code.
    - nijave 3y ago
      I wonder how hard it is to just compile the perl (as a library from the perl codebase) vs calling the executable It seems that's a decent middle ground unless there's not a good API on the perl side
    - jrockway 3y ago
      Yup, absolutely. My take is that because you get to do something fun (start from scratch in a good language), the thousands of test cases you have to write and then run against the old implementation doesn't feel so bad. (I have to imagine a good amount of mailing list archeology will also be required. "How did Linux mess this up in 1992?" etc.)
  - stephen_g 3y ago
    Apple have chosen to go all in on Swift for their first-party code, from the kernel to the libraries to the apps. Even things running on microcontrollers (but there’s no official or standard embedded Swift subset yet). It’s quite interesting actually that they’ve very intentionally focused on building two-way transition layers so they can start gradually integrating Swift into codebases built in C and Objective-C, and recently new support for C++ and Objective-C++. Which is the best way to do it, big rewrites are the worst, after years of effort you often have a replacement with fewer features than the old one! So being able to replace little bits at a time and write new features in a new language is cool. See this talk for the details on that - https://youtube.com/watch?v=lgivCGdmFrw https://youtube.com/watch?v=lgivCGdmFrw So don’t expect to see any Rust code from Apple, although of course they might ship third party things written in it at some point.
    - detourdog 3y ago
      They are definitely working a long term plan. The development apple has been doing with identity since they bought NeXT is very sophisticated. I think they are about to make a major push that will put their ecosystem at another level.

Someone 3y ago

> Not sure if they can remove Perl; it's tangled up in standard C libraries I think Indeed. char *cmd = "/usr/bin/perl -e 'print join(chr(0), @ARGV), chr(0)' -- "; (https://github.com/Apple-FOSS-Mirror/Libc/blob/2ca2ae74647714acfc18674c3114b1a5d3325d7d/gen/wordexp.c#L192 https://github.com/Apple-FOSS-Mirror/Libc/blob/2ca2ae7464771...) That’s to implement wordexp, a POSIX function that probably is best avoided unless you really really need it. I think the sanest implementation would move lots of code from the shell into the standard C library, but that probably has its own problems, as FreeBSD does something similar. https://man.freebsd.org/cgi/man.cgi?query=wordexp&apropos=0&sektion=3&manpath=FreeBSD+15.0-CURRENT&arch=default&format=ascii https://man.freebsd.org/cgi/man.cgi?query=wordexp&apropos=0&...: ”IMPLEMENTATION NOTES The wordexp() function is implemented using the undocumented freebsd_wordexp shell built-in command.” OpenBSD actually has the sanest approach. “The only winning move is not to play.” or, in Theo’s words, “I think we should stand up to crap and not ever impliment it” (https://www.mail-archive.com/tech@openbsd.org/msg02325.html https://www.mail-archive.com/tech@openbsd.org/msg02325.html)

jrockway 3y ago
This is probably a nice project to throw to a team at Apple that wants to ship something in Rust. Many years ago, you had to write the C library in C, but those days are over, and doing a bunch of string processing doesn't sound that fun. (If the code's already written, sure, keep it. But if you're writing brand new code to replace Perl oneliners, there are probably a lot of fun bugs you're going to add with a C rewrite.)
- tedunangst 3y ago
  The problem is not the doing it in C, but the precisely matching the behavior of some existing code.
  - nijave 3y ago
    I wonder how hard it is to just compile the perl (as a library from the perl codebase) vs calling the executable It seems that's a decent middle ground unless there's not a good API on the perl side
  - jrockway 3y ago
    Yup, absolutely. My take is that because you get to do something fun (start from scratch in a good language), the thousands of test cases you have to write and then run against the old implementation doesn't feel so bad. (I have to imagine a good amount of mailing list archeology will also be required. "How did Linux mess this up in 1992?" etc.)
- stephen_g 3y ago
  Apple have chosen to go all in on Swift for their first-party code, from the kernel to the libraries to the apps. Even things running on microcontrollers (but there’s no official or standard embedded Swift subset yet). It’s quite interesting actually that they’ve very intentionally focused on building two-way transition layers so they can start gradually integrating Swift into codebases built in C and Objective-C, and recently new support for C++ and Objective-C++. Which is the best way to do it, big rewrites are the worst, after years of effort you often have a replacement with fewer features than the old one! So being able to replace little bits at a time and write new features in a new language is cool. See this talk for the details on that - https://youtube.com/watch?v=lgivCGdmFrw https://youtube.com/watch?v=lgivCGdmFrw So don’t expect to see any Rust code from Apple, although of course they might ship third party things written in it at some point.
  - detourdog 3y ago
    They are definitely working a long term plan. The development apple has been doing with identity since they bought NeXT is very sophisticated. I think they are about to make a major push that will put their ecosystem at another level.