I’m Zach, founder and CEO of Warp, and am excited to show you Warp, a fast Rust-based terminal that’s easy to use and built for teams. As of today, Warp is in public beta and any Mac user can download it. It works with bash, zsh, and fish.
The terminal’s teletype-like interface has made it hard for the CLI to thrive. After 20 years of programming, I still find it hard to copy a command’s output; I always forget how to use `tar`; and I always have to relearn how to move my cursor. To fix fundamental accessibility issues, I believe we need to start innovating on the terminal, and keep pushing further into the world of shells, ultimately ending up with a better integrated experience.
At Warp we are building a Rust-based terminal that keeps what’s best about the CLI while modernizing the experience. We’ve built
1) An input area that works just like a code editor: selections, cursor positioning and completion menus 2) Grouped commands and outputs: so you can easily copy, search, and share terminal outputs 3) AI-powered Command Generation and Community-sourced Workflows [0]: so you can find useful commands without leaving the terminal 4) The ability to share your outputs with teammates: no more pasting long unformatted code into Slack 5) Project Workflows: save your team’s common commands into your project so your teammates can run them from Warp See a demo here: [1]
We built Warp in Rust with GPU-accelerated graphics, and along the way we built our own UI framework, a text editor that’s a CRDT, and an out-of-the-box theming system. You can learn more here [2]. Huge thanks to our early collaborators: Atom co-founder Nathan Sobo, Nushell co-founder Andres Robalino, and Fish shell lead developer Peter Ammon.
We are planning to first open-source our Rust UI framework, and then parts and potentially all of our client. As of now, the community has already been contributing new themes [3]. And we’ve just opened a repository for the community to contribute common useful commands. [4]
Our business model is to make the terminal so useful for individuals that their companies will want to pay for the team features. We will never sell your data.
We are calling today’s release a “beta” because we know there are still some issues to smooth out. You will notice that a log-in is required and that we do collect usage data and crash reports. We do so to enable team features and also to keep improving the product. Post-beta, we will allow users to opt out of usage data. You can see our privacy policy here [5].
While it is a “beta”, we are confident that even today the experience is meaningfully better than in other terminals. If you use a Mac, please give it a shot at warp.dev and let us know how it goes. Otherwise, sign up here [6] to be notified when Warp is ready for your platform.
Join our community on Discord [7] and follow us on Twitter [8]
Let me know what you think! Ask me anything!
[0] https://docs.warp.dev/features/workflows [1] https://youtu.be/X0LzWAVlOC0 [2] https://blog.warp.dev/how-warp-works/ [3] https://github.com/warpdotdev/themes [4] https://github.com/warpdotdev/workflows [5] https://warp.dev/privacy [6] https://github.com/warpdotdev/warp/issues/120 and https://github.com/warpdotdev/Warp/issues/204 [7] warp.dev/discord [8] twitter.com/warpdotdev
- Outgoing request to googleapis.com
- Outgoing request to segment.io
- Outgoing request to sentry.io
- Requires sign up (only via Github, mind you)
I understand the first request is probably to get some dynamic configuration, even though I'd rather my terminal ship with static configuration. But then you have segment and sentry: not interested in sending telemetry from my terminal. Finally having user accounts for a terminal is such as strange concept.
I really wanted to like it, too. The screenshots look great
I expect my terminal to be a much more secure environment than my web browser. When an application starts communicating with the internet, I have no choice but to treat it with the same level of scrutiny as my browser.
Even making telemetry opt-in means that it has the capability to send information to the internet that I don’t know about, which means that I have to treat it like an application that can do that.
Honestly, this freaks me out. It’s an angle I’ve never considered before. Now I need to make sure my current terminal emulator (kitty) isn’t sending information to the internet without my permission.
> Announcing Warp’s Series A: $17M to build a better terminal
And just thinking about this... it's not clear to me what their moat will be as I suspect if there's a really compelling feature it will be available in OSS terminals quite quickly. Perhaps it's the product polish? But I'm not sure polish is what I want from a terminal, at least... it's not the top thing I want .
It's more essential to be honest about this during the beta period than after, so "oh it will be opt in" is a cold comfort, alongside the approximately never-true "we'll open source it some day."
Not touching this with a ten foot pole. Not for something as essential to my day to day work as a terminal.
The general stance on telemetry that we have is that a) we are just starting and it's really helpful to see which of our product ideas are useful to our users (e.g. does anyone use AI Command Search? Should we continue to invest in it) b) we tried to be very explicit about what we are and are not sending - it is only metadata and never command input or output (you can see the full list of events we track here: https://docs.warp.dev/getting-started/privacy#exhaustive-tel... c) if you aren't comfortable with telemetry, then please don't use the product just yet - we will make telemetry opt-in when we have a large enough sample size that we can be confident extrapolating what's going on
For googleapis - this is for login. We use firebase as our auth provider.
For segment - this is for temeletry, as you point out.
For sentry - this is for crash reporting.
As for why we have accounts, it's because we are starting to add features for teams and it's important in that context that there is some type of identity associated with the user.
But like I said at the start - the feedback is totally reasonable and we are trying to figure out how to balance concerns here while still being in a good place to iterate on and improve the product.
Well, at least they didn't lie.
As of my personal position: I want less products in my computing environments, not more. I hope more people would ponder on possible ramifications of going in the opposite direction.
Looks cool but I will never even give this a try.
Yup, well, that's what happens when you take money from VCs or other third party investors, you need to monetise / demonstrate ROI / need numbers for your investor slide-decks.
I'll stick to my old-fashioned spyware free terminal thanks very much. Why overcomplicate things that don't need to be complicated.
https://docs.warp.dev/getting-started/getting-started-with-w...
I feel bad for the engineers who worked on this, as this is really awesome but probably will not find market fit
Yikes.
Agreed! Let's just wait for a FOSS alternative to pop up that has a few similar fundamental features. Don't need the cloud-multi-user-account-based stuff.
try again
It seems like misdirection and sleezy marketing. Products built with Rust are particularly susceptible to it.
My thoughts exactly. I don't use potential keyloggers on my browser (think grammarly or similar), I'm not going to install a terminal making requests or getting my data as I use it.
They promise that after beta you won't need Github, and telemetry will be optional.
Though imo this is just as easy to read and understand: https://assets-global.website-files.com/60352b1db5736ada4741...
edit: no windows or linux support ???
It's free, does not spy on me, comes by default with Kubuntu and has great themes out of the box (including the Solarized themes).
We think the two products are meant for two different audiences.
Alacritty has a very minimalist philosophy that suits some terminal power users very well. It’s geared towards folks who are familiar with more advanced tools like tmux, and who are comfortable doing advanced configuration in the shell. For instance, Alacritty has no tabs: users are expected to use tmux.
With Warp, you get similar performance to Alacritty (we are both Rust-based, GPU-accelerated native apps, and Warp leverages some of Alacritty’s model code) But you also get many more built-in features that we think make all developers more productive, like:
- Blocks (grouping commands and outputs together)
- A modern text editor for your input
- Features like Workflows and AI command search that help you perform tasks faster
- Tabs, native split panes, and menus
That said, it’s not perfect. For example it lacks font ligature support, and there appears to be no prospect of that being implemented. I don’t care about ligatures that much anyway, so no big deal for me, but for others it is.
My experience using terminal emulators is that they are all flawed in at least one way. Whether it’s lack of true colour support; lack of ligature support; weird text rendering; weird colours; confusing configuration; etc. I feel like a terminal supporting all of those things must be possible, but I haven’t come across it yet.
Did you guys talk to real-world users while building this and before this launch?
This whole blow-up re: your telemetry / open sourcey'ness seems like it could have been avoided. I'm curious if you actually floated these ideas with real world users and a) everyone else is cool with it but the HN crowd is super put off by it, b) everyone is super put off by it but you decided to launch anyway, or c) you didn't actually check with real-world users and hoped for the best.
Sorry if that sounds snarky - it's not my intent. I'm genuinely curious here as a product person / entrepreneur / builder, etc.
My take is that the hacker news crowd is not the target market for Warp. I think it does an amazing job of making the terminal easy and friendly to infrequent users. I'd recommend it to anyone who tells me they prefer a git GUI interface over the shell because of how confusing the shell is. (this is where Warp's completions really shine)
But if you're already very comfortable in the shell and have a customized setup there's some very rough parts of Warp. Lack of any compatibility with existing bash/zsh completions is the huge deal breaker for me.
Also you'd be surprised at the number of software engineers that really don't care how many sentry logging calls their apps make. I completely agree with the sentiment, and I personally just disable the Warp application's internet access to address this, but it's worth recognizing that we're in the minority of people that care.
I assume you're asking specifically about discussing telemetry and open source, not only the features. We try to be super open about collecting the data, and published an extensive list of things we report. Most of our users don't mind. Those that did, messaged us directly about it and shared their feedback. Some even decided to trust us after exchanging emails, talking to the team and seeing us improving the messaging based on their feedback.
Regarding open source - it is not just a vague promise. We do have plans on doing it, many team members joined the company because they want to contribute to the community. We actively discuss this topic with our community on Discord and Github. I'm personally super excited about our UI framework, and can't wait until we open it up to other people (we recently added some a11y support, which is super cool and not as common among the Rust frameworks). Here's the github discussion for more context: https://github.com/warpdotdev/Warp/discussions/400
However, we understand that our current mode of operation won't (and honestly, can't) please everyone, so it's not surprising that there are people who don't agree with this approach.
We also were expecting some of this response from the HN community, and understand it.
The short answer to your question is that different developers care about different things. A lot of developers are OK with login, telemetry etc (we are not the only tool that has these things), and they exist in our case because it helps us produce a better product experience.
That said, I don't want to dismiss your question - we needed to do a better job understanding the perspective of more developers, and the response on HN has made that very clear. We are going to take the feedback and adjust course.
Thank you!
I would not blame companies for adding telemetry for improving their product (instead of tracking user), and not explicitly tell the paranoid mob about it, as if to give them excuse not to use the product. It's not like they won't find out anyway.
It's not open source, and "maybe it will eventually be" is unacceptable for such a core component of an engineer's workflow. Most of the features on the front page are "coming soon," not actually available. There's no timeline for support for non-Mac OS systems, and it's built using Metal rather than any cross-platform API, so it will be at least moderately difficult to port. (Isn't the whole point collaboration?) It is "blazingly-fast" but has no benchmarks for latency or startup time.
The team raised money because "[b]uilding a terminal is hard," and the business model seems reasonable - build a terminal people like, and then get businesses to pay for it - but I'm hard-pressed to find a use case that would benefit from the upsides of this tool which isn't also utterly hamstrung by its shortcomings, at least currently.
Yeah, maybe you can justify it at an all-Mac dev shop, but at the last all-Mac place I worked we did everything this currently does with iTerm (free) and Tuple, and frankly I don't see this obviating the need for Tuple in that use case. (EDIT: Tuple also works fine on Linux, and of course there are myriad excellent terminals for Linux.)
Perhaps most importantly, though, this FAQ entry concerns me:
> Every session you work on your desktop can be backed by a secure web permalink. It opens into a browser tab that shows your terminal state and allows readers to scroll and interact with the read-only elements. You might use this for yourself: so you can view and run commands on it while you're away from your machine. Or you might share it with a coworker for debugging.
First of all, is this actually available at the moment? I think not, since "Web (WASM)" is still on the roadmap.
Second, "secure" is doing a lot of work here. What's the threat model Warp considers themselves secure against? How are these sessions allocated? Does every terminal start in a connected state, or is the connection only made once the user opts in? Are the terminal sessions E2EE? Are they exposed to Warp's internal systems? If so, what is stopping any attacker who makes it into Warp's network from remotely monitoring and controlling user machines? If Warp says it _is_ E2EE or otherwise secured in this manner, how can we trust them when it's not open source?
This seems too risky to be worth using seriously, and perhaps too risky to even try out.
Software doesn't need to be open source for it to be adopted, if they have the right security practices and I'm sure for enterprise contracts they will have the right level of information available under NDA when GA.
Regarding the cross-platform piece, the plan is absolutely to support different platforms. In fact we've built our own cross-platform UI framework to help us with this endeavor which you can read about here: https://www.warp.dev/blog/how-warp-works. We chose Metal to start because the Metal debugging tools in Xcode are excellent, allowing us to inspect texture resources and easily measure important metrics like frame rate and GPU memory size. Thankfully, because our graphics code is decoupled from our UI framework, porting the graphics piece of the UI framework essentially mounts to porting over a few hundred lines of shader code, which shouldn't be too difficult.
Edit: After searching for variations of “terminal” “iterm” and “tuple”, of course it’s the top hit if you just search Mac and tuple! https://tuple.app/
That's a huge overstatement. What's unacceptable about it (or any other software for that matter) closed-source?
I mean the CLI has been one of the last parts of my system that I really still trust is working on my behalf only.
This product made me rethink that assumption.
As for capturing the output from a command line on the mac (and also on linux IIRC) just use pbcopy/pbpaste.
My opinion: It's not worth giving your privacy away for features like this.
Regarding the other thoughts in this post, I have to agree. I use iTerm instead of Terminal.app, but if I had even the remotest fear that it was sending anything elsewhere, I would jump ship. My terminal has all kinds of information that can act on my behalf, and I wouldn't want any of it leaving my Mac at all, ever, period. Had this been open-ish source but not phoned home, I'd give it a try. But opaque data leaving for who knows where? Nope.
I suspect OSX is no different and has similar telemetry and privacy policy for its terminal.
https://wezfurlong.org/wezterm/
Having now tried Warp, I think it's fine. I doubt performance will be a problem. What concerns me more is that it's not open-source.
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 feel like a crazy person in this thread because I’ve literally never had the thought: “I could be so much more productive but this damn terminal is slowing me down”.
I strongly doubt you can create a good terminal if it also needs a business model that can recoup $23M.
puts on thinking cap
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.
Jeez, I have a crap-ton of half baked ideas and a bridge that I would love to sell.
But the one thing that really excites me is to have a full team working full-time on building the terminal that developers want to use. They're doing real user research, talking to developers, and taking feedback in forums like HN seriously - and using up millions of VC-dollars building a new version of this fundamentally important core utility. I'd much rather have that VC money go toward an attempt at a better terminal than some ML or web3 startup.
I think this doesn't usually happen? All the terminal emulators I've used usually open-source projects developed in someone's free time. Don't get me wrong, projects like Alacritty, urxvt, xterm, Terminator etc. are amazing for the funding they have (I think mostly $0?), but I'm super excited to see what a cohesive terminal based on real UX research can look like.
It's nice to think of this as 'taking advantage of' VC dollars, but VC dollars come with strings attached, namely the need for an 'exit'. The exit only happens if the company in question makes multiples of what it invested, meaning that VC-funded companies need significant revenue from their users. These days, the growth required for an exit leads to: 1) advertising being laced into a product, 2) user data being sold or otherwise monetized, or 3) charging you a monthly subscription fee.
Maybe this time it's different—there are theoretically other VC-friendly business models that work for software—but I struggle to see how.
Open-sourcing the application from the beginning would certainly give more confidence here.
There are some great open source terminals out there, but having the opportunity to rethink it with a team of dedicated full-time engineers I think gives us an opportunity to build something really powerful and useful.
I read this article the other day that people with "technical background"[1] have this "instinct" to quickly look for "wrongs/fails" to avoid failures, issue here is, we express our selves terribly and most of the time it will go blunt on comments. This lead a whole discussion on the topic, some people it was the right thing to do, and others thought that we should be more human/kind to each others.
The article above was actually about Pull-Request/Code-reviews, and how some people will mostly scrutinise others people work to feel like a hero.
[1] I believe most of us here have a "technical background", who else uses a "ugly forum"
In fact, I participated in a very first user research sessions (back then it was me and the ENTIRE WARP TEAM) almost a year ago, and after a session like this I decided to interview with the company and changed my job, and joined Warp :))
Warp has taken a dramatically different approach; they got millions in funding and just made it a company. I am shocked because I never considered there was a market for these things. Developers hate having their tools taken away when their credit card expires, and it's kind of hard to compete with free, which clearly works well enough to have created all software and systems currently in existence. But I guess there was a time when you only got a UNIX shell with a commercial UNIX license, and people did somehow get access to those, and they did become very popular.
Anyway, seeing this really made me rethink the world and I'm still reeling a little bit. (I think my thing will be better though ;)
Even at these times you got tons of GNU and BSD utilities.
And since Slackware days, the commercial Unix' days were numbered.
How can I learn more about your project?
Btw, we are hiring! ;)
To get this veritable torrent of information past those "pesky" secops people, they resort to underhanded tricks like using host names like "microsft.com" to bypass firewall rules blocking "microsoft.com".
It is borderline impossible to stop telemetry in a typical corporate environment without heroic, ongoing vigilance from a rabid sysadmin foaming at the mouth about privacy.
This is the new normal. Get used to it, or do something about it.
And don't use it until it changes.
That's a shame because terminal multiplexers like GNU screen and tmux such a core part of my terminal usage that I'm hesitant to discard them, even for something that looks really useful like Warp.
I'm not sure how many people actively use terminal multiplexers like GNU screen and tmux, so maybe I represent only a tiny minority of users.
All my friends, which are using terminals, are also using tmux. It's still small sample, but probably we don't represent such a tiny minority here.
But...it is exciting to see someone reimagining the terminal a bit. People frequently talk about wanting a better GUI interaction model for everyone, but the actual ideas to improve it seem to be missing, I think because the desktop status quo is really not that bad for low-learning curve systems. (In fact, I think many of the changes in the name of desktop/mobile convergence have been for the worse.) I'm way more interested in the idea of creating a hybrid text/graphic command interface for programmers. There's a much better interface waiting for someone with the vision and (more importantly) ability to create an ecosystem around it. Some ideas:
* Warp's more visual completion is super welcome. Does it work with the shell's standard completion scripts?
* Warp's blocks look like a nice step in the right direction. How do they work? I'd guess it's ANSI codes like iTerm uses to distinguish the ends of commands, although that has the downside that a broken/hostile command can impersonate the shell saying the command has ended. It'd be nice to work out some compatible yet more robust protocol. (Maybe the shell takes responsibility for piping subcommand's output through it and filtering, or maybe something else.)
* It'd be interesting to further extend blocks with some protocol that allows programs to output within their block using richer elements: non-monotype fonts, adjustable tables, etc. A little like a Jupyter notebook, maybe. Even better if it works with some richer way for programs to pipe information to each other.
* Likewise, when launching alternate-screen terminal stuff, to allow them to do more with the rectangle than a grid of text. Closer to embedding an arbitrary cross-platform network-transparent GUI, launched from the shell, occupying its rectangle.
* And at first glance, looks like it's missing tmux-like features (whether integration with tmux proper like iTerm has or its own thing). I'd want that in any richer terminal app—most of my work in terminals is on remote machines, often over flaky network connections.
In order to promote the idea I've been spending most of the time writing a client in Go. I think it has enough functionality that I can start writing servers that really showcase the capabilities.
> Warp's more visual completion is super welcome. Does it work with the shell's standard completion scripts?
It does not. But we have completions out of the box for 200 commands.
Warp's input is a text editor instead of the shell input. This means we ended up building completions by hand and soon, via the community. We think this is a better experience because we can provide more in-line documentation.
> Warp's blocks look like a nice step in the right direction. How do they work?
tldr; shell hooks
Most shells provide hooks for before the prompt is rendered (zsh calls this precmd) and before a command is executed (preexec). Using these hooks, we send a custom Device Control String (DCS) from the running session to Warp. Our DCS contains an encoded JSON string that includes metadata about the session that we want to render. Within Warp we can parse the DCS, deserialize the JSON, and create a new block within our data model.
Re: impersonation: that's a good concern we will consider.
> It'd be interesting to further extend blocks with some protocol that allows programs to output within their block using richer elements.
Absolutely! This is definitely in the roadmap. We want rich output like adjustable tables and images. We also want to support a protocol so other CLI programs can use it.
> Likewise, when launching alternate-screen terminal stuff, to allow them to do more with the rectangle than a grid of text.
Yes we are thinking of supporting blocks within tmux, for example.
> And at first glance, looks like it's missing tmux-like features (whether integration with tmux proper like iTerm has or its own thing).
Yes, other than split panes, we do not have tmux-like features. We've begun mocking out what those features could look like. We are thinking of a native window management solution and a native way of saving workspace/session templates.
We are also thinking of what a deeper integration with Tmux might look like.
To be honest - it feels weird seeing a company launch a free terminal, in 2022. How will the company make money? How long will this tool be around for? How will this company degrade the experience, or my privacy, so they can make money?
I also don't know how to square my thoughts on the above with the need to have sustainable open source development which no one seems to pay for?
---
Anyway, neat to have a new terminal that isn't Electron, but I'll stick to MS Terminal. At least they already have all my telemetry data.
The terminal is totally free for individuals. Our business model is to make the terminal so useful for individuals that their companies will want to pay for the team features.
We will not degrade your experience: we would never charge for anything a terminal currently does. No paywalls around SSH or features that don't cost us money. We will never sell your data. We treat privacy seriously at Warp: check out www.warp.dev/privacy for more information.
We are planning to open-source parts and potentially all of the terminal.
Otherwise, it looks neat.
But the other features of it have been really great too. I like the terminal splitting, the history searching, the command palette, and no performance issues I've noticed either. It's made my terminal a joy to use for once. Keep up the great work!
While folks have mentioned here that shells have powerful line editing capabilities, I've found that a lot of people miss this. We want to allow a broader set of people to be productive in the terminal. And FWIW, a lot of developers - with varying amounts of experience - have resonated with the text input.
Personally, I'm a heavy vim user and I've never gotten particularly comfortable using the shell's line editor.
The best implementation of this to date was in TotalTerminal/Visor, which was a mod for the Apple terminal that added this feature but naturally went the way of the dodo when macOS added SIP. iTerm2 has a feature that kinda does this, but that implementation is comparatively janky and half-baked feeling.
If Warp gained a polished version of this there’s a good chance of it becoming a mainstay on my systems.
https://github.com/varbhat/dotfiles/tree/main/dot_config/zsh
I could even have enabled real time type ahead completions with this plugin but i haven't (because i don't need this feature) : https://github.com/marlonrichert/zsh-autocomplete
i use my current configuration on foot terminal (which itself is blazing fast and boasts fastest vtt parser) in linux and kitty terminal (which is very feature rich, even has terminal graphics protocol so that you can even run glxgears(opengl cube demo: https://github.com/michaeljclark/glkitty) on it) on linux and macos.
i am sure that other shells such has fish also have these features.
So, what benefits do i get on switching to warp? currently,i don't see any except few marketing words which aren't enough for me to start using warp.
I might be missing something but i am all ears.
Here are some differentiated features:
- Blocks: we group commands and outputs together so it is easier to navigate through the terminal, and perform actions on the outputs [0]
- A text editor for the input: selections, cursor positioning, multiple cursors [1]
- Workflows which allows you to save and share hard-to-remember commands [2]
The projects you mentioned are great. They do involve some amount of configuration. We have those out of the box so they are more easily accessible to developers.
[0]https://docs.warp.dev/features/blocks
> The terminal’s teletype-like interface has made it hard for the CLI to thrive
bullshit
> user accounts to just run a terminal?
bullshit
> collaboration
bullshit ...
I know and have worked at companies with very complicated setups for CLI-based workflows where you need 2 people to agree for each command. This could potentially solve all of that.
That being said, with the move to containers there's a lot less CLI surgery to do.
Talk about a bad taste. This is basically the Elasticsearch licensing fiasco waiting to happen again.
So many red flags, I don't have time to list them.
Bottom line: The company attitude is not open, and bears the whiff of the aggressive Docker-4-Desktop fiasco and financial investment recoupment strategy.
Lots of things can change, but organization DNA doesn't.
See also: Microsoft, Uber, Apple. Things don't really change.
Looks really neat. But there's a dissonance between the positioning here vs. the audience it is intended for. The community of folks interested in using a terminal is largely one of grizzled veterans that significantly overlap with security (conscious) folks.
Overlap with Instagram influencers living their best life in public is approximately nil. :)
I suppose there are newbie developers that don't know better, but are already using vscode and use the built-in term if they even bother. I could see cloud features and telemetry being useful however as an opt-in separate install.
So, I'd dial back the idea that "modern" means giving in to the surveillance dystopia.
Bonus points if you get it running under OS/2.
Also, was just reading about how Flynn couldn't get funded, that made me a bit sad.
I don’t think so. I think they’re running the same playbook as most investor-backed dev tool companies. They just forgot you’re supposed to reach critical mass before you start the mandatory invasive data harvesting.
- Love the idea overall of a fresh, new shell. I love novelty, features, ergonomics, and this pushes all the right buttons
- Looks gorgeous
- The mandatory Github login is...weird. I don't mind logging in, but it seemed unskippable, and conceptually that leaves a bad taste.
- Mandatory telemetry...ehhh. Like I get it, I use Sentry and OTEL, I love the visibility, and I get exactly why you want it in the beta, but ehhhh, really bad look. Especially in this community. Also the privacy policy doesn't seem to be linked from the app. I can get to it, but would be nice to just go there right from the about page. On the whole...I find it tolerable, but I don't work in a highly sensitive field at the moment. At $LASTCO, that would be a complete nonstarter. Between the squick factor and compliance, it would be good to at least allow some amount of opt-out on the phone home.
- I would easily pay $20-50 for a souped-up terminal (I spend all day in it), even a closed-source one, but the "we raised tons of money to build a free terminal and haven't figured out how to monetize it yet", again, understandable, but not the best look, given the mandatory data collection. Hey, dev's gotta eat, but I'd rather pay for OSS and transparency, rather than free-but-you-are-the-product, and I hope they go for the former route.
> I would easily pay $20-50 for a souped-up terminal (I spend all day in it), even a closed-source one, but the "we raised tons of money to build a free terminal and haven't figured out how to monetize it yet", again, understandable, but not the best look, given the mandatory data collection. Hey, dev's gotta eat, but I'd rather pay for OSS and transparency, rather than free-but-you-are-the-product, and I hope they go for the former route.
The terminal is totally free for individuals. Our business model is to make the terminal so useful for individuals that their companies will want to pay for the team features.
The general philosophy is that we would never charge for anything a terminal currently does. So no paywalls around SSH or anything like that. The types of features we could eventually charge for are things that have a cost to us, for example enabling real-time terminal collaboration. Even those will likely be free up to some level of usage and only charged in a company context.
We will never sell your data.
> Also the privacy policy doesn't seem to be linked from the app. I can get to it, but would be nice to just go there right from the about page.
The privacy policy is linked from the login screen and it's also one of the first items in our user docs.
I don't understand. Why is login a requirement to even use it?
Why not have an excellent free terminal as a way to get people using your tools, and then add the collaborative/audit features as paid features? That way many devs would not only start using this, but can make it a part of their daily workflows.
The terminal is totally free for individuals. The general philosophy is that we would never charge for anything a terminal currently does. So no paywalls around SSH or anything like that.
You're totally right in that the collaborative/audit features are a good fit for being paid features. Our business model will be around charging companies for team features.
For our public beta, we do send telemetry 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. But we only track metadata, never console input or output. For an exhaustive list of events that we track, see here: https://docs.warp.dev/getting-started/privacy#exhaustive-tel.... If this is uncomfortable to you, please wait for Warp to enter General Availability. At that point our plan is to make telemetry opt-in and anonymous.
But one thing that your landing page has left me confused about: you have two examples like this:
cargo +stable fmt
cargo +stable check
cargo +stable tests/
presumably to show off multi-cursors. But in neither example does the person appear to hit "Enter", which is the part I'm really wondering about. Like... what happens? If you run three separate commands like that at the same time are they in separate subshells or implicitly `&&`'ed together or something else? What's the return status if either `check` or `tests` fails? If `check` fails but `tests` pass... is the check failure's exit status lost? What does (e.g. in fish) `echo $status` say afterwards?Multi-cursors and multi-line editing is definitely cool, but the example there totally doesn't match my mental model of a how a shell works, so it leaves me perplexed and confused how warp actually works.
And, honestly, I can't use it. They interfere with the operation of the shell to such a degree that I had to disable almost my entire bash configuration.
Add to that, that I already have the following features native to bash shell (and I'm sure they're in zsh too):
- history of commands: easily searched by pressing ↑ or ⌃+r - completion: via the awesome bash-completion project - split panes: both terminal.app and screen do this for me - session sharing: screen + ssh does this for me - "workflow" sharing, I can and do write shell scripts that can be used by others
I've seen comments trying to defend this that REALLY make me doubt that the devs even understand how a terminal + shell work. A shell script will run in it's interpreter regardless of what shell you happen to use, shared commands will inherently be in the flavour of shell-script that the sharer is used to, and so i have to know how to use their shell as well as mine to translate between them, which again isn't a problem when running a script. They claim that people don't document their scripts, but the same people who won't document a script won't document stuff they share in warp. They claim there's no way to find documentation natively from the terminal or to search for scripts based on what they do, apparently they haven't heard of apropos and man pages?
There are a lot of great shell configs. One advantage of Warp is that the terminal & shell have these features out-of-the-box.
> A shell script will run in it's interpreter regardless of what shell you happen to use, shared commands will inherently be in the flavour of shell-script that the sharer is used to, and so i have to know how to use their shell as well as mine to translate between them, which again isn't a problem when running a script.
Workflows in Warp specify the shell in the metadata.
The idea for workflows is to allow people to search commands based on what they accomplish, rather than requiring everybody to remember the command and type. For example, if I wanted to delete all empty files in a line, instead of remembering the exact incantation of sed to accomplish this, I could search "delete empty files".
versus
"our terminal model code is based on Alacritty’s model code."
Well done. Sorry guys, that's where you lost me.
My take is that there are plenty of commercial projects that have open source dependencies so it's not quite so black and white. That said we are still figuring out the best way to proceed on open sourcing the warp client code.
I imagine if it was open source, didn't have a bunch of strange network calls built in, and most importantly a third party audited the source code to make sure you're not doing anything wrong, then I'd be open to trying it.
The issue here is you have a black box, which will have complete control over my system. I have no idea what happens the moment I give you my sudo password, do you install a bunch of weird stuff in the background? How do I know this isn't just a keylogger?
I can't imagine any company approving this for internal use.
Equally concerning, what's your business model. Are you selling my data ? Will you deliver ads straight to the terminal ?
At the same time, I would absolutely love to see you. Someone do this, but as a transparent open source project. I'm just not sure how you can create a business from that.
Regarding open source, we want to do it for parts and potentially all of the code. We plan to open-source our extension points as we go. You can read more about this here https://github.com/warpdotdev/Warp/discussions/400.
We have also talked internally about having penetration testing.
As for our business model, the terminal is totally free for individuals and we want to make a terminal so useful for individuals that their companies will want to pay for the team features.
The general philosophy is that we would never charge for anything a terminal currently does. So no paywalls around SSH or anything like that. The types of features we could eventually charge for are things that have a cost to us, for example enabling real-time terminal collaboration.
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.
For benchmarks, we have some preliminary info in this tech blog https://www.warp.dev/blog/how-warp-works.
And I don’t mind using my GitHub account or contributing to telemetry during a private beta. I understand why others here find that problematic, but I’ll probably just use another terminal if I need to use/access sensitive data during that period.
Looking forward to trying this out! Thank you for sharing.
They’d probably get their million paying users in the first year.
For this crucial part of this target market’s (engineers) toolkit, it HAS to A) be open source and B) have the option for zero telemetry.
Inb4: “if it was open source why would people pay for it?!?” Because at the right price people are happy to pay and support something they love and get low-effort trustworthy updates built in.
The terminal is totally free for individuals and our business model is to make the terminal so useful for individuals that their companies will want to pay for the team features.
We are also definitely open-sourcing parts and potentially all of the code.
You can read more about how we see it here: https://github.com/warpdotdev/Warp/discussions/400.
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.
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).
We do want to support linux once we get the product experience right. We decided to build in Rust and set up a UI framework because we wanted to make it easier for us to port to Linux.
For now, every platform we support entails additional engineering overhead that takes away from getting to product-market fit. Once there, we will invest resources into supporting Linux, Windows, and the Web.
WezTerm is crazy fast with GPU-accelerated ligatures, mcfly has an NN in it that startles me, fzf, rg, bat. Everything has bash/zag/fish autocomplete in it now. tmux customization has become a high art form, VSCode has forced all the best language tooling features in vi and emacs.
There’s definitely a renaissance of the terminal happening, I just think it’s fueled more by the Rust community having found its first killer use case/thin end of the wedge into all our lives by pimping our ride on the terminal experience than corporate backing.
Best of luck to these folks, but I hope they’re aware of Lucid and have its outcome incorporated into their plan. They did great stuff but a bunch of GNU people with something to prove built it in the bazaar.
It’s on a visibility toggle with one key, nice margins on all sides, tmux, spaceship prompt, a color scheme that matches my IDE, I can hide the title bar if I like. It’s basically perfect. I don’t need error messages with rounded borders.
Rust has pretty extensive platform support, which makes it relatively simple for us to do that.
Our business model is to make the terminal so useful for individuals that their companies will want to pay for the team features. Even those will likely be free up to some level of usage and only charged in a company context.
The terminal is totally free for individuals. Our business model is to make the terminal so useful for individuals that their companies will want to pay for the team features.
The general philosophy is that we would never charge for anything a terminal currently does. So no paywalls around SSH or anything like that. The types of features we could eventually charge for are things that have a cost to us, for example enabling real-time terminal collaboration. Even those will likely be free up to some level of usage and only charged in a company context.
> warp lets you securely share your terminal with one simple command: warp open. When connected to your warp, clients can see your terminal exactly as if they were sitting next to you. You can also grant them write access, the equivalent of handing them your keyboard.
> warp distinguishes itself from "tmux/screen over ssh" by its focus and ease of use as it does not require an SSH access to your machine or a shared server for others to collaborate with you.
> Despite being still quite experimental, warp has already proven itself useful especially in the context of:
> - Interaction with remote team-members
> - New engineer onboarding (navigating code in group without projection) Installation
https://github.com/seanmonstar/warp
It seems like you're going to confuse people and crush someone's established project with your $17m. "Warp" + "Rust" is a web framework.
There is absolutely zero chance that I'm going to do all of this using a proprietary closed-source telemetry-sending terminal emulator no matter what visual niceties or fancy UI frameworks it may offer.
Telemetry for a beta? Sure, whatever, y'all are being transparent about what is being collected and, as a developer, I can definitely understand the desire to collect information about usage to improve the experience.
- Collecting telemetry - Requiring sign up (and associating telemetry wit it)
Are flags for me.
If you want to collect feedback fast and easy, the best would have been letting it be taken for a spin by folks in HN and and you could have probably benefitted from a good deal of input on improvement or bug-hunting.
A terminal with a dedicated well funded company, I welcome and can pay for such terminal. But collecting too much data these days is at least frowned upon by almost everyone.
You started a company to write a terminal app? I'd say that's either misguided, or you have something underhanded planned.
> any Mac user can download it.
Any _Mac_ user? Sounds fishy.
> The terminal’s teletype-like interface has made it hard for the CLI to thrive.
Isn't that an anti-tautology? Hmm.
> An input area that works just like a code editor
Why wouldn't I just use a code editor? We are talking about an app for graphical desktop environments, right?
> ... with GPU-accelerated graphics
That you wrote especially for this app? I don't know...
> We are planning to first open-source our Rust UI framework, and then parts and potentially all of our client.
A _closed-source_ terminal app? Nuh-uh. You're up to no good.
----
And after noticing those red flags, I read @orastor's post about the app connecting to all sorts of servers.
I'm 100% on board with trying out a new terminal that is fast and has features, but there's an implicit expectation of the simplicity of the communication channel, and... this is not it.
> After 20 years of programming, I still find it hard to copy a command’s output; I always forget how to use `tar`; and I always have to relearn how to move my cursor.
Huh? I think if it takes you >20 years to do basic stuff like that, you need to revisit your approach to learning new things. If I play chess for 20 years and still don't know how to move the pieces, it's not the game's fault, it's mine.
I wonder if you thought of adding plugins a-la Fig [1], but using WebAssembly instead of being restricted by Javascript?
Some projects like Lapce [2], Dprint [3], Fiberplane [4] are already using this strategy to extend their ecosystems and I really believe it could be incredibly useful to extend usability on the terminal side!
Please feel free to reach to syrus@wasmer.io, I'd love to help as much as possible on that path!
[1] https://fig.io/docs/getting-started
So, don't collect it to begin with, so even if you get bought the data can't be sold, because there is none?
Ah wait...
This has me reconsidering my usage of iTerm. What could be lurking in there? Maybe it's safe for now, but will the next update include spyware so iTerm can get its piece of the pie?
Mac's builtin terminal is quite good. Nothing fancy. It's good at what it does and doesn't try to be something it's not.
CLIs are available on every OS.
> I always forget how to use `tar`;
You can increase the amount of command history you keep. Or keep a file with oft used commands.
> Our business model is to make the terminal so useful for individuals that their companies will want to pay for the team features.
Hard to believe. But good luck.
> We will never sell your data.
Define never. What if apple offered you $10 billion for the data? Even then? Also, why would you be collecting our data in the first place? Why does a terminal need to collect data?
Is there any new development or any product today that isn't collecting data? When's the last new product or upgrade or anything that didn't have data collection.
I think they are planning a lot of work for teams. Some people hate IDEs, but I love them. I see this as IDE-izing the terminal.
Like others have mentioned, I am confused about why I have to sign in, why telemetry is recorded, etc.
From the comments, seems the team is well-meaning. Time will tell. The privacy blowback reminds me of Kite’s first post on HN.
Everything you'd want to do in a terminal that is worth sharing would be version controlled, which is vastly superior in everyway.
You've all done some cool work here, and I can complement that, but I think this is a really weird idea with no real world evidence to justify its existence.
The world is in trouble when your putting 17M into a Terminal designed to track and make money off of us? ie. Facebook. ie. we are the product?
No thanks, deleted. I'm a programmer, don't need a corporation in my terminal.
Besides many on the pain points / motivations you mention, like "Developers work in teams, but terminals don’t support collaboration" just make me think that what you want to develop is a productivity and collaboration tool, but don't want to call it that.
I do enjoy someone is looking into the terminal but not this way...
Just a heads up: on Pixel 6 on Firefox, the homepage is not smooth at all and feels sluggish.
At first I thought it was a sh-compatible replacement, but it wasn't, and then I thought it was a terminal emulator, but that's not really what it is either. And then came the intrusive pop-ups all the time and now I don't really know what it is. A teaching tool perhaps? A "use it once a year" tool?
This is a hill I will die on and it sets terrible precedence for other core workflow tools.
To make myself clear: I completely agree with you. Just pointing out the fun.
if true, as an engineer, i'm a hard pass.
[I] [I]ls
fish: Unknown command: '[I]ls'At https://github.com/warpdotdev/Warp How did you achieve to have the folders /keysets and /themes to be linked to the other git repos https://github.com/warpdotdev/keysets and https://github.com/warpdotdev/themes I wanted to do this for a long time but all tutorials pointed to all alternatives one more difficult than the other.
[1] https://twitter.com/anshublog/status/1511553856487845892?s=2...
Uh... Sign up where?
I'm sure some people wouldn't like what I'm about to propose as it again "phones home" but I encourage the team to take a look at GPT models for converting text to commands, I have a simple fine-tuned model that does wonders when I'm in the terminal.
As for me at home, all I need are those sweet blocks with text-editing mode in any open source terminal.
[1] mightyapp.com
Heck the windows terminal and macOS terminal are closed source and I use them everyday.
That's pretty cool. I'll be interested in trying it once all of the source is available. A proprietary terminal program that connects to googleapis.com, sentry.io, segment.io, etc. is a *total* non-starter for me.
Good luck with the beta! I'm really interested to see a release I'll be able to try.
(FWIW, I think the model, in macro, sounds like something I'm glad to support. It reminds me of Bitwarden, for which I happily pay every year.)
Not going to be usable for me unless that's fixed, or at least made into a setting. Certain directory structures are built deep into my muscle-memory now, and I feel crippled when the auto-complete does something different than what I'm used to.
A terminal. With login. And telemetry. A terminal with telemetry.
Looks like a cute terminal though.
That’s a nope from me Dog.
And I don't want to tie my github to this thing, i have all sorts of github accounts for legitimate reasons.
I would be glad pay a lifetime licence fee (maybe with a 30 day money back guarantee?) to check it out, but no way am i going to do a subscription model for my terminal.
1. this desparately needs multiple profiles where I can customize the command that is launched (ie. with iTerm2 I have keyboard shortcuts mapped to a profile which launches SSH instance to our various aws environments)
2. powerlevel10k doesn't work (dealbreaker)
More NGS perspective on the UI - https://github.com/ngs-lang/ngs/wiki/UI-Design
why does my terminal have any data besides a config file, and why does it need access to the internet at all?
next!
I clicked "Sign up with GitHub", it took me to the website where I authorized it. It was seemingly working until I saw this:
"Oops! We were unable to log you in."
The team has been responsive, constantly improving, and bringing real innovation to the space.
Highly recommend!
check the difference: https://imgur.com/a/GUTVaeF
Are there _really_ enough terminal users and companies willing to shell out $$$ to make more than 1 million gross per year?
This kind of reminds me of that prettification of the node repl fad a few years ago, but when they switched to pay only people were like "hard naw"
That sounds a bit ageist :) also - can command editing integrate with my editor of choice? I don’t want to have to learn how to use another editor - I already know my way around bash keyboard shortcuts, having to learn a third thing sounds like a step backwards.
don't get me wrong, it looks great as it is right now, but i'm very sceptical about it's future
- Downloaded it - Saw the github login - Uninstalled it
Some things only happen on HN. This is one of them.
- Workflows - Ever heard of scripts?
- Block editing - That is just vi mode inside bash/zsh.
- Terminal sharing has existed since so long.
- Forming commands - We got tldr for that.
- Fast and GPU accelerated - Open source terminal emulators have cracked that already. See alacritty and kitty for instance.
And on top of all this, when you factor in VC money, I don't see how this product can truly beat its alternatives.
What makes you think its acceptable for you to spam HN with Warp every few months ?
> 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? ;-;
Good luck with your product but HN does take privacy somewhat serious, I know I do.
Why is a company building a terminal? How are they going to earn money at all when there are other fast, performant terminals that are open source, community run, and don't have interests at-odds with user freedom and privacy?
It seems like just about any tech project is being funded now.
edit: It's also sad that we're at the point of "no electron" being a selling point, when it should be the standard for CLI tools. And I'm so glad to see it supports other shells, like just about every other terminal out there.
> By continuing you are agreeing to our Terms of Service and that Warp can collect usage data.
lol, no
At least it isn’t a blockchain terminal I guess