Is this a bit of chickens coming home to roost as far as developer culture forgetting how to work with cross-compiling toolchains? When I started my career, it was common understanding that the developer may be manipulating sourcecode on a different system and/or platform than where it will be executed.

Our source control, editing, compilation, and execution was understood to happen in different computational spaces, with possible copy/staging steps in between. You were doing something very naive if you assumed you could execute the built program on the same system where the sourcecode files existed and the editor/IDE was running.

This was a significant fraction of the build rules we used to manage. E.g. configuration steps had to understand that the target platform being measured/characterized is not the same as the platform executing the build tools. And to actually execute a built object may require remote file copies and remote program invocation.

▲

bloppe 3 days ago | parent | next [-]

Actually, the Rust toolchain makes cross-compiling way easier than any other fully-compiled language I've ever used. There are like 100 different platforms you can target by just setting the `--target` flag, and they all pretty much just work on any host platform.

Sounds like the real issue is that some Git developers have ancient, rigid requirements for their own development machines.

▲

pdpi 3 days ago | parent | next [-]

> Actually, the Rust toolchain makes cross-compiling way easier than any other fully-compiled language I've ever used

Zig takes the crown on that one, to the point that some people use Zig to cross-compile Go projects with CGo dependencies.

	▲	wyldfire 3 days ago \| parent [-]
		The way Zig solves this problem "better" than Rust is by claiming the target libraries as part of its distribution and building those on demand. It makes for a really excellent experience cross-building. Rust might have a harder time if it wanted a corresponding feature because it doesn't natively build C like Zig does (using libclang). Either it would have to start using libclang or ship with rust re-implementations of the C library. AFAIK it's impossible to write the C++ library in Rust though.

▲

dabinat 3 days ago | parent | prev | next [-]

That has not been my experience. I develop on Windows and need to compile for Linux. After spending several hours trying to get cross-compilation working, I gave up and do it via WSL now.

I switched from Go and I feel like Go was much better at this than Rust.

(I tried “cross” but it was very slow and I found it faster to rsync the files inside the container and then run the build scripts)

	▲	yencabulator 3 days ago \| parent [-]
		I'd bet the difference is that Go has a default assumption that everything is reimplemented in Go and calling C is awkward and slow, meanwhile lots of low-level Rust libraries are actually just type-safety wrappers over C libraries.

▲

saltcured 3 days ago | parent | prev | next [-]

Others have said Rust does not support NonStop.

But, my point is you shouldn't even have to cross-compile Git to a platform like NonStop in order to develop NonStop apps. So the portability of Rust shouldn't even matter here. The app developer should be able to run their Git commands on a supported platform and cross-compile their own app to NonStop.

▲

Ambroisie 3 days ago | parent [-]

I haven't double checked, but my recollection of that story was that they were using Git as part of the operations at runtime, not (just) as a development dependency.

	▲	leftyspook 3 days ago \| parent [-]
		Ah, I see Tom the Genius has moved on from using Subversion for his enterprise JSON DSL

▲

cogman10 3 days ago | parent | prev [-]

A good example of it is how easy it is to do WASM from rust. WASM is even one of the harder platforms to target with rust.

▲

rcxdude 3 days ago | parent | prev | next [-]

I suspect the majority of developers never even learnt as such. Cross-compilation is almost always a second-class citizen and I never expect it to work correctly on an external project. Linux distros have given up, with fedora even insisting on running compilation on the real target hardware for platforms like the raspberry pi, which is kind of insane, and as a result basically no-one puts in the effort to make it work.

▲

forrestthewoods 3 days ago | parent | prev [-]

> Is this a bit of chickens coming home to roost as far as developer culture forgetting how to work with cross-compiling toolchains?

I don't understand your comment. Completely ignorning Rust the modern state of cross-compilation is an unmitigated disaster.

Linux is especially bad because glibc is badly architected pile of garbage stuck in the 80s. It should be trivially possible to target any minimum glibc version for any possible Linux hardware environment. But glibc and Linux distros don't even attempt to make this possible. Linux toolchains make it nearly impossible to not use the default system libraries which is the opposite of correct for cross-compiling.

Zig moves mountains to make cross-compiling possible. But almost no projects actually attempt to support cross-compile.

▲

saltcured 2 days ago | parent [-]

You mostly understand my comment, but not my graybeard perspective.

The modern disaster is exactly that developer culture has forgotten how to do this for the most part.

But, you're focusing on Rust compiling when I don't think it is relevant. If those weird financial platform developers were aware of cross-compiling, they wouldn't think that a developer tool like Git has to be built to run on the target financial server platform. They would be capable of cross-compiling or otherwise staging their build into that platform while still using Git on a supported workstation platform to manage the sources.

	▲	forrestthewoods 2 days ago \| parent [-]
		Definitely agree the world has utterly lost the principle of cross-compiling. Support for cross-compile really should be a first-class and sacrosanct principle.