I'm a layman, but the information on your website reminds be both of what GreenArrays are doing and of the 80's INMOS transputers. People might want to know how those compare with what you're working on.
The Oracle JVM is virtually all open source under a different name (OpenJDK) and there are lots of other JVMs out there. Oracle won't care about this project.
("AnonymousField" is the name they give to it. But it's inheritance. Badly executed and doesn't fit well in the type system, but that's par for the course for Go)
I don't get where these statements keep coming from. Well, I do, to an extent : the Go authors keep claiming these sorts of things, but I don't understand why. They're not true. There is no complex language feature that Go does not have. Go has inheritance, Go has generics (simply inaccessible for everyone except the language authors, like in modula-2), Go has polymorphism (simply inaccessible for "mere" users). Go has return-value polymorphism. Go has type parameters, both in types and functions (again, inaccessible for users of the language, but it's there).
Everything is simply built as custom compiler code that's inconsistent and riddled with unexpected edge cases, none of it worked into the type system itself. This is the real reason for resistance against these language features : working them into the type system would be a necessity, and isn't possible without breakage because they're not consistent.
Sure. Take a look at all the mathematical theories and models out there. They're all languages, and solving problems within a framework of any given mathematical theory is pretty similar to a process of compilation - a source language should be transformed into another language in which the solution can be "executed".
Let's take CAD as an example. We've got a source language: a constructive solid geometry, for simplicity. Pretty much everything a CAD does boils down to various transforms of this language - into an optimised octree for rendering purposes, into G-code slices for production, into, say, SVG for blueprints, etc.
CRUD stuff boils down to transforms between different semantic domains - a relational structure at one end and workflow graphs and document trees on another.
It's really hard to come up with any practically important problem domain which would not benefit from being represented in terms of languages and transforms.
It probably has something to do with out languages having more grammatical cases than English (which, arguably, has two, though it's possible to only use one).
With Vim and Emacs you can get this if you have a plugin that autogenerates a ctags/etags file. Then (in Vim) just <C-]> to an identifiers definition and <C-o> back.
I'm pretty sure linearity was also part of the picture -- no matter how many layers of neurons you have, as long as they perform linear combinations, they could all be replaced with a single one (ignoring numeric errors).
I mentioned this in my post ("given nonlinear activations"), but you're correct to point out its importance. The combination of linear functions is always linear. Full stop. You need at least one non-linear layer to get reasonable results.
I was also talking about projects and porting in general. Incidentally, I've been paid to do exactly what we're discussing. (Porting a production program using automated translation.) It works.
