[_-___________-_]

> The main thing that I use compiling for is to validate little off-by-one things. Like, is substring() exclusive on the second parameter? What about range syntax and the slice operator? What if I wrote + 1 instead of - 1 somewhere, or did < instead of <=? I could spend a few minutes combing documentation, or just compile it and check immediately. Well, assuming compilation is fast anyways.

I'm a really big fan of reading the docs (or, where the docs are insufficient, the source), and will always have docs.rs open alongside my editor. While the examples you provide are easily validated by testing (and I'd probably use `evalr` in `##rust`, or some similar thing, for them), many subtleties can exist in more complex functions, so not reading the docs/source for unfamiliar functions feels like programming-by-guessing to me.

[johnfn]

Perhaps my examples were a little too trivial. I do a decent amount of game/graphics coding, so there's a lot of "hmm, does this look good 20 pixels over? How about 18?" and I don't know how you'd get around that without recompiling.

(OK, you could read preferences from a file, but then you'd have to optimistically write every value you'd ever want to recompile to a file. I've tried this, but it's far too much overhead.)

[CogDisco]

Why not have controls in your program to do these immediate, non-logic changing modifications? It can report the ideal value through a debug interface. No recompiles needed.

I'd also recommend getting used to serialisation/deserialisation. Serde for Rust makes this remarkably easy. Writing every setting to a file is simple if the compiler can do it for you, rather than you walking the long way around.

[logimame]

When you're doing any sort of non-trivial gamedev, graphics, or physics simulation work, there are so many instances when you have to get a bunch of magic numbers by trial and error, and it's usually all over your code. If you try to "refactor" these cleanly into a separate JSON file (hint: it NEVER is that clean), it still takes time and effort away from you to by writing boilerplate code, which seriously kills your momentum for experimenting and iterating with your code. It's kind of a niche domain-specific thing which most gamedevs and graphics programmers would sympathize with.

Also there are also a shit-ton of minor logic-changing modifications when you're writing prototype gamedev code, (for example, moving an if statement here or there to tweak the physics of your platforming). These cannot be easily represented in config files, and this is why people attach lightweight scripting languages like Lua to their game engines (so that you don't have to wait for those atrocious C++ compile times when tweaking your gameplay code).

(Ironically, serde is known for its atrocious compile times, which really makes the situation even worse. Because of this some frustrated Rust gamedevs wrote their own serialization libraries such as nanoserde (https://github.com/not-fl3/nanoserde)... but you get the point.)

[saurik]

FWIW, I am with you in the camp that cares about compile times. I use C++, I care deeply about compile-time correctness (and have "as close as I can get to rust as I can" abstractions for tons of things such a small locks, but then take advantage of the almost-dependent typing provided by C++ to go even further than you can in rust to prove correctness of my buffers), and I envy people who get to code in Haskell or Idris. I am not a "dynamic typing" addict by any means.

But I work on network protocols and file formats and parsers and video transformers and user interfaces (often command line or web) and a long time ago games ;P... I make a small change and then I want to see the behavior difference. I almost always type code that compiles, but that doesn't mean it did what I want when interacting over the network: rust doesn't provide anywhere near powerful enough type abstractions to actually prove my code is correct... it only is proving that my code can't crash and will avoid undefined behavior.

What is so frustrating is that there is nothing about Rust that makes it impossible to make fast. With C++ I get to manually make tradeoff in my code on a file-by-file basis with an assumption that my project will be built out of thousands of mostly-independent fragments that I am able to compile incrementally or in parallel. I can very rapidly isolate individual functions I am working on for fast iteration without having to restructure my project, I can tell the compiler to instantiate templates in different ways to reduce dependencies, and I have designed a system to let me do parallel compiles on AWS Lambda (I haven't yet gotten my build environment to be ready for a -j1000 parallel build, but I am somewhat close).

I have been integrating some rust libraries into my codebase (I haven't even gotten to the point of really coding in it omg) and Rust is just so painful and frustrating to work with... and it really does just seem to be, as you pointed out, a matter of priorities and interest: there is this myth that it is some kind of tradeoff on the type system, but it isn't; it is just that the people who work on rust seem to not work on the same kind of projects that we do, at least in the same way, and so have made a bunch of trade offs like "I would rather never have to type a prototype than save any time compiling" and "I would rather my build system never have to consider dependency management than save any time compiling" and "I would rather provide the highest possible quality resulting binary than save any time compiling" (which is at least one I can appreciate, but only once a month when you cut a release... not the hundreds of times a day that I recompile my C++).

[zozbot234]

> "I would rather never have to type a prototype than save any time compiling" and "I would rather my build system never have to consider dependency management than save any time compiling" and "I would rather provide the highest possible quality resulting binary than save any time compiling"

Rust outputs prototype information in .rmeta artifacts that are generated as one of the first steps in compilation, so this is not a compile-time issue. AFAICT, dependencies are also tracked, and debug vs. release switches are provided that also control things like binary optimization.

The real "problem" for compile times in Rust is that Rust makes it idiomatic to write code that's slower to compile. That's really all there is to it. If you were to literally write Rust like it's C, you'd find that there's no real overhead introduced by Rust per se.

(This is not to say that improvement is not possible, of course. Even what's "idiomatic" can be tweaked over time to reduce the amount of excessive, duplicated work that the build system has to do. Newer features like const generics will probably make this feasible in the future, and improvements in the compile workflow itself will do the rest.)

[pjmlp]

Yes, for example I can easily do multiple UI changes in UWP, with C++/WinRT or C++/CX, in a fraction of the time that it takes to build Rust applications.

I am quite curious how usable Rust/WinRT will turn out to be for WinUI work.

[smt88]

> I do a decent amount of game/graphics coding, so there's a lot of "hmm, does this look good 20 pixels over? How about 18?" and I don't know how you'd get around that without recompiling.

I know exactly what you mean. Front-end development can be this way, too.

I think it's OK (and probably true) to say that you shouldn't use Rust for cases like this right now.

[johnfn]

Yeah. It's a bummer because Rust would be a fantastic language for gamedev otherwise, and a lot of people are interested in it for this reason. It's got everything else you'd want out of a good gamedev language - no GC, smart memory model, blazing perf, really expressive...

[nicoburns]

> I think it's OK (and probably true) to say that you shouldn't use Rust for cases like this right now.

I think that's true, but only because of the slow compile times. Which is why they're so frustrating. Rust would otherwise be an excellent language for these use-cases.

[smt88]

I see where you're coming from. The good news is that compile times are something we are certain will get better. Rust's maintainers know it's a high priority, but even if they didn't, we would still benefit from increasingly powerful machines used for graphics/gaming development.

[chrismorgan]

That’s the sort of thing where you often use another language suitable for hot reloading for such customisation or rapid-feedback alteration. As a couple of examples I’m aware of:

• The Azul GUI toolkit uses CSS for styling of its widgets, and hot-reloads stylesheets.

• The Mun programming language is designed for the sort of niche Lua is often used, with hot-reloading scripting-like functionality to augment your Rust code. (Well, Rust is the main host language at present, anyway.)

[dleslie]

Unity build times on a huge project aren't hot, either; particularly when you must build a client to test.

[_-___________-_]

Yeah, for game/graphics stuff I can definitely see that.