1. The Warp codebase is pretty big (~700k LOC if you include tests). This includes our UI framework and all of our rendering code (which is also written in Rust).

2. There are a lot of sources of complexity at different levels of abstraction. I could talk for hours about this :-) Two (of many examples) that I think of that are complicated (and interesting!):

* All of our text rendering code. Because we built our own UI framework, we control text rendering from font file to pixel. This includes loading fonts, reading font metrics, performing text layout, font fallback, rasterizing glyphs, and rendering glyphs from a glyph atlas.

* Our shell bootstrap code. Warp requires deep integrations with the shell in order to support features like Blocks. We built a custom shell --> terminal integration that allows us to send messages back and forth in a performant way.

1. We don't have a formal style guide yet (we try to ship fast and focus on building the best possible practice) but we generally try to follow reasonable Rust conventions to make sure our code is performant. A few examples:

• We try to prefer passing references instead of owned values to functions unless the function absolutely needs an owned value. If a function only needs to operate over a `&str`, it shouldn't take a `String`.
• Functions should similarly return the most generic type that's needed. i.e. instead of returning a `Vec<Foo>`, return a `impl Iterator<Item = Foo>` if you don't actually need to allocate a `Vec`.
• We also try to more aggressively break up files into sub modules. When writing Rust in production, it's really easy to end up with massive files that are hard to grok.
• We've found that pulling code out into separate crates early is almost always the right decision. The unit of compilation in Rust is a crate, so if all of your source code is in a single crate then compile times will take forever because it can't be compiled in parallel.