|
|
|
|
|
|
by steveklabnik
1519 days ago
|
|
|
> Moreover, many people are just going to run their CI on amd64 Debian or RHEL and assume it works for all targets. Rust has a strong concept of "tiered platforms", and so lots of people support at least Mac/Windows/Linux. Nobody uses Jenkins (for open source packages that will become your dependencies, at least), they use GitHub Actions or CircleCI, which make it easy to support many platforms. I personally run Windows, no WSL, and 99.99% of the time, everything Just Works for me. But yes, that's why I wasn't saying it's purely just as good. For sure. But it does generally work well. > My whole thesis here is that Go leans less on FFI than other ecosystems, Gotcha, that's fair. Pure-x for any x often is really, really nice! Full agreement there. |
|
|
Yeah, and it's really interesting how the relative ease/difficulty of FFI shapes an ecosystem. On one extreme, you have Go which has a lot of purity, but on the other you have Python where FFI is so easy that the maintainers can't really change anything including optimizations without breaking compatibility which means pure Python packages are relatively slow driving more reliance on FFI. It also means the package management tooling has to solve for the universe of C packages to be worthwhile, which drives a whole bunch of other problems. A decade ago, if you had asked me whether easy FFI was a good thing or a bad thing, I would have unequivocally said "a good thing". That might've been the correct answer if the lingua franca had a standard concept of reproducible builds.