The current compiler was written with the aim of quick development till 1.0 is reached (because in the initial development phase, there are obviously many other important things to focus on). So, yeah the toolchain has some issues, eg. there are very few (if any) optimizations. Also, only 32 bit is supported.
There are AFAIK no plans to add 64 bit support before bootstrapping phase because the current toolchain architecture isn't that great and will be heavily improved during 1.x cycle.
A bit more details here -
https://gitter.im/red/red?at=56ac45a1586242210ae0704d
and https://github.com/red/red/wiki/Question-about-contributing-...
64 bit processors (and their OS platforms) will retain backwards compatibility to 32 bit apps for the forseeable future. There are too many situations where 32 bit apps are better for that not to be the case (smaller binary size and better cache performance).
iOS 11 does not.
For mobile and desktop, sure 32 bit is fading, but embedded 32 bit is so far from obsolete. I don't know how you can even claim that when even 8 bit platforms still have a huge market share.
ARM cortex-M (32 bit) has only recently been able to chip away at 8 bit platforms and gain major use
https://en.wikipedia.org/wiki/List_of_common_microcontroller...
Yes, but the embedded platforms that are interesting for high-level scripting are mostly phones. Worse than desktops, they won't bother with 32-bit compatibility layers.
Using the other meaning of embedded (I embedded a Lua script in my C application), compatibility libraries don't help. It simply won't link.
So, on one hand, there's massive cross-platform support. On the other hand, those platforms are all obsolete, or about to be. Even the mobile and embedded ones have all gone 64-bit.
Maybe backwards compatibility will be maintained for a few years. But it ruins the embed-red-in-C story already.