4 ms·

I like Rust, but wasn’t “plopping” a binary onto a server and running it one of the original virtues of Go? Arguably a louder “plop” due to size, but then you

by biztos 2y ago

I like Rust, but wasn’t “plopping” a binary onto a server and running it one of the original virtues of Go? Arguably a louder “plop” due to size, but then you don’t have to chmod.

berkes 2y ago
Certainly. A lot (all?) of the points I make aren't unique to rust, or even invented in rust. Many have even better implementations in other languages. Go also invented the "fmt", with one opinionated code style "enforced" by default - bikeshedding be gone! My point was that it's the combination of all of these points. AFAIK, go ticks many of these boxes too. But for me golang falls short with mutability, and with the type system (though that one's catching up really fast). It's the "package-deal" that I like about rust.
n8henrie 2y ago
I much prefer rust to go for many reasons, but IME go gets this part much better. Darwin / Linux cross compilation, armv7, FreeBSD, oh sorry you don't have a linker for that toolchain, wait where are those OpenSSL headers... lots of cross-compilation targets I've done in minutes with go that scp and run right away that end up being days / weeks of adventures to cross compile in rust, in spite of me knowing rust much better than go at this point.
- berkes 2y ago
  I have had the luxury to work in projects that don't have to target many platforms, but rather "one": a server. Which then is often a simple linux variant so setting up a CI or even the local build to target that "one" is relatively simple. But wasn't Go a lot more limited in the amount of targets it can build for than rust?
  - n8henrie 2y ago
    Yes and no -- obviously I can build for no_std targets like esp32 and atmega128p in rust but not go (haven't tried tinygo), but the proportion of targets that successfully built and ran IRL has been higher for me with go. On rust, the dynamic linking of libc (by default) and failure to include a linker with the toolchain have repeatedly been stumbling blocks, go "just works."

by biztos 2y ago

I like Rust, but wasn’t “plopping” a binary onto a server and running it one of the original virtues of Go? Arguably a louder “plop” due to size, but then you don’t have to chmod.

berkes 2y ago

Certainly. A lot (all?) of the points I make aren't unique to rust, or even invented in rust. Many have even better implementations in other languages. Go also invented the "fmt", with one opinionated code style "enforced" by default - bikeshedding be gone! My point was that it's the combination of all of these points. AFAIK, go ticks many of these boxes too. But for me golang falls short with mutability, and with the type system (though that one's catching up really fast). It's the "package-deal" that I like about rust.

n8henrie 2y ago

I much prefer rust to go for many reasons, but IME go gets this part much better. Darwin / Linux cross compilation, armv7, FreeBSD, oh sorry you don't have a linker for that toolchain, wait where are those OpenSSL headers... lots of cross-compilation targets I've done in minutes with go that scp and run right away that end up being days / weeks of adventures to cross compile in rust, in spite of me knowing rust much better than go at this point.

berkes 2y ago
I have had the luxury to work in projects that don't have to target many platforms, but rather "one": a server. Which then is often a simple linux variant so setting up a CI or even the local build to target that "one" is relatively simple. But wasn't Go a lot more limited in the amount of targets it can build for than rust?
- n8henrie 2y ago
  Yes and no -- obviously I can build for no_std targets like esp32 and atmega128p in rust but not go (haven't tried tinygo), but the proportion of targets that successfully built and ran IRL has been higher for me with go. On rust, the dynamic linking of libc (by default) and failure to include a linker with the toolchain have repeatedly been stumbling blocks, go "just works."