Our great sponsors
-
awesome-wasm-langs
😎 A curated list of languages that compile directly to or have their VMs in WebAssembly
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
Just about every language can compile or transpile to WASM:
https://github.com/appcypher/awesome-wasm-langs
> Golang only has a GC, it doesn't have an option to manage memory in other ways.
But as far as I understand golang's memory internals, they still offer you to use the copy-based stack directly ("var some SomeStruct;") or to allocate things directly on the heap (via "new(SomeStruct) / make(SomeStruct)".
I might be wrong about this, but this is what I understood from casually reading the spec [1]; while they never mention stack or heap specifically and describe it more as memory being allocated at run time, which kind of hints to a copying garbage collector underneath. But they also seem to implement a mark and sweep mechanism [2] so I'd say it's a hybrid GC, similar to how ECMAScript VMs work these days because closing a function/stack scope leads to a mark.
Nevertheless you're right with the argument that it doesn't offer a way to manage memory yourself, which I think is a good thing. Technically you could use "C.malloc()" and "C.free()" though.
> Were you referring to unsafe pointers and calls to Cgo?
Yeah, I was kind of referring to the possibility to implement C-interface adapters using CGO (the internal "C" and "unsafe" packages). Personally I would only use C APIs if there's no way around them, though, and keep as much code in golang as possible.
[1] https://go.dev/ref/spec#Allocation
[2] https://github.com/golang/go/blob/master/src/runtime/mgc.go#...