I find the idea of Elements/Water interesting. Much like seeing the magic of Haxe transpile into a bunch of targets, seeing the “magic” of two languages in the same project side-by-side is really interesting.
However, implying that because the language syntax is supported everything will just be okay, even when behavior is different… is somewhere between confusing and misleading.
It’s obvious Elements is willing to deliver a “language syntax” with behavior that differs from the main existing implementations of those languages. And this isn’t a problem. In fact, it’s more of an inevitability of the approach.
However, It would be nice if the docs and marketing were upfront about how this thing works, so we could understand how we might have to work with it to get a desired set of results.
As for the definition of the term “language”…
I personally consider the “C# language” to be what is defined in ISO 23270 / ECMA-334 document titled “The C# Language Specification”. I think most would agree.
This document outlines the requirements of the C# Language automatic memory management system, and ARC can not satisfy those requirements. Which means a C# compiler to an ARC memory manager is not the C# language – because it will not correctly run C# programs. (unless you consider using infinitely more memory acceptable)
I think the word the blog post should be using is “syntax” not “language”. However, this is just a pointless semantics argument. Whoever’s words we use, we need to be able to talk about things clearly…
Let’s just talk about “syntax” and “behavior”.
Myself and others have lots of C#/Java/Go code with memory-cycles that will not work under an ARC system. Others have lots of go-routine code that will not work under a system with heavyweight stacks.
The manual says:
RemObjects Go is a 100% compatible implementation of the Go language supported for all Elements platforms — .NET, Cocoa, Android, Java, Windows, Linux and WebAssembly.
In my world, using ARC under Mac-native is not 100% compatible with existing code. And if you are not providing lightweight heap stacks for Go then it’s also not 100% compatible with existing code.
So what is this “100% compatibility claim”? That it’s 100% compatible syntax parsing, even if it won’t run the same? I fail to see how that’s useful. And this isn’t just theoretical. Even my trivial ~20 line Go test program doesn’t run the same on Elements as on Google Go.
Here’s another ambitious claim…
An iOS or macOS app [written in any syntax] will look, feel and be as fast as any app written in Xcode.
Please explain what we’re dealing with here…
How does Java for MacOS native map native structs and packed native struct-arrays to Java language constructs?
Is there a new struct keyword (thus making the language a Java-superset like J#) or is there a functionality limitation (thus making Java-for-native-macos incapable of being as fast as native code). Likewise, if it’s being compiled to static native ARC code, what parts of standard Java libraries work and don’t work?
Likewise for Go and Go-routines. Is Gold/Go for JVM using lightweight heap-stacks? Or is this a case where it’s “technically Go syntax, but memory consumption is massively more for many threads”?
Looking forward to any clarity…