20 ms·

I tried Rust about a month ago. The language itself is amazing, the pattern matching is super expressive, the borrow checker is incredible in the kinds of error

• FridgeSeal 6y ago
  I find that the strong type system and editor plugins like Rust Analyzer have me covered for “does this do what I expect?”, which means I do way less write-run-check than I would I say, Python.
• byteofbits 6y ago
  As a datapoint for your hypothesis, when working in a typed language I will build my code only a few times a day. I much prefer working from a logical and thoughtful approach rather than iteration. At the point where I start a build I am already reasonably confident that it will do what I want it to. There are some bugs where I will need to re-build several times consecutively but these are relatively rare for me (I work on REST API systems - so nothing too crazy).
  • johnfn 6y ago
    That's really interesting. Compiling only a few times a day is mind boggling to me - in a normal day I'd probably average hundreds to a thousand compilation cycles! 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.
    • wiz21c 6y ago
      >> in a normal day I'd probably average hundreds to a thousand compilation cycles! Maybe it's time to switch to an interpreter ? :-)
      • logicchains 6y ago
        Or a language like Go, C or Nim that can compile tens of thousands of lines of code in a few seconds.
        • pjmlp 6y ago
          Or OCaml, Java, C#, F#, Eiffel, Delphi,...
          • hellofunk 6y ago
            Just googling “f# compile times” would beg to differ.
            • pjmlp 6y ago
              Apparently you didn't bother to read the 3 answers that come up. Only one of them says anything and it an empty statement like > F#'s compile times also seem to err on the long side but not very much so, my impression goes. However it is quite easy to validate write the same algorithm in F# and Rust and then compare. Ah but Rust is AOT compiled, easy, use NGEN, .NET Native, or Mono AOT for the F# compile time measurements.
• felipellrocha 6y ago
  Man... I hear you, but this is only a problem compiling from a cold cache. From a warm cache, it really isn't a problem anymore.
  • johnfn 6y ago
    No, it's an issue for warm caches as well. I had a 10 second compilation cycle to add a comment to a file in a project with a couple hundred lines of code and like 4 lines in my cargo.toml. 10 seconds! For a few hundred lines! Maybe that doesn't sound insane, but extrapolating out, that's at least 100x worse than the languages that I'm used to. (I know that compilation speed is a Hard Problem, I know that I'm comparing apples to oranges, I know that Rust does fancy magic that other languages could only dream of. But everything that slow compiles buy me won't get bring me back flow state.)
    • DougBTX 6y ago
      If it is a project you’ve recently built, it shouldn’t matter what’s in your cargo file, since none of that will change from build to build. I wonder what’s broken. How long does it take to build a new empty project? One think that’s helped me stay “in the flow” is switching to rust-analyzer instead of the current official RLS. Much faster, I leave format on save turned on, so `cargo check` output is usually ready in about a quarter of a second after save.
      • johnfn 6y ago
        A new empty project compiles in under a second. However, adding dependencies will add some arbitrary number to this. Additionally, every hundred lines of code seems to add some amount of time between half a second and a whole second. I did some reading and read that generics are particularly expensive to compile, so I wonder if that accounts for the variance. I can't explain why cargo deps add time, though. I LOVE rust-analyzer. It's actually what got me to reconsider Rust after I tried a year or two ago, and it is SO good.
        • 6y ago
• sfgweilr4f 6y ago
  Glad I'm not alone. This frustrated me completely. But if their use case is twice a day or similar it makes sense. Why care about compilation time at all if its seen as that rare? Other opinions exist.
• _-___________-_ 6y ago
  Using Rust heavily for ~4 years here. I usually compile a few times a day, so while I do hear people talk about compile times a lot, it's just never really been a problem for me. I'll often write hundreds of lines of code, and sometimes build the "outline" of a whole app or library, before compiling. I haven't developed that workflow in response to slow compile times, it just feels natural to me.
• echelon 6y ago
  > I'm the kind of guy that likes to re-run his code continually to see if it validates to what I expect it to be doing. I used to be the same way, but the more I practiced holding the state in my head while I worked, the better I got at it. > One group loves fast compile times and quickly validating hypotheses. You just don't need it. As you make changes, the delta between expected behavior and actual behavior continues to grow. You begin to develop an intuition for what kind of things might not work as expected, and you can conceptually model around those things and continue to build your logic and make your changes. An IDE helps immensely with type error minutiae. I'm using CLion and it's pretty great. For the few cases it can't figure out the types for you, you can run "cargo check". I'm confident that Rust has made me a better engineer. I don't need to continually save and evaluate and I can do deeper work with more uninterrupted flow. Give it a try! I think you'll start to acclimate. Edit: Why the downvotes? I stated my personal experience as it relates to OP's observations. I improved in how I approach problems after exposure to Rust.
  • logicchains 6y ago
    >I used to be the same way, but the more I practiced holding the state in my head while I worked, the better I got at it. Doesn't that partially defeat the point of having a powerful compiler? The more work the compiler does, the less we have to keep track of in our head (and conversely, much of the pain of coding in a language like Python is the amount of stuff we need to mentally keep track of).
    • echelon 6y ago
      The compiler makes sure we're not making mistakes, and it keeps the code safe from humans. I think this is somewhat orthogonal.
    • kd5bjo 6y ago
      > The more work the compiler does, the less we have to keep track of in our head There’s two sides to this: on the one hand, you don’t have to keep as much info in your head because the compiler will tell you if you ask it. On the other hand, when you do try to keep state in your head, the compiler is able to double-check that for you so that you don’t have to do it perfectly. With a language like Python, you’re working without a safety net, so you make small, cautious, steps in order to not fall. A strongly-typed language like Rust enables you to make larger, bolder, changes in one go, confident that the little mistakes will get caught.
• zozbot234 6y ago
  > I keep reading in Rust surveys that Rustaceans just don't care that much about compile times enough to prioritize improving them. I've often wondered how this can be possible Well, there's a simple answer... https://xkcd.com/303/ https://xkcd.com/303/
• archseer 6y ago
  While the initial compile time might be slow because of dependencies, subsequent runs are incremental and maybe take a second for me.
• rapsey 6y ago
  > I'm the kind of guy that likes to re-run his code continually to see if it validates to what I expect it to be doing This honestly is a bad habit. Thought it does depend quite a bit on the type of work you are doing. For some things it is necessary especially if it is inherently fibbly. Rust is a language to which the programmer must adapt his way of working and thinking. If the programmer is too set in his way, his Rust journey will be unsuccessful. If the programmer is adaptable, he will come out in the end a better programmer, because the Rust way is actually the right way. I think I actually went a couple of weeks once before trying out my program for the first time and there was no big deal to get it to actually work in the end.
  • bluecmd 6y ago
    > because the Rust way is actually the right way. [Citation needed]
  • johnfn 6y ago
    > This honestly is a bad habit. I'd like to hear some justification for this rather than a blanket assertion. Just because our work styles differ doesn't mean that my style is necessarily wrong. > Rust is a language to which the programmer must adapt his way of working and thinking. I mean, Rust is actively attempting to improve compile times. It's not like devs made them intentionally long to cultivate good programming habits or something. So I'm not sure how this is relevant.
    • rapsey 6y ago
      The most time wasteful part of programming is debugging. Writing slowly and thinking through your options and double checking what you wrote saves time. Especially since you are doing this while writing and you have the complete picture in your head. Obviously it does not catch everything. But one should strive to minimize detective work.
      • drenvuk 6y ago
        After I've been programming for an entire day I will rely on the compile to tell me when I'm wrong with an assumption. I'm honestly trying to conserve mental energy so I've learned that it's better to do it from the start and avoid keeping track of as much stuff as possible in my head. The compile tells me something's wrong somewhere and I go fix it and move on. That's not detective work, at least it doesn't feel like it to me since it's so quick.
• pengaru 6y ago
  Is this not something you can just throw more hardware at?
  • kungtotte 6y ago
    Other languages are able to compile much faster than Rust on the same hardware. So while adding hardware helps (up to a point), Rust is definitely an outlier when it comes to compilation speed.
    • mlindner 6y ago
      This really isn't true compared to C++. Also Rust is doing more than basically every other language, so it's provably slower.
      • kungtotte 6y ago
        I don't have a good idea about the compilation speeds of C++, so I don't doubt you on that point. That's hardly the only other AOT language competing with Rust though, and while some of them are simpler on a language level (i.e. C) the compilers do a fair share of work in the optimizing stage of those simpler languages. There's also several languages that do quite a bit of heavy lifting during compilation, like Zig and Nim have extensive compile time features for example. And Nim does two passes since it compiles to C first (by default) and then that's compiled to machine code. On balance, I don't think you can wriggle out from the fact that Rust compiles slowly compared to its competitors. Even the Rust team admits this and are working on improving it.
        • pengaru 6y ago
          If you want to use rust, and can achieve fast enough performance by simply buying some newfangled threadripper machine with a boat load of ram, what difference does it make? The OP sounded like they wanted to use rust except for this one issue of compilation being too slow for their development style. How fast is fast enough and is that achievable just by throwing some money at the machine? Perfect is the enemy of good enough as they say.
• Fiahil 6y ago
  Well, I like an instantaneous edit-compile loop too, bit I was never bothered by rust compile times. Once you get your cache warm, it's pretty much instant. If not, run `cargo check` instead of `cargo run`. You can also use rust-analyser for an in-editor <1s feedback loop.
  • johnfn 6y ago
    Copying this from someone else I replied to: No, it's an issue for warm caches as well. I had a 10 second compilation cycle to add a comment to a file in a project with a couple hundred lines of code and like 4 lines in my cargo.toml. 10 seconds! For a few hundred lines! Maybe that doesn't sound insane, but extrapolating out, that's at least 100x worse than the languages that I'm used to.
    • Fiahil 6y ago
      If you were using `cargo run` or `cargo build` instead of `cargo check`, these 10 seconds could be spent in linking the final binary and not running the compiler frontend. for that matter 10 secs is not unheard of for large libraries with a lot of debug symbols. That's why you should use `cargo check` instead : it will only run the rust compiler frontend, but not the LLVM linker.
      • jfkebwjsbx 6y ago
        Cargo check does not help with what the parent is talking about, which is a edit-compile-run loop.
      • entha_saava 6y ago
        Static checking is just a part of correctness verification (pretty large chunk but not enough). It can't catch many logic bugs, eg forgetting to update a variable's value. The type system can't help without non-straightforward techniques, and at that point it is diminishing returns. A powerful type system shouldn't be an excuse for not being able to iterate fast.
• thijsvandien 6y ago
  As someone who regularly uses Delphi, famous for its compile speed, I can totally see where you're coming from. Rust looks really interesting to me, but I've been holding off getting into it, because I would likely end up feeling the exact same way.
• bad_user 6y ago
  In dynamic languages like JavaScript or Python it's necessary to continually run your code in order to validate that the API (of the standard library or of dependencies) was used correctly, that the types match, etc. Rerunning your code continually is no longer necessary in a language like Rust, because the compiler already does that for you. People complaining about slow compile times in static languages like Rust, Haskell, Scala miss the forest from the trees, which is that the compiler eliminates entire bug categories, logic you'd otherwise need to check at runtime, either via unit tests or at least by running the code locally. Compiler times can always be better, but the compiler works as a theorem prover and the slowness is entirely justified, overall yielding a better ROI. N.B. I'm not saying that with Rust you don't need to run your code or have unit tests. There's only so much a compiler can prove. But you no longer need to do it as often. You can't switch to a language like Rust and expect Python and if you do, then the experience is going to be horrible, because Rust is a very different language.
  • tastyminerals2 6y ago
    In theory and to some degree in practice. The compiler won't fix the code that compiles but runs incorrectly. Besides, there are statically typed functional languages where compiling time is not a problem, see D.
    • bad_user 6y ago
      I haven't worked with D, but D isn't a functional programming language ;-)
      • tastyminerals2 6y ago
        You will be surprised if you do ;) Multi-paradigm to be exact. Scala is a multi-paradigm as well btw. http://beza1e1.tuxen.de/stuff/FunctionalD.pdf http://beza1e1.tuxen.de/stuff/FunctionalD.pdf
      • Recurecur 6y ago
        Julia also has plenty of functional features, but is above all a practical, fast, and fast-compiling language. The elegance is free.
• tastyminerals 6y ago
  Why don't you try D if type-and-compile is what you enjoy?
• on_and_off 6y ago
  I don't use Rust (super interested in rectifying that someday though, especially to replace the ruby we use in our server) but I have the same compile time issue with bytecode on Android. I used to be the kind of dev who compiles every tens minutes. The thing is, on Android compilation time are just getting larger and larger. Anecdotally, this is not because the tooling team is not interested in build performances, on the contrary they continuously work on it. However they are currently losing the battle : the median app complexity is growing way faster than they are improving the build times. I mostly got used to it. I can write code for a whole day and only compile once or twice. The more I am accustomed to our ecosystem and codebase, the less I feel the need to compile frequently. The only exception is for graphics code. The only way to know if something looks correct and good is often to compile. For that reason, while I still love writing polished animations, I dread having to compile 10 times in a row to get it just right.
• spuz 6y ago
  Could someone who is familiar with Rust clarify something for me? If I am using an IDE such as IDEA's Rust plugin, and I write some function which contains a type error, do I have to compile in order for the IDE to tell me there is a type error, or can I rely on automatic type-checking like I can in e.g. Java? In other words, is Rust slow to validate code, or is simply slow to compile code into a runnable binary? If it is the former then I can totally understand why Rust would turn certain programmers away. If it is only the latter, then I find it slightly harder to understand.
  • zozbot234 6y ago
    > In other words, is Rust slow to validate code, or is simply slow to compile code into a runnable binary? The latter. Validation/type checking is super quick. It might slow down a little bit if you do a lot of compile-time processing via macros, etc. IDE support is also improving a lot, and many Rust devs use an experimental component known as rust-analyzer to do the IDE-based validation you're talking about.
  • tadzik_ 6y ago
    Something like aforementioned rust-analyzer will catch errors like that within a second of you writing it, there's no need for recompilation.
• krzat 6y ago
  UI code absolutely requires fast compile times, ideally hot reload, but it wouldn't hurt to have a compiler that compiles code on background and executes unit tests for it.
• strangescript 6y ago
  People seem desperate for one language to rule them all. If you don't need a binary, blazing fast multi-threaded speed, and memory safety then you probably don't need Rust. "Need" being the big thing here. Do you need these things or are they just nice to haves in your head. A scripting language and a web browser can solve a surprising amount of application requirements these days, and its only getting better with time.
  • michalhosna 6y ago
    Yes, you need memory safety, everyone needs memory safety. And if you can write program in very fast language, why not? There doesn’t have to be need. Just no reason not to
    • Hercuros 6y ago
      If you can afford a garbage collector, then you can also just use something like Haskell or OCaml or Python, which also gets you memory safety. No need to think about lifetimes or different types of smart pointers. Not saying that it’s a lot of mental overhead, but it’s definitely a trade-off.
      • michalhosna 6y ago
        Agreed. I am not saying that rust is best for everything. I think, that languages are just tools, and you should use the best tool for the job, there should not be fanboyism in this. The bigger your toolbox the better. I just don't agree with statements about memory safety and speed. The thing is much more complex. I think simply stating "Use the best tool for the job" is much better than showing bad examples. Because everybody needs memory safety and wants speed. Nobody wants to write unsafe slow programs (Well, I HOPE). Nobody wants to drops either of those requirements. When you drop those requirements, it's because of tradeoffs (I think memory safety shouldn't ever be dropped, yes use GC lang if you want to, but in 2020 memory safety should be a very hard requirement)
• steveklabnik 6y ago
  > I keep reading in Rust surveys that Rustaceans just don't care that much about compile times enough to prioritize improving them. I am interested in how you got that impression, because at least in our official surveys, it's often one of the most-requested improvements to Rust, and it's something that we're constantly working on improving. Still a ton of work to do though! For what it's worth, my workflow is closer to yours than "compile twice a day." And if you're using rust-analyzer, by default, it compiles the code every save!
  • microcolonel 6y ago
    Maybe with some heuristics, you could hide some latency by beginning to compile before saving.
    • steveklabnik 6y ago
      Maybe. At the rate I hit :w, probably not :)
      • mlindner 6y ago
        How do you have Vim (or neovim) set up to do that and report errors inline?
        • steveklabnik 6y ago
          I use VS Code with the vim plugin. I hear you can get this working with vim/neovim but I haven’t done it myself.
        • sudosysgen 6y ago
          How I did it is that I install VimPlug then CoC then the rust extension.
        • ricree 6y ago
          I use ALE, which I believe includes Rust by default. https://github.com/dense-analysis/ale https://github.com/dense-analysis/ale
• staticassertion 6y ago
  > I keep reading in Rust surveys that Rustaceans just don't care that much about compile times enough to prioritize improving them. Confusing since this is, to my knowledge, a top 3 issue just about every year. That said, I think Rust programmers dislike compromise (maybe to a fault). Rust is naturally a 'have your cake and eat it to' language and the community very much likes to be best-in-class, so compromises on runtime performance to improve compile time (which is one way you can go today) are often not seen as viable by a large part of the community. For what it's worth, I think I've called out compile times as probably one of my top issues with Rust, working on a fairly large and quite dependency heavy codebase. It isn't a deal breaker for me by any means, but it's a pain.
  • whatshisface 6y ago
    >compromises on runtime performance to improve compile time (which is one way you can go today) are often not seen as viable by a large part of the community. Typically this tension would be resolved with o-level flags (O1, O2, O3...).
    • steveklabnik 6y ago
      Rust has those, though most people interact with them through cargo (with --release corresponding to O3 and not passing it to O0.) Sometimes, non-release builds are too slow to meaningfully run. It is not uncommon for release builds to be extremely faster than debug builds.
      • whatshisface 6y ago
        Might we get an -O2?
        • steveklabnik 6y ago
          It exists as well, and if you want to use it, it's a short "throw the option in your cargo config and call it a day." That being said, I'm not aware of it making any meaningful difference.
• ragnese 6y ago
  I don't have that much to add to the discussion, really. I just wanted to ruminate on something: > I've often wondered how this can be possible, given that to me it's such an obvious glaring issue that all the other cited problems are distant distant seconds at best. It's amazing how little I understand your point of view. And I'm being genuine and not critical of you at all. To me, all of the features of the language, from move semantics, to ergonomic sum types, to nicer error handling (to me. I know it's debatable), and great runtime performance are so important, and bring me so much more peace and joy while working that compile times are literally not even on my radar. I simply don't care if they ever get better (assuming that effort is being put elsewhere. I guess if the language is "done" then work on the compile times is appreciated). And I've certainly done real work in languages that compile fast (Go, Java) and languages that don't even compile. They always made me so much less happy because of the languages themselves just not clicking with my mental model of problem solving. Again, compile-run feedback loop just had nothing to do with it. All that said, I use Rust Analyzer for code completion and it's generally fast enough. But it's still sometimes has a noticeable stall. That's not my favorite and it's kinda related to compile times. Just really amazing how different people using the same tool have such wildly different modes of interaction and perceptions. Cool stuff. Cheers!
  • stjohnswarts 6y ago
    The time to compile these small web apps is not worth worrying about after the initial compile. I'm not sure what he's getting at to be honest. While it's certainly not instant, it's not that bad.
  • johnfn 6y ago
    Believe me, I love the same things you love about rust. Move semantics, sum types, error handling are all amazing, to say nothing of the ridiculous perf! I think our difference is I spend a lot of time on graphics and games, where there's a lot of manual tweaking that you have to do. (Is 20px far enough? 25px? Is 1 second long enough for the explosion? Maybe 0.5s instead?) There's just no way to test it outside of rerunning the app.
• throwaway894345 6y ago
  Disclaimer: I’m only a casual Rust user. > One group loves fast compile times and quickly validating hypotheses In Rust, it’s sufficient to type check (if it type/borrow checks, it will probably work) and Rust can type check in real time via rust-analyzer. This is much faster feedback than running your program or even its tests. Of course, Rust’s type/borrow checker is also choosier than many others, and you still spend more time fighting with errors that don’t actually improve your code’s correctness (e.g., borrow checker errors are rarely indicative of a bug in a single-threaded context). So Rust’s iteration loop is quite fast but it’s development velocity is still relatively low (even when adjusting for quality), but it’s improving all the time.
  • KMag 6y ago
    On the other hand, I've seen a few Java applications that leaked memory (and one case of leaking file descriptors) because developers had mostly gotten away with not thinking about resource ownership. Removing data races isn't the only advantage of refusing to generate binaries when the programmer appears to need to think a bit more about ownership.
• rezeroed 6y ago
  "there must be two groups of engineers" -- possibly, but I'm both groups - with Go i'm in the obsessive build group, to the point that people hate pair programming with me, and with Rust I compile less, review more. I'm certainly not driven away.
• 77gbnxfr67 6y ago
  `lld` is incredibly fast and allows medium crates to compile in under a few seconds for me. For people who don't know, if you're on linux put this in the `~/.cargo/config` file, and install the LLVM linker on your system. ``` [target.x86_64-unknown-linux-gnu] rustflags = [ "-C", "link-arg=-fuse-ld=lld" ] ``` `-Clinker=clang` also works. I think you need a recent `gcc` (8 or newer) for `-fuse-ld=lld`. For `linker=clang` you probably need `clang` installed. Permalink: https://reddit.com/r/rust/comments/dsfi5m/rust_2020_are_we_compile_yet_are_we_cache_yet_are/f6vzvoa?context=3 https://reddit.com/r/rust/comments/dsfi5m/rust_2020_are_we_c...
• ape4 6y ago
  I hardly know Rust. What about using many small .rs files so the compilation units are quicker. For a change of one line of code only that .rs needs to be compiled.
  • steveklabnik 6y ago
    Rust's unit of compilation isn't a file, but a crate. (this is ignoring incremental compilation, of course.)
    • estebank 6y ago
      Furthermore, most libraries make the stylistic decision of using generics and trait bounds instead of trait objects, which potentially generates faster code at the cost of slower compilation. This also has the consequence of requiring a recompilation of every dependant if that item: if you modify a root item that uses generics you will get a nice recompilation of your entire tree. Edit: working on dependency leaves though is mostly painless. If you don't work on fundamental libraries or frameworks of your system the experience becomes much better, although linking can take quite a while depending on your project.
• axilmar 6y ago
  Wouldn't a Rust interpreter solve this issue? Does Rust have anything that prevents it from being run interpreted?
• nicklauri 6y ago
  About long compile time, I recommend using sccache. It saved a lot of compile time for me. You can find how to install and use it here: https://github.com/mozilla/sccache https://github.com/mozilla/sccache
• adsjhdashkj 6y ago
  It's interesting - i very frequently recompile, running tests, etc - and i just don't have a problem with Rusts compile times. Maybe you want it more immediate than i do? The project i'm working on now takes ~8s to compile. Perhaps too slow, but i guess it just doesn't bother me. Though i definitely want to see it improve for wider adoption, as it's clearly an issue for many people - I just have difficulty feeling the pain in this case, i guess. edit: I imagine i compile once every 5 min of code writing. Varies by problem solving of course.
  • karmakaze 6y ago
    Yes 8s would me too slow for me. I'd usually set up a fullstack front+backend dev that hot reloads both parts an 8s delay interrupts flow. Compare that with 1s (or less) for Go or even Java (with a lightweight framework).
• caente 6y ago
  > I'm the kind of guy that likes to re-run his code continually to see if it validates to what I expect it to be doing. In Rust, this kind of workflow just doesn't work at all. Interestingly, my case is the exact opposite. When I am coding in Typescript or Python I'm out of place, since I got used to first write the types to make sure everything is aligned, _and then_, start writing logic... Even in Typescript this workflow is not easy to do, since its compiler is nowhere as powerful.
• randyrand 6y ago
  Is there interest in a rust interpreter? Would it be too slow to be useful?
• jasonpeacock 6y ago
  Can you share how long your compile times are? And what you feel is are "usable" compile times? I see comments a lot about "this is too slow" but rarely are numbers provided, neither the actual times nor the expected times. You may have something setup wrong and are seeing unusually long compile times. Or your expectations may not be realistic. Or you're just an outlier whos work triggers some pathological compile issues. But without data, we can't know what's going on.
  • johnfn 6y ago
    Sure. In an empty project, I saw around 0.7s compile times. This is ideal. But I kept developing and added around 300 lines of code and a few (3?) dependencies to my cargo.toml, and I was seeing compilation times that were exceeding 10 seconds to, say, add a dbg! message. 10 seconds is basically as slow as I'd accept. I wouldn't love it, but I'd suffer through it if I had to. But what I really didn't like was that my feeling was it wasn't the bottom - adding more deps or more lines of code looked like it would continue to increase the time without bounds. I like doing a lot of game dev and graphical work, and it often requires really rapid iteration to test small changes. (How fast should the AI walk? Should he turn around at this point? Does this logic "feel right" like this, or do I need to trigger it conditionally?)