undefined

points

[-]

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.

by cyberpunk42 minutes ago|

parent|

[-]

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…

by packetlost8 hours ago|

prev|

[-]

An JavaScripts is? Rust is probably a more performant target regardless

by lpil8 hours ago|

parent|

[-]

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.

by Imustaskforhelp7 hours ago|

parent|

[-]

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!

by lpil6 hours ago|

parent|

[-]

For that sort of compilation target more flexibility is beneficial, so C, Wasm, LLVM IR, Cranelift IR etc are better than Go, Nim, and D in my opinion.

> cross portability/small binaries/fast compiled language which is fast to compile

You don't need native compilation to build fast single file executables for a program, there's ways one can achieve this with Gleam today. Bundling the BEAM into your Gleam application executable with something like Gleepack is one option, and this will produce smaller executables than Go will by default for many applications.

by __MatrixMan__7 hours ago|

parent|

prev|

[-]

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.