What are we going to do about mobile?

[Joakim via Digitalmars-d]

On Friday, 7 April 2017 at 09:40:26 UTC, rikki cattermole wrote:
> On 07/04/2017 10:34 AM, Joakim wrote:
>> On Thursday, 6 April 2017 at 05:32:41 UTC, rikki cattermole 
>> wrote:
>>> IMO there is two things that need to be done to get D for 
>>> mobile:
>>>
>>> 1: ldc needs to natively target and distribute binaries for 
>>> Android
>>> (MIPS, ARM, at least).
>>
>> I'm not sure what you mean by "natively target."  Do you mean 
>> that the
>> shipping ldc compiler should come with Android/ARM target 
>> support built
>> in?  That can be done, but it's useless without a stdlib 
>> cross-compiled
>> for the target and ldc doesn't provide the cross-compiler
>> scripts/toolchain with its releases that would allow you to 
>> easily start
>> cross-compiling, even though the compiler itself is capable.  
>> Instead, I
>> provide a cross-compiler for linux/x64 that comes with a 
>> cross-compiled
>> stdlib for Android/ARM, and link to instructions on how to use 
>> it with
>> the Android NDK toolchain.
>
> So basically druntime, Phobos all good to go basically be able 
> to do ldc2 test.d and get a valid (yet to be apk'd) executable. 
> But the point was to have it all officially supported and ready 
> to go with clear instructions on how to use it.

That's all available from my Android releases: the only part you 
could say is missing is "official support," since they're not put 
out on ldc's official github release page.

There are a couple issues that block that, one of which I 
mentioned above: ldc has never released a cross-compiler with a 
cross-compiled stdlib, or at least scripts that make it easy to 
cross-compile the stdlib yourself, and instructions on 
integrating with some cross-compilation toolchain.  Another is 
that my cross-compiler currently requires a lightly tweaked llvm.

>>> 2: extern(JNI) seriously, its a pain to work with Java over 
>>> JNI
>>> otherwise. It would be worse then not having extern(Obj-C).
>>
>> I don't think it's that bad, but sure, we could always make it 
>> easier.
>
> After working on djvm, there is no way I'd want to not have it. 
> It's just too hard to do it library only.

I have not tried djvm yet, perhaps we could work together on this.

On Friday, 7 April 2017 at 14:47:03 UTC, Marco Leise wrote:
> Am Thu, 06 Apr 2017 05:24:07 +0000
> schrieb Joakim <dlang at joakim.fea.st>:
>
>> D is currently built and optimized for that dying PC platform.
>
> As long as the world still needs headless machines running
> web sites, simulations, cloud services, ...;
> as long as we still need to edit office documents, run
> multimedia software to edit photos and video, play AAA video
> games the "PC master race" way;
> I'm confident that we have a way to go until all the
> notebooks, PCs and Macs disappear. :)

As I've noted many times on this forum, no tech ever completely 
disappears:
there's still somebody out there running COBOL and mainframes.  
But they do _effectively_ disappear, as you almost never see them.

That is what is happening to the PC.  When is the last time you 
saw someone running a UNIX workstation?  Back when I was in 
college decades ago, that's all I used to use, except for writing 
papers.

In my household, we had two Windows laptops and two Android 
smartphones four years ago; today we have two Android tablets and 
two Android smartphones, ie no PCs anymore.  There are 
increasingly people worldwide using smartphones and tablets who 
have never and will never touch a PC!  This move to add 
multiwindow docked functionality to smartphones makes that more 
prevalent.

As for your examples, my first link above notes that Microsoft 
and Adobe have made software available to do just that on your 
S8.  Yes, there are compute-heavy workloads that you will always 
need servers for, but ARM is going after that market too 
(https://arstechnica.com/information-technology/2017/03/microsoft-latest-open-source-servers-shown-off-with-intel-amd-and-even-arm-chips/), and because the number and capability of mobile devices is exploding, that compute-heavy share is going down.

> I'd say we just have /more/ fully capable computers around us
> nowadays. I'd probably roughly split it into
> - web/cloud server machines, often running VMs
> - scientific computation clusters
> - desktops (including notebooks)
> - smart phones
> - embedded devices running Linux/Android (TVs, receivers,
>   refrigerators, photo boxes, etc...)

My point is that mobile, ie smartphones and tablets, is so 
dominant that it is subsuming many of those other categories.  
I've already mentioned desktop/laptop sales going down since 
mobile took off, another is embedded devices that you'd have 
mentioned before getting subsumed into mobile, ie mp3 players, 
ereaders, standalone cameras, and GPS devices' sales have all 
been devastated.  People don't buy TVs, receivers, and photo 
boxes as much as before because their mobile device suffices.  
Unfortunately, you cannot use your smartphone for refrigeration 
yet. ;)

> When targeting smart phones you have to comply to every 
> manufacturer's frameworks and security measures. On the other 
> hand you can directly sell software and services.

I'm not sure what you're referring to here: Samsung has different 
security measures than Huawei, which require app modifications?  
And mobile sales are usually less direct, as you have to go 
through an app store, which you didn't have to with PCs.

> The embedded device I know best is my TV receiver, which boots 
> into Linux and then starts a statically compiled executable 
> that handles GUI rendering, remote control input and 
> communication with the hardware. If you knew the protocols you 
> could replace it with something written in Dlang.
>
> These devices are not as prominent as phones, but the
> barrier of entry is relatively low for many applications once
> you have bindings to a couple of frequently needed C libraries
> such as freetype, ffmpeg or opencv.

I don't know much about the software stack for receivers, but 
it's not as important as mobile and likely has higher barriers 
given the greater fragmentation.  It is likely that some 
mobile-based platform, like Android TV, will end up being much 
more important in this market.

>> I realize D is never going to have a polished devkit for 
>> mobile unless a company steps up and charges for that work.  
>> But we can do a lot better than the complacency from the 
>> community we have now.
>
> As you can use mostly the same compiler targets for embedded as 
> for phones, your best bet to stabilize the ldc targets are 
> probably the embedded developers, because they can see the 
> immediate benefit for their projects and their knowledge about 
> the underlying hardware can help track down bugs.

My understanding is that embedded both has many more hardware 
targets and software stacks, so mobile is actually much easier.  
I'd like to see D on more capable embedded hardware that can 
handle it, and the runtime stripped down eventually for less 
capable embedded hardware.

However, it's not a market I deal with, so either way, I'm not 
going to do anything with it.