Ivy: iOS app written in Go | Hacker News Reader

Ivy: iOS app written in Go

itunes.apple.com

152 pointsAYBABTME58 comments

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].

[1]: https://twitter.com/rob_pike/status/619995629566058496

[2]: https://twitter.com/shurcooL/status/620084337401171968

[3]: https://twitter.com/shurcooL/status/620343011671609344

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

Unfortunately, if you write

  2[star][star]123456

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.

Do you have a link to the Python version? What was used to generate it? Also, what browser did you use, I'm curious.

I believe he means plain python, which automatically promotes big integers to the bigint type

Oh, ok.

I know GopherJS math package uses some native JavaScript funcs that are fast, but I think math/big does not have a native implementation.

Rob Pike's Ivy: https://github.com/robpike/ivy

Video about it (Nov 2014): "Implementing a bignum calculator" https://www.youtube.com/watch?v=PXoG0WX0r_E

Worth to mention, only the logic part is shared[1], for UI, both on Android and iOS native tools are used.

[1]: https://www.reddit.com/r/golang/comments/3d0stz/ivy_first_an...

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

Fun trick: turn your phone to landscape mode while in Calculator and you get 26 digits instead of 9.

26? I get 15 digits before it switches to exponent representation. This is on iPhone 5s running iOS 8.4.

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.

Why should the user of a calculator care how the numbers are represented internally?

More importantly, why should they be forced to?

It's a bug.

Well, what if these users you speak of are trying to accomplish more than just homework?

Some users do expect arbitrary precision for basic operations (addition, subtraction, multiplication, division) since the Calculator app that comes with Windows does it[0].

[0] http://blog.codinghorror.com/if-you-dont-change-the-ui-nobod...

Yep, typo, 16 not 26.

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.

The point is to demonstrate that Go runs on iOS, regardless of what other languages also run on iOS.

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.

You can write business logic for both iOS and Android using Go and only have to write the UI specific stuff in Swift/objc or Java.

A friend of mine was recently at gophercon and sent me this link: https://sourcegraph.com/blog/live/gophercon2015/123653512740

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

Huh? You can use C libraries on Android with JNI & the NDK. In fact it's how most games do it.

i never said you can't. i just said you could...

Reluctant how?

they held back a toolchain for android native development for ages, but yet quite obviously used one to build the OS itself.

its still a 3rd class citizen, despite being the backbone of the platform.

anyone care to explain the technical how-to that made this possible.

Could be related to this

https://news.ycombinator.com/item?id=9815464

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.

I can estimate it as follows.

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.

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.

Just wanted to thank you and acknowledge your work - Go on iOS represents a significant opportunity. Thanks!

previous discussion:

https://news.ycombinator.com/item?id=9866152

Cool stuff!

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 :)

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.

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

You'll probably be interested in https://github.com/google/gxui, targets desktop, mobile and web.

Here's some really basic Qt bindings I've been helping with recently https://github.com/salviati/go-qt5

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.

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.)

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.

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.

No, Apple does not allow JIT. It does not dictate language use.

I'm using LuaJIT on iOS just fine, and experienced no restrictions from Apple about using it.

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.

Alas, you are right and I have learned something new today. It seems that Safari is the only JIT'able process we developers can gain access to ..

There are plenty of apps on the App Store with using Flash (Adobe AiR). As well as other languages like JS (React Native, Titanium).

I think you're thinking of when iOS decided not to support Flash in the browser.

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?

This project compiles the Go code to a C library that can be linked quite easily with ObjC.

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].

[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...

What's the point? Swift is a much nicer language to work in, it's more performent and iOS supports it...

The same Go code works on Android and desktop too.

and web.

Reply on news.ycombinator.com