
Ivy: iOS app written in Go - AYBABTME
https://itunes.apple.com/us/app/ivy-big-number-calculator/id1012116478?mt=8
======
dmitshur
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](https://twitter.com/rob_pike/status/619995629566058496)

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

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

~~~
ericfrederich
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 2 __123456 in both and Python was quite fast, Ivy on gohperjs quite slow

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

------
aric
Rob Pike's Ivy:
[https://github.com/robpike/ivy](https://github.com/robpike/ivy)

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

------
vhakulinen
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...](https://www.reddit.com/r/golang/comments/3d0stz/ivy_first_android_app_in_100_golang_on_google/ct0rcdj)

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

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

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

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

------
estefan
A friend of mine was recently at gophercon and sent me this link:
[https://sourcegraph.com/blog/live/gophercon2015/123653512740](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...

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

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

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

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

~~~
crawshaw
This work is the extension of the Go on mobile experiment for Android, which
was originally proposed here:
[http://golang.org/s/go14android](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](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.

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

------
molecule
previous discussion:

[https://news.ycombinator.com/item?id=9866152](https://news.ycombinator.com/item?id=9866152)

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

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

------
fit2rule
I recently ported IPFS ([http://ipfs.io](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!)

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

~~~
tree_of_item
You'll probably be interested in
[https://github.com/google/gxui](https://github.com/google/gxui), targets
desktop, mobile and web.

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

~~~
wstrange
I think Google is more interested in Dart as a cross platform language.

See the Sky project
[https://github.com/domokit/sky_sdk/](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.

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

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

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

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

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

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

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

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

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

~~~
vhakulinen
The same Go code works on Android and desktop too.

~~~
sangnoir
and web.

