But I'm ignorant: is the Go runtime built in any way to accomodate third party languages? Apart from writing an interepreter in Go, is there a good way to target it?
No it's not. That's why you haven't seen many alternate languages.
Something else is that the semantics of the Go language itself are purposely limited in ways that help build an efficient runtime easily. So even if you could target the Go runtime easily, it would impose limits to what the language can do as I understand.
Go assembly is just a slightly funny version of the target platform's assembly. At that point, you might as well just assemble for the target directly and avoid the quirks of Go's assembler.
I'd settle for the CoffeeScript of Go. Keep most of it, add sum types, expand generics, and replace nil with options. If you're feeling spicy, make whitespace significant.
As does OCaml since 1996, no need for sugar substitute instead of using the real deal.
Compiles to native code, has a repl, version 5 is multicore for those not happy with Lwt or multiprocessing in the UNIX classical style of each tool does one thing, and a GC only second to GHC in handling immutable types.
I generally agree about the runtime and language semantics.
However, (stable) OCaml not having multithreading support is still a gigantic limitation. Also, OCaml supports fewer target platforms, and I believe it's worse at cross-compiling (though I admit I may be wrong on this).
Go disliking is due to its syntax not semantics. Go as a dynamic language runtime platform will be interesting; the platform defines the semantics and languages define syntax.
On similar lines, Fable [0] project recently announced rust & dart runtime support making F# a very attractive choice.
Go dislike has many different reasons, and some of them are semantics - e.g. the way nil interfaces work, or the dance you have to do to add an item to an array. And then there's the whole issue with FFI, which has nothing to do with syntax, and everything with Go threads being "special".
I've been toying with adding a new generator to Derw (currently targets JS, TS, Elm, English and Derw itself for formatting) that would support Go-based output. It will probably be an experimental branch later this year. Go's performance and distribution makes it an appealing target to hopefully get a faster runtime (particularly interested in making the compiler faster once self-bootstrapping is finished)
go runtime is not VM like JVM [0]. Go doesn't run on top of runtime, more like run along side it. That's why there's go for embedded where it has no runtime. So it's very less likely other language reuse go runtime.
There is absolutely no real difference between the two. One just bundles the code with the runtime while the other doesn’t and uses an intermediary format.
Would you consider the C runtime a virtual machine once you link against libdill or use OpenMP? If not, why not? If so, well, then we just disagree on the term 'virtual machine'. My litmus test would be the presence of some sort of well-defined instruction set.
A quick look at libdill indicates that concurrency there is cooperative, so it's not green threads, either. So, that's just a library.
OpenMP uses OS threads, doesn't it?
When you have coroutines that can be preempted, without explicit yielding in the source code, that's the line at which I would consider it a VM. Basically, it's a VM if some userspace code (JIT, GC, scheduler etc) runs in the background and does things to your code.
I don't think there's a definitive interpretation of VM, so this is all arguable. But e.g. Java and C# are generally considered VM languages even if AOT-compiled, despite the fact that there's no bytecode involved past that point.
Most relevant in context of our discussion: The JVM is a (virtual) stack machine with its own instruction set and semantics specified in the Java Virtual Machine Specification. As far as I'm aware, something equivalent does not exist for Go, or as an internal implementation detail at best (some intermediate representation might potentially qualify if you squint at it the right way).
That's also an implementation detail, because the majority of execution time happens in native code with a native GC "managing it" the exact same way, not by interpreting abstract virtual machine instructions.
But I'm ignorant: is the Go runtime built in any way to accomodate third party languages? Apart from writing an interepreter in Go, is there a good way to target it?