Hacker News Reader

Comment by woodruffw | Hacker News Reader

You probably already know this, but I figure it bears repeating: most people should be running `cargo check` during development, not `cargo build`. The latter is only necessary when you actually need the built binary; the former is sufficient for type- and borrow-checking.

(On my local machine, `cargo check` is roughly 2x faster than `cargo build`. It's still slower than hot-reloaded Python, but it's rarely my development bottleneck.)

View on HN

cargo check is useful to verify the code compiles (it's extremely rare to have compilation errors that survive cargo check). But cargo build is required if you want to actually try out the code you wrote, e.g. in order to run a test that you or the LLM wrote.

Yeah, I mean more for the iteration half -- YMMV, but I find that I make the LLMs most productive when I have them design the typestates first, ensure they compile, and then work on tests after that (rather than stacking tests through the process).

Yeah but like, tests encode behavior… sometimes I go all day without running a test. Sometimes multiple days. I’ve been using unit tests less and debug asserts more and more now days anyways. Encoding behavior as close the relevant code as possible. And using types and type state to minimize invariants. Idk, but it seems like such a smell when my coding agent drops 10 unit tests for a 300 LoC module. It means it did a bad job of writing the code in the first place.

Anyways, if the code compiles, but the behavior is wrong, a test might be useful. But so is reading the code… so I’m skeptical of rerunning tests constantly.

A non starter for anything related to graphics or UI development, which is kind of most Rust stuff are CLIs or TUIs, like being back on curses heyday, Turbo Vision and Clipper.

Various Rust UI projects have been working towards hot-reloadable capabilities, based on the work from the Dioxus team.

IME it's just not really that big of a deal at this point. YMMV, etc.

I am aware, still far away from what something like C++ Builder was already offering in the 1990's, let alone other more modern alternatives.

Is it? An immense amount of the world’s graphical software is written for native graphical targets like SwiftUI, where the iteration cycle is similarly bound to build times. It’s certainly painful, but I don’t think it’s a non-starter.

SwiftUI has an incremental compiler with interactive workflows.

Rust has an incremental compiler. And TMU SwiftUI’s live preview is essentially a very rough approximation of what the actual build would produce; it’s not a suitable replacement for a real build when developing a non-trivial UI.

The experiences still fails short of XCode or Playground, hence why Slint has its own scripting language.

Sure, I don't disagree. It's just not clear to me that developers actually index that heavily on hot reloading to begin with.

Devs doing graphics and game development care so much, that there are companies like Live++ selling hot reloading tools for C++.

Like, devs actually pay for having hot reloading.

My rust compiles in the time it takes to switch from my editor to my browser to see the changes incremental recompiles are fast enough imo. Dioxus has hot reloading if you want to go faster and Bevy uses it for hot reloading as well.

With a beefy desktop, or some Apple wonder CPU, right?

M2 air. Pay to play brotha

Which is why devs on other world regions will chose something else, more ammendanble to their pockets to stay productive.

Ok and?

And less language adoption in regions whose devs aren't able to afford beefy computers to use Rust ergonomically.

Which is why then they go back other languages,

https://loglog.games/blog/leaving-rust-gamedev

Gamedevs usually have the most powerful machines of all types of devs because of it's very nature. Yes you can't compile Rust on the GPU but big gpu's come with big CPUs usually.

Reply on news.ycombinator.com