31–40 of 168 posts
I'm wondering about the logistics of making this integrate with Go at the assembly/object file level rather than at source code level. What if it compiled to Go's assembly rather than to Go source code
†: I've tried to transpile Rust code through WASM into Go assembly, and I've also explored how to inject trampolines into Go binaries (which involves generating Go assembly too).
Looks great. But I can't help wondering: If it is similar to Rust why not make it the the same as Rust where it feature-matches? Why import "foo.bar" instead of use foo::bar? Why Bar.Baz => instead of Bar::Baz =>? What are you achieving here? Why make it subtlety different so someone who knows Rust has to learn yet another language? And someone who doesn't know Rust learns a language that is different enough that the…
As for int and float64, this comes from Go's number type names. There's int, int64, and float64, but no float. It's similar to how Rust has isize but no fsize.
For "classic" Rust what's actually nice is that no runtime is needed, so this looks like a step backwards. What would be actually nice is running async Rust on the Go green threads runtime.
In my experience, what's actually nice is the correctness. The low-levelness is not helpful for most of the software I write, and imposes a constant burden. Rust, of course superbly achieves its goals within its niche! But it is a niche, is my meaning here. What I actually want is code that's correct, but ergonomic to write. So my ideal language (as strange as it sounds) would be Rust with a GC. I don't want to worry…
For "classic" Rust what's actually nice is that no runtime is needed, so this looks like a step backwards. What would be actually nice is running async Rust on the Go green threads runtime.
I know it is Rust inspired, but why write it in Rust and not Go?
I'm wondering about the logistics of making this integrate with Go at the assembly/object file level rather than at source code level. What if it compiled to Go's assembly rather than to Go source code
Having explored that approach (†), I can tell that generating Go assembly is harder than it seems. †: I've tried to transpile Rust code through WASM into Go assembly, and I've also explored how to inject trampolines into Go binaries (which involves generating Go assembly too).
Looks great. But I can't help wondering: If it is similar to Rust why not make it the the same as Rust where it feature-matches? Why import "foo.bar" instead of use foo::bar? Why Bar.Baz => instead of Bar::Baz =>? What are you achieving here? Why make it subtlety different so someone who knows Rust has to learn yet another language? And someone who doesn't know Rust learns a language that is different enough that the…
These are just syntax differences, which not only are easy to learn but I believe aren't the primary goal of the language, which is to bring the benefits of Rust's type system to Go. As for int and float64, this comes from Go's number type names. There's int, int64, and float64, but no float. It's similar to how Rust has isize but no fsize.
isize is the type for signed memory offsets, fsize is completely nonsensical.
Earlier quoted context omitted.
Having explored that approach (†), I can tell that generating Go assembly is harder than it seems. †: I've tried to transpile Rust code through WASM into Go assembly, and I've also explored how to inject trampolines into Go binaries (which involves generating Go assembly too).
That is interesting, but I imagine Rust has features which can not be translated into Go's assembly. This language is specifically designed for Go interop; the logistics wouldn't be the same, though I still expect it to be difficult.
Why would there be? Go’s assembly might be lacking ways to make them optimally efficient, but that’s probably a given either way without an optimizing compiler backend.