Hacker News new | ask | show | jobs
by adamnemecek 2331 days ago
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.
2 comments
sprucely 2331 days ago
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.

link
adamnemecek 2331 days ago
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.

link
vanderZwan 2331 days ago
> Build scripts in Rust are written in Rust, not some ad-hoc declarative build language.

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

link
adamnemecek 2331 days ago
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.

link