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.
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.
> 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...
> 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.
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 ?? "")
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
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.
> 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...
> 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.
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.
Related to using Swift as scripting: https://github.com/jrz/tools (transparent compilation vs interpreting)
Sick!
tldr;
Before:
After:Thanks for sharing! :)