Golang

[dbrattli]

Exploring in #3345 the possibility of translating F# and Fable into the [Go programming language] (https://go.dev/). It started with looking into Cython and Rust for writing Python extension modules. Then after getting introduced to Go I figured it could be a good language for Fable. Clean simple syntax, GC and very fast tooling makes it an attractive target language. Anyways, a long way to go but let's do this one step at a time.

I've currently done some testing with functions and nested closures to see how things works out with generics. No big surprises so far so hopefully there will be no hard blockers.

Things to figure out:

• Tuples, Go has no tuple type. Should we use arrays or structs?
• Parameter pass by reference or by value. Explicit or implicit?
• How to generate the package name from namespaces?
• Go does not have exceptions, so what to do?
• Go does not have inheritance, so we need to use composition instead

PS: Would be very interesting to one day run @ncave ray-tracer project and see where Go would end up on the performance scale.

[Zaid-Ajaj]

Fable to Go would be amazing! 😱 ❤️

[ncave]

@dbrattli

Perhaps:

Tuples, Go has no tuple type. Should we use arrays or structs?

• Arrays elements are usually of the same type (unless it's dynamic), so perhaps use anonymous structs?

Parameter pass by reference or by value. Explicit or implicit?

• Either one would work, but perhaps by value (unless the type is byref of some sort), to match .NET cc.

How to generate the package name from namespaces?

• Namespaces are a bit of a problem in languages that don't support them natively (e.g. Rust).
  I'm not sure what a good solution might be for Go, since a Go package is represented by a directory.

Go does not have exceptions, so what to do?

• Perhaps panic + recover + defer handler_fn for the catch, or just defer for finally?

Go does not have inheritance, so we need to use composition instead

• Same with Rust, no inheritance (except on traits).
  If you have a good general solution with composition, please share.

[dbrattli]

Thanks @ncave. Another thing is unit handling. Go do not have optional parameters or overloading so e.g simple generics like this becomes a problem:

let fn(a) = a

let main () =
    fn()

This is because fn must receive a value. We probably have to make a unit value as e.g an empty struct: type unit struct{} so we have something to give the function. This would then translate to:

type unit struct{}

func fn[_A any](a _A) _A {
	return a
}

func main() {
	fn(unit{})
}

This works, but would make interop a bit more difficult. I have the same problem in Python sort of, where you would see code like this:

def fn(a: Optional[__A]=None) -> Optional[__A]:
    return a

def main(__unit: Literal[None]=None) -> None:
    fn()

Which is not pretty, but it works. I guess you don't have this problem in Rust since Rust has a unit type!? I guess I have to invent a unit value and then think about interop later.

[ncave]

I guess you don't have this problem in Rust

• A bit less of a problem, yes, but I still need to fix the printer as it currently improperly eats nested parens (e.g. tuple with unit value in it).

[dbrattli]

Example on howto dump the Go AST from a string literal program. Online Go parsers such as astexplorer cannot handle generics:

package main

import (
	"go/ast"
	"go/parser"
	"go/token"
)

func main() {
	fset := token.NewFileSet() 

	src := `package foo

	import (
		"fmt"
		"time"
	)

	func SumIntsOrFloats[K comparable, V int64 | float64](m map[K]V) V {
		var s V
		for _, v := range m {
			s += v
		}
		return s
	}

	func bar() {
		fmt.Println(time.Now())
	}`

	a, _ := parser.ParseFile(fset, "", src, parser.DeclarationErrors)
	ast.Print(token.NewFileSet(), a)
}

[ncave]

@dbrattli And just in case, here is the AST dump for Rust as well:

rustup run nightly rustc -Z unpretty=ast-tree src/main.rs > ast_tree.json

[knocte]

Hi @dbrattli , I see you closed your WIP PR because you chose Rust instead. Rust is definitely better than Go IMO, so kudos for developing the Rust transpiler indeed, but why kill the Go one anyway? Just wondering if there would be any value on resurrecting it, cause being a dotnet dev and not be able to use the Go ecosystem is kind of a bummer for me.

BTW, wrt Go and error handling today I found this gem: https://github.com/samber/mo (maybe its Option and Result types map well to FSharp.Core's).

[dbrattli]

The PR was a very early beginning so far from anything usable. Someone can always continue it if they have the capacity to commit and maintain it (for years). As for myself, it's way too much work even for the Python part of things, so decided to consolidate with Rust instead.