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.
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.
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...
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.
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.
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.
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.
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].
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.
[1]: https://twitter.com/rob_pike/status/619995629566058496
[2]: https://twitter.com/shurcooL/status/620084337401171968
[3]: https://twitter.com/shurcooL/status/620343011671609344