Live data from Hacker News

Warp: Fast, Rust-based terminal (waiting list)

warp.dev

81–90 of 181 posts

Re: Warp: Fast, Rust-based terminal (waiting list)

#81
Looks interesting! I'm surprised. I've been working on my own emulator [0] and we share some ideas. I think you could go a little farther with what you have. If you watch my demo feel free to reach out.

Banter is always useful

[0] https://media.handmade-seattle.com/terminal-click

Re: Warp: Fast, Rust-based terminal (waiting list)

#82
post #78

Somehow it feels odd that an implementation detail like the programming language it's implemented in is so prominent in the project's description. I have no idea what bash is written in and frankly I don't care much about it. It's a tool that enables me do be more productive. Could it be faster? Probably, but does anyone even notice that in the context of all the other things that we do _with_ it? Are there any benef…

I can see how "written in safe-only Rust" can be a plus, as that comes with certain security and safety assurances, but Rust itself doesn't warrant anything. You can write unsafe code with Rust too.

I can guaranty you that stuff using GPU ect ... are using unsafe anyway. They don't even advertise safety on their page.

Re: Warp: Fast, Rust-based terminal (waiting list)

#83
post #73

Earlier quoted context omitted.

Our plan is to open source the Rust client code once it's more mature. We are particularly excited about sharing our Rust UI framework since there aren't a lot of great options for building native UIs in Rust right now. We want to make it cross-platform first though.

Why not just develop out in the open from the start, instead of dangling an open source carrot? You might even get community contributions.

It's a fair point, but we don't feel ready to accept community contributions yet.

Re: Warp: Fast, Rust-based terminal (waiting list)

#84
post #47

Earlier quoted context omitted.

Assuming that it wasn’t a rhetorical question: I do. I spend 1/3rd of my day in terminal emulators, and anything that reduces the number of stupid (normally memory corruption) crashes that interrupt my work is a legitimate value proposition for me. Edit: This isn’t an endorsement of this particular product, to be clear. I don’t know anything about it, except that being written in a fast, memory safe language endears…

What terminal are you using that crashes so often? I’ve used Linux and Mac terminals for ages and cannot remember one terminal crash.

It's been a while, but gnome-terminal on earlier gnome 3 releases used to segfault very frequently for me. It's the thing that finally made me seek out other terminal emulators

Re: Warp: Fast, Rust-based terminal (waiting list)

#85

Earlier quoted context omitted.

Do we care even if it open source? The use of Rust is an implementation detail and shouldn’t really matter.

Alacritty is open-source and written in Rust with great performance. I don't see a reason to use Warp yet.

Alacritty's performance in day-to-day use is actually very underwhelming, I tried to use it but there was just so many little lags left and right I promptly switched back to urxvt

Re: Warp: Fast, Rust-based terminal (waiting list)

#86
post #27

Who cares that it's Rust if it's closed source? Also: "All cloud features are opt-in. Data is encrypted at rest." The fact that this even needs to be stated makes it a hard no, especially for a terminal emulator.

> The fact that this even needs to be stated makes it a hard no, especially for a terminal emulator.

True. And a terminal that requires an e-mail login? I doubt they are going to build a social product, then users can co-op or date in the terminal.

Re: Warp: Fast, Rust-based terminal (waiting list)

#87
Look super cool, i definitely think there is a need for a modern interpretation of the terminal experience. Please think of a good licensing scheme for single dev. who would want to use it and support you guys without being tied to a subscription. Something like sublime text on time fee.

Re: Warp: Fast, Rust-based terminal (waiting list)

#88
post #27

Who cares that it's Rust if it's closed source? Also: "All cloud features are opt-in. Data is encrypted at rest." The fact that this even needs to be stated makes it a hard no, especially for a terminal emulator.

Our plan is to open source the Rust client code once it's more mature. We are particularly excited about sharing our Rust UI framework since there aren't a lot of great options for building native UIs in Rust right now. We want to make it cross-platform first though.

There are a lot of promising options for native UI, but none finished and mature. As of today, that number sounds like it is one more.

Druid as it exists today is not a great fit for what you're trying to do, as drawing on mac is all based on Core Graphics and Core Text. GPU-based drawing is the future, and we're working on that (piet-gpu), but it's not yet in a really usable state.

In any case, hope this goes well. It's clear to me that Rust-based UI is the most viable path to an Electron alternative in the future, and the more evidence we have for that, the better.

Re: Warp: Fast, Rust-based terminal (waiting list)

#89
post #67

Earlier quoted context omitted.

Our plan is to open source the Rust client code once it's more mature. We are particularly excited about sharing our Rust UI framework since there aren't a lot of great options for building native UIs in Rust right now. We want to make it cross-platform first though.

What about the UI framework druid? It has 3.9k stars on Github and is under active development. https://github.com/linebender/druid

It's definitely something we actively considered! You can find some more details about why we chose to implement our own UI framework here: https://blog.warp.dev/how-warp-works/. The tldr; for Druid is they don't support any GPU backend at all right now.

Re: Warp: Fast, Rust-based terminal (waiting list)

#90
> After a very brief experiment with Electron, we quickly pivoted to building in Rust and rendering directly on the GPU using Metal

Huh? What about Linux? Why not use something like gfx-rs instead? It's too bad Apple refuses to support Vulkan, but at least you could use something that could help it actually work on multiple platforms. Using Metal will make it unportable, unless you plan to support multiple GPU APIs.

Also, there is no source in the Github link: https://github.com/warpdotdev/warp

Post reply on HN