6 ms·

Let’s Bolt: low-level libraries designed to make developing mobile apps easier

82 points by _pius 13y ago

vitd 13y ago
OK, admit it. You also thought it was a reference to "My So-Called Life," didn't you?
mattgreenrocks 13y ago
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 13y ago
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 13y ago
  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
j_s 13y ago
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.
mattschmulen 13y ago
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 13y ago
  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.
xpaulbettsx 13y ago
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
- yareally 13y ago
  > Even down to the method names (trySetException). At least they're no longer capitalized, as .net naming standards generally follow.
- yapcguy 13y ago
  Will they be visually cleaner? Look at all those square brackets in the Bolt examples. [[[[[self findAsync:query]
- memracom 13y ago
  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 13y ago
    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.
seivan 13y ago
How is https://github.com/BoltsFramework/Bolts-iOS#chaining-tasks-together https://github.com/BoltsFramework/Bolts-iOS#chaining-tasks-t... better than using group_dispatch signaling? The latter would give you cleaner code and get rid of any nested blocks.
drewcrawford 13y ago
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.
- bklimt 13y ago
  I should point out that the Parse iOS SDK has been built on top of this task framework for over a year, and the Facebook iOS SDK has been using it for months. So it has been battle-tested in at least thousands of production apps. Maybe promises aren't appropriate for every single situation, but we certainly haven't noticed anything that makes them particularly tricky in iOS.
- davelee 13y ago
  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.

82 points by _pius 13y ago

vitd 13y ago

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

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 13y ago

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 13y ago
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

j_s 13y ago

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.

mattschmulen 13y ago

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 13y ago
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.

xpaulbettsx 13y ago

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

yareally 13y ago
> Even down to the method names (trySetException). At least they're no longer capitalized, as .net naming standards generally follow.
yapcguy 13y ago
Will they be visually cleaner? Look at all those square brackets in the Bolt examples. [[[[[self findAsync:query]
memracom 13y ago
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 13y ago
  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.

seivan 13y ago

How is https://github.com/BoltsFramework/Bolts-iOS#chaining-tasks-together https://github.com/BoltsFramework/Bolts-iOS#chaining-tasks-t... better than using group_dispatch signaling? The latter would give you cleaner code and get rid of any nested blocks.

drewcrawford 13y ago

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.

bklimt 13y ago
I should point out that the Parse iOS SDK has been built on top of this task framework for over a year, and the Facebook iOS SDK has been using it for months. So it has been battle-tested in at least thousands of production apps. Maybe promises aren't appropriate for every single situation, but we certainly haven't noticed anything that makes them particularly tricky in iOS.
davelee 13y ago
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.