
iOS 5 has garbage collection. Here comes MacRuby/iOS? - themgt
http://pogodan.com/blog/2011/06/07/macruby-on-ios-5-confirmed
======
schrototo
iOS 5 doesn't have garbage collection, it has a new compiler-level feature
called _Automatic Reference Counting_ which does pretty much what you think it
does. It's basically retain/release without you having to explicitly write
retain/release instructions.

(I don't think I'm violating any NDAs here, since ARC was up pretty big on one
of the slides at the keynote. In any case, anybody who cares about this stuff
is either at WWDC or at least has a dev account and has been pouring over the
beta docs since they've gone online.)

~~~
maximilianburke
I'm not sure why you would say this isn't garbage collection. It performs
automatic management and reclamation of resources without programmer
intervention. It doesn't operate like the GC's of the JVM or .NET CLI, but
then neither to the GCs for other languages like Lua, Python, or Perl.

~~~
drewcrawford
> I'm not sure why you would say this isn't garbage collection.

Because it isn't. Garbage collection is something that happens at run time by
a garbage collector via an algorithm like mark-and-sweep, tri-colour marking,
etc, and as a block of code that's called at runtime it A) has a lot of
information about your program and B) has a nontrivial performance impact.

Unfortunately I can't talk specifics (stupid NDA), but schrototo has said that
it's a compiler-level feature, which would automatically disqualify it as
being a bona fide garbage collector.

Speaking generically, any static feature is going to a great deal less
powerful than its dynamic equivalent. Thinking of compile-time memory
management as garbage collection is not just a leaky abstraction, it's a
broken water main flooding into the street.

Think less "auto pilot" and more "cruise control". You still have to
understand the accelerator and the break, you just don't have to use them as
much.

~~~
maximilianburke
A garbage collector doesn't need to use an algorithm like mark-and-sweep, or
two space copying. It can be something as simple as a system that scans a
block of memory looking for any sequence of bytes that appears to be a pointer
into managed memory. You don't need special compiler support or extra program
knowledge for garbage collection -- conservative collectors can be added to
any language, like using the Boehm-Demers-Weiser GC with C or C++.

Automatic garbage collection doesn't even require a garbage collector -- the
monolithic piece of code that performs the scanning and reclamation of objects
-- it simply requires freeing the programmer from the task of managing the
storage of an object. Fancy collector algorithms are meant to improve
throughput and latency -- you could definitely create an implementation of
Java that uses automatic reference counting but you'd be searching for
something faster really quickly.

If I have a language where I create a number of managed objects and the
compiler's escape analysis determines that these objects never leave the
function's scope and so changes them to be an alloca then you would have
garbage collection without involving a garbage collector.

Again, if that's what automatic reference counting is as sold by Apple then
I'd consider it to be garbage collection.

~~~
schrototo
For what it's worth, Apple sees this as distinct from garbage collection. For
new projects they recommend using ARC, even on the Mac where "real" GC is (and
will continue to be) available.

~~~
bonch
Are you willing to elaborate on this? Recommending it over garbage collection
on OS X would run contrary to their previous evangelism of GC and its
concurrent scalability.

~~~
schrototo
I can't, since I don't know any more than the next guy reading the docs. I'm
sure there'll be an in-depth WWDC session on this and I'm eagerly awaiting the
videos.

(I haven't done any Mac OS programming with GC, so I really don't know
anything about it, but I've always heard people say the GC is not all that
great. So my own uneducated guess is that while GC is messy and complicated,
ARC is simple & doesn't have any runtime overhead (they say in the docs that
retain/release is now much faster, as is autorelease using the new syntax).)

------
adriand
The arguments over performance, compiler features, and the definition of
garbage collection aside, I'm curious what members of the HN community think
about the chances of Ruby becoming an iOS-approved programming language.

It seems as though the groundwork has been laid, and from an aesthetic
perspective, Ruby seems like a nice fit for Apple. Plus, it's not Python,
which is arguably Google's baby.

~~~
jcnnghm
I think it's a certainty that it's a feature in the pipeline. The only
question is when it will happen, which is really a function of performance and
memory usage. I suspect this is a big step forward.

~~~
nupark2
I don't think it's quite the certainty you're making it out to be. Ruby is a
step sideways, if not backwards, from Apple's current strategy. We're far more
likely to see an Objective-C without the C than we are to see Ruby as a first
class development target for iOS.

~~~
skidooer
Ruby essentially is Objective-C without the C.

If Apple was looking for a language that moved away from the low level C, what
benefit would an "Objective" language bring over MacRuby, which is already
using the native Objective-C system frameworks?

~~~
nupark2
__A non-runtime type system. __

First class familiar Objective-C-style messaging and block syntax.

Stable, mature, well defined language invariants on par with Apple's
requirements for its own APIs and languages.

"Objective-C without the C" would look more like Smalltalk or Strongtalk with
a near identical syntax, not Ruby.

~~~
skidooer
I may be misunderstanding you, but:

When you remove the C bits, Objective-C and Ruby use the same type system,
conceptually speaking. They are both descendant from Smalltalk; the main
feature differences really come down to the syntax alone.

I really like the idea of a higher level Objective-C-based language, I just
don't necessarily see the business appeal of creating and maintaining a brand
new language that only brings a more familiar, to Objective-C developers at
least, syntax. Especially given the amount of effort Apple has been putting
into MacRuby.

~~~
nupark2
_When you remove the C bits, Objective-C and Ruby use the same type system,
conceptually speaking. They are both descendant from Smalltalk; the main
feature differences really come down to the syntax alone._

Objective-C is typed -- not just the C part, but the 'Objective' part too. You
can cast around type system, but it's there.

The new compiler even uses inference of those types in order to implement ARC.

 _Especially given the amount of effort Apple has been putting into MacRuby._

Not Apple, just a few people that also work for Apple.

~~~
skidooer
The type system exists, but when working with the Objective half of the
language, it is mostly meaningless, at least from a developer's point of view.
With the C parts removed, you could replace every type definition with id and
your program would run just fine.

The article says that MacRuby is bundled with Lion as a private framework.
Surely they wouldn't bundle it if they weren't using it? And being a private
framework, it is not there for the benefit of third-party developers.

~~~
nupark2
Objective-C is typed, and that's considered (by Apple, and most developers) as
a feature, not just a legacy inheritance from C.

~~~
jonhohle
Objective-C types are optional and the language is dynamic, and that's
considered (by Apple and most Objective-C developers) a feature.

    
    
        id something = nil;
        [something countForObject: nil];
    

Completely valid, won't crash your program, and only enough type information
to satisfy the compiler (but largely meaningless for anything but the most
basic static analysis). The only requirement for the above to compile is that
countForObject: is a selector defined somewhere in the include path for the
file. Even that is a relatively soft requirement since you can pass arbitrary
selectors to any object.

And none of this has anything to do with ARC, as far as I can tell.

There was a first class language on Mac OS X which was fully statically typed.
It was deprecated with Leopard and never introduced on iOS. The dual nature of
Objective-C is one of its attractive properties.

~~~
nupark2
Most of what you just said is simply not true. Without the method types, the
compiler will print a warning, infer the wrong ABI and generate the wrong
code. If am ambigious match ia made, the wrong code will be generated. What
you just wrote may work, but only because the compiler works to match against
_defined_ methods _types_ , and even then it can and will get it wrong.

The support for 'id' is only intended to serve as a mechanism to get around
the lack of parameterized types, and as part of ARC, the compiler _does_ now
infer the types for alloc/init.

~~~
jonhohle
> Without the method types, the compiler will print a warning, infer the wrong
> ABI and generate the wrong code.

Did you even try my example? No compiler warnings are generated (nor should
the be). What do you mean by defined method types? It is simply looking for
any selector which matches on any class because there is not enough statically
available information to know any different. Messages are always passed
dynamically.

Are we talking about Objective-C? Are you familiar with NSInvocation? Or
performSelector:, performSelector:withObject:,
performSelector:withObject:withObject:? Or NSNotificationCenter's
addObserver:selector:name:object:? This is all done at runtime. No special
type information is available to the compiler when using these. Objective-C
messagse are always sent dynamically, so the only ABI concerns are how the
stack is prepared, and not the interface of the class of an object. You can
define methods and swap them out at runtime, this feature would be useless if
everything had to be known at compile time.

ARC needs to know that the types of Objective-C objects, id still works fine,
beyond that it needs to know no other type information from what I can tell.

It seems we are talking past each other. Objective-C is not like C++, though.
All methods are virtual, always. The runtime goes through great pains to make
that efficient and still allow complete dynamism. This is orthogonal from ARC.

~~~
nupark2
_> Did you even try my example? No compiler warnings are generated (nor should
the be)._

Only because it managed to match on a defined method type. If a class
declaration hadn't been found _at compile time_ with the given declared
method, it would have issued a warning.

If the match was ambiguous and the types incorrect, it would have emitted
incorrect code, and possibly a warning (or always, with -Wstrict-selector-
match).

 _> What do you mean by defined method types? It is simply looking for any
selector which matches on any class because there is not enough statically
available information to know any different._

By 'defined method types', I mean methods declared on visible classes that
match the given selector.

If it matches on the wrong one, the wrong dispatch function and/or the wrong
function call epilogue will be emitted.

Method calls are _ABSOLUTELY NOT_ ABI identical for all possible types. I
can't possibly emphasize this enough.

For example:

    
    
      - (void) performWithObject: (NSObject *) object;
    
      - (void) performWithObject: (NSObject *) firstObj, ...;
    

The instructions emitted for a vararg dispatch ARE NOT the same as the non-
vararg dispatch on all platforms, and incorrect method selection will result
in undefined behavior on dispatch.

 _> Are you familiar with NSInvocation? Or performSelector:,
performSelector:withObject:, performSelector:withObject:withObject:? Or
NSNotificationCenter's addObserver:selector:name:object:? This is all done at
runtime._

 _> No special type information is available to the compiler when using these.
_

Yes, it is. Methods have associated type encodings that describe the return
and argument types, and that's used to perform runtime dispatch with
NSInvocation. This is why NSInvocation is so slow -- similar to libffi, it
must evaluate the types and construct the call frame at runtime. It does this
by evaluating the type data associated with method implementations by the
compiler.

Methods such as performSelector rely on specific type conventions (such as
void return, optional single object argument) and will fail if used with
targets that do not match the expected convention.

~~~
jonhohle
You're right. I hadn't realized the compiler not only ensures the selector
exists, but does type C-style type checking on dynamic calls as well. I was
surprised to see that two messages with the same selector but different
parameter types required a type cast to use.

Of course IMPs aren't identical if they take different parameters. This
doesn't affect interchanging Objective-C types though. Yes, the arity and
order are important, but the compiler doesn't enforce anything beyond that a
pointer is passed for id types.

~~~
nupark2
Cheers to the peer comment regarding HN discourse. Unfortunately (?) I have
more :)

 _> This doesn't affect interchanging Objective-C types though. Yes, the arity
and order are important, but the compiler doesn't enforce anything beyond that
a pointer is passed for id types._

This is true prior to ARC: all ObjC pointers are the same size, and hence ABI-
compatible given equivalent arity/order. It's theoretically possible that a
future ABI could be incompatible between two methods returning void vs pointer
return value, but currently, all supported ABIs return pointer-sized values in
a register.

 __However __, with ARC, this changes. The type system has been effectively
extended to denote the required referencing behavior for calling code. This
means that for a given arity/order, you must _also_ have equivalent
referencing attributes.

------
themgt
Eloy says not confirmed:
<http://twitter.com/#!/alloy/status/78089941829160961>

~~~
alloy
Yeah, sorry to rain on your parade, bro. But these kind of ‘confirmed’
articles, in the end, help nobody. Users will be sad when it doesn’t happen,
whereas neither Apple nor the MacRuby team have actually confirmed/promised
this. Sorrow all around isn't good publicity.

Thanks for the update, though! :)

~~~
uxp
Automatic Reference Counting is not Garbage Collection, but it's a start, and
can weakly be used as a sort of garbage collection. It is up on iOS5's site
page, however, so that part is confirmed for now.

<http://developer.apple.com/technologies/ios5/>

~~~
alloy
I’m talking about “MacRuby on iOS 5 - CONFIRMED!!!”.

------
alloy
Although I empathize with your wishes, your article is way too
sensationalistic. Let me confirm (I’m not with Apple); MacRuby on iOS has
_NOT_ been confirmed.

~~~
alexbell
Agreed. ARC is not garbage collection, nor is it an indication in any way that
MacRuby on iOS is coming.

------
patrickg
Someone has made a comment on HN before like this: if the title of a
submission is a question, the answer is most likely 'no'.

------
justincormack
You dont _need_ OS support for gc to do gc in a scripting language. Wax,
<https://github.com/probablycorey/wax> which is a Lua binding for UIKit does
all the gc for you. The framework just needs to do all the bookkeeping for you
behind the scenes.

~~~
prodigal_erik
When the platform's native data structures are explicitly managed but not
garbage collected, the language runtime can't just steamroller them, it has to
notify the platform about each individually becoming disused. It's the worst
of both worlds, you pay for O(n) work to handle garbage as well as not
reclaiming memory immediately, and it's worse with an API that takes graphs of
first-class objects rather than buffers which happen to contain the bits you
want (which are incredibly risky, but the language runtime can handle that
once and for all).

------
sspringer
More important for MacRuby on iOS seems to be the "static" compile option (not
functioning yet) see <http://bostonrb.org/presentations/102>
(<http://vimeo.com/25213324>) @ 32:03 - 32:48 in combination with
<http://bostonrb.org/presentations/106> (<http://vimeo.com/25232412>) @ 06:15
- 07:40; with this "static" option some Ruby features will not be supported. -
Also note @ 05:26 - 05:58 in the first video :-)

------
pornel
I hope this will be better than LLVM Analyzer's warnings about missing
retain/release, which in my experience catches most, _but not all_ of missing
retains/releases.

------
nick_urban
I wonder what effect this will have on HTML5 app development.

Would the Ruby developers who are considering building HTML5 apps go for
native Ruby instead if given the option?

~~~
cincinnatus
HTML5 apps are going to be heavy on JavaScript. It is a matter of personal
preference or dislike of JS which is a big factor here.

More important though is how performant and tight the app is, I think most
developers who are wanting to have the best performance will choose native.

------
jemeshsu
Not on topic but anyone knows why Lion comes with Ruby 1.8.7 and not 1.9
branch?

------
sspringer
[http://www.research.ibm.com/people/d/dfb/papers/Bacon03Pure....](http://www.research.ibm.com/people/d/dfb/papers/Bacon03Pure.pdf)

------
lisperforlife
Does this mean that we can write apps that target iPhone and iPad with
MacRuby?

------
ori_b
This is probably going to hurt performance a whole lot more than proper GC,
because now the compiler throws in a whole bunch of retain/release statements
where they aren't really needed.

Unless they're doing some pretty strong analysis to remove redundant reference
operations.

~~~
dirtyaura
I think it's still easier to ensure performant code as reference counting is
more deterministic than GC. I assume you can turn off ARC for compilation unit
if you want, so performance critical code can be manually managed.

~~~
ori_b
Naieve reference counting incurs a bus lock across all processors on every
assignment, more or less. That's quite painful.

~~~
gonzo
How many processors (cores) do most iOS devices have?

GC is still supported on MacOS X.

~~~
cpeterso
One core, but the Apple A5 in the iPad 2 and iPhone 4GS/5 (the flagship
devices for iOS 5) has two cores.

------
brianbal
I hope this is true

