[swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Jean-Daniel Dupas]

> Le 11 juil. 2016 à 09:39, Tino Heth via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> 
>> 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.

Server side swift is already alive:  https://developer.ibm.com/swift/

> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution