Hacker News new | past | comments | ask | show | jobs | submit login
Warp: Fast, Rust-based terminal (waiting list) (warp.dev)
291 points by garrettdimon on July 14, 2021 | hide | past | favorite | 173 comments




FYI, this appears to be a startup launching an e-mail signup for a product that isn't available yet. Nothing wrong with that, of course, but it's worth noting up front. There is no download link and the GitHub link goes to an issues-only repo with no code.

There are several fast Rust-based, GPU-accelerated terminal projects that are open source and under active development:

Alacritty: https://github.com/alacritty/alacritty

Wezterm: https://github.com/wez/wezterm

Fig ( https://fig.io/ ) isn't Rust, but it's worth noting as a YC-backed competitor terminal product that has autocomplete similar to Warp.dev. Their website is eerily similar to warp.dev 's website, to the point where I can't help but imagine one was the inspiration for the other.


> There is another fast Rust-based, GPU-accelerated terminal project that is open source and under active development:

I really thought 'Alacritty' came next! It's cool there are a few. If someone's looking for something popular and robust though, and not specifically interested in the cloud features of OP, Alacritty is pretty mature, actively developed, and also rust if you care.


Thanks! I forgot Alacritty was written in Rust. I added it to my comment.


With terminal emulators having already existed for decades, what benefits do Rust and GPU acceleration bring at this point? What problem are they solving? Not trying to sound confrontational, if I do, I’m just curious.


Cannot say too much about that since I only tried alacritty once, and from what I see it is mainly speed. And yes, that's actually noticable, at least on my machine.


I have not used the above terminal emulators, but I got a fast high refresh monitor (250Hz) with a 1000Hz keyboard recently, and the programs supporting 250 refresh/second does feel snappier. While it does feel snappier, it's not like I can press over 200 keys per second anyway, it's like with good sound, it's "night vs day" once you've paid for premium.


Well damn, i had no idea about Wez. I really miss Ligatures with Alacritty, so i should give Wez a try. Thanks for the link!


Also alacritty


Just tried it:

    2021-07-14T17:05:56.423Z WARN  window::os::windows::window    > EGL init failed with_egl_lib failed: with_egl_lib(libEGL.dll) failed: no compatible EGL configuration was found, atioglxx.dll: LoadLibraryExW failed, fall back to WGL
    2021-07-14T17:05:56.500Z ERROR wezterm_gui::frontend          > Failed to create window: The OpenGL implementation is too old to work with glium

I feel sad when terminals need OpenGL ... OTOH, apparently, my modest needs are adequately served by ConEmu on Windows and xfce4-terminal on Linux.


On the flip side, if you do have OpenGL, why not utilise it for unparalleled terminal performance? I've used Kitty for years for that reason, it's incredibly responsive and smooth, a pleasure to use.


What does a responsive terminal look like compared to something else? What are you doing with your terminal that demands responsiveness?

Genuinely curious. I've never ran into a situation where the standard terminals felt "sluggish"... barring a slow internet connection sshing.


You should look into Casey Muratori's quest[1] against Windows terminal slowness on github and youtube. There were some heated exchanges there and some proof of concept software created to demonstrate both how slow Windows Terminal is, and how fast a GPU enabled terminal can be.

[1] The latest video for it is here: https://www.youtube.com/watch?v=99dKzubvpKE


It's hard to describe, things just feel quicker. Scrolling through files in vim or tailing logs is super smooth, when your grep accidentally hits a huge json file that's lurking in your project it prints instantly instead of making the terminal unresponsive for a few seconds.

I used Urxvt for about fifteen years, it didn't feel slow at all. Kitty just _feels_ faster.


For one thing it's easy to build a bash line or even a NodeJS script that produces a lot of output that is dominated by the terminal's capability to render. When you benchmark it against the same thing but with a `foo > /tmp/foo.txt` redirection into a file, you'll notice that on bad terminals, it's several times or even orders of magnitudes faster than rendering to the screen. Many, many terminal emulators I have tried in the past did look sleek at first sight but then failed miserably a simple `cat manylines.txt` test.


Is kitty the one where it's really difficult to open two of them at once with different sizes and colors because those things can't be specified on the command line?


Well, that is kind of a given for a GPU accelerated terminal emulator, no?


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 benefits I'm missing that come from it being implemented in Rust?


If it's a language your proficient in, as an HN user it can be interesting to see the language in the title.

That said, it's particularly bizarre for a closed source product, where the language is completely irrelevant ¯\_(ツ)_/¯

Also, I like how simple HN is, but sometimes I wish for "tags", at least for project languages - that would keep the title "cleaner", while still including the language for anyone interested. Would be cool to search HN posts by language too.


Rust is an active and growing community, and there are a lot of software engineers here who are interested in how the sausage is made. I can think of two solid reasons I like to know when something is written in Rust:

1) This is a new codebase that we can study and contribute to. Knowing it is in Rust is relevant, so us Rust people know if we are able to dig into it.

2) Rust makes some guarantees about the properties of programs written in it. These guarantees are of interest to some, to the point where many have adopted Rust versions of common utilities (ls/exa, grep/ripgrep, etc.).

edit: just saw it is closed source. Bit of a bummer, and nullifies my points to a certain extent. But I will leave them up since I think they apply to other projects that are more open.


I have dug into the bash source on two separate occasions. Once in response to the absolutely crushing CVE-2014-6271[1] and once to add what should have been a trivial logging feature.

What this experience (and others like it) have taught me is that far more people should care, and that we as an industry should be investing dramatically more effort into completely rewriting low-level C projects that were designed and developed thirty or more years ago. Little of the code I saw would pass modern code review for a variety of reasons.

Software engineering tools and practices have improved dramatically in those thirty years, but our foundations are built on frankly completely shoddy infrastructure that’s barely held together with duct tape and fishing line. Our industry profits almost exclusively off of building more and more on top of what’s already been built, but I’m convinced it’s becoming increasingly important to spend more of our collective effort on fixing, replacing, and repairing the stuff that lies below.

None of this is meant to malign the efforts of the developers of `bash` or any of the other venerable yet aging tools at the bottom of our stacks. There’s no blame to be had for building a tool with the knowledge and best practices of the time and for being hesitant to “fix what ain’t broke” in the thirty years since. But frankly, these things are a lot more broke and waiting to fail than most of us realize.

Further, none of this is to say that things are on the dire verge of collapse or that any one program is going to be the thing that dooms us all. Simply that our foundations are suspect and are increasing need of repair, particularly as we build ever-higher on them. Community efforts like those to improve OpenSSL in the wake of severe exploits have been invaluable and we need so much more of it. Preferably before exploits are discovered.

So I for one applaud efforts to rewrite and rethink these programs, and especially to develop them in modern languages with stronger protections, infinitely fewer footguns, and better testing infrastructure.

[1]: https://nvd.nist.gov/vuln/detail/CVE-2014-6271


We mention Rust primarily because it produces a really high-performance app and to make clear that it's not built using Electron or web tech.

We wrote up a pretty detailed technical design if you're interested in checking out how we built and why we made the decisions we made:

https://blog.warp.dev/how-warp-works/


But who would expect Electron or web tech for a terminal?

Having written terminal code both in compiled and interpreted languages, and on machines about a thousand times slower than a typical modern machine, speed here is also much more down to algorithm choices - especially for rendering - than language.

I find the focus on FPS pretty odd as well, as really high update speeds for a terminal typically only comes into play if dumping huge amount of data to the terminal by accident, in which case typically handling scrolling properly is easily speeded up by skipping lines that need never be visible at all.

I do expect terminals I use to be low latency for normal operations, but that's a very different consideration.

Not objecting to your choice of Rust. Just like some others found it odd to highlight it near the top of your main page.


I guess you missed the HN posts about another buzzy terminal app that is in fact written with Electron and boasts about extensible web tech as a feature: https://hyper.is/


I might have suppressed it, as the very idea is the stuff of nightmares.

That said, I'll note that unlike Warp it will actually run on Linux...


They exist. Hyper is the most notable one using Electron.


DomTerm and xterm.js are terminals for web.


I was just looking at that! It seems that I'm also conflating "terminal" and "shell" here possibly. Is Warp both in this case?


Warp is a terminal, we still rely on the underlying shell to do the interpretation / execution of the commands. At the moment, we support using bash, zsh, or fish as the shell.


...huh.

Writing a tty which has to support specific shells isn't confidence inducing.

How did you paint yourself into that specific corner exactly?


I'm guessing the auto-complete handling means they need to understand the line editing of the shell. If they've done it well, it'd hopefully be possible to quickly handle others and/or make it configurable.


Ah, that.. almost makes sense? fish at least has its own autocomplete.

I'd be more careful about the messaging then, something like "you can use any shell you want, we provide enhanced features for bash/zsh/fish and are looking to expand that in future".


This. Also the mention of ‘collaboration’ and ‘cloud’ put me off. “Do one thing and do it well”.


>...I have no idea what bash is written...

This is a terminal emulator not a shell language so this should be compared to the likes of Xfce4-terminal, Konsole, Alacritty, Kitty, st, etc...


Yeah I realize I conflated "terminal" and "shell".


Well just a total guess but since it has a tiny bit more OO than C (traits) it could be argued it has a slightly better (aka more clearly obvious) ability to have plugins which is definitely possible in C, but it means you can pass a thing around that can do certain things for you, whereas in C there's a lot of crufty stuff to do that.


> whereas in C there's a lot of crufty stuff to do that.

Which is true.. but owing mostly to the fact that C actually has a stable ABI.


I see comments about open source, safety guarantees, speed, etc, but let's be honest. The real reason why Rust was mentioned in the title is because Rust is popular now and mentioning it attracts attention.

It's the same deal with every popular language that was the new hotness at the time: "written in Python", "written in Ruby", "written in Go" from years ago, which I see less of now.

Nothing wrong with this, it's just a straightforward way of tailoring information to the target audience to maximize engagement with an ad, whether the authors did it consciously or unconsciously (maybe they like Rust a lot and mention it often).


there's been a lot of the "[blank] (but in rust)!" posts here lately, much like not too long ago node.js was the new best thing.


Do you remember what was the cool thing before that? LISP? I'm interested in the history of hype in HN


golang, maybe?


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.


Rust seems to be all the rages these days (Specially here in HN). Besides that, most of the post on Rust also have the word fast in it (Or a similar word related to the speed of the software).


The screenshots look cool, and I joined the waitlist, but gotta say, a prominent GitHub icon in the nav bar only to land me on an issue-only “repo” for what is actually a closed source project is highly misleading.


That's a fair point - it wasn't meant to mislead since we are using Github for feature requests and issue tracking, but I think you're right. We'll remove the link.


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 it needs to be stated means that it has cloud features.

Opt-in and "encrypted at rest" AKA actually encrypted are the correct defaults.

I'm also uninterested unless both the client and the server are made open-source, because terminals are a bread-and-butter program and there's just no way I'm getting locked into someone else's cloud for that.

But the specific sentence you've quoted is a strange thing from which to recoil, from where I'm sitting.


The point I got from that that it's unacceptable that it's keeping data on their servers. The issue wasn't that it's encrypted at rest - the issue was that they got data they need to encrypt to begin with.


The data pertains only to opt-in cloud features. Warp is local-first. Note that the closed beta collects some info, so if you're not comfortable with that, please wait until our open launch.

All details here: https://www.warp.dev/privacy


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.


Thank you, Raph! We've been following your work on Druid quite closely for a while, it's very impressive.

You'd exactly right that's why we didn't pick Druid--we needed something that rendered on the GPU. We actually talk more about this decision in our "How Warp Works" blog post here: https://blog.warp.dev/how-warp-works/


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.


You really don't have to accept contributions if the repo is open. You could simply disable issues and close all PRs with a comment explaining that you're not ready for contributions yet. You could even automate that with a Github Action or similar.

Developing in the open would make it easier to trust that you're not doing something nefarious. When I think about the kind of data that goes through my terminal on a day-to-day basis, I have to _know_ for sure that my terminal can be trusted. That makes Warp a non-starter for me until it's open source, which is really a shame because it looks fantastic.


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.


Super excited about both of these things. Will your text editing widget be part of that? Because I'd absolutely love it if a widget with capabilities similar to that of full on text editor (sublime/vs code, etc) became the standard "textarea widget".


> Our plan is to open source the Rust client code once it's more mature.

Your plan should have been to wait until something was downloadable before you announced it.


https://xkcd.com/463/ Strictly speaking, your plan is better than the alternative of keeping it closed-source, yet someone is clearly doing their job horribly wrong.

Anything useful you produce will be community-maintained eventually, and your cloud product will vanish once you complete your amazing journey; anything in-between seems like rent-seeking. Meanwhile, your competitors are Free Software and can out-develop you.


> 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.


They're definitely planning to build a social product:

https://assets-global.website-files.com/60352b1db5736ada4741...


If this was a better, generic, screen sharing solution, it might be awesome. But forcing people to use a specific terminal to work with others feels like it'll be a non-starter for most people. Not least given how rarely I've ever had a need to show anyone my terminal (despite having had solutions for it for literally decades via e.g. sharing screen or screen sharing all the way back to VNC and similar).


Our strategy here is to share sessions to the web, so collaborators don't need to download the app. It's fascinating how far utilities like screen will get you in functionality, but I agree it's really hard to get people on there.


My point in mentioning screen was rather that despite having had solutions that work for decades, that everyone I collaborate with knows how to use, I can literally count the number of times I've felt a need to share just a terminal window with someone, rather than e.g. a full screen, on two hands over the course of 25 years.

It's rare enough for me to have a need for sharing a screen, but sharing a single type of window would cover just a tiny proportion of those rare cases.

My tech stack is atypical enough in many respects that maybe others will find it more useful, but to me this seems like a couple of useful but easily copied features (the auto-complete), and some stuff I'd never use.


> terminal that requires an e-mail login

Email is required only for the closed beta. Warp will be offline-first. All details here: https://www.warp.dev/privacy.


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 me to it.


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


Same for me in Linux and Windows. If your terminal regularly crashes because of memory corruption, there’s something wrong with your setup.


Maybe it's the way I use it, but iTerm2 crashes (or hangs) fairly regularly for me on macOS. I usually need to restart it at least once a week, which means losing ~dozens of tabs with context in them.

I use urxvt on Linux, and I don't have any problems with it.

Edit: I should also mention that I see plenty of non-crashing, non-hanging bugs with iTerm2 that look like memory misuse to me: split-workspace mode (tiled with a text editor) causes wonky graphical errors, and I've seen what looked like buffer reuse artifacts when switching between monitors.


I have run across one - of maybe a dozen terminals I've tested because I'm difficult and have very specific requirements of a terminal - that crashes on weird input. I can't even remember which one it was, because I moved on, but odds are it was while testing unusual features like Sixel or ReGIS support.


I crashed iTerm2... once. In 6 years that I used it. Oh and the VS code embedded terminal has stopped rendering on me once.

I cannot recall any crashes in alacritty, gnome-terminal, xfce-terminal or the legacy windows console for other terminals I've used a decent amount.


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


I had the same experience with gnome-terminal back on Ubuntu 14.04 (or maybe even 12.04, it's been a while).


rxvt-unicode regularly segfaults... during "quit".


I can't remember my terminal emulator ever crashing, much less crashing due to memory corruption. Maybe I've just been lucky.


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


urxvt was my workhorse for years; And I tried Alacritty + a tmux configure that emulated urxvt's tabs. It wasn't quite all the way there, wezterm is another one that seems to work well and has slightly improved rendering over urxvt, and I'm pretty happy with it right now, though it has a lot more bells & whistles.


Alacritty is a different approach: they're building a traditional terminal. Warp is hoping to push the boundaries and build something different.

Warp is a fork of Alacritty, their team was very gracious in collaborating and reviewing Warp's initial designs.


> Who cares that it's Rust if it's closed source?

People who care about security.


Don't they also usually care if they can audit it?


>People who care about security.

Those people tend to care more for their term being opensource than it being in Rust. Dont trust those who claim otherwise.


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

Can you explain your objection in more detail? It seems like a terminal offering some kind of real-time collaboration with team members is a reasonable thing to offer, and that if you have that feature then it's good that it's opt-in with encrypted data.


Agreed about the Rust comment but I also was looking to make sure it wasn't webkit-based.


If you “hard no” so easily, then what else may you be missing out on?


Things that eat your data, your time, your money, your attention.

Fads.

Unicorns (but they probably don't exist).


I wouldn’t be so sure…

> the report says that they have "recently reconfirmed" the lair of one of the unicorns ridden by the ancient Korean King Tongmyong, founder of a kingdom which ruled parts of China and the Korean peninsula from the the 3rd century BC to 7th century AD. https://www.theguardian.com/world/2012/nov/30/unicorn-lair-d...

^a joke


I had no idea that terminals and Rust projects were such highly charged emotional territory, nor that either were danger zones which commonly ate your time, your money, or your attention.

Kind of seemed to me like just another project.

I guess the kids these days have to start at volume 10 with "hard no!" or "best ever!" to be heard. THAT is a fad.


THIS. Chasing after shiny things ignores means wasting the opportunity to become truly expert about something.

EDIT: silent downvotes for saying this?


I didn't downvote you, but it's certainly fine to pass on something you think is a fad. It's another thing to jump directly to the end of the emotion spectrum by saying "hard no". My comment wasn't about skipping shiny things, it was about being so vocally firm about the negative. That doesn't leave much room for reconsideration later.

What if the project turns out to not be a fad, and a month or six later more people are using it and loving it? How does a "hard no" person back down from their bold rejection? This is what I was talking about.


[meta] I think many people here are interested in learning Rust and they use upvote button to "bookmark" (should use favorite instead, until you have actually read the article) (sugg: add favorite link to the main page)


What data leads you to this conclusion?


Co-founder of Fig (https://fig.io) here.

I'm pleased that there is more innovation in the terminal emulator space. For a tool used by just about every developer, not a ton has changed since the launch of the VT100 [1] in the 70s.

Fig adds autocomplete [2] to your existing terminal. Soon, we're launching the ability for you to build your own visual apps and shortcuts (like these: https://fig.io/videos/old-sizzle-reel.mp4) and share them with your team or the community.

Rather than building our own terminal, we integrate with the terminals you already use (even the one embedded in your IDE). This means everyone on a team can collaborate but keep using their existing terminal and shell setup.

We are excited to integrate Fig with Warp.

[1] https://en.wikipedia.org/wiki/VT100

[2] https://github.com/withfig/autocomplete


Actually, a lot changed since the launch of the VT100, but most of those features just haven't survived into modern terminals and/or people don't use them.

E.g. Sixel, ReGIS, html output, terminals treating the scrollback buffer as a live document where commands can be re-executed. AmigaOS let you auto-complete filenames using a file requester.

The hard part is becoming so seamless that it integrates into peoples workflow to the point of being something they're not willing to live without, and none of the above really succeeded at that.

The terminals I use have Sixel and ReGIS enabled, and I have a shortcut to output images to the terminal, but I still often forget and open a separate image viewer anyway, for example (but it is awesome to be able to display an image from a remote server directly over the ssh connection, but that depends on a utility script on said server).

Instead we revert to the lowest common denominator because it's good enough and other things, like latency and being ubiquitous across platforms matters more.


Thanks Brendan!

We've been following fig and are excited to see more innovation in this area!


"Warp" is also the name of a popular Rust web framework. (https://github.com/seanmonstar/warp)


Which looks better to be honest


Not to be confused with the other big warp rust project, https://github.com/seanmonstar/warp/


Or CloudFlare's Warp, also using Rust.


Hi HN,

I’m Zach, from Warp. Excited to get feedback on what we’ve been working on. Happy to answer any questions!


Looks quite nice. A few questions:

* How do you expect to make money from developers using Warp?

* What's the source code license?

* Where's the source code?


Not sure if I missed it on the website, but...is this to be a paid product?


The terminal itself is totally free

We may add paid features for enterprises around collaboration, and other things on the server that would cost us money to support.


Does is rely on OpenGL drivers to compile? (whenever its available as OSS). An option to compile it by disabling any hardware acceleration (kitty does require openGL I think) and disabling fancy animations/effects would be great for getting this installed at my workplace. I currently use an not-so-recent version of konsole and its a pain to customize. Kitty, which I on my personal machine is pretty good for customizations and is desktop agnostic too.


I'd be curious: Did you use any of the existing Rust UI frameworks? (Druid, Iced, Femtovg, etc) or is it all custom build on something like wgpu? If it is all custom, congratulations the rich text layout looks really, really good (something of a sore spot in the current set of pure rust UI frameworks).

Great product! I signed up for the beta, excited to try it out.


Thank you! The UI framework is entirely built in house with the help of Nathan Sobo (co-founder of the Atom text editor). We definitely considered a few of the options on https://www.areweguiyet.com/ but ultimately found none of them supported the requirements we wanted.

You can find more details about why we decided to build our own UI framework in the "How Warp Works" blog post we wrote here: https://blog.warp.dev/how-warp-works/


Zach, looks like a cool product! How would you say this differentiates itself from Teleport Ssh? I can see at a glance there this is written in Rust (vs Golang) and seems to be based on being a full terminal (vs being an application run on the terminal).


Why closed source?


It will be probably easier to monetize.


*crickets*


When are you going to be on other platforms?


We are building a web version now using WASM and WebGL.

Next up will be Linux, followed by Windows.


macOS's built-in Terminal app is notorious for not handling meta + non-letter keystrokes properly, which is a real pain for emacs users who need a meta-shift-uparrow, for example. Does Warp handle these key mappings, and can they be customized (i.e. option = nomal, option, or esc+) like in iTerm2?


how does auto-completion work? will it force me to use shells like fish that has auto-completion built in, or I can use bash?


Any chance of supporting nushell?


The UI seems interesting, and I'm a sucker for RIIR, but why do terminal emulators keep trying to use "blazingly fast" as a feature? They're all fast (except the hideous electron ones), they're white text on black rectangles.


I don't get it either - I use Windows (the default cmd, Powershell and Cmder), Linux and MacOS and don't recall a terminal emulator being slow... ever.

Yet when the subject of terminal emulators comes up, there are often comments from other HN users insisting that Windows terminal emulators are molasses compared to MacOS, or that this emulator is much faster than that. I don't get it.


> I don't get it either - I use Windows (the default cmd, Powershell and Cmder), Linux and MacOS and don't recall a terminal emulator being slow... ever.

You might be a particular type of person... I don't remember Windows Cmd being not slow, ever. It feels extremely sluggish. It supposedly has something to do with Windows ConHost, but I don't know about the details.

In fact, even most terminals on Linux are unbearable to me. Not only do the antialised vector fonts tire the eyes on sub-4K screens - most of the terminals I've tried feel slow as well, though not as slow as Windows Cmd.

http://danluu.com/term-latency/

https://github.com/cmuratori/refterm

Personally I use xterm with bitmap fonts whenever I can, it feels sooo good. It has both crisp font rendering as well as being reasonably fast/responsive. (It's probably not the fastest ever in throughput if you want to display /dev/urandom, but that's not my benchmark).


The funny thing is fast terminal rendering was a solved issue as far back as the mid 80's even on machines like the Amiga.

Yet people seem intent on inventing slow ways of doing it that then gets people to reinvent all kinds of complex ways of making it faster.

The performance differences between different terminals are indeed absolutely astounding (but rarely matters much, because the things that are much faster/slower are things you rarely do on purpose, like dumping thousands of lines to the terminal at once)


It's all about latency and ergonomics for me.

I suppose that terminals like Gnome's [0] are slow or feel "jittery" (i.e. inconsistent latency) for example because everything needs to go through a separate terminal server process. Then, there is Desktop compositing in the way. There might even be latency added by GPU acceleration (handling double buffering badly vs naively sending pixel updates to the Display Server?). Then, vector fonts are just terrible for programming on normal [1] displays - either anti-aliased (mushy, eye-straining) or not (jagged-y).

Another issue is historically bad / incompatible VT-100 emulation. I don't know what it is and I'm not a fetishist for organically grown terminal cruft, but in any case I've always had the most trouble with Gnome and KDE (missing characters, wrong colors, wrong drawing positions) while xterm works just fine, only the occasional "tput reset" needed after dumping binary data.

[0] just talking experiences, I'm probably referring to something based on VTE? Don't use Gnome regularly.

[1] "normal" meaning sub-4k / ~100dpi, soon will have to be referred to as "older"


https://www.youtube.com/watch?v=hxM8QmyZXtg

This, I think, sufficiently explains the slowness of terminals on Windows.


It's an hour long, but I watched a few snippets - is the "problem" only if you try to print megabytes of text on the terminal?

I started with computers more than 30 years ago, and have been a "power user" and coder for essentially all of that. In all that time and experience, I've never found any terminal to be slow, or found one to be noticeably "faster" than another.


> It's an hour long, but I watched a few snippets - is the "problem" only if you try to print megabytes of text on the terminal?

That's pretty much where most of the terminal performance difference is on most platforms. Latency can be an issue on some, but really this was a mostly solved problem as far back as the Amiga.

I have a toy terminal written in Ruby + a tiny C extension to interface to raw xlib that currently draws individual characters and redraws the entire screen on scrolling, and even that is fast enough for most normal usage (but indeed slow at printing megabytes of text)

But getting a terminal fast enough, including on the "print megabytes of text" test boils down to a few simple principles (and you'll be "fast enough" without doing all of them even on pretty slow hardware):

* Render your text to a buffer, and only render to screen at intervals.

* Use non-blocking IO and read as much as you can into suitably sized buffers (aka: reduce pointless context switches)

* Scroll the bitmaps using whatever OS/toolkit provided functionality, rather than re-rendering the text like my stupid Ruby term.

* If you have multiple lines in your buffer, scroll once and render all of the new lines at once.

* If vector fonts, prefer to pre-render glyphs to a buffer rather than re-rendering every time.

That's about what I remember from rewriting parts of the AROS (AmigaOS replacement) terminal handling code a decade ago (does not do all of the above, but is still more than fast enough).


Not true!

If a terminal doesn't paint on a per-frame basis, then dumping reams of text to that terminal will slow the program to the speed of printing, this can easily be a 100x slowdown versus only updating the view when the monitor wants more pixels.

Most of them don't do this, so the ones that do are within their rights to advertise it as a feature.


Fast enough, sure, but nobody’s pushing the envelope. Casey Muratori recently did a proof of concept on this problem: https://mobile.twitter.com/cmuratori/status/1411437902802808...


Interesting. I'm looking forward to watching the video, thanks for the link.


"Blazingly fast" is just a buzz word. I guess at some point someone should put a requirement on that buzz word that means it has at least some response rate of X ms after key press (or mouse move).


A terminal requiring a privacy policy? I'll stick to simpler tools even if that means missing an occasional quality of life feature.


May be consider a name change? There is a rust based web framework called warp.

I know, totally unrelated except for the rust part but the annoying thing is that a search for warp always shows startrek stuff and searching with rust brings up quite rusted metal solutions stuff so I use warp+rust :)


Or Warp, the best-known Haskell web server: https://hackage.haskell.org/package/warp


Worst part is all inspired by a technology that is theoretically impossible and all picked by developers. It could be anything else that denotes speed in any human language but its warp always :D

(Off to work on my next project that will speed up note taking - probably going to name it after a technology in my favourite tv series)


Funny how similar this is to https://fig.io/ . Even the landing pages are hard to tell apart!


I've been piloting Warp for a few weeks, and I have to say it's awesome. I can totally see the future of where this is going and I think that there is a lot left to be done to improve the terminal experience. Breaking the barrier of having the terminal be accessible only to thee most sophisticated folks will be huge. Excited to follow along with this project as it continues to evolve and mature.


I think collaboration, saving sessions and rehydrating it with a link are killer features. Uh.. so much value there.

A lot of work happens in the terminal but it is not in repo or documented, and each team member kinda develops their own thing. I see Warp standardizing and making the non-code writing part of development


Somewhat off-topic: After seeing the layout of the page, I instinctively looked for a "Pricing" link.


This is cool! I especially like the help functionality for various flags.

How does this handle really long outputs like with [tail -f], or pagers like [less]?

Also, does opening up vim “just work”?


Some of the features make it sound dubious. "Real-time collaboration". Why would you bake that in your terminal?


Why wouldn't real-time collaboration be useful?


What are you doing in a terminal that you need real-time collaboration? Here's what I do in my terminal:

* log in to AWS * push commits (though that's mostly in Emacs now) * tail logs from remote services * use ssh * random grepping/cat/awk/sed one-off stuff

I don't see any of those benefiting from real-time collaboration. The use-cases presented on the landing page don't make sense to me either - when my entire team is debugging production, we usually fan out and all look at different things rather than needing to fan-in and all do/look at the same thing. And if I want to chat I'll have Slack open next to the terminal.


How’d you learn how to do all those things?

This is where the real-time collaboration comes in. Easy to teach novices how to use powerful shell commands to make things easy.


What? You'll suddenly need 5 people to chat about that multiline command you're about to type?


What if you open an editor inside this terminal and collaborate in there?


it's very useful: prank your colleagues with the occasional fork bomb, steal their ssh keys and delete their files.


Just share the screen/tmux session on a server. We already had realtime collaboration.


I agree. I'm staring at the use-cases for sharing and don't understand what this does any better than tmux/tmate

If I want to save a session, I use tmux. If I want to share that session, I use tmate.

I can also self-host tmate on my own machines which makes it even more attractive.

I think some of the session stuff is nice, but it's not for me.


If only the website was as blazingly fast as the terminal claims to be!

It scrolls at 2 fps.


Cool idea, but finding product/market fit might be hard. I've never experienced a situation where collaboration in the terminal would be useful, and if I want to share sequences of commands with other users, a recorded zoom video with commentary is usually more useful.

However, if you work closely with larger companies, I'm sure there's some killer feature that will hook the engineering managers, even if developers are split on using it.


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.


> 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


Congrats on the launch! I think the team features will be really useful. We currently use browser based repl at work and I could see something like this replacing that.


What's the business model?

How will that impact the quality of the product in comparison to, say, iTerm2?

I see the team [1] has some strong credentials, which honestly looks overpowered for "just" a terminal app. Unfortunately, that makes me suspicious of their goals for "just" a terminal app, which has a relatively well-established expected feature-set.

[1] https://www.warp.dev/about-us


The text editing features (multiline, multiple cursors) are something I've really wanted from a terminal for a long time. Editing long/complicated commands in most terminals is not a great experience, so the point that I normally copy and paste from my text editor. A little wary of this if it's not open source, but looking forward to being to try it out.


man bash, and search for, 'edit-and-execute-command', to launch a configurable editor for long commands.

zsh has a similar facility.


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


Warp looks great, but what do I do next? Where's the call to action?

There is no download link, no "sign-up to hear more". With all of the thought and polish that went into this I'm surprised to see the ball dropped at the most important step!


There's a "Request access" button above the fold.


Not the original commenter, but thanks.

In my case the "Request access" button was blocked by uBlock Origin.


Good to know! You can find a direct link to sign up for the waitlist here: https://zachlloyd.typeform.com/to/yrwMkgtj?typeform-embed=oe...


Every terminal I've used for the past 30 years has been blazingly fast beyond diminishing returns. You could stick random usleep() calls in there for small values, and I wouldn't notice.


I expected this to be related to https://github.com/seanmonstar/warp

the typo did not help


You guys did a really great job with the user experience! I'd love to see an interactive Repl/Notebook with the UI/UX you've figured out for the terminal.


Block IO is a feature I never knew I wanted until now. Are there any other terminal emulators with similar functionality?


I don't get all these terminals/prompts in rust at the moment, is it the 'Todo list' of rust?


How many are there? Two? I only know of alacrity as the other written-in-Rust terminal app.


Anyone else avoid closed source tools?

This would be interesting if the source was actually available.


I prefer open source tooling as well. Check out Tabby, it's been my daily driver. It's kind of annoying it doesnt by default open up to a terminal, but this is now configurable.


I've been using Tabby (used to be called Terminus) which I have been enjoying


the branding decision when there's other related Warp things around this space is unsettling. Forever doomed to constantly have to follow the word Warp with 'terminal'


Is Warp to terminal what Superhuman is to Gmail?


The logo is quite similar to the Scroll logo.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: