Compile Gleam to Go

[sep2]

Both Beam and JavaScript are not so good for CPU intensive workflow.

Go is a light-weight and solid concurrent (go routine) platform and also bare mental enough with decent performance. It has GC too. Go is also mainstream enough according language ranks.

Go itself lacks many functional programming features we love, and Go team is no going to add them as the time being.

It would be good chance for Gleam to become a better Go and attract more users, like Typescript as a better JavaScript.

[lpil]

Go is a poor target for a functional language as the memory allocator is slow. In Go one uses a small number of large allocations and avoid memory churn, but in FP we do the opposite, so a Go FP language would be disappointingly slow.

If we were going to have a new compilation target we would want to pick one that has many advantages and minimal disadvantages, enables things we can't do today, and solves existing problems. Go doesn't meet these requirements.

We're also not looking for a new target generally. Currently the focus is on making everything one needs to make real production systems in Gleam: libraries, documentation, guides, frameworks, tools, examples, etc. To add a new target we would need to stop all of that and return to focusing on language design and implementation, which would be frustrating for Gleam users and likely greatly hinder growth and maturation of the ecosystem.

[Eveeifyeve]

I feel like gleam should compile to something like Rust, but go could be slow for large allocs and for the reasons above.

[lpil]

Rust isn't a good compile target as it's slow to compile and all the static analysis features that make it nice for humans to write make it really annoying for compilers to generate.

[Eveeifyeve]

Plus Duplicate #1736

[Daniel-Shunom]

I like what we already have so far. Compiles to JS so we have gleam on the web and bring Gleam to the hands of probably what is the largest groups of engineers out there, and compiles to erlang so we get the best part of the BEAM, hence giving us access to what is considered the best VM for concurrency, and makes for a great backend language.

I don't see what compiling to Go will bring to the table that the existing compilation targets do not collectively have.

[SnakeDoc]

Beyond wishful thinking - and I love being on the BEAM for backend stuff - however, a JVM target would be pretty interesting and unlock a whole new ecosystem of libs, frameworks, tooling, etc. Writing functional code in Java/Kotlin leaves a lot to be desired. Ignore my input here though, I have no idea what I'm talking about! I'm quite happy with the BEAM 😉

[Eveeifyeve]

I mean go for it if you can maske a pr and if you know how to do bytecode and can make gleam support it.

[lpil]

We would not accept such a contribution. It would create huge amounts of ongoing work for us and we would have to postpone or cancel all our current priorities.

[Eveeifyeve]

We would not accept such a contribution. It would create huge amounts of ongoing work for us and we would have to postpone or cancel all our current priorities.

I mean yes, but whoever added it should have the responsibility of adding the support to continue to support. because clearly your not going to maintain it.

[lpil]

That's not how it works unfortunately. There is no way for us to ignore that one part of the codebase as the whole project needs to build and test successfully as a whole, and bug reports for this new code would come to us.

It would need to be a fork, like all the other alternative targets.

[SnakeDoc]

I think the reality is, both the BEAM and JS targets cover almost every possible case you might need/want, and the core team focusing on making Gleam the best possible language within that space is nothing but good. Most apps don't need "raw metal" performance, and the BEAM excels at concurrency, making many differences more academic than practical in my opinion.