Hacker News Reader

Comment by saagarjha | Hacker News Reader

In my experience Rust’s ability to rid itself from autoconf comes not because of any inherent benefits but because Rust code typically does not support systems where autoconf would really be required. For the mostly sane platform differences, the popular ones are probably hardcoded in some dependency crate with “-std” in its name so you don’t have to see it, unless of course it turns out to not support your less common platform or the check is broken, in which case you lob a GitHub issue at them and they deal with it.

View on HN

Yes, cargo is perfect if you are willing to always compile from source, everything is Rust and one is willing to deal with everything else themselves in build.rs scripts.

Google and Microsoft aren't using cargo on their projects, rather had to come up with their own build tool.

At Microsoft, we do use cargo internally but we make use of an internal crate registry.

Google's bazel/blaze predates rust. It has the advantage of supporting multiple languages

and is pretty much unuseable in the traditional unix setting where you are supposed to vendor nothing and use all the libraries of the OS however broken they may be

That's less a limitation of the build system and more an intentional policy to ensure reproducible binaries etc.

Technically bazel can load any external files, but they must be tracked as workspace dependencies, which is more verbose:

E.g.

    new_local_repository(
        name = "system_libs",
        # pkg-config --variable=libdir x11
        path = "/usr/lib/x86_64-linux-gnu",
        build_file_content = """

cc_library( name = "x11", srcs = ["libX11.so"], visibility = ["//visibility:public"], ) """, )

That's a feature, no?

I think there's an argument to be made that some developers might be willing to sacrifice portability to some lesser-used platforms in order to make the ecosystem a bit cleaner for the platforms it does support. This is definitely a tradeoff though, so it make sense and is good that different ecosystems make difference choices here, as it allows people to choose whichever suits them best.

Rust does support a surprisingly deep set of platforms, but it achieves this by baking platform-specific knowledge into Rust itself. See for example how it finds errno, it's just a big list of special cases. It is pleasant to not need the configure scripts, but a downside is that no new platform can participate without first patching Rust.

https://doc.rust-lang.org/src/std/sys/unix/os.rs.html#38

(Into the standard library, not into Rust itself. Anyone can write this, you don't need to patch Rust first just to call some functions.)

I believe you can write your own completely separate standard library if you want to (much like each platform typically has it's own libc). It's just that it's easier to manage the first-party supported platforms as one codebase.

Reply on news.ycombinator.com