Readit NewsI mentioned pyright because (some of) the specific concerns by OP are addressed by it.
I do agree that I (and most HNers) find explanations of inner workings interesting in Show HN (or anything on HN).
I didn't imply anything about BlenderGPT at all, I just responded to a comment. Reddit is both an advertising platform for products of all kinds, and a conversation platform for broader categories of audiences, whereas SHOW HN is like a "here's my project/product, I hope you find it interesting, and here's a chance to ask me about it". If someone posts a Show HN, it's fair assume that if people find it interesting, they'll ask how it works, because we're going to be curious, and if a person is hypothetically not prepared for that, Show HN might not be the best place to post it. I didn't say any of that was true or false regarding BlenderGPT, it was just a general remark.
The question was: > why does it matter how it works?
and that's all my comment was intended to answer. Many people here are interested both in the idea of doing something enough to upvote AND are curious how something works. We're not necessarily just consoomers, we're often interested in details, but if I was buying something and wanted to know why I should, the maker should probably be able to answer why their thing is special; in this case, I'm just saying that people on HN are generally interested in how things work.
But you specifically said that without such an explanation, products should "go to Reddit" (which presumably means, they don't belong on HN). I'll leave whether that's a "dismissal of someone's work" or not up to you, but all I'm saying is: it's evident via voting that many HNers find BlenderGPT, a tech product, interesting, even with the lack of that explanation. And so BlenderGPT does not need to "go to Reddit".
Plus, many are probably tired of seeing the same thing being made repeatedly that just proxys requests to chatgpt and makes them look pretty.
Make sure that your ide/vscode is using the exact same rust toolchain as you to build/check/run. Otherwise you don't get incremental compiling but recompilation a lot. I think there's an environment variable to force it.
One thing that popped out is that you might want to try to define dependencies at the workspace level and then in the sub-crates point to those instead.
Otherwise you are correct, your setup is already very granular. Furthermore, I have no clue about why it takes so long on your end :/ . I am running on Linux, so I wonder if there's something in the MacOs stack that messes things up and so you end up recompiling dependencies over and over.
Another thing I noticed in my setup is that one of the biggest offenders was sqlx if the macro feature was enabled since the queries were ran at each incremental compilation.
I figured out the issue: I transplanted the bit about setting optimization levels from the blogpost into my setup (which sets opt-level = 3 for all dependencies), and when I removed that, my compile times went down by a factor of 5-10!
I'm also looking forward to the maturity of Rust-based type checkers, but solely because one can almost always benefit from an order of magnitude improvement in speed of type checking, not because Python type-checking is a "shit show".
I do grant you that for outsiders, the fact that the type checker from the Python organization itself is actually a second rate type checker (except for when one uses Django, etc, and then it becomes first-rate) is confusing.