How would you feel if you joined a company using Rust with a style guide focused on speed and iteration, emphasizing imperative code, simple types, more tests, and avoiding functional abstractions, complex types, and generics?

I came across an interesting idea about a Rust style guide designed for startups that need to prioritize speed and fast iteration. The concept suggests focusing on imperative code, using simple types, and writing tests, while avoiding functional abstractions, complex types, and generics. This approach is intended to make the codebase more maintainable and adaptable in a fast-paced environment.

One of the biggest complaints I see with Rust in the environments I work in, and with people who have been working with Rust for a while, is the overuse of dependencies and the tendency to add them for everything. Additionally, there's a heavy reliance on abstractions using generics, with the goal of making everything generalized and functional.

The idea isn't to ban complex types, generics, or abstractions altogether, but to reserve them for situations where they genuinely make the code simpler and more efficient, rather than adding unnecessary complexity.

What do you think about this approach? How would you feel if you joined a company using Rust with a style guide like this? Would it be challenging to move away from functional programming and more abstract patterns in favor of simpler, more flexible code?

EDIT:
It's not about not generalizing, not using generics, or not using highly defined types; it's about not using them too early when definitions can change in a matter of weeks, while you’re still discovering the business rules.

It’s not about the type being overly described, but rather about generic abstractions or early definitions that try to generalize something still in its early stages.

For example, something might just need an amountValue to work, but because you start with a certain type of invoice, you tie everything to that invoice type, making it more complex. Now you have several invoices types, and while the code could work with the same rules, it requires a lot of refactoring to adjust all the types. This issue continues to accumulate over time.

It's not about the type system itself—the type system in Rust is great. The problem lies in creating complex types that tie things too early. This isn’t a Rust problem per se, maybe a domain problem when working at enterprise, fintechs early stage; it happens in Java codebases all the time with enterprise devs who overcomplicate things by making everything too tightly coupled to specific types just because they can.

Another point: can you suggest what you think would be more effective than this, or something to add to it? Maybe some courses? Should we add a step in the interview process to make this clear to the developers and try to find developers who already have this coding approach?

Just giving more context: I was against the use of Rust in my fintech, but some developers pointed out that my problem wasn’t with Rust, but with a certain type of developers who have the habit of generalizing everything, abstracting early, and basically making libraries and things, which is much more common in their domain than in fintechs and the enterprise world. After several experiments, we concluded that Rust is great, with some common sense and style guides they created and showed me. The result was very effective, and I’d say the iteration was just as great as with our Go and TS codebases — we didn’t lose anything. It broke my strongest argument against using Rust. But now my question is: how do we share these lessons with new hires? Interview process? Courses? Style guide?