7 ms·

Still yearning for an Ocaml-like language that uses the Go runtime.

kornish 4y ago
RIP Oden! https://oden-lang.github.io/ https://oden-lang.github.io/
cmrdporcupine 4y ago
I don't like Go, but I think I would use that. 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?
- ck45 4y ago
  This is just an assumption, but it might be possible to translate to Go assembly and then use the Go toolchain. Edit: https://github.com/minio/c2goasm https://github.com/minio/c2goasm seems to slightly go in that direction.
  - vore 4y ago
    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.
- didibus 4y ago
  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.
pjmlp 4y ago
I don't see the point, just use OCaml.
- kevinmgranger 4y ago
  I don't understand how this is a response to every "I wish I had blank but like ocaml". Threads exist.
  - pjmlp 4y ago
    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.
    - kevinmgranger 4y ago
      I get that everyone has their own favorite tools, but "use a version that isn't out yet, or use separate processes for parallelism" is a non-answer. I'm excited for version 5, but until it's out, it's hard for people to take seriously in conversations about _Go_ of all things.
      - wtetzner 4y ago
        OCaml-on-Go also doesn’t exist…
      - pjmlp 4y ago
        It is more powerful than Go on every sense, and I really don't get what people think using Go runtime into a completly different language would help. Maybe they should spend more attention in their compiler design classes regarding runtime implementations and language semantics.
        simiones 4y ago
        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).
eatonphil 4y ago
F# on Go, yeah would be killer! Some time when I have enough free time, if it doesn't exist already, I'd love to build.
- jjtheblunt 4y ago
  what would it give that evolution of the .NET runtime and tooling isn't likely to offer?
  - eatonphil 4y ago
    Go has nice libraries for networking on Linux.
    - lmm 4y ago
      Nicer than .net core?
eeue56 4y ago
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)
cheriot 4y ago
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.
- geenat 4y ago
  Agreed. See http://igo.herokuapp.com/ http://igo.herokuapp.com/
crudbug 4y ago
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. [0] https://fable.io/blog/2022/2022-06-06-Snake_Island_alpha.html https://fable.io/blog/2022/2022-06-06-Snake_Island_alpha.htm...
- int_19h 4y ago
  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".
- baby 4y ago
  What? Go’s syntax is great. But it lacks sum types.
  - deleted 4y ago
    [deleted]
wejick 4y ago
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. [0] https://go.dev/doc/faq#runtime https://go.dev/doc/faq#runtime
- kaba0 4y ago
  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.
- pjmlp 4y ago
  There are also bare metal JVMs for embedded development, here are the two best ones. https://www.ptc.com/en/products/developer-tools/perc https://www.ptc.com/en/products/developer-tools/perc https://www.aicas.com/wp/products-services/jamaicavm/ https://www.aicas.com/wp/products-services/jamaicavm/ And while we are at it, for .NET as well, https://www.wildernesslabs.co/ https://www.wildernesslabs.co/
- int_19h 4y ago
  Go doesn't have bytecode interpreter or JIT, but it still needs a VM, if only for green threads.
  - cygx 4y ago
    Not every runtime environment is a virtual machine...
    - kaba0 4y ago
      Then you can sure list some differences between go's and JVM's runtime.
      - cygx 4y ago
        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).
kaba0 4y ago
Why would that be a good, over much more performant runtimes like the CLR, JVM, etc?
baby 4y ago
Why not ocaml?

RIP Oden! https://oden-lang.github.io/ https://oden-lang.github.io/

I don't like Go, but I think I would use that. 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?

ck45 4y ago
This is just an assumption, but it might be possible to translate to Go assembly and then use the Go toolchain. Edit: https://github.com/minio/c2goasm https://github.com/minio/c2goasm seems to slightly go in that direction.
- vore 4y ago
  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.
didibus 4y ago
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.

pjmlp 4y ago

I don't see the point, just use OCaml.

kevinmgranger 4y ago
I don't understand how this is a response to every "I wish I had blank but like ocaml". Threads exist.
- pjmlp 4y ago
  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.
  - kevinmgranger 4y ago
    I get that everyone has their own favorite tools, but "use a version that isn't out yet, or use separate processes for parallelism" is a non-answer. I'm excited for version 5, but until it's out, it's hard for people to take seriously in conversations about _Go_ of all things.
    - wtetzner 4y ago
      OCaml-on-Go also doesn’t exist…
    - pjmlp 4y ago
      It is more powerful than Go on every sense, and I really don't get what people think using Go runtime into a completly different language would help. Maybe they should spend more attention in their compiler design classes regarding runtime implementations and language semantics.
      - simiones 4y ago
        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).

eatonphil 4y ago

F# on Go, yeah would be killer! Some time when I have enough free time, if it doesn't exist already, I'd love to build.

jjtheblunt 4y ago
what would it give that evolution of the .NET runtime and tooling isn't likely to offer?
- eatonphil 4y ago
  Go has nice libraries for networking on Linux.
  - lmm 4y ago
    Nicer than .net core?

eeue56 4y ago

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)

cheriot 4y ago

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.

geenat 4y ago
Agreed. See http://igo.herokuapp.com/ http://igo.herokuapp.com/

crudbug 4y ago

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. [0] https://fable.io/blog/2022/2022-06-06-Snake_Island_alpha.html https://fable.io/blog/2022/2022-06-06-Snake_Island_alpha.htm...

int_19h 4y ago
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".
baby 4y ago
What? Go’s syntax is great. But it lacks sum types.
- deleted 4y ago
  [deleted]

wejick 4y ago

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. [0] https://go.dev/doc/faq#runtime https://go.dev/doc/faq#runtime

kaba0 4y ago
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.
pjmlp 4y ago
There are also bare metal JVMs for embedded development, here are the two best ones. https://www.ptc.com/en/products/developer-tools/perc https://www.ptc.com/en/products/developer-tools/perc https://www.aicas.com/wp/products-services/jamaicavm/ https://www.aicas.com/wp/products-services/jamaicavm/ And while we are at it, for .NET as well, https://www.wildernesslabs.co/ https://www.wildernesslabs.co/
int_19h 4y ago
Go doesn't have bytecode interpreter or JIT, but it still needs a VM, if only for green threads.
- cygx 4y ago
  Not every runtime environment is a virtual machine...
  - kaba0 4y ago
    Then you can sure list some differences between go's and JVM's runtime.
    - cygx 4y ago
      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).

kaba0 4y ago

Why would that be a good, over much more performant runtimes like the CLR, JVM, etc?

baby 4y ago

Why not ocaml?