Why not write a Go backend for the OCaml compiler?

[typesanitizer]

Disclaimer: I come here in peace, in an effort to understand your thought process, not to proselytize or ask you to change direction.

Looking at your goals, it seems to me that writing a Go backend for ocamlc (e.g. it already has a JS backend using Bucklescript, a bytecode backend, and a native code backend) fulfills all the goals.

• Pair an OCaml-like language with the benefits of the Go platform which are:
  • speed
  • concurrency
  • static binaries
  • a healthy ecosystem
• Bring powerful FP concepts to Go
• Get around Go's lack of generics
• Interop with Go code
• Ability to use Go stdlib

I'm also listing some other pros and cons here.

Pros:

You benefit from

1. ReasonML's front-end which is actively maintained.
2. OCaml's type-checker which is actively maintained.
3. Having alternate backends to test your backend for correctness.

Unsure if Pros or Cons:

1. You'll end up writing the code in OCaml instead of Go.
2. A lot of the type system is already in place, however it may not be exactly what you're looking for.

Cons:

1. Different licensing/copyright setup compared to what you currently have.
2. You need to dive into a large, unfamiliar codebase instead of starting from a clean slate.

Of course, there are lots of more considerations that I haven't listed here.

I'd love to hear your opinion on this idea/why you didn't choose to go this route?

[joshsharp]

Thanks for this! It was really thoughtful, I appreciate it.

There are definitely strong benefits for writing a Go backend to OCaml. My OCaml is mediocre but so is my Go so there's not a lot of difference there. One downside I could see is that OCaml has issues on Windows and incomplete support, I'm pretty sure, so going that route would mean you end up with targets Go (and thus Braid) could build for, but that the Braid compiler couldn't be run on. That's not optimal.

Ultimately there were two reasons I chose to write Braid in Go:

1. It seemed neater to write the compiler in the language it is for — this means it only has the Go compiler (and some Go tooling) as dependencies;
2. I wanted to write a language for fun as well as for practicality, and part of the enjoyment is to figure out my own syntax and how best to fit an ml-like language to Go concepts. I do really like OCaml, but I wanted to make something of my own rather than just port an existing language, in much the same way that Elm is a lot like Haskell but also its own thing. I guess that's not entirely practical, but I didn't set out to be entirely practical, that's less fun :)

Hope that makes sense!

[typesanitizer]

One downside I could see is that OCaml has issues on Windows and incomplete support, I'm pretty sure

While I know that it isn't as smooth as on Linux, there is an answer on SO that probably works. On the support bit, yes, you may have a bit more trouble finding help, I agree, but usually people on Reddit/OCaml Disqus are happy to help.

It seemed neater to write the compiler in the language it is for — this means it only has the Go compiler (and some Go tooling) as dependencies;

By that logic, the C/C++/Go compilers should be written in assembly 😛

Elm is a lot like Haskell but also its own thing

In Elm's case (at least the way I understand it from the outside), it is that Haskell has a lot of complexity which Evan thinks is not necessary for writing good front-end applications. However, in your case, it seems to me that Braid is much closer to OCaml (at least, in terms of target features).

However, the bit about "fun" does make sense to me. It may not be as exciting to contribute to an already existing project as to create something new by yourself and freely experiment with things.

Thanks for the answer!

[joshsharp]

However, in your case, it seems to me that Braid is much closer to OCaml (at least, in terms of target features).

Yes, but if I commit to implement OCaml, I may find things that don't map well (for example, the "O" in OCaml is rarely used). Even if Braid ends up being close in terms of features, keeping it separate allows me to add or remove things that make more sense. For example, as Go has a strong story around interfaces, I might choose to implement Rust-style traits which would map well but don't belong in OCaml. I'd like to retain the ability to experiment.