Comment by lpil
8 hours ago
Go's garbage collection isn't well suited for an immutable language like Gleam, so the performance would likely be disappointing compared to other targets.
8 hours ago
Go's garbage collection isn't well suited for an immutable language like Gleam, so the performance would likely be disappointing compared to other targets.
The concurrency model in Go is also poorly suited to the BEAM's process model. Goroutines share a heap so you can't do a lot of things safely that processes can do. Having independent memory space for a process allows you to free it safely when work is done without GCing everything and you can also safely share data because you have a copy not a ref.
There is this: https://github.com/ergo-services/ergo which i keep meaning to take a look at, but never seem to quite get around to…
An JavaScripts is? Rust is probably a more performant target regardless
Surprisingly yes! JavaScript's allocator and garbage collection system is quite well suited to immutable programming.
Rust is a very poor compile target as the compiler is slow and not commonly available, and the aspects of Rust that make it good for humans to write make it a poor choice for compilers to target. With humans the produced code is verified, but with a compiler the compiler is what is to be verified, so the inflexibility of Rust are largely a hindrance compared to other native compilation targets.
What lower-level language do you think aside from rust which can be more helpful for the purposes of being a compile target, nim/D both support garbage collection and non garbage collection, so would languages like these be more preferable
I really love gleam and its community and I would really really love if gleam could be more like golang though, which can help it in compiling to machine code
gleam language but with the developer experience of golang (cross portability/small binaries/fast compiled language which is fast to compile) is honestly one of my fever dreams and I would love to know if it can ever be a reality!
1 reply →
I don't get the impression that javascript is among Gleam's targets because of performance.
- server target: BEAM
- client target: js
Once you've covered those bases, you're kind of done.
If the server needs to do something special in an OS process... might as well let the OS mediate that interaction so that it can be fully generic, rather than trying to bend the language around whatever the unknown action might be.