They’ve raised $23m?!? Uhhh
I think you could build a really good terminal if you had $23M to piss away.
I strongly doubt you can create a good terminal if it also needs a business model that can recoup $23M.
Show HN: Warp, a Rust-based terminal
101–110 of 757 posts
Re: Show HN: Warp, a Rust-based terminal
#102> Warp is a fully native, GPU-accelerated, Rust-based terminal. No Electron or web-tech.
I understand that this probably appeals to most readers there, but I don't like the negativity. I like Rust and Web tech, sometimes together, and I don't want my tools to shit on what I like.
We can also discuss the full nativeness. To me, the menus don't even try to look native. Is it native because it doesn't use a virtual machine or an interpreter? Almost all computers use a microcode, I think this argument is a bit obsolete. Performances matters, not how many layers or virtual machines you have.
I prefer some marketing about this terminal being fast, backed by proper benchmarks in which you can compare it against electron web-based terminals, and faster ones such as alacritty.
Re: Show HN: Warp, a Rust-based terminal
#103They’ve raised $23m?!? Uhhh
Yeah it might seem like a crazy amount. Building a terminal is hard. We have to build feature parity, maintain a stable terminal-shell interface, on top of modernizing the product experience. The money allows us to hire engineers to work on this project full-time and create a great product experience.
I don’t doubt any of that. The amount seems crazy not because of the potential costs, or ability to invest in the product, but rather due to TAM.
But nobody would lead a round of that size without a decent monetization strategy. I suspect enterprise focus around security / IAM integrations (hence all the telemetry).
Re: Show HN: Warp, a Rust-based terminal
#104Hello Zach, founder and CEO of Warp.
What makes you think its acceptable for you to spam HN with Warp every few months ?
Re: Show HN: Warp, a Rust-based terminal
#105> Telemetry > When Warp comes out of beta, telemetry will be opt-in and anonymous. > But for our beta phase, we do send telemetry by default and we do associate it with the logged in user because it makes it much easier to reach out and get feedback when something goes wrong. This is a hard pass for me, it looks really amazing though. I'm so tired of telemetry, how do we quit our day jobs to focus on open source? ;-;
I expect someone will fork shortly and remove all the telemetry
Re: Show HN: Warp, a Rust-based terminal
#106Anyone know how this lines up to other terminals performance wise. I’ve been pretty happy with alacritty, but would be willing to try a terminal with more features. https://github.com/alacritty/alacritty
Good question! We did an initial benchmark of scrolling back in July against Terminal, iTerm, Hyper, Kitty, and Alacritty, if you’re interested: https://www.warp.dev/blog/how-warp-works . We started by forking Alacritty's model and parser and because we have a similar architecture (Rust-based, rendered on the GPU) we should generally be at, or near, the performance of Alacritty.
I just ran a quick test using Casey Muratori's termbench (https://github.com/cmuratori/termbench) you are an order of magnitude slower than Alacritty, and also significantly slower than iTerm. Warp also locks up pretty severely and only shows a new frame once every few seconds during most of the run.
Alacritty
CPU: Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
VT support: no
ManyLine: 1.5670s (0.0399gb/s)
LongLine: 1.1261s (0.0555gb/s)
FGPerChar: 0.3293s (0.0551gb/s)
FGBGPerChar: 0.6598s (0.0534gb/s)
TermMarkV2 Small: 3.6822s (0.0484gb/s)
iTerm
CPU: Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
VT support: no
ManyLine: 13.2968s (0.0047gb/s)
LongLine: 3.6535s (0.0171gb/s)
FGPerChar: 1.8944s (0.0096gb/s)
FGBGPerChar: 2.8304s (0.0125gb/s)
TermMarkV2 Small: 21.6750s (0.0082gb/s)
Warp
CPU: Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
VT support: no
ManyLine: 9.6199s (0.0065gb/s)
LongLine: 8.3727s (0.0075gb/s)
FGPerChar: 8.1124s (0.0022gb/s)
FGBGPerChar: 6.0873s (0.0058gb/s)
TermMarkV2 Small: 32.1924s (0.0055gb/s)
Re: Show HN: Warp, a Rust-based terminal
#107Smooth scrolling with the Mac trackpad (especially at 120hz+) is something I've wanted for a long time, feels really good. Too bad about all the usage tracking...
Re: Show HN: Warp, a Rust-based terminal
#108It's unfortunate that the name conflicts with an HTTP library in rust already: https://crates.io/crates/warp Otherwise, it looks neat.
Yep, this is what I first thought of when the title said Rust.
Re: Show HN: Warp, a Rust-based terminal
#109Earlier quoted context omitted.
I definitely understand the concerns. For our public beta, we do send telemetry and associate it with the logged in user because it makes it much easier to reach out and get feedback when something goes wrong. But we only track metadata, never console output. For an exhaustive list of events that we track, see here: https://docs.warp.dev/getting-started/privacy#exhaustive-tel... . Once we hit general availability, ou…
> we only track metadata, never console output It would be meaningful to indicate whether you track console input as well.
From their link, it seems they don’t. Agree that positive confirmation would be good, for beta.
> We do not store any data from the command input or output itself as part of our telemetry.
Re: Show HN: Warp, a Rust-based terminal
#110I think that Blocks are the most interesting feature here as it seems to fix the biggest issues with terminals that make them feel broken and out of date. I am concerned that they will only work for simple workflows and not work with ssh, or docker attached shells, unless extreme effort is put into this area.
We do support SSH, but Docker support is still something we'd like to support, you can read more about how we are able to render blocks here: https://www.warp.dev/blog/how-warp-works.
Ultimately, our ideal state would have to have an API for this so that developers can implement this themselves to support blocks in arbitrary REPLs (mySQL, Python, etc).