[Jtsummers]

The primary difference between swift and dynamic languages like ruby is the type system. An existing language like ruby would've been unsuitable if one of the objectives was a safer type system. Taking ruby and putting a static type system into it would've been interesting, but would've created a fork of the primary ruby language, which has its own pain points (being so close, but not quite the same language).

On the other hand, an existing language with the right type system features would've needed a lot of rework to make it suitable for the object model and API.

Or it'd be like C++, where you can program C++ for Linux, or C++ for Windows, and a lot of things may be the same, but then you find out that one of them has different semantics for what you thought was a standard library.

[pekk]

Nothing about making programs for mobile devices in any way requires static typing.

[gress]

Why are you talking about mobile devices?

[Jtsummers]

Nothing about making programs requires static typing ever. If you're targetting reliable, performant programs, then static typing is a boon.

Dynamically typed languages require additional tooling beyond the language itself to provide a lot of the reliability/correctness assistance that good statically typed languages can offer. See the dialyzer for erlang, a very useful tool, but a separate tool. If you want to see an example of statically typed languages that require extra tools, see C and its various static analysis tools. Swift, Rust, Ada, etc. (I'm sticking with the more imperative ones with good or better than average type systems) don't require that extra tooling. It's not an additional step. It's just part of the language.

If you want good performance, that is C/Fortran level performance, you either need a sufficiently smart compiler (see SBCL) that can take type hints (derived from the static analysis tools perhaps), or static typing. Static typing (and good static typing like the languages I've mentioned seem to have) improves performance compared to dynamically typed languages. You can remove all the possible branches based on the types used for addition if you know that you're adding two ints, two floats, an int and a float at compile time. In a tight loop, having to select between all those options is a drag on performance. Statically typed languages can reduce that to a single path, instead of the 3 branching paths I just came up with (and there are probably more for most languages).

Besides, performance on mobile is critical. We're depending on miniscule (relatively) batteries. The better performance we can get out of our code, the better battery life we'll see. Every app that's written in a dynamically typed language that doesn't have good type hints (like CL, there are probably others) is going to be a huge drag on battery performance.

Fuck, a friend writes python to run on clusters for numeric code (simulations, he's an Aerospace Engineer). Fucking brilliant, the type system hinders his performance compared to Fortran/C/others. He has jobs that take 24 hours to run on an 80-machine cluster. I hate to consider how much time is wasted because they don't use a language with even a simple static type system like Fortran and C offer.

I love dynamically typed languages, my favorite languages are erlang and common lisp, scheme is a close 3rd. But they have their place, and if performance is one of your requirements they (in general) are not what you want. If reliability is what you want, something that knocks out a huge percentage of errors right off the bat is wonderful, dynamically typed languages (without extra tooling) can't tell you, until you run the program, that you added an integer to a binary blob. And delightfully some are also weakly typed, meaning they'd permit such an operation and you'd get bizarre errors later on in your execution.

--

EDIT: Some scheme implementations offer good performance. Do they, like SBCL, implement static analysis under the hood?

EDIT: I may have left in words that should've been removed when I switched gears in mid-sentence.