> With the existence of Swift on the server, dynamically linked, independently > distributed frameworks will not be an Apple-only issue - this extends beyond > Apple's OS X-based platforms towards how dynamic frameworks link against each > other as if they are to be distributed separately. > > It is short sighted to suggest that all Swift deployments will be under > Apple's control. I'm really looking forward for server-side Swift — I'm planning for years to extend my portfolio in that direction, and Swift could really push that diversification.
But I had a concrete reason for interest in writing my own backend-code: Server-side was imho broken on large scale, and it still isn't fixed yet… I can run circles around those poor Java-developers who have to fight crusted structures and deal with sluggish tools like Maven and Tomcat (and Java ;-).* It seems to me I'm not alone with my opinion, because there are already alternatives on the rise: Look at Docker — it's a huge success, because it not only takes application and libraries to build a robust unit; it even includes a whole OS! On iOS, it already hurts when you have a bunch of Swift-Apps which all have the stdlib bundled — but on the server, this doesn't matter, and I'm convinced it would be a bad move to propagate shared frameworks. - Tino * of course, there are agile alternatives — but in my environment, most of the big players wouldn't even consider something like Rails _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
