
“Adds iOS build support to gomobile command” - ConceitedCode
https://go-review.googlesource.com/#/c/11587/8
======
wiremine
So, let me get this straight:

* You can write part of your app in Go

* You can share that code across your Android and iOS apps?

Is that right? If so, seems like a solid use case for Go. Until Swift compiles
to Android...

~~~
akhilcacharya
Is it really that beneficial to do this? Your system API's are still in
Java/Obj-C/Swift, so all you can really share is business logic.

Has anybody had any real benefit from doing this in the past? I know Facebook
did it with moments, but the image processing code could at least be shared
here.

~~~
sandGorgon
is that still correct after the Dalvik -> ART move ? I always thought a long
term strategy around ART was to move away from the jvm dependency.

Just in time for all the Oracle lawsuits confirming that Java apis are patent
encumbered.

~~~
on_and_off
Nothing official but after all these efforts with ART and jack&Jill both of
which are not tied to java, it seems likely that Google is at least
experimenting with another language.

~~~
akhilcacharya
What else would Google use? Android dev is pretty reliant on the OO model.

~~~
on_and_off
Well, that's an open question...

IMO, moving to another language should be taken as an opportunity to fix the
oversights of the Framework. Things like the atrocious Activity lifecycle or
the backstack handling.

There are several contenders :

-Dart : Google controls this language and the Dart Team is openly experimenting with their own Android fralewirj. The results are extremely underwhelming so far though.

-Kotlin : A better Java. I doubt that it would solve Android legal troubles though.

-Rust : the language has so many interesting ideas. I don't know if its complexity is warranted in Android's context though.

-a new language inspired by Kotlin, Rust, Go, Swift,... . Why not ? It would need a serious value proposition in order to be interesting though.

-insert your pet language here : everyone seems to want to develop Android apps in their most familiar language ...

Again, the official word from the Android team is that Java is the language of
the platform for the time being. I just hope that if they are indeed planning
a switch to another language, it will be discussed in the open beforehand.
Such a debate is not always constructive, but it could be very important in
Android's context.

------
avinassh
OT: Does Gerrit provide any extra features helping in code review, compared to
Github? We use Github and it does fine.

~~~
uxp
Gerrit and GitHub provide two different paradigms. If you want a
straightforward answer, then yes Gerrit provides a number of extra features,
but it isn't a replacement for GitHub.

------
Gys
So this make something similar as Cordova possible ? Running a local webserver
with all logic, serving html5/css/js as GUI ? Would still need bindings for
accelerator and such (just as Cordova) but maybe its possible to use the ones
Cordova already has ?

------
eva1984
Which part of the application can be shared between iOS and Android apps that
is most suitable to write in Go? Data layer, like communication protocol?

~~~
hobarrera
go has issues on IPv6 clients, so not communication.

Probably the business logic, which is what least needs to interact with the OS
APIs.

------
pbreit
What exactly does this enable?

~~~
zaroth
Here's some good examples: [https://medium.com/using-go-in-mobile-
apps](https://medium.com/using-go-in-mobile-apps)

Judging from the popping a dialog example, I think the main use case is
reusing a Go library inside an iOS app, not any kind of standalone app
development entirely with Go. At least, not without a lot of helper libraries
which don't exist yet!

------
aaronbrethorst
Dear mods: _please_ stop 'de-editorializing' headlines when the alternative
won't make any sense. The new title for this link is nigh-unintelligible.

(the previous title was something like "Go 1.5 will add support for building
iOS apps")

~~~
dang
Take the sample bias out of your request and generalize it to all of HN, and
what you're asking will no longer sound so trivial.

Submitters make up titles all the time that are (to use the sibling comment's
words) "clear, descriptive", and wrong. Set aside the fact that HN's rules
explicitly ask people not to do that. What would you have us do?

If you say "never change them", that would flood HN with false and
manipulative titles forever. (Not that this one was false and manipulative—I
wouldn't know. But I do know that that would be the consequence of never
changing titles.) If you say "change the ones that are false and keep the ones
that are true", you're asking us to be experts on everything.

The submitted title was "Go 1.5 will have iOS support". The submitted web page
says nothing of the sort. What should we do? Being an expert on the Go
project's internal progress—that is, being an expert on everything in the
general case—is not an option. So we look for language in the article itself
that is representative of what it says. That has two merits: (1) it preserves
the neutral quality of HN's front page and (2) it's doable.

If you'd like to propose a change that doesn't demand superhuman powers of us
and wouldn't destroy the character of HN, please do. But getting upset over a
single suboptimal example doesn't seem serious to me. HN sees a thousand
stories a day. Not every example is going to come out optimal no matter what
we do.

~~~
aaronbrethorst
Hi Dan - fair point. To be pedantic, though, the title of this article should
then be

    
    
        Change Ibc23b6d3: cmd/gomobile: enable target=ios
        builds | go-review.googlesource Code Review
    

which a) doesn't fit, and b) doesn't make any sense. A potential technical fix
would be to allow both titles and descriptions on posts with URLs.

~~~
dang
Even pedantically, that's not true: the HN guidelines have never said you must
always use the original title. Pedantry aside, the important thing above is
_language in the article itself that is representative of what it says_.
That's both why we changed the title and what we changed it to.

> allow both titles and descriptions on posts with URLs.

I appreciate the suggestion, but we're unlikely to do that. On HN, submitting
a story conveys no special rights, and submitters do not get to frame the
story for everybody else. Framing it for everybody else effectively means
controlling the discussion. We want discussion to be driven by the article
itself, not a single user's spin. If a submitter wishes to offer a description
or say what they think is important about a story, they're welcome to do so by
adding a comment to the thread on the same footing as everybody else.

------
crazychrome
I don't think the fruit company will approve apps programmed other than objc
or swift.

~~~
matthewmacleod
They've been doing that for ages already.

Please do at least a cursory bit of research before commenting about an area
you're clearly not familiar with! It will save a lot of time, and prevent FUD
like this from continuing to spread.

~~~
hughw
Well, I'm glad he asked, because I didn't know all these languages mentioned
in the responses, were supported on iOS and the App Store.

