Automate All the Things with Swift Subprocess
Posted3 months agoActive2 months ago
blog.jacobstechtavern.comTechstory
supportivepositive
Debate
20/100
SwiftAutomationDevelopment Tools
Key topics
Swift
Automation
Development Tools
The post introduces Swift Subprocess, a tool for automating tasks using Swift, and the community discusses its potential applications and benefits.
Snapshot generated from the HN discussion
Discussion Activity
Active discussionFirst comment
7d
Peak period
12
168-180h
Avg / period
5.7
Comment distribution17 data points
Loading chart...
Based on 17 loaded comments
Key moments
- 01Story posted
Oct 13, 2025 at 11:55 AM EDT
3 months ago
Step 01 - 02First comment
Oct 20, 2025 at 1:25 PM EDT
7d after posting
Step 02 - 03Peak activity
12 comments in 168-180h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 21, 2025 at 4:22 PM EDT
2 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45569787Type: storyLast synced: 11/20/2025, 1:39:00 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
Before:
After:https://developer.apple.com/documentation/foundation/fileman...
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...
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.
The SourceKit LSP server has worked fine for me, although I admit I spend most time in Xcode.
> Better documentation.
What’s the issue here? The documentation seems comprehensive.
> The build system only half works. Better packaging.
What are the issues with SwiftPM?
- `async` being all-or-nothing
- Strict `Serializable`
- ???
- async coloring every function - actors coloring every function and type - everything is now in tasks - sendable/non-sendable closure especially when integrating with legacy code
You write any piece of code that touches async and you have to add 4 additional keywords
The weird open stache {} brackets that are permitted when the last argument of a function is a closure. This is a ridiculous feature, combined with ResultBuilder, made the language worse. And I will assert that both of these awful features increased complexity for the sole purpose of making SwiftUI syntax approachable to JavaScript devs.
On the other hand, I hate react-native and prefer to not live in a world where all my software is glitchy and slow, so I understand Apple’s motivations. React-native is a threat with hip modern syntax. Apple still used the icky MVC with the crusty old CALayers.
I just hope it was worth it!
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.
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
Unless it's cashed, of course, then you get the extra overhead on first run, but lower overhead on at the subsequent runs? This is even mentioned in the article, so what's the issue in this specific peculiarity?