I'm one of the largest dispatch-on-linux users right now. In fact, I'm
reasonably sure I'm THE largest. I have an application in production that uses
some 400 dispatch calls.
On Linux, I'm running Swift 3 in production, essentially because Dispatch/Linux
in 2.2 does not even exist. On OSX/iOS, I compile the same codebase with Swift
2.2, because that's the version that's released, and using released software is
a sane thing to do.
This proposal places me in the uncomfortable situation of trying to somehow
smooth out a truly MASSIVE API delta with #if. And that's not going to happen.
Realistically, what I will do is create some kind of FrankenSwift that either
backports the new API to Swift 3 or the old API to Swift 2. And that is a ton
of work, really stupid work, and I would infinitely prefer to spend that time
doing something actually useful to the world. To be clear, I don't fear
migration; what I fear is the heisenmigration, where one of my platforms must
migrate, and the other ones can't.
More broadly, I am concerned about the direction the language is going where we
do not even have working libraries yet and already we are doing sweeping API
changes to them. I suspect this is motivated by a fundamentally incorrect
premise–the premise that because it's not released yet, we can get away with
it. When actually that's backwards: we can get away with breaking changes
later, but if we do them now we will ruin everything. Let me explain.
Right now, Linux Swift programmers exist. And they need to be able to solve
ordinary problems, like writing a string to a file, or spinning up a background
thread. And I do mean: sometime before Late 2016. No amount of telling them
"don't do that, it's not released" is going to stop this. The only question is
whether upstream is going to be the repo that solves their problem, or whether
they go to solve the problem somewhere else. Because when they go somewhere
else, they invest there.
Increasingly, because upstream is not interested in the problem, I am seeing
Linux folk go solve the problem somewhere else. Just counting the projects I'm
personally aware of, there are 3 foundation alternatives and 1 package manager
alternative. All because upstream has no sane path to e.g. reading a file on
disk in the kind of timeframe working programmers actually need to do it in.
What we *should* be doing is creating libraries that *work*, *releasing them*,
and then we can do as much API Disneyland as we want without harassing the
working programmer.
1. If we're out of bugs to fix, why not release? Then folks like me can get
off the snapshot treadmill and we won't be annoyed by massive API delta until
we can do it all at once, which is (relatively) easy.
2. If we're not out of bugs to fix, why not work on them, and then release,
and then come back to this?
3. Since Swift 3 will have a stable ABI, why not ship both libdispatch2 and
libdispatch3 and let the programmer plan her own migration? I'm not even sure
the stable ABI part is relevant, since Dispatch is almost entirely C.
All of these are saner alternatives to the proposal, and all of them achieve
the stated goal (e.g. we still end up with happy modern APIs).
I don't mean to pick on this proposal specifically, I agree with the need to
modernize the API surface area. But if we continue to do breaking changes
first and releases later I'm concerned about where the early adopters will get
pushed to.
Drew
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
