On Wed, May 11, 2016 at 1:30 AM, Drew Crawford via swift-evolution < [email protected]> wrote:
> 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. > FWIW, I believe the first Swift 3 preview branch is being created from master tomorrow... > > Drew > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
