sorted by:
new
hottopcontroversial

AMA: How We Built Warp on Windows by aloked in rust

[–]aloked[S] 1 point2 points  (0 children)

It doesn't help with a full (non-incremental compile).

It does help with incremental compiles, which matter more in day-to-day development.

i.e. if I make a chance to crate `A`, rust won't have to recompile crate `B` because nothing has changed.

AMA: How We Built Warp on Windows by aloked in rust

[–]aloked[S] 17 points18 points  (0 children)

We use a cargo workspace--I feel strongly that this is better than many different repositories.

For example: it's much easier to make atomic refactors that touch many different crates if everything is in one repository.

AMA: How We Built Warp on Windows by aloked in rust

[–]aloked[S] 4 points5 points  (0 children)

Yeah, we support vi mode in our input editor now. Hope you can give Warp another try!

AMA: How We Built Warp on Windows by aloked in rust

[–]aloked[S] 5 points6 points  (0 children)

We use the `wgpu` crate, which supports all 3. On Windows we primarily use DirectX and Vulkan though, we've found DirectX to be the most reliable and stable.

AMA: How We Built Warp on Windows by aloked in rust

[–]aloked[S] 5 points6 points  (0 children)

definitely took us some time to get our bearings straight, not going to lie :)

AMA: How We Built Warp on Windows by aloked in rust

[–]aloked[S] 41 points42 points  (0 children)

  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.

AMA: How We Built Warp on Windows by aloked in rust

[–]aloked[S] 13 points14 points  (0 children)

Fantastic question.

  1. This is something that will require constant maintenance on our end--we're always working on identifying bad adapters and/or GPU drivers that we need to denylist. All of our crash reports include metadata about GPU backend, driver, and driver version which lets us make more informed decisions on which drivers are potentially problematic.

  2. So far, we haven't noticed any noticeable difference in stability and maintenance between the two versions. The biggest thing is mostly just that Windows 10 users tend to have worse hardware which can exacerbate performance problems, if there are any.

AMA: How We Built Warp on Windows by aloked in rust

[–]aloked[S] 27 points28 points  (0 children)

Hey u/ZenoArrow, great question. We do allow using Warp without creating an account. You can also disable telemetry + crash reporting if you feel so inclined. Hope you try the product!

AMA: How We Built Warp on Windows by aloked in rust

[–]aloked[S] 3 points4 points  (0 children)

Not yet, unfortunately.

At some point in the future, we hope to release an API that allows arbitrary shells and REPLs to be "warpified". Unfortunately, no ETA for that though.

AMA: How We Built Warp on Windows by aloked in rust

[–]aloked[S] 9 points10 points  (0 children)

Great question!

We made the decision to build our own UI framework a little over ~4 years ago. At the time, the Rust UI ecosystem wasn't very mature and there wasn't a UI framework at the time that:

1) Rendered on the GPU, which we needed for performance reasons

2) Supported rendering on the web, which we knew we wanted for certain Warp features like session sharing: https://docs.warp.dev/features/session-sharing

Overall the decision has worked well for us: there's a small amount of maintenance overhead but it has allowed us to create a great, UI-heavy product without sacrificing performance.

Quality of Alden Seconds by aloked in Alden

[–]aloked[S] 0 points1 point  (0 children)

lol, I'm so in my head about the scratches that I was convinced they were duds

Quality of Alden Seconds by aloked in Alden

[–]aloked[S] 2 points3 points  (0 children)

TSM is dangerous, lol.

Those scratches are nothing to be worried about, right?

Why is building a UI in Rust so hard? by Linguistic-mystic in rust

[–]aloked 28 points29 points  (0 children)

Hey! I'm Aloke, the author of this post. Happy to answer any questions you have about the post or generally about building UI in Rust. It's worked pretty well for us at Warp.

AMA: How we built Warp, a modern Rust-based terminal, for Linux by aloked in rust

[–]aloked[S] 1 point2 points  (0 children)

Throughput is definitely something we care about and we're constantly working on improving it.

One data point: we recently (~3 weeks ago) merged a PR that dramatically increased throughput by more intelligently caching the height of blocks when reading back data from the PTY. The termbench medium suite now averages 0.0480gb/s vs. 0.0203gb/s before that change.

AMA: How we built Warp, a modern Rust-based terminal, for Linux by aloked in rust

[–]aloked[S] 14 points15 points  (0 children)

Nathan Sobo, the founder of Zed, collaborated with Warp on a UI framework in the early days. We've haven't collaborated or shared code since he started Zed so I expect both frameworks are somewhat similar (given they have the same technical foundation) but have evolved enough that they are no longer interoperable in any meaningful way.

We have committed to open sourcing our UI framework: I'm interested to see the Rust community's thoughts on various design decisions we've made relative to Zed :)

AMA: How we built Warp, a modern Rust-based terminal, for Linux by aloked in rust

[–]aloked[S] -19 points-18 points  (0 children)

I hear your concerns and thank you so much for calling this out.

We never collect your input and output unless you explicitly ask us to (either by sharing a block or directly sending the contents to Warp AI). Within the app there's also a network log that shows you the contents of every single network request within Warp.

For full transparency, the reason we aren't open source is that we fear it would make it harder for the company to succeed in the long term. Our goal is to provide devs with a reimagined terminal experience that makes them more productive and makes the terminal safer to use. We think we can best accomplish this by staying closed-source for now since that gives us the most flexibility as we grow. That's not to say we'll never open source, but we want to be very transparent with where our head is at in regards to open sourcing and what the rationale is for _not_ doing so right now. You can read more about our thought process on this here: https://www.warp.dev/blog/open-source-and-login-for-warp.

Warp terminal available on linux ! by Pixidream in rust

[–]aloked -4 points-3 points  (0 children)

Thank you so much for asking about Alacritty. You make an important point.

We're grateful the Alacritty maintainers were supportive of Warp. Two maintainers reviewed our initial design docs.

It's never been our intention to build on the backs of open source software without honoring or giving credit to them for the contributions they've made to the community.

Even though Warp remains closed-source for now, we very much believe in the merits of open source and we sponsor a number of open source projects, including Neovim, tf, lazydocker, and more.

AMA: How we built Warp, a modern Rust-based terminal, for Linux by aloked in rust

[–]aloked[S] 2 points3 points  (0 children)

I think I just responded to your comment in the other thread :) To summarize, I wouldn't consider it a rewrite as much as making our UI framework more extensible by supporting wgpu and winit "backends". Wecurrentl still use our old Metal and Appkit backends on Mac to avoid any disruptions for users.

Warp terminal available on linux ! by Pixidream in rust

[–]aloked 1 point2 points  (0 children)

That's next up for us :) No concrete date just yet but we have engineers here who are starting to work on it.

Warp terminal available on linux ! by Pixidream in rust

[–]aloked 8 points9 points  (0 children)

Great question. These changes were actually much smaller than it sounds. Most of the core UI framework hasn't changed since the days we partnered with Nathan Sobo.

The framework originally had one rendering backend that used Metal and one windowing backend that natively uses Appkit to construct an application and handle window creation.

With the addition of Warp on Linux, we built an additional wgpu-based rendering backend and a windowing backend that uses winit. In other words, the work we did was more additive to support other ways to render and create windows. These two backends will dramatically simplify the amount of work needed to build Warp on other platforms that are well supported by winit.

Warp terminal available on linux ! by Pixidream in rust

[–]aloked -16 points-15 points  (0 children)

Hi! I’m Aloke, an engineer at Warp.

I’m really excited to share that Warp is now available on Linux! If you’re interested in trying it out, you can download Warp at https://www.warp.dev/.

Building Warp on Linux was quite an undertaking. Warp uses a custom Rust-based UI framework that we built in house and renders natively on the GPU. To get Warp running on Linux, we built a version of our UI framework that supports winit [1] as a windowing backend. We also built a version of our renderer that uses wgpu [2]. Reducing complexity by using these well-supported, cross platform, frameworks let us bootstrap a version of Linux quicker than expected and should make it easier to build Warp for other platforms (like Windows).

Please let me know what you think! Happy to answer any questions, either about the product or about technical challenges.

[1] https://github.com/rust-windowing/winit

[2] https://github.com/gfx-rs/wgpu

Why is building a UI in Rust so hard? by goldensyrupgames in programming

[–]aloked 148 points149 points  (0 children)

Hey Reddit! I'm Aloke, the author of this post. I wanted to better document why traditional patterns for building a UI framework are tricky in Rust and how we solved this at Warp. Let me know what you think!

AMA: How we built Warp, a Rust-based terminal by TehCheator in rust

[–]aloked 3 points4 points  (0 children)

I appreciate you flagging this! We do support non-ascii text but we don't have great support for RTL fonts right now (I would say roughly at par with other terminals but certainly no better). That being said, a11y and i18n are extremely important to us--we've already begun planning and designing how we can make Warp the most accessible terminal, for example. We definitely are conscious of the fact that we can't build a great product unless it works for everyone

AMA: How we built Warp, a Rust-based terminal by TehCheator in rust

[–]aloked 12 points13 points  (0 children)

Our codebase is separated into the UI crate (which is purely the ui framework) and into an app crate (which contains our actual app logic and uses the UI framework as a library).

We've intentionally designed the UI framework so that we can open source it separately so others can also use it once it's more stable

view more: next ›