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

[Tino Heth]

> 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