Re:Crystal 0.31
by nerdponx on Monday September 23, 2019 @07:11PM
(#21054766)
How portable are Crystal binaries? Or more generally, how easy is it to share a Crystal program with someone who isn't a Crystal user? E.g. C and C++ requires a lot of esoteric knowledge w/ occasionally slow builds, Go isn't that bad but has an intrusive bad default GOPATH, Rust + Rustup is like Go with better defaults but relatively long compilation times, Python/Ruby need the runtime installed + some kind of isolating environment, NodeJS just needs the runtime + NPM, Perl needs some kind of CPAN setup which is really confusing for newbies, etc.
[ Parent
| on HN ]
Like Go, Crystal embeds the runtime inside of the executable by default so it doesn't require the user to install the language runtime libraries on the users computer unlike Java, C#, etc.
The only way to get a true portable statically-linked Crystal binary on Linux is to compile your program statically using an Alpine Linux Docker container. MacOS portability shouldn't be a problem since everything is static except for libSystem.dylib.
Like Java and C# actually, it just doesn't get more known due to the amount of devs that don't deal with commercial AOT toolchains outside corporations.
Re:Crystal 0.31
by SomaticPirate on Monday September 23, 2019 @10:55PM
(#21056061)
Just to clarify, Go has an extremely simple cross compilation story. GOOS=windows GOARCH=amd64 go build main.go will consistently create a windows binary. It also has great support for a wide variety of architectures. This has been true since Go 1.5 and GOPATH idiosyncrasies are largely going away with the move to go modules.
https://golang.org/doc/install/source#environment
It's actually pretty easy; I compile stuff on a mac, then run it on a Linux box regularly. Usually use Docker though.
Re:Crystal 0.31
by KenanSulayman on Wednesday September 25, 2019 @07:52AM
(#21069818)
It's not cross compilation in Docker because Docker on macOS is literally just a VM running a Linux kernel.
N.B. unlike the other problems you listed, Go's "intrusive bad default GOPATH" is a development-time choice; presuming the developer used Go modules, the compiling-from-source user won't have to think about GOPATH.