[fauigerzigerk]

I don't see how you can conclude from any of that what the most appropriate use case for Swift on the server side is. It's just what a couple of early adopters are talking about today.

For me, the case for Swift is that it is a modern language that doesn't waste half of the available memory on a tracing garbage collector.

The same goes for Rust, which has even more opportunities for low level optimization where necessary (and way superior string handling on top of it).

[geodel]

I can conclude that by looking at for example Go offers today vs effort of setting Swift web framework like Kitura. IMO it is far away from general purpose server side usage.

As far as memory usage goes Swift does not color me impressed when compared to GC'd language:

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

[fauigerzigerk]

Adoption is not the same as appropriateness at all.

As far as memory usage goes these benchmarks are completely irrelevant. They use very little memory and they measure it in a way that is unsuitable for a memory benchmark in the first place.

The problem with tracing garbage collection is that it requires a lot (~50%) of spare memory at all times to give the GC time to catch up without slowing the program down too much.

[geodel]

Sure, May be I am wrong and Swift will be just fine for server use cases.

[solidsnack9000]

> I can conclude that by looking at for example Go offers today...

This is the kind of argument that used to be trotted out all the time for Java and Perl before it. If we always went by what was offered today, we'd never use anything new.