Hacker News Reader

Comment by sprucely | Hacker News Reader

I agree, but I'm wondering if there is anything inherent in its design that facilitates this. Or is it mostly attributable to the fact that it makes use of LLVM?

View on HN

It's also cargo and the way the build system works.

Build scripts in Rust are written in Rust, not some ad-hoc declarative build language. This is a really good decision because you can do insane shit in your build scripts.

Also macros, you can generate say bindings relatively easily.

I've been doing some cross-platform GPU stuff lately and Rust makes so much of this a breeze.

I can't imagine combining C++ projects this easily.

I'm really bullish on wgpu (https://github.com/gfx-rs/wgpu-rs). It's the Rust implementation of the WebGPU standard. It goes beyond the web though, it's a really nice GPGPU API to work with and will be a popular API in the next decade.

Right. Now that I think about it, I've seen some crates that perform interesting codegen tasks at compile time; things like ffi bindings that automatically stay up-to-date. The only part I found difficult about working with generated code was that RLS was not up to the task of parsing the generated code, so no intellisense. But that was several months ago, so perhaps it's already been addressed.

[edit] And I'm interested in further exploring macros to create a DSL for doing some magic in the spirit of, but not quite replicating, dotnet's Linq Expressions.

I've been using CLion with the Rust plugin recently after having used VS Code for some time.

I'm not sure what my opinion is yet, but "go to definition" seems to work more often than not which is nice.

> Build scripts in Rust are written in Rust, not some ad-hoc declarative build language.

And therefore also platform-independent by default, I guess?

And therefore can be treated just like any other Rust code.

I can use frameworks in my build script (lol at the idea of using makefile frameworks).

And I can also build up on these. Like your build script really just invokes other dependencies' build scripts. So I never really care about integrating some low-level dependency. This might work with other build systems in theory but never in practice.

Maybe I generate some assets during compile time and really want to cache these. I can legit just add some sort of disk cache framework to my build script and just serialize the paths and then load that up on recompilation instead of regenerating things.

I am getting an aneurysm just from thinking about doing this in makefiles.

Coming from C++, I think it is the whole picture

- Key figures in the community that established a culture of caring about cross-platform

- Cargo making it very easy to have portable builds

- Standardized platform conditionals both for dependency declarations, for "including" files, and for individual items (e.g. functions).

Reply on news.ycombinator.com