I apologise for not being clear enough. The "mashup" style also happens between apps/processes as well as within them. There are resources tracking counter parties.
For example the canonical way to structure a music app would be an activity (gui) for visuals, a content provider to provide the library and a service to play the actual audio. There is no requirement for these to be in the same app/process and it is pretty much immaterial to the code. But if your activity is communicating with the service (eg to send play/pause/next in one direction and getting the current play position and file in the other) then Android does housekeeping to make sure the right thing happens such as what happens when either side crashes or exits.
Android can do memory management within a process - for example if you switch to your email app, the music playing service can keep going, and the activity can be terminated (it is usually told).
This isn't remotely the same thing as swapping out pages as is done by the kernel. Additionally a whole bunch of the pieces have no kernel representation (eg a content provider). There is an IPC mechanism (binder) that has both kernel and user space components working in harmony.
To have something analogous in C, your "app" would be a large number of shared libraries (dozens), and they would be dynamically loaded and unloaded. They would talk to each other and shared libraries in other processes. There would be garbage collection, lifetime management and possibly reference counting. Calls into them could be asynchronous, as well as calls out. Managing all that would be non-trivial "scaffolding".
> ... almost everything has near-seamless support for calling C API functions
Dalvik already has that - using JNI. The pattern is to implement your interface to Android in Java and then call through to C when you need to.
The problem with Go is that it isn't designed to play well with others. It doesn't support dynamically linking, and expects to own the process - being in charge. The work the posting is about is some toolchain hacks that make it so a dynamically loadable binary is produced instead of an executable. There is then work to make the Android API available which is non-trivial, and Java flavoured.
> I would be plenty happy if they would just provide a native C API like GNU/Linux does
The "native" API it would provide would need to be analogous to libc, glib, X (and extensions like xrandr), gnome, systemd/udev, dbus, sdl, ibus, garbage collection, shm, reference counting etc all combined (in addition to whatever I forgot). There is no "just providing" that!
>To have something analogous in C, your "app" would be a large number of shared libraries (dozens), and they would be dynamically loaded and unloaded. They would talk to each other and shared libraries in other processes. There would be garbage collection, lifetime management and possibly reference counting. Calls into them could be asynchronous, as well as calls out. Managing all that would be non-trivial "scaffolding".
It sounds like you could do it a lot more easily by just having separate processes or threads for each activity/service/whatever.
>This isn't remotely the same thing as swapping out pages as is done by the kernel.
It seems to be almost identical to the OS sending SIGTERM and then SIGKILL to the process in question however.
>The "native" API it would provide would need to be analogous to libc, glib, X (and extensions like xrandr), gnome, systemd/udev, dbus, sdl, ibus, garbage collection, shm, reference counting etc all combined (in addition to whatever I forgot).
Are you assuming the necessity of a one to one mapping between Java API functions and C API functions? I don't care about something "analogous" to libc, just give me libc and you don't have to do any work. That solves most of what's on your list and obviates the need for garbage collection or reference counting.
The real trouble is the UI API because there isn't anything to lift it from since Android has a totally independent UI from Desktop Linux. But that doesn't mean it isn't worth doing -- and even if that isn't worth doing, why can't I have the rest of it? If I'm trying to port a Linux daemon into a service then I don't much care about a lack of GUI functions but I most certainly could use a full POSIX implementation.
> It sounds like you could do it a lot more easily by just having separate processes or threads for each activity/service/whatever
Do you know much memory is used for a thread? Or for a process? The answer for either is not zero. In fact it is possible (but not used) for the same Dalvik process to host multiple apps.
> It seems to be almost identical to the OS sending SIGTERM and then SIGKILL to the process in question however.
Not even close. With swapping the kernel has to operate in units of 4kb pages. Dalvik can use a compacting garbage collector to reduce memory consumption. Signals are trivial. They are a single number, and not come even remotely close to interprocess resources. Think something closer to dbus, plus a bunch of code built on top of it.
> don't care about something "analogous" to libc, just give me libc and you don't have to do any work
Android already includes that (bionic). You can compile elf binaries that work just fine. Heck you'll even find 'ls' etc on the system done that way. But your binary won't be able to examine the clipboard.
Note the posting was about writing Android applications in Go, not about trivial binaries. Applications means all the crud you are dismissing.
> Are you assuming the necessity of a one to one mapping between Java API functions and C API functions?
Nope. But those functions only have a Dalvik hosted Java centric implementation. If you want to work with them then they all have to be reimplemented in a compatible manner, or you need to call from the native code back into Dalvik using JNI. Either way is a lot of work.
Your example of porting a Linux daemon to a service won't work as is. Being a service means the system has expectations of you - how you are started, how data is provided and returned and how it is stopped. (There is also other stuff such as permissions and process hosting.) The canonical way of doing this is to write the service front end in Java, and then use JNI to load native code you need. But it does mean your native code needs to play well with others in the same process - something that isn't Go's sweet spot.
In your scenario there are several SSH servers available. Most are delivered as a single "app", but behind the scenes consist of an sshd binary, plus Java authored code to provide a UI (start/stop/status/configuration) and manage lifecycle.
The desire from most folk is for Go authored apps to be first class citizens, and not require using any other language. That is what is a lot of duplicate work.
For example the canonical way to structure a music app would be an activity (gui) for visuals, a content provider to provide the library and a service to play the actual audio. There is no requirement for these to be in the same app/process and it is pretty much immaterial to the code. But if your activity is communicating with the service (eg to send play/pause/next in one direction and getting the current play position and file in the other) then Android does housekeeping to make sure the right thing happens such as what happens when either side crashes or exits.
Android can do memory management within a process - for example if you switch to your email app, the music playing service can keep going, and the activity can be terminated (it is usually told).
This isn't remotely the same thing as swapping out pages as is done by the kernel. Additionally a whole bunch of the pieces have no kernel representation (eg a content provider). There is an IPC mechanism (binder) that has both kernel and user space components working in harmony.
To have something analogous in C, your "app" would be a large number of shared libraries (dozens), and they would be dynamically loaded and unloaded. They would talk to each other and shared libraries in other processes. There would be garbage collection, lifetime management and possibly reference counting. Calls into them could be asynchronous, as well as calls out. Managing all that would be non-trivial "scaffolding".
> ... almost everything has near-seamless support for calling C API functions
Dalvik already has that - using JNI. The pattern is to implement your interface to Android in Java and then call through to C when you need to.
The problem with Go is that it isn't designed to play well with others. It doesn't support dynamically linking, and expects to own the process - being in charge. The work the posting is about is some toolchain hacks that make it so a dynamically loadable binary is produced instead of an executable. There is then work to make the Android API available which is non-trivial, and Java flavoured.
> I would be plenty happy if they would just provide a native C API like GNU/Linux does
The "native" API it would provide would need to be analogous to libc, glib, X (and extensions like xrandr), gnome, systemd/udev, dbus, sdl, ibus, garbage collection, shm, reference counting etc all combined (in addition to whatever I forgot). There is no "just providing" that!