
Why Rubyist Will Love Swift - mattsears
http://littlelines.com/blog/2014/06/11/why-rubyist-will-love-swift/
======
Argorak
I'm not buying this. It basically says "there are a few concepts in Ruby that
map nicely to Swift". There are quite a lot of concepts that don't map, for
example evaluated classes, which enable things like:

    
    
        class Foo
          include Virtus.model
    
          attribute :foo, String
        end
    
    

Now, I could go on like this, but that would be moot. I just question the
basic premise of saying that just because 5 features match somewhat nicely
(even if it involves more braces of different kinds), those would be reasons
for Rubyists to love Swift. Much in contrast, similarity might not be the most
compelling reason to switch to something different.

------
heydenberk
Optional binding in JavaScript is a misfeature, and Ruby's looks that way too,
because 99% of the time when you do this:

    
    
        if (hasAccess = true) {
            doSomething();
        }
    

you meant to compare, not assign. So when I saw this Ruby example, I was not
amused:

    
    
        if current_user = find_current_user
           notify_user(current_user)
        end
    

However, the Swift equivalent is the best of both worlds:

    
    
        if let currentUser = findCurrentUser() {
           notifyUser(currentUser)
        }

~~~
chc
The thing that's interesting about optional binding is Swift is that it is a
special construct for unwrapping optionals, not a normal assignment. If you
try to bind to something that is _not_ an optional using that syntax, it won't
work. For example:

    
    
      if let currentUserIsAuthorized = true { // COMPILE ERROR
        ...
      }
    

This makes it useful for the one case where you'd actually want it without
introducing any pitfalls, because using it incorrectly will be a syntax or
type error.

------
angersock

      if current_user = find_current_user
        notify_user(current_user)
      end
    

Funny to see an anti-pattern in C/C++ so lauded in another community.

Also, you know what I like about Ruby? I can write it and it'll run
everywhere, and it is maintained by a vibrant community effort. Where's that
on this list?

~~~
Karunamon
You realise that you're talking about a prerelease, right? The language hasn't
even been available to developers for a month yet, let alone the general
public.

Give the vibrant community effort some time.

~~~
jerluc
I could be wrong, but I believe the parent is referring to the inability for a
"vibrant community" to maintain Swift as a language implementation (instead of
Apple), which is very different than Ruby. There's no doubt in my mind that
there will be swarms of people developing _with_ the language, but AFAICT,
we'll mostly only see Apple developers working _on_ the language itself.

~~~
coldtea
> _There 's no doubt in my mind that there will be swarms of people developing
> with the language, but AFAICT, we'll mostly only see Apple developers
> working on the language itself._

Well, it's not like there's a "vibrant community" working on Ruby either.

AFAIK, the core developers are Japanese (
[http://rubycoreteam.heroku.com/](http://rubycoreteam.heroku.com/) ) and the
core communication and decisions is mostly opaque to outsiders, and new
language stuff mostly comes in bunches pre-formed.

As opposed say to Python and the PEPs discussion, PHP etc.

~~~
jerluc
I entirely disagree. As most all open source projects, Ruby has a set of core
contributors, but is clearly open to community contribution, as can be seen
from their Git repo's history
([https://github.com/ruby/ruby/network](https://github.com/ruby/ruby/network)).
And no, core communication and decisions are NOT opaque to outsiders, as is
the usual case with most open source software (Google groups, mailing lists,
IRC channels, etc). And lastly, language features and design is a product of
the RubySpec, which is itself a Git repo for people to contribute to possible
language design/syntax/core libraries for Ruby VM implementors to introduce
([https://github.com/rubyspec/rubyspec/](https://github.com/rubyspec/rubyspec/)).

------
mcosta
Why Rubyist Will Love Swift? Because Apple has published it.

Disclaimer: I have walked the tutorial and reference and I belive it is
fantastic. I am waiting for someone to release a linux compiler.

~~~
sigzero
That might be a long while.

------
asolove
The comparisons with scala and c++ are stronger. This is a large language,
with a lot of complexity from having to maintain compatibility with an
existing environment, plus lots of new concepts bolted on top. Like those
languages, the time to basic proficiency may be faster than with their
predecessors, but the time to mastery will be much longer.

~~~
tendom
Scala, yes, but not C++ at all. Indirectly from C#, perhaps (and there is a
fair bit of that), but there is very little that borrows from C++ at the
language level.

~~~
Glide
Oh I would love to see a write up comparing it with Scala idioms. As a person
who has done C# for a while a lot of idioms translate very well to Swift.

The if let x = whatever {} syntax in Swift is damn brilliant after looking at
a ton of C# code with the as check.

~~~
nileshk
Here is a Swift vs Scala syntax comparison:

[https://leverich.github.io/swiftislikescala/](https://leverich.github.io/swiftislikescala/)

And also, a comparison to C#:

[http://pietschsoft.com/post/2014/06/07/Basic-Comparison-
of-C...](http://pietschsoft.com/post/2014/06/07/Basic-Comparison-of-C-and-
Apple-Swift-Programming-Language-Syntax)

------
Karunamon
As a wannabe-rubyist who thinks reading Obj-C is somewhere between having a
migraine and using H2SO4 eye drops, so far I'm in love with the language. I'm
doing lots of tripping over the Cocoa APIs, though, in no small part due to
Xcode.

The error messages you get when you've done something wrong are unintuitive at
best and downright misleading at worst.

Example: I've got a field I want to render an image in. It's represented as an
object of type NSImageCell.

I've got my image file defined as an object of type NSImage. So far, so good.

I type the . after the image cell, and I'm presented with a number of
autocomplete suggestions. One of which is a method called "setValue" which
accepts an object as an argument.

Okay cool.

    
    
        myCell.setValue(NSImage(named: "myImage"))
    

Compile and.. instacrash with "Unrecognized selector"

What?

Some research turns up that this error means you've tried to send a message to
(call a method on) something that doesn't accept that type of message.

Turns out that the method I needed is called setObjectValue. And it also
accepts an object as an argument.

So, Xcode. Why did you give me setValue as an autocomplete when it isn't valid
on that object? Why are these method names nearly identical? _facepalm_

And that's before I get into the almost completely worthless inline error
messages. "Cannot convert to $T1". What?

I really, really like the language, but Xcode is trying its damndest to turn
me away. I've got a stack of bugs/feature requests that need to be entered
into Apple's reporting tool - hopefully some of these are just warts that'll
get fixed as Xcode 6 comes out of beta.

~~~
allsystemsgo
It's still in beta dude. Night and day difference between beta and gold
master. If you're turned away from a _brand new_ language due to an IDE's
autocomplete, then you're in for a world of hurt when you start learning all
the Cocoa APIs.

~~~
mitchty
Heh, this is the truth. Most of the difficulty of learning Swift I think will
lie in learning Cocoa. Just like Objective-C that.

~~~
micampe
That is true for every programming language and platform pair. The syntax is
always the easy part, but unfortunately the only thing most people fixate on.

~~~
mitchty
Valid point, also amusing that everyone focuses on the trivial part of syntax
over the difficulty of the environment it lives in.

------
galfarragem
I'm not a rubyist, neither I am a professional programmer, but I'm sad that
Apple didn't/couldn't choose Ruby as their main language. Nowadays I'm
deciding what programming language to learn as a hobby. Reality (market) tells
me that should be JavaScript or right now Swift (looks like javascript for
me). It makes me sad, I wish it could be Ruby. So clean and clear. Everything
makes sense, I don't need to memorize almost nothing.

Edit/Disclaimer: My first contact with programming (besides BASIC) was
Autolisp (Autocad scripting) and my professional field is design.

~~~
gress
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.

~~~
MrBra
>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)?

~~~
srgpqt
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.

