Fixing C's Biggest Mistake

[H. S. Teoh]

On Fri, Dec 23, 2022 at 08:46:09PM +0000, Hipreme via Digitalmars-d wrote:
[...]
> Just check how much time D lost while trying to get into Android
> (which is unfortunately broken again).

What broke in Android?  My Android project still compiles (though I
haven't worked on it for a while now -- busy with other things).


> Now we're living the Web era without real D support in WASM. D with
> the ability to be used as an alternative to Javascript/Typescript
> programmers would be specially useful as it is not a hard language to
> work with.

Call me a skeptic, but the last time I checked, which was earlier this
year, I found WASM still very much in its infancy, it's still early
adopter tech with lots of rough edges and uncertainties.  Expecting
polished support at this point is IMO a bit unrealistic.  As I pointed
out in another post, a lot of Javascript glue and boilerplate is still
required to make things work.  A while back I posted my vision of what D
support might look like: a preprocessing tool for extracting D function
signatures, type declarations, target APIs (WebGPU, DOM, etc), etc., and
generating the necessary JS boilerplate to make it work.  And some way
to make the GC work without causing too many problems (which involves
working with threads, which involves yet more JS boilerplate, which
involves potentially nasty performance bottlenecks lurking behind the
convenient abstractions).  The days of being able to just cross-compile
a full-fledged D application, bells & whistles and GC and everything,
into WASM with just a flick of a switch, are still far ahead in the
future.  Be glad that LDC *can* compile a pretty big subset of D code
into WASM already.  The key ingredients are already there, now we just
need to build the plumbing.

But given the infancy of WASM, I'm really not sure if I want to be
pouring a ton of time and effort into this yet.  I mean, c'mon, they
haven't even finalized how you're going to interact with the host APIs
yet, key things like GPU access, I/O, etc. -- these are pretty
fundamental things without which you just ain't gonna have end-to-end
WASM support, no matter how much you wish for it.  Even something as
fundamental as passing string data across the JS/WASM boundary involves
a huge amount of glue code and boilerplate; this isn't an off-the-shelf
product that you can just take home and plug into your standardized WASM
interface socket (it doesn't exist yet) and expect things will Just
Work(tm).  This is a raw microchip that, despite whatever tremendous
potential it may have, you still have solder to the motherboard yourself
with your own soldering iron -- and the motherboard isn't provided, you
have to build your own.

If somebody wants to build that standard WASM motherboard for
interfacing with D, I'd fully applaud it.  But for the time being, I'm
not expecting to be able to "just use D" on WASM just yet.


> The runtime problem must be solved somehow for we can stop dividing D
> and betterC libraries. A lot of projects were duplicated after betterC
> announcement.
[...]

What runtime problem?  Not being facetious here, just wasn't clear from
your post which issue(s) specifically you're referring to.


T

-- 
Study gravitation, it's a field with a lot of potential.