10 ms·

Rust is actually portable

355 points by ahgamut 4y ago

mihaigalos 4y ago
> I’d like a bit more flexibility in specifying what I want cargo to do. Check out Bazel for Rust. It allows: * caching of artifacts. * shareable caches between {developers, build jobs} based on hashes. * remote distributed builds (on very many cores). https://github.com/google/cargo-raze https://github.com/google/cargo-raze
- livinglist 4y ago
  Wow, I didn’t know Basel was this powerful, gotta try it out now.
- echelon 4y ago
  I do not know why you're downvoted for this (crazy!?) -- this is exactly what I wanted to know [1]. I have a Rust monorepo with a bunch of "library"-type crates and about a dozen binaries (jobs, servers, userland programs) I need this in my life. [1] https://news.ycombinator.com/item?id=29745426 https://news.ycombinator.com/item?id=29745426
  - grimgrin 4y ago
    Because at first glance it lacked context. Now the OP has updated it with relevancy, by quoting a bit from the article author.
    - mihaigalos 4y ago
      Sorry about that, I realized it once I saw the downvote (thank you - it made the post better). Empathy is essential.
      - grimgrin 4y ago
        I didn't downvote you, for what it's worth :P
  - mihaigalos 4y ago
    Did you eventually get a ref to an example Bazel build for Rust in that thread? (Writing here because you'll probably not look at the other thread again.) I see the linked resources are to docs only. If it's any help, here's a bazelized Rust demo implementation: https://github.com/mihaigalos/code_templates/tree/master/rust https://github.com/mihaigalos/code_templates/tree/master/rus...
- daniel_rh 4y ago
  I think the newer version of this is https://github.com/bazelbuild/rules_rust https://github.com/bazelbuild/rules_rust which lets you either vendor the dependencies or pull them from your Cargo.toml directly every time. Per the article: bazel + rules_rust should have the flexibility to override the linker flags that Cargo may take as required since that would be a property of the bazel toolchain used. It's a nice amalgamation of how cargo works and how bazel works. In general bazel supports hermetic builds, multiple toolchains, cross complilation, and ways to compile multi-language projects. I still wish that Cargo.toml didn't support build.rs as it can cause a lot of system-dependent problems that bazel sidesteps entirely by being hermetic.
- csomar 4y ago
  I wish I knew about this earlier! It's interesting that this project doesn't have a much higher visibility. Also wondering, what's the current relationship of this project with Google? (if you are involved with it)
  - junon 4y ago
    It does, it's just that it... doesn't work well in practice. It's another case of "this works well for Google but doesn't translate well outside of Google". Plus, seems like Bazel is a very neutered version of Blaze anyway.
    - ikiris 4y ago
      buildfarm takes away a lot of the neutering.
      - mihaigalos 4y ago
        Not sure what to say concerning buildfarm's remote execution. Reading an issue I've opened almost 2y ago [1], seems the backend requires the client to have a specific gcc version. That's a strong limitation imho. [1] https://github.com/bazelbuild/bazel-buildfarm/issues/545 https://github.com/bazelbuild/bazel-buildfarm/issues/545
        p_l 4y ago
        This is related to non-hermetic build graph, so the builds have system-provided dependency in GCC, and to make the build sane requires that they are in sync.
        ikiris 4y ago
        Never run into this issue in the real world so.... /shrug
- kaba0 4y ago
  I am always surprised how good and not-well-known google’s tooling is. Another example would be its closure compiler (with the accompanying j2cl/j2objc tools, which are all ridiculously cool).
  - jart 4y ago
    What you might not have known is that Actually Portable Executable https://justine.lol/ape.html https://justine.lol/ape.html and Bazel's Closure Compiler tooling were written by the same person. https://github.com/bazelbuild/rules_closure https://github.com/bazelbuild/rules_closure
    - technologia 4y ago
      @jart, just wanted to say thanks for both APE and cosmopolitan, those projects have made my life infinitely easier as well as giving me a lot of my time back not having to figure out windows executable minutia. It's a no brainer for me to create either a WASM module or an APE to get the job done.
      - csdvrx 4y ago
        And also tysm @jart for derasterize https://github.com/csdvrx/derasterize https://github.com/csdvrx/derasterize, which was a great basis to work on, and helped me make sixel-tmux https://github.com/csdvrx/sixel-tmux https://github.com/csdvrx/sixel-tmux We achieved textmode supremacy, and jart achieved binary-portability supremacy. There seems to be a pattern here :)
  - bsder 4y ago
    > I am always surprised how good and not-well-known google’s tooling is. The problem is that Google is well-known for unceremoniously dumping stuff. So my first question about any Google tool is: "Does it have enough non-Google people supporting it?" because, if it doesn't, it will die as soon as it becomes a political football. My second question about any Google tool is: "Are there small projects using it and singing its praises?" Can I use the tool to do what I need to a handful of files after reading a couple of web pages for 15 minutes and have it work. I don't need to scale to 4 gazillion foobars--I do need to get stuff done without an IT staff of 100 people. From a cursory look, Bazel fails that question. My final question about any tool is more personal: "Does it use C++?" because, if it does, then integrating with anything other than C++ is going to be a gigantic PITA. At this point there are plenty of fine alternatives to C++ that don't suck. If you don't have a clean, pleasant way of talking to things that only understand C library conventions, you fail and I'm moving on.
- spockz 4y ago
  I really really want to like Bazel but I’m having issues with having the amount of bookkeeping I need to do in Bazel build files. And then someone comes along saying something along the lines of “oh but we just use <somecli>” to do the updating of Bazel for us… sometimes that is even internal tooling. Something else is that most projects tend to build everything from source, even protobuf dependencies, so it takes me an hour to get the initial build of envoy done.
  - withinboredom 4y ago
    I don’t know what it is these days, but I can remember waiting 12 hours to compile Chromium from scratch while the entire x-windows + KDE and friends taking only 4-5 hours to compile from scratch. This was back in 2014 on a little two core laptop.
    - Cloudef 4y ago
      The joys of c++
      - FpUser 4y ago
        You saying that if rewritten in Rust Chromium will compile much faster?
        Cloudef 4y ago
        No, rust is another slow language to compile. But there are faster ones such as C and zig. You can reduce C++ compilation times by following certain strict coding conventions, but it only gets you so far.
        lloeki 4y ago
        in such large projects linking is also a severe bottleneck, which I hear has been repeatedly tried to be addressed with alternative linkers
        4y ago
- hazz99 4y ago
  I’m using Bazel to build my rust project (Using the rules_rust rules) and it’a become quite a pain to use in concert with docker. This is not a complaint about Bazel specifically, its fantastic, and easily my favourite build system bar none. However it cannot cross compile Rust. This means if I’m developing on my MacBook, and I want to compile a Rust binary and put it in an Ubuntu docker container, I can’t do it on my host machine. I need to copy the source into the container and build it there, using multistage builds. But this is -extremely slow- because it cannot take advantage of Rusts build caching. I’m talking 10-15 minutes for my small Rust project. Has anyone run into this? How do you work around it? I’ve considered running a Bazel remote execution server on a local Ubuntu VM, but this feels like so much extra complexity just to use Rust, Bazel and containers.
  - tinco 4y ago
    Why not just mount the code in the container instead of copying it over? Rust deals very cleanly with build artefacts from different architectures so there's no risk of corruption.
    - fnord123 4y ago
      This is a good idea but there is tension between this straightforward approach and the fact that, on macos, docker is running in a VM so it's inherently slower.
      - arein3 4y ago
        Isn't docker trying to use virtualization from the OS to run linux on "bare metal"? If so it should acheive similar speeds to native linux
        tinco 4y ago
        The virtualized storage layer could actually be a bottleneck here. Though I think they've improved the performance of it to the point where it might no longer be a bottleneck but I'm not sure.
- rajman187 4y ago
  also worth noting is Buck, which is a clone of Bazel. Not only does it support Rust, interestingly it seems the next version seems to be moving toward using Rust as the language of choice for developing it [1] [1] https://developers.facebook.com/blog/post/2021/07/01/future-of-buck/ https://developers.facebook.com/blog/post/2021/07/01/future-...
  - hobofan 4y ago
    Which makes sense given yesterdays announcement that Rust is now an endorsed server-side language at Meta and Rust the recommended language for CLI tools: https://engineering.fb.com/2022/07/27/developer-tools/programming-languages-endorsed-for-server-side-use-at-meta/ https://engineering.fb.com/2022/07/27/developer-tools/progra...
- anothernewdude 4y ago
  Last thing I want is more things to use Bazel. I can do without the headache. Perhaps Cargo can improve.
  - hazz99 4y ago
    I’m hoping by more projects adopting Bazel, we get more powerful libraries, and it becomes trivial to use.
- wongarsu 4y ago
  There's also mozilla's sccache, which integrates with cargo (by wrapping rustc) to cache artifacts. A local cache is 2 lines of config in your .cargo/config.toml, and if you want to you can have shared caches in Redis or S3/Azure/GCP. Not nearly as flexible or powerful as Bazel, but also vastly simpler to setup if all you want is caching. https://github.com/mozilla/sccache https://github.com/mozilla/sccache
  - MuffinFlavored 4y ago
    is there any effort to a public trusted shared cache?
    - est31 4y ago
      For single projects, it's possible to build such caches and it's done by some, e.g. Firefox uses it. But for the "any project" use case, the combination of Rust's compilation model and how crates.io works makes this hard. Due to Rust's compilation model, if crate A depends on crate B, then the version of crate B it's been compiled for can't be changed: you have to use that version. It also means that the features of the crate that have been enabled can't be changed. "Normal" Rust projects can quickly get into hundreds of crates.io dependencies in their DAG. Those are the very dependencies you want to use ssccache for. However, due to how crates.io works, basically every day you get a new updated crate in your DAG, and this invalidates all the crates that depend on it, including your own. In a single project use case, this is no problem because everyone uses the same Cargo.lock so they use the same dependencies and the same features of those dependencies. But if you don't share a Cargo.lock, the problem is too wide. There are some solutions like freezing crates.io according to a schedule and only pushing out updates once per week or so. But this still leaves the feature issue unsolved. Plus it is probably against the idea of crates.io to have updates available immediately. Another solution would be API only dependencies, but this is harder to pull off.
- dundarious 4y ago
  These seem orthogonal to the flexibility desired in the post. My understanding is cargo-raze doesn't provide a way to trim -lm from the link line, for example -- it doesn't seem like it would provide any such features over what cargo provides.
- reiniermaas 4y ago
  > It allows: > > * caching of artifacts. > > * shareable caches between {developers, build jobs} based on hashes. This sounds like something that nix is optimised for. The inputs into building each package is captured so having different feature flags would just create different artifacts.
csomar 4y ago
I feel some of the OP points. I was working on a profiling agent lately, and one of the issues was running it on multiple platforms (just the four big ones linux/mac-x86/arm) on FFI (because it'll be run directly from python/ruby/etc...) and preferably having the thing just work without having to install or configure any dependencies. Like OP I hit two walls: libunwind, and linking. For libunwind, I ended up downloading/compiling manually; and for linking there is auditwheel[1]. Although it is a Python tool, I did actually end up using it for Ruby (by creating a "fake python package", and then copying the linked dependencies). It was at that time that I learned about linking for dynamic libraries, patchelf and there is really no single/established tool to do this. I thought there should be something but most people seem to install the dependencies with any certain software. I also found, the hard way, that you still have to deal with gcc/c when working with Rust. It does isolate you from many stuff, but for many things there is no work around. There is a performance hit to this strategy, however, since shared dynamic libraries will be used by all the running programs that need them; whereas my solution will run its own instance. It made me wonder if wasm will come up with something similar without affecting portability. Finally, the project is open source and you can browse the code here: https://github.com/pyroscope-io/pyroscope-rs https://github.com/pyroscope-io/pyroscope-rs [1]: https://github.com/pypa/auditwheel https://github.com/pypa/auditwheel
forrestthewoods 4y ago
Is compiling once and running on 6 platforms really that compelling? One of Rust’s super powers is that it’s really easy to write code once that can be compiled N times for N platforms without making any changes. I’m all about writing code once. But compiling a few times doesn’t seem like that big of a deal to me? The article says it runs on “six operating systems” but I can’t find them listed?
- petesergeant 4y ago
  > Cosmopolitan Libc ... that runs natively on Linux + Mac + Windows + FreeBSD + OpenBSD + NetBSD + BIOS So some subset of those
- pritambarhate 4y ago
  The python article mentions those: https://ahgamut.github.io/2021/07/13/ape-python/ https://ahgamut.github.io/2021/07/13/ape-python/ > This post describes a proof-of-concept Python executable (2.7.18 and 3.6.14) built on Cosmopolitan Libc, which allows it to run on six different operating systems (Linux, Mac, Windows, NetBSD, FreeBSD, OpenBSD)
- deleted 4y ago
  [deleted]
- AgentME 4y ago
  I'm not sure if the "actually portable executable" stuff is really practical for anything in its current state, but I find it neat the way the development of the project encourages people to try to find unifying abstractions between software environments and practice writing build tools for new software environments.
  - nindalf 4y ago
    10 years ago when almost all computers except smartphones were x86 this would have been a gamechanger. Nowadays, we need to account for ARM no matter what. Either the developer machine or the deployment target could be ARM. Therefore the build system needs to be aware of cross compiling.
aabbcc1241 4y ago
node.js is also portable with pkg
- feffe 4y ago
  Nitpicking on terminology. Portable used to mean that software can run on another platform with minimal modifications. Typically by relying on abstraction layers that then has multiple implementations. It's cool that a single executable can run on both Windows and some Unixes but that's something else than what portable used to mean. portable = able to port
  - aabbcc1241 4y ago
    Thanks for the clarification. So I learnt executable isn't the same as portable. In this sense, we cannot say "C is portable"? Since we need to compile it for each platform; the same for java, we need to run the bytecode on each platform's virtual machine, and the compiler/virtual machine isn't built-in along with most os. Then back to node.js, since v8/bun is not built-in on most os, so we cannot say it's portable right?
techdragon 4y ago
While I love this sort of portability and in particular how it just makes Rust even more useful to me. The library this is built on does have a bit of a weakness with respect to GUI software https://github.com/jart/cosmopolitan/issues/35 https://github.com/jart/cosmopolitan/issues/35 if this can be fixed this will be an amazing tool for building simple cross platform utilities and tools.
childintime 4y ago
Just one question, as suggested by the title: the rust compiler itself could be made portable using this? I guess not, because of its use of multi-threading.
- rkangel 4y ago
  You probably could, but that would be less useful than you think. There are two machines that you care about with a compiler: the machine the compiler is running on ("Host"), and the machine the compiler is producing code for ("Target"). Generally we use a compiler with the same Host and Target - if you use Rust on x64-Windows you get a binary that runs on x64-Windows. If you use it on ARM-Linux you get a binary that runs on ARM-Linux. What you are talking about is making a compiler that would run on all Hosts, but it would take different work to make it be able to produce code for all Targets. So you'd produce a compiler that targeted x86-Windows and it would run on x86-Linux but still produce code for x86-Windows. It would also NOT be able to run on ARM-Linux. [For completeness there's actually three machines we talk about with compilers - in addition to Host and Target there is also "Build". This allows you to cross-compile your compiler. For example you want to build your compiler on x86, you want the resulting compiler to run on ARM, and when it runs it produces code for RISC-V. Here Build is x86, Host is ARM and Target is RISC-V.]
  - TazeTSchnitzel 4y ago
    But the “actually portable executable” is a single target and runs on many platforms, surely a rustc compiled as an APE for APE would be useful?
    - rkangel 4y ago
      Oh I see! You mean "built as an APE and targeting APE". That would indeed be an interesting idea.
  - mastax 4y ago
    > What you are talking about is making a compiler that would run on all Hosts, but it would take different work to make it be able to produce code for all Targets. This is already how rustc works, it is not like GCC. Any rustc can (cross-)compile for any target, as long as you have the rlibs for that target, your libllvm has those targets enabled, and you have the appropriate linker. Rustup usually manages all that for you.
manholio 4y ago
Aside form neatness factor and hacker street cred, I don't exactly get the practical point for the vast majority of software. What am I to do with such a binary? Do I put it live on my website and allow my clients to download it? If I leave it with an .exe extension so that it runs in the Windows shell, wouldn't that confuse users of other platforms? What if I need a directory structure as 99% of programs do? Do I use a zip or a tgz? In the first case, how do I preserve permissions on Unix targets? Do I need to instruct my clients into how to use tgz on the command line and/or create permissions? Software distribution is by its nature a very platform specific problem; even if we accept the premise of an x64 world, an universal binary solves just a very small portion of the practical problems of portable deployment. Ironically, the best use case I can imagine is creating an universal binary installer that can run on any Unix system and then proceed to make platform-specific decisions and extract files contained in itself, sort of like Windows binary installers work. But that's an utterly broken distribution model compared to modern package managers.
zaphar 4y ago
I’d change a configuration flag, some part of std would break because my flag was wrong, and I’d learn something new about Rust and how std worked. The project was probably worth doing just because of this. Breaking things in a safe environment is such a great way to learn how it all works.
logankeenan 4y ago
I’ve found rust incredibly portable. I’ve hacked around running the same server side app on the web (WASM), PC/Mac/Linux, iOS, and Android. Another project is a web app running on iOS and Android leveraging a SQLite DB.
ajross 4y ago
> I just built a Rust executable that runs on six operating systems I help maintain a kernel in C that runs on nine architectures, some of which don't even have LLVM backends, much less stable rust toolchains. "Portable" means rather different things. This blog post is focused on the easy stuff.
- 8jy89hui 4y ago
  While this project might focus on the “easy” definition of portable, I’ve never seen this done before. This post was both interesting and informative. I don’t think you comparing your (unlinked and unnamed) kernel to this is very constructive. It feels like you’re gate-keeping.
- DenseComet 4y ago
  They didn't build six executables that run on six operating systems. Rather, it's a single nativity compiled executable that runs on six different operating systems unmodified. Cosmopolitan is an incredibly cool project that does more than you think. https://github.com/jart/cosmopolitan https://github.com/jart/cosmopolitan

355 points by ahgamut 4y ago

> I’d like a bit more flexibility in specifying what I want cargo to do. Check out Bazel for Rust. It allows: * caching of artifacts. * shareable caches between {developers, build jobs} based on hashes. * remote distributed builds (on very many cores). https://github.com/google/cargo-raze https://github.com/google/cargo-raze

livinglist 4y ago
Wow, I didn’t know Basel was this powerful, gotta try it out now.
echelon 4y ago
I do not know why you're downvoted for this (crazy!?) -- this is exactly what I wanted to know [1]. I have a Rust monorepo with a bunch of "library"-type crates and about a dozen binaries (jobs, servers, userland programs) I need this in my life. [1] https://news.ycombinator.com/item?id=29745426 https://news.ycombinator.com/item?id=29745426
- grimgrin 4y ago
  Because at first glance it lacked context. Now the OP has updated it with relevancy, by quoting a bit from the article author.
  - mihaigalos 4y ago
    Sorry about that, I realized it once I saw the downvote (thank you - it made the post better). Empathy is essential.
    - grimgrin 4y ago
      I didn't downvote you, for what it's worth :P
- mihaigalos 4y ago
  Did you eventually get a ref to an example Bazel build for Rust in that thread? (Writing here because you'll probably not look at the other thread again.) I see the linked resources are to docs only. If it's any help, here's a bazelized Rust demo implementation: https://github.com/mihaigalos/code_templates/tree/master/rust https://github.com/mihaigalos/code_templates/tree/master/rus...
daniel_rh 4y ago
I think the newer version of this is https://github.com/bazelbuild/rules_rust https://github.com/bazelbuild/rules_rust which lets you either vendor the dependencies or pull them from your Cargo.toml directly every time. Per the article: bazel + rules_rust should have the flexibility to override the linker flags that Cargo may take as required since that would be a property of the bazel toolchain used. It's a nice amalgamation of how cargo works and how bazel works. In general bazel supports hermetic builds, multiple toolchains, cross complilation, and ways to compile multi-language projects. I still wish that Cargo.toml didn't support build.rs as it can cause a lot of system-dependent problems that bazel sidesteps entirely by being hermetic.
csomar 4y ago
I wish I knew about this earlier! It's interesting that this project doesn't have a much higher visibility. Also wondering, what's the current relationship of this project with Google? (if you are involved with it)
- junon 4y ago
  It does, it's just that it... doesn't work well in practice. It's another case of "this works well for Google but doesn't translate well outside of Google". Plus, seems like Bazel is a very neutered version of Blaze anyway.
  - ikiris 4y ago
    buildfarm takes away a lot of the neutering.
    - mihaigalos 4y ago
      Not sure what to say concerning buildfarm's remote execution. Reading an issue I've opened almost 2y ago [1], seems the backend requires the client to have a specific gcc version. That's a strong limitation imho. [1] https://github.com/bazelbuild/bazel-buildfarm/issues/545 https://github.com/bazelbuild/bazel-buildfarm/issues/545
      - p_l 4y ago
        This is related to non-hermetic build graph, so the builds have system-provided dependency in GCC, and to make the build sane requires that they are in sync.
      - ikiris 4y ago
        Never run into this issue in the real world so.... /shrug
kaba0 4y ago
I am always surprised how good and not-well-known google’s tooling is. Another example would be its closure compiler (with the accompanying j2cl/j2objc tools, which are all ridiculously cool).
- jart 4y ago
  What you might not have known is that Actually Portable Executable https://justine.lol/ape.html https://justine.lol/ape.html and Bazel's Closure Compiler tooling were written by the same person. https://github.com/bazelbuild/rules_closure https://github.com/bazelbuild/rules_closure
  - technologia 4y ago
    @jart, just wanted to say thanks for both APE and cosmopolitan, those projects have made my life infinitely easier as well as giving me a lot of my time back not having to figure out windows executable minutia. It's a no brainer for me to create either a WASM module or an APE to get the job done.
    - csdvrx 4y ago
      And also tysm @jart for derasterize https://github.com/csdvrx/derasterize https://github.com/csdvrx/derasterize, which was a great basis to work on, and helped me make sixel-tmux https://github.com/csdvrx/sixel-tmux https://github.com/csdvrx/sixel-tmux We achieved textmode supremacy, and jart achieved binary-portability supremacy. There seems to be a pattern here :)
- bsder 4y ago
  > I am always surprised how good and not-well-known google’s tooling is. The problem is that Google is well-known for unceremoniously dumping stuff. So my first question about any Google tool is: "Does it have enough non-Google people supporting it?" because, if it doesn't, it will die as soon as it becomes a political football. My second question about any Google tool is: "Are there small projects using it and singing its praises?" Can I use the tool to do what I need to a handful of files after reading a couple of web pages for 15 minutes and have it work. I don't need to scale to 4 gazillion foobars--I do need to get stuff done without an IT staff of 100 people. From a cursory look, Bazel fails that question. My final question about any tool is more personal: "Does it use C++?" because, if it does, then integrating with anything other than C++ is going to be a gigantic PITA. At this point there are plenty of fine alternatives to C++ that don't suck. If you don't have a clean, pleasant way of talking to things that only understand C library conventions, you fail and I'm moving on.
spockz 4y ago
I really really want to like Bazel but I’m having issues with having the amount of bookkeeping I need to do in Bazel build files. And then someone comes along saying something along the lines of “oh but we just use <somecli>” to do the updating of Bazel for us… sometimes that is even internal tooling. Something else is that most projects tend to build everything from source, even protobuf dependencies, so it takes me an hour to get the initial build of envoy done.
- withinboredom 4y ago
  I don’t know what it is these days, but I can remember waiting 12 hours to compile Chromium from scratch while the entire x-windows + KDE and friends taking only 4-5 hours to compile from scratch. This was back in 2014 on a little two core laptop.
  - Cloudef 4y ago
    The joys of c++
    - FpUser 4y ago
      You saying that if rewritten in Rust Chromium will compile much faster?
      - Cloudef 4y ago
        No, rust is another slow language to compile. But there are faster ones such as C and zig. You can reduce C++ compilation times by following certain strict coding conventions, but it only gets you so far.
        lloeki 4y ago
        in such large projects linking is also a severe bottleneck, which I hear has been repeatedly tried to be addressed with alternative linkers
        4y ago
hazz99 4y ago
I’m using Bazel to build my rust project (Using the rules_rust rules) and it’a become quite a pain to use in concert with docker. This is not a complaint about Bazel specifically, its fantastic, and easily my favourite build system bar none. However it cannot cross compile Rust. This means if I’m developing on my MacBook, and I want to compile a Rust binary and put it in an Ubuntu docker container, I can’t do it on my host machine. I need to copy the source into the container and build it there, using multistage builds. But this is -extremely slow- because it cannot take advantage of Rusts build caching. I’m talking 10-15 minutes for my small Rust project. Has anyone run into this? How do you work around it? I’ve considered running a Bazel remote execution server on a local Ubuntu VM, but this feels like so much extra complexity just to use Rust, Bazel and containers.
- tinco 4y ago
  Why not just mount the code in the container instead of copying it over? Rust deals very cleanly with build artefacts from different architectures so there's no risk of corruption.
  - fnord123 4y ago
    This is a good idea but there is tension between this straightforward approach and the fact that, on macos, docker is running in a VM so it's inherently slower.
    - arein3 4y ago
      Isn't docker trying to use virtualization from the OS to run linux on "bare metal"? If so it should acheive similar speeds to native linux
      - tinco 4y ago
        The virtualized storage layer could actually be a bottleneck here. Though I think they've improved the performance of it to the point where it might no longer be a bottleneck but I'm not sure.
rajman187 4y ago
also worth noting is Buck, which is a clone of Bazel. Not only does it support Rust, interestingly it seems the next version seems to be moving toward using Rust as the language of choice for developing it [1] [1] https://developers.facebook.com/blog/post/2021/07/01/future-of-buck/ https://developers.facebook.com/blog/post/2021/07/01/future-...
- hobofan 4y ago
  Which makes sense given yesterdays announcement that Rust is now an endorsed server-side language at Meta and Rust the recommended language for CLI tools: https://engineering.fb.com/2022/07/27/developer-tools/programming-languages-endorsed-for-server-side-use-at-meta/ https://engineering.fb.com/2022/07/27/developer-tools/progra...
anothernewdude 4y ago
Last thing I want is more things to use Bazel. I can do without the headache. Perhaps Cargo can improve.
- hazz99 4y ago
  I’m hoping by more projects adopting Bazel, we get more powerful libraries, and it becomes trivial to use.
wongarsu 4y ago
There's also mozilla's sccache, which integrates with cargo (by wrapping rustc) to cache artifacts. A local cache is 2 lines of config in your .cargo/config.toml, and if you want to you can have shared caches in Redis or S3/Azure/GCP. Not nearly as flexible or powerful as Bazel, but also vastly simpler to setup if all you want is caching. https://github.com/mozilla/sccache https://github.com/mozilla/sccache
- MuffinFlavored 4y ago
  is there any effort to a public trusted shared cache?
  - est31 4y ago
    For single projects, it's possible to build such caches and it's done by some, e.g. Firefox uses it. But for the "any project" use case, the combination of Rust's compilation model and how crates.io works makes this hard. Due to Rust's compilation model, if crate A depends on crate B, then the version of crate B it's been compiled for can't be changed: you have to use that version. It also means that the features of the crate that have been enabled can't be changed. "Normal" Rust projects can quickly get into hundreds of crates.io dependencies in their DAG. Those are the very dependencies you want to use ssccache for. However, due to how crates.io works, basically every day you get a new updated crate in your DAG, and this invalidates all the crates that depend on it, including your own. In a single project use case, this is no problem because everyone uses the same Cargo.lock so they use the same dependencies and the same features of those dependencies. But if you don't share a Cargo.lock, the problem is too wide. There are some solutions like freezing crates.io according to a schedule and only pushing out updates once per week or so. But this still leaves the feature issue unsolved. Plus it is probably against the idea of crates.io to have updates available immediately. Another solution would be API only dependencies, but this is harder to pull off.
dundarious 4y ago
These seem orthogonal to the flexibility desired in the post. My understanding is cargo-raze doesn't provide a way to trim -lm from the link line, for example -- it doesn't seem like it would provide any such features over what cargo provides.
reiniermaas 4y ago
> It allows: > > * caching of artifacts. > > * shareable caches between {developers, build jobs} based on hashes. This sounds like something that nix is optimised for. The inputs into building each package is captured so having different feature flags would just create different artifacts.

csomar 4y ago

I feel some of the OP points. I was working on a profiling agent lately, and one of the issues was running it on multiple platforms (just the four big ones linux/mac-x86/arm) on FFI (because it'll be run directly from python/ruby/etc...) and preferably having the thing just work without having to install or configure any dependencies. Like OP I hit two walls: libunwind, and linking. For libunwind, I ended up downloading/compiling manually; and for linking there is auditwheel[1]. Although it is a Python tool, I did actually end up using it for Ruby (by creating a "fake python package", and then copying the linked dependencies). It was at that time that I learned about linking for dynamic libraries, patchelf and there is really no single/established tool to do this. I thought there should be something but most people seem to install the dependencies with any certain software. I also found, the hard way, that you still have to deal with gcc/c when working with Rust. It does isolate you from many stuff, but for many things there is no work around. There is a performance hit to this strategy, however, since shared dynamic libraries will be used by all the running programs that need them; whereas my solution will run its own instance. It made me wonder if wasm will come up with something similar without affecting portability. Finally, the project is open source and you can browse the code here: https://github.com/pyroscope-io/pyroscope-rs https://github.com/pyroscope-io/pyroscope-rs [1]: https://github.com/pypa/auditwheel https://github.com/pypa/auditwheel

forrestthewoods 4y ago

Is compiling once and running on 6 platforms really that compelling? One of Rust’s super powers is that it’s really easy to write code once that can be compiled N times for N platforms without making any changes. I’m all about writing code once. But compiling a few times doesn’t seem like that big of a deal to me? The article says it runs on “six operating systems” but I can’t find them listed?

petesergeant 4y ago
> Cosmopolitan Libc ... that runs natively on Linux + Mac + Windows + FreeBSD + OpenBSD + NetBSD + BIOS So some subset of those
pritambarhate 4y ago
The python article mentions those: https://ahgamut.github.io/2021/07/13/ape-python/ https://ahgamut.github.io/2021/07/13/ape-python/ > This post describes a proof-of-concept Python executable (2.7.18 and 3.6.14) built on Cosmopolitan Libc, which allows it to run on six different operating systems (Linux, Mac, Windows, NetBSD, FreeBSD, OpenBSD)
deleted 4y ago
[deleted]
AgentME 4y ago
I'm not sure if the "actually portable executable" stuff is really practical for anything in its current state, but I find it neat the way the development of the project encourages people to try to find unifying abstractions between software environments and practice writing build tools for new software environments.
- nindalf 4y ago
  10 years ago when almost all computers except smartphones were x86 this would have been a gamechanger. Nowadays, we need to account for ARM no matter what. Either the developer machine or the deployment target could be ARM. Therefore the build system needs to be aware of cross compiling.

aabbcc1241 4y ago

node.js is also portable with pkg

feffe 4y ago
Nitpicking on terminology. Portable used to mean that software can run on another platform with minimal modifications. Typically by relying on abstraction layers that then has multiple implementations. It's cool that a single executable can run on both Windows and some Unixes but that's something else than what portable used to mean. portable = able to port
- aabbcc1241 4y ago
  Thanks for the clarification. So I learnt executable isn't the same as portable. In this sense, we cannot say "C is portable"? Since we need to compile it for each platform; the same for java, we need to run the bytecode on each platform's virtual machine, and the compiler/virtual machine isn't built-in along with most os. Then back to node.js, since v8/bun is not built-in on most os, so we cannot say it's portable right?

techdragon 4y ago

While I love this sort of portability and in particular how it just makes Rust even more useful to me. The library this is built on does have a bit of a weakness with respect to GUI software https://github.com/jart/cosmopolitan/issues/35 https://github.com/jart/cosmopolitan/issues/35 if this can be fixed this will be an amazing tool for building simple cross platform utilities and tools.

childintime 4y ago

Just one question, as suggested by the title: the rust compiler itself could be made portable using this? I guess not, because of its use of multi-threading.

rkangel 4y ago
You probably could, but that would be less useful than you think. There are two machines that you care about with a compiler: the machine the compiler is running on ("Host"), and the machine the compiler is producing code for ("Target"). Generally we use a compiler with the same Host and Target - if you use Rust on x64-Windows you get a binary that runs on x64-Windows. If you use it on ARM-Linux you get a binary that runs on ARM-Linux. What you are talking about is making a compiler that would run on all Hosts, but it would take different work to make it be able to produce code for all Targets. So you'd produce a compiler that targeted x86-Windows and it would run on x86-Linux but still produce code for x86-Windows. It would also NOT be able to run on ARM-Linux. [For completeness there's actually three machines we talk about with compilers - in addition to Host and Target there is also "Build". This allows you to cross-compile your compiler. For example you want to build your compiler on x86, you want the resulting compiler to run on ARM, and when it runs it produces code for RISC-V. Here Build is x86, Host is ARM and Target is RISC-V.]
- TazeTSchnitzel 4y ago
  But the “actually portable executable” is a single target and runs on many platforms, surely a rustc compiled as an APE for APE would be useful?
  - rkangel 4y ago
    Oh I see! You mean "built as an APE and targeting APE". That would indeed be an interesting idea.
- mastax 4y ago
  > What you are talking about is making a compiler that would run on all Hosts, but it would take different work to make it be able to produce code for all Targets. This is already how rustc works, it is not like GCC. Any rustc can (cross-)compile for any target, as long as you have the rlibs for that target, your libllvm has those targets enabled, and you have the appropriate linker. Rustup usually manages all that for you.

manholio 4y ago

Aside form neatness factor and hacker street cred, I don't exactly get the practical point for the vast majority of software. What am I to do with such a binary? Do I put it live on my website and allow my clients to download it? If I leave it with an .exe extension so that it runs in the Windows shell, wouldn't that confuse users of other platforms? What if I need a directory structure as 99% of programs do? Do I use a zip or a tgz? In the first case, how do I preserve permissions on Unix targets? Do I need to instruct my clients into how to use tgz on the command line and/or create permissions? Software distribution is by its nature a very platform specific problem; even if we accept the premise of an x64 world, an universal binary solves just a very small portion of the practical problems of portable deployment. Ironically, the best use case I can imagine is creating an universal binary installer that can run on any Unix system and then proceed to make platform-specific decisions and extract files contained in itself, sort of like Windows binary installers work. But that's an utterly broken distribution model compared to modern package managers.

zaphar 4y ago

I’d change a configuration flag, some part of std would break because my flag was wrong, and I’d learn something new about Rust and how std worked. The project was probably worth doing just because of this. Breaking things in a safe environment is such a great way to learn how it all works.

logankeenan 4y ago

I’ve found rust incredibly portable. I’ve hacked around running the same server side app on the web (WASM), PC/Mac/Linux, iOS, and Android. Another project is a web app running on iOS and Android leveraging a SQLite DB.

ajross 4y ago

> I just built a Rust executable that runs on six operating systems I help maintain a kernel in C that runs on nine architectures, some of which don't even have LLVM backends, much less stable rust toolchains. "Portable" means rather different things. This blog post is focused on the easy stuff.

8jy89hui 4y ago
While this project might focus on the “easy” definition of portable, I’ve never seen this done before. This post was both interesting and informative. I don’t think you comparing your (unlinked and unnamed) kernel to this is very constructive. It feels like you’re gate-keeping.
DenseComet 4y ago
They didn't build six executables that run on six operating systems. Rather, it's a single nativity compiled executable that runs on six different operating systems unmodified. Cosmopolitan is an incredibly cool project that does more than you think. https://github.com/jart/cosmopolitan https://github.com/jart/cosmopolitan