
Let’s Bolt: low-level libraries designed to make developing mobile apps easier - _pius
http://blog.parse.com/2014/01/29/lets-bolt/
======
drewcrawford
I actually wrote a promise library for iOS (and didn't release it). The
postmortem is here: [http://sealedabstract.com/code/broken-
promises/](http://sealedabstract.com/code/broken-promises/)

The tl;dr is that you can run into trouble on the iOS platform if you don't
enforce a strict 1:1 chain of cause/effects and are very careful about the
timing of adding new links to the chain.

This library doesn't appear to do that, and they appear to consider this a
feature, and actively push you in that direction. For example, a bullet in the
readme is that tasks are "fully composable" and another bullet point discusses
adding new tasks to the tree on-demand. These can work on some platforms, but
iOS isn't one of them, and so this really reads like someone familiar with JS
or .NET trying to add "missing" functionality to iOS without considering why
these patterns are not generally used on iOS. Plus, it's trying to achieve API
similarity with Android, which is a code smell.

So I would really advise against using this library, at the very least use it
a in a superficial way that would be easy to tear out later. If you really
want to do this promises thing, I would push you toward Reactive Cocoa, which
I am also skeptical about but it's been around much longer, seems to have a
much more mature API, and I know at least some smart people who've used it
successfully.

~~~
davelee
It really sucks that this is the top comment. To use the cliche: This is why
we can't have nice things.

Please consider the following as a more frank replacement tl;dr:

"My promises implementation didn't work out _for me_. Maybe I just didn't go
about it the best way, but judge for yourself by reading about my individual
experiences, references from 70's papers, a bunch of 'what ifs', no code, no
benchmarks, no constructive alternatives, and repeated use of 'we' instead of
correctly using 'I'."

Is the above unfair? Maybe somewhat, but if so only as unfair as your
representation. I enjoyed your GC article, but any good points to take from
"Broken Promises" (or your above comment) are impossible to see through the
thickness of pejoratives.

~~~
drewcrawford
This probably isn't the right place to discuss the article, but I don't think
your summary is either accurate or applicable. For example, the article does
include code, it does provide constructive alternatives, it goes well beyond
my experience by outlining a general proof for why the problem I was working
on is theoretically intractable, it was hacked on by multiple people (hence
"we"), and so on.

Even if that list of criticisms were accurate, the correct response to an
article that has "no code, no benchmarks, no constructive alternatives" is to
respond with code, benchmarks, and constructive alternatives. What you do here
is essentially say "Because this does not meet some threshold of evidence I
can ignore it" instead of what rational people say, "I should collect better
evidence but in the meantime let's rely on the evidence that is available".

Finally, you don't really state an articulable position on the actual issue,
so the discussion does not really advance. My position is pretty clear:
promises work on the platform if and only if there are particular guarantees,
and the README of this project explicitly says you don't get those guarantees,
ergo this library is trouble. Clearly you object to this position but you do
not say, let alone defend, any alternative theory that would have predictive
power over whether or not promises will work for a project and for that
reason, the comment does not add anything to the discussion.

~~~
davelee
> This probably isn't the right place to discuss the article

yeah, you're probably right.

------
xpaulbettsx
This first "Bolt" is effectively a port of .NET's Task Parallel Library to iOS
/ Android. Even down to the method names (trySetException).

I may be biased, but if you're writing a complex app, you'd do better to get
thee to:

* [https://github.com/Netflix/RxJava](https://github.com/Netflix/RxJava)

* [https://github.com/ReactiveCocoa/ReactiveCocoa](https://github.com/ReactiveCocoa/ReactiveCocoa)

~~~
memracom
Lots of people are rediscovering Functional Reactive Programming piecemeal on
various different platforms. I agree with you that it is best to skip the
piecemeal stuff and go directly to Reactive Extensions and its various ports
such as the two links you mentioned. And for iOS/ReactiveCocoa, there is a
good book on the topic
[https://leanpub.com/iosfrp](https://leanpub.com/iosfrp)

~~~
seanmcdirmid
These libraries have nothing to do with FRP, even Rx stops at just event
streams that precede FRP by many years; reactive cocoa seems to be that plus
some form of data binding. I'm not even sure if calling it impure FRP is
correct.

------
j_s
This looks like a step in the right direction. In previous HN discussions,
Facebook's approach to mobile app development hasn't gone over so well:

Dalvik patch for Facebook for Android |
[https://news.ycombinator.com/item?id=5321634](https://news.ycombinator.com/item?id=5321634)

    
    
      > I can't believe an app requires 8M RAM just for method names!
    
      > They actually did have the stonkingly huge arrogance to monkey patch the OS
    
      > Basically these engineers decided to be really clever, painted themselves 
      > into a corner, smashed a hole in the wall so as to escape from said corner, 
      > and then bragged about how great they are.
    

Updated Facebook for Android requires "Retrieve Running Apps" permission |
[https://news.ycombinator.com/item?id=5543363](https://news.ycombinator.com/item?id=5543363)

    
    
      > Is there any good reason they don't split the functionality to the 
      > appropriate applications? Then maybe they wouldn't have to hack dalvik to 
      > run a simple facebook client.

------
mattgreenrocks
This looks really similar to an anti-framework I've been working on for a long
while for RubyMotion:

[https://github.com/mattgreen/elevate](https://github.com/mattgreen/elevate)

IMO, tasks are the real unit of composition for UI-facing apps: "do this,
update the UI in that way, and do this if cancelled". It sure beats writing
ad-hoc state handling code every time.

Edit: Bolt's idea of tasks is a lot smaller than Elevate's. Bolt seems to take
a promise-esque approach, whereas Elevate combines futures (for I/O) and GCD.
It appears Bolt is closer to ReactiveCocoa in spirit.

------
leobelle
For Android at least, the async tasks pieces seem very interesting, although a
little verbose. I guess it can't be helped in Java though. If Android adopts
Java 8's lambdas that should clean up nicely though.

~~~
rst
Or you could try programming in Scala, though it's an awkward fit to Android.
Scala's standard library is large enough to strain size limits on an Android
app, to the point that shrinking things down with ProGuard is pretty much a
requirement.

That said, using the tools of more modern JVM-based languages can tighten up
your code in all sorts of ways. An experiment along those lines is here:

[https://github.com/rst/positronic_net](https://github.com/rst/positronic_net)
[http://rst.github.io/positronic_docs.html](http://rst.github.io/positronic_docs.html)

------
seivan
How is [https://github.com/BoltsFramework/Bolts-iOS#chaining-
tasks-t...](https://github.com/BoltsFramework/Bolts-iOS#chaining-tasks-
together) better than using group_dispatch signaling?

The latter would give you cleaner code and get rid of any nested blocks.

------
mattschmulen
i think reactive task (JavaScript style promise) paradigm's are great for the
mobile interaction use case. small segmented operations that async update the
ui. block style coding mechanism are also nice because you can see the
callback code next to the invoke. very interesting . seems like combining this
with an JavaScript runtime would be even more powerful

~~~
mackey
Here at Brightcove, we have been using ReactiveCocoa internally in our new iOS
SDK. We expose some ReactiveCocoa to the consumers, but not a whole lot yet.

Overall I love working with ReactiveCocoa. The guys at github run an open
source project the way it was meant to be run and are extremely helpful.

One downside is that it makes debugging memory leaks/crashes/retain cycles
more difficult but that will be inherent in any block based API. It is still
worth using it though.

------
vitd
OK, admit it. You also thought it was a reference to "My So-Called Life,"
didn't you?

