[HN Gopher] Automate all the things with Swift Subprocess
___________________________________________________________________
Automate all the things with Swift Subprocess
Author : jakey_bakey
Score : 33 points
Date : 2025-10-13 15:55 UTC (7 days ago)
(HTM) web link (blog.jacobstechtavern.com)
(TXT) w3m dump (blog.jacobstechtavern.com)
| jbverschoor wrote:
| Related to using Swift as scripting: https://github.com/jrz/tools
| (transparent compilation vs interpreting)
| jakey_bakey wrote:
| Sick!
| jakey_bakey wrote:
| Thanks for sharing! :)
| hooch wrote:
| tldr;
|
| Before: let process = Process()
| process.executableURL = URL(fileURLWithPath: "/bin/ls")
| let pipe = Pipe() process.standardOutput = pipe
| try! process.run() process.waitUntilExit() let
| data = pipe.fileHandleForReading.readDataToEndOfFile() if
| let output = String(data: data, encoding: .utf8) {
| print(output) }
|
| After: let result = try await run(
| .name("ls"), arguments: ["-1"], output:
| .string(limit: 1 << 20) )
| print(result.standardOutput ?? "")
| w10-1 wrote:
| OP objections to scripting in Swift are (1) requires a build
| step; and (2) subprocess API requires wrapping for each tool --
| both are true.
|
| The Swift team did just release Subprocess, but it doesn't break
| hugely new ground. Swift has had API's for running system
| processes, and the best wrapper has been the Shwift library[1]
| which supports async operations and bash-like syntax for
| captures.
|
| Wrapping tools with static functions that make convenient choices
| is helpful, but the real benefit comes with using type-safe API's
| - e.g., records for git-log output, enumerations for
| configuration, etc.
|
| For the update-build-and-run dance, there are tools like clutch
| [2]. It helps most when you have a bunch of scripts that benefit
| from common (wrapping) libraries - as with builds, processing
| pipelines, etc. - because the common code doesn't need to be re-
| built, only the script.
|
| - [1] shwift: https://github.com/GeorgeLyon/Shwift
|
| - [2] clutch: https://github.com/swift-nest/clutch
| John23832 wrote:
| I feel like Swift could be such a great language if it was only
| given the proper care and feeding of open source. Instead it's
| largely locked in the apple walled garden with tokens given to
| the outside.
| w10-1 wrote:
| > it's largely locked in the apple walled garden with tokens
| given to the outside
|
| So, the compiler, stdlib and runtime, core libraries, build
| system ... not enough? What else would you want?
|
| I feel the problem is not what's in open source, but that the
| open-source community cannot really form, since no outsider can
| significantly change what the Apple contributors decide. Some
| of the peripheral projects have relatively free rein, but they
| can't compete e.g., with server libraries elsewhere.
|
| Also, the Apple people have to track what Apple needs, so
| they'll put out stuff per schedule that works for them but
| falls apart on untested code paths. And they don't really
| deprecate stuff, so you end up with multiple ways to do the
| same thing. And there seems to be no budget for documentation,
| which is quite far behind esp. for concurrent programming. And
| so it goes.
|
| We'll see where they get with ownership and inter-op with
| C/C++/Java. Concurrency + ownership + legacy + FFI inter-op =>
| combinatoric complexity...
| John23832 wrote:
| > So, the compiler, stdlib and runtime, core libraries, build
| system ... not enough? What else would you want?
|
| First class IDE support (Xcode is not that). Better
| documentation. The build system only half works. Better
| packaging. I can keep going.
|
| The swift ecosystem often feels like just enough was done to
| lock in iOS devs (but not enough to actually provide a good
| developer experience) and then they stopped because Apple has
| no incentive to do more than that.
|
| > I feel the problem is not what's in open source, but that
| the open-source community cannot really form, since no
| outsider can significantly change what the Apple contributors
| decide. Some of the peripheral projects have relatively free
| rein, but they can't compete e.g., with server libraries
| elsewhere.
|
| So you agree. This is exactly the point I was making.
| randomNumber7 wrote:
| I think the problem is that C/C++ interop in practice sucks
| because they made pointers annoying to use (for ideological
| reasons. Pointer == Evil).
|
| It's sad because technically they have amazing C/C++ interop,
| but using s.th. like SDL2 to write some toy game would be way
| less pain in C++.
|
| You need to link against C libraries as a compiled system
| language and you just need a lot of pointers to do anything
| meaningfull in C.
___________________________________________________________________
(page generated 2025-10-20 23:01 UTC)