I just landed on this website today… I’m reading about this elements compiler environment decoupling languages and platforms, and the obvious unanswered question is…
what the heck is the memory model / GC / typing / runtime situation for this cross-compiling? and why doesn’t the website say anything about it?
- Is Swift on windows an ARC system talking to a .NET runtime? Is it compiling swift into CLR?
- Is C# on Cocoa running on a GC runtime? Or is it C# with ARC? Does it ARC all C# objects?
- Is Java for Windows Native on a GC runtime? Or some Java/C hybrid with unsafe unmanaged memory?
- Does Google Go for CLR/JVM compiling Go to bytecode? If so, does it support row polymorphic structural typing? and if so, how? Is it using dynamic for everything? Or have some other way to map structural typing into these non-structural typing runtimes?
When talking about this kind of cross-compiling… this memory model (and type-model) information is essential. Seems like it should be answered up front, right on the Platforms Page. Yet there is zero mention of it. This makes me believe the platform is targeted at less sophisticated developers who don’t understand these details matter. Is that the case? Or is there a solid story here?
This docs page on Storage Modifiers is the first inkling of an answer I’ve been able to find… where it suggests the ARC storage keywords are available in all languages. However, this doesn’t really explain how this hybrid memory model / cross-compiling actually works. Is there some obvious page that has some details?
Here you can see my related post asking why Elements-Go produces different output than Google Go.