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.

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

Why are you talking about mobile devices?

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.

Ruby isn't fast enough, and it would chew battery on a phone and make some apps impossible to do correctly. Ruby is a great language, it's my favourite hands down, but all that sugar comes at a cost. Even in ruby, we often use c libs to do the heavy lifting, they're just wrapped by ruby using the C extension framework.

The RubyMotion folks disagree:

RubyMotion for Android features a completely new Ruby runtime specifically designed and implemented for Android development. This is a new implementation of the Ruby language, it does not share code with RubyMotion for the Objective-C runtime. We are using the RubySpec project to make sure the runtime behaves as expected.

...

We feature an LLVM-based static compiler that will transform Ruby source files into ARM machine code. The generated machine code contains functions that conform to JNI so that they can be inserted into the Java runtime as is.

...

RubyMotion Android apps are packaged as .apk archives, exactly like Java-written apps. They weight about 500KB by default and start as fast as Java-written apps.

http://blog.rubymotion.com/post/87048665656/rubymotion-3-0-s...

It's a bold claim, but I haven't seen anything to back it up. I haven't tried all the apps made with the framework, but I haven't seen too many heavy apps that would require the power. Every game is a puzzler of some sort it seems. Nothing to really test if it is fast enough for gaming, or time critical operations.

That doesn't actually dispute either of the claims you're saying it does. Everything you just quoted can be true and Ruby could still be too slow compared to Objective-C and chew up too much battery.

Swift is not anything like JavaScript. And unfortunately ruby isn't powerful enough to do what Apple needs, but I agree that it would be nice if they could have chosen something with more syntactic elegance, although I'd have preferred it if they'd just gone in the direction of Smalltalk.

I presume you haven't programmed lisp, because although there is very little syntax to memorize, there are a huge number of functions.

I can't say that Swift is like JavaScript, my technical knowledge is not enough to have an opinion about it. I say that looks like, or using the right terms, has as much syntactic elegance as JavaScript.

I programmed a little bit in Autolisp (lisp dialect for AutoCAD scripting) as amateur and what I liked about it is that everything works the same way (even if you don't know all functions is not a big deal), it's just a list. JavaScript looks like a mixture of paradigms and syntax, trying to please everybody. When I don't program in it often I forget most of the stuff. Probably it needs to be like this but it doesn't look like an optimal solution.

> And unfortunately ruby isn't powerful enough to do what Apple needs

I'd say on the power spectrum of programming languages, ruby is MORE powerful than swift.

There are so many things you can do in ruby that you can't do in swift, especially along the lines of reflection. The only stuff swift has that ruby doesn't comes in way of restrictions eg. typing.

>And unfortunately ruby isn't powerful enough to do what Apple needs

If this was the main and only reason such that removing this limit Apple would have used Ruby, then why in your opinion didn't Apple try to implement themself something like RubyMotion (which was made by a company a thousands orders of magnitute smaller)?

RubyMotion author used to work for Apple. When Apple shut down their MacRuby efforts, he left Apple and started his own company to continue the work.

Doesn't prove anything about Ruby's suitability, though.

You seem to care a great deal about a topic you don't yet know enough about. You seem to have a superficial attraction to Ruby, which is fine, but it doesn't actually make Ruby better in any meaningful way. If you actually use a language and make real programs in it, you'll stop being a beginner before long, and your opinion now will be irrelevant even to you. Ruby is my go-to language for getting things done, but there is still a whole lot that is awesome in Swift.