The gomobile tool is part of the broader project, but that particular CL is about `gomobile build`, a sub-command designed to build all-Go apps. From inside Go, we have only built out access to portable APIs like OpenGL.
This app uses a different mode of the same tool, `gomobile bind`. This lets you use a Go package from inside an Android app, or from ObjC in an iOS app. It is related but parallel work.
This work is the extension of the Go on mobile experiment for Android, which was originally proposed here: http://golang.org/s/go14android.
Over the past several months, several open source contributors (most notably minux) and I have been working on darwin/arm and darwin/arm64 support for Go 1.5. We can build binaries, and we can build Go packages as C archives that can be compiled into an ObjC program.
At the same time Hana has been extending gobind (http://golang.org/s/gobind) with ObjC support, and came up with the idea of turning Rob's Ivy into an app. Hana built the Android app, I did the iOS app.
This is a few hundred lines of ObjC/UIKit for the UI, calling into a Go function:
func Exec(line string) (string, error)
With the bulk of the app being the actual Ivy implementation in Go.
It will be open source when I find the hours in the next week.
Fun little app to mess with and I'm glad Go's branching out. That said, I was very disappointed when the app didn't include the ability to clear the screen.
Thanks. Screen clearing and state saving are on my todo list. It's just a big list. I'd like to get the source code published first, and that means landing some toolchain cleanups first. (The android app is a bit ahead, it has a clear button.)
This is awesome. Ignoring the fact that it is written in Go, the iOS calculator only goes up to 100,000,000 and it is super annoying. Free ones have obnoxious advertisements.
Now, I want to learn to write iOS apps in Go as well.. Super neat and a great app to start with
15 decimal digits around is the approximate limit for a 64-bit IEEE floating-point number, which is what the built-in Calculator uses (most non-integral math done on computers uses either 32-bit of 64-bit IEEE floating-point numbers). The exponential notation is because floating-point numbers can represent absurdly large values, it just is limited on precision. So you can represent 10^31, you just can't represent 10^31 + 1.
Some users do expect arbitrary precision for basic operations (addition, subtraction, multiplication, division) since the Calculator app that comes with Windows does it[0].
I could possibly see the point of this if Swift didn't exist (ObjC is my second least-favorite language, right behind C ), but otherwise it seems like little more than an interesting POC.
That's not news, Apple allows a lot of languages to run on their OS now.
What matters is: how extensive is the support for this language on iOS? As far as this app shows, the support for Go looks very primitive and not really applicable to anything but toy apps.
Operators in APL had the same associativity and precedence semantics. On his github page, Rob Pike describes Ivy as "an interpreter for an APL-like language", so it makes sense.
Doesn't this break the policy of Apple? As I know, Apple allows apps only made of some restricted languages from when Adobe tried to make iOS apps with Flash.
LuaJIT for iOS, confusingly, does not do JITing. Normal apps on iOS are unable to mark pages as executable, so it's impossible to JIT; it's not just an app store review-enforces restriction.
I did actually think that Apple required the use of Apple's developer tools for iThing apps --- so unless you can compile your target language into C, C++, ObjC (or Swift, I suppose) and then use XCode to compile the final binary, your app would be rejected. Has this changed?
Yeah, but it's still producing native code via a non-Apple toolchain. I'd want to check the T&Cs carefully, in case Apple notice and pull the app further down the line.
The policy used to exist, it was Section 3.3.1 of the iOS Developer Agreement in 2010 [1]:
"Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs"
Steve Jobs also wrote some emails on the issue [2], but by September 2010 and following a potential Federal Trade Commission investigation, the clause had been removed again [3].
Rob Pike tweeted about it (the Android version) recently [1]. I ported [2] the app to the web within a few hours. The port involves ~70 lines of Go, 22 lines of HTML, and 24 lines of CSS [3].
Python seems faster than this gopherjs solution.
I thought they'd be about equal or the JS being faster since JS is supposed to be really fast at math.
I ran 2123456 in both and Python was quite fast, Ivy on gohperjs quite slow
in a HN comment, the HN software will decide that this means a 2, then an emphasized empty string, then 123456, and the results will be indistinguishable to readers from the much smaller number 2123456.
Writing a single shared library for different platforms makes sense. I think Google do this currently with java & then convert the java to objc, but if go provides an alternative it might finally be time for me to learn it...
> Writing a single shared library for different platforms makes sense
i've always taken this approach... like since the 90s, although not necessarily a library, but shared code. there has always been a way to do this thanks to the ubiquity of C - its just been that Google has been reluctant to allow 3rd parties to do on android what they do internally for reasons I really don't know...
very good of apple to not reject it for the terrible ui... well done though its good to see new tech making its way into the walled garden of the app store.
I recently ported IPFS (http://ipfs.io) to iOS and have been running it on my iPhone for the last few months .. I was very pleasantly surprised how little fuss was required to get Go compiling for the iOS platform, and reminded once again that underneath all the garden trimmings, iOS is really just a little Unix workstation.
(BTW, IPFS on iOS: not ready for primetime, but .. what a world it will be when it is!)
I strongly feel that once Swift makes it to be open sourced the path from iOS native to Android (cross) will become much simpler then (go:logic, java:android UI, objc:iOS UI).
I think Google is more interested in Dart as a cross platform language.
See the Sky project https://github.com/domokit/sky_sdk/ which uses Dart as the UI framework. Currently runs on Android- but I believe the intent is to have it run on iOS as well.
From my perspective, Dart makes a lot more sense as an application language when compared to Go.
I wish Go had a proper way to do graphics and GUI. It would be great to make Go desktop and mobile apps without all the messy interop or launching a web browser locally.
62 comments
[ 20.6 ms ] story [ 132 ms ] threadhttps://news.ycombinator.com/item?id=9815464
This app uses a different mode of the same tool, `gomobile bind`. This lets you use a Go package from inside an Android app, or from ObjC in an iOS app. It is related but parallel work.
Cocoa/UIKit works in ObjC.
ObjC is a super set of C that translates the objc parts to calls to objc_msgsend.
Go supports ARM/OSX.
Go makes it pretty easy to call into C
Therefore it should be pretty easy to port to iOS, all you need to do is to write a bit of go to interface with objc_msgsend.
Over the past several months, several open source contributors (most notably minux) and I have been working on darwin/arm and darwin/arm64 support for Go 1.5. We can build binaries, and we can build Go packages as C archives that can be compiled into an ObjC program.
At the same time Hana has been extending gobind (http://golang.org/s/gobind) with ObjC support, and came up with the idea of turning Rob's Ivy into an app. Hana built the Android app, I did the iOS app.
This is a few hundred lines of ObjC/UIKit for the UI, calling into a Go function:
With the bulk of the app being the actual Ivy implementation in Go.It will be open source when I find the hours in the next week.
Now, I want to learn to write iOS apps in Go as well.. Super neat and a great app to start with
More importantly, why should they be forced to?
It's a bug.
[0] http://blog.codinghorror.com/if-you-dont-change-the-ui-nobod...
What matters is: how extensive is the support for this language on iOS? As far as this app shows, the support for Go looks very primitive and not really applicable to anything but toy apps.
https://news.ycombinator.com/item?id=9866152
I'm curious why they chose to have expressions evaluated in right-associative order.... Basically why is operator precedence equivalent?
Was it done because it was easier to code? Don't understand why this would be of significant difficulty.
Won't this complete diversion from accepted notation hinder adoption?(not intending to imply they are aiming for widespread adoption)
Could anyone who would use the app for an actual purpose chime in here?
Totally understand this is a pet-project/example btw. Just wondering.
Cool shit googlers :)
Video about it (Nov 2014): "Implementing a bignum calculator" https://www.youtube.com/watch?v=PXoG0WX0r_E
I think you're thinking of when iOS decided not to support Flash in the browser.
"Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs"
Steve Jobs also wrote some emails on the issue [2], but by September 2010 and following a potential Federal Trade Commission investigation, the clause had been removed again [3].
[1] https://daringfireball.net/2010/04/iphone_agreement_bans_fla...
[2] https://www.taoeffect.com/blog/2010/04/steve-jobs-response-o...
[3] http://www.peterfriese.de/apples-updated-developer-license-t...
[1]: https://twitter.com/rob_pike/status/619995629566058496
[2]: https://twitter.com/shurcooL/status/620084337401171968
[3]: https://twitter.com/shurcooL/status/620343011671609344
I ran 2123456 in both and Python was quite fast, Ivy on gohperjs quite slow
I know GopherJS math package uses some native JavaScript funcs that are fast, but I think math/big does not have a native implementation.
Writing a single shared library for different platforms makes sense. I think Google do this currently with java & then convert the java to objc, but if go provides an alternative it might finally be time for me to learn it...
i've always taken this approach... like since the 90s, although not necessarily a library, but shared code. there has always been a way to do this thanks to the ubiquity of C - its just been that Google has been reluctant to allow 3rd parties to do on android what they do internally for reasons I really don't know...
its still a 3rd class citizen, despite being the backbone of the platform.
[1]: https://www.reddit.com/r/golang/comments/3d0stz/ivy_first_an...
(BTW, IPFS on iOS: not ready for primetime, but .. what a world it will be when it is!)
See the Sky project https://github.com/domokit/sky_sdk/ which uses Dart as the UI framework. Currently runs on Android- but I believe the intent is to have it run on iOS as well.
From my perspective, Dart makes a lot more sense as an application language when compared to Go.