We built Fig because of our own struggles in the terminal: we were tired of context switching between man pages, Stack Overflow posts, and Medium tutorials anytime we got stuck. We wanted our CLI tools to be more discoverable.
The terminal is powerful, but unforgiving. It emulates the constraints of hardware (like teletype printers and video terminals) that became obsolete a generation ago. There are no built-in affordances. No hints about the 'right way' of using a tool or even finding the right tool for the job. Beginners are thrown in the deep end. And even seasoned developers can screw up their system with a few unfortunate keystrokes.
To solve this, we add a UI overlay that is linked with the interactive shell. As you type, Fig pops up subcommands, options, and contextually relevant arguments in your existing terminal. For example, you can type `npm run` and Fig will show you the scripts available in your package.json. You could also type `cd` when SSH'd into a remote machine and Fig will list the folders within your current directory on the remote machine.
We use the Accessibility API on Mac to insert text on your behalf and read what you've typed. We also integrate with the shell to determine the current process and working directory. We are built natively for macOS in swift. We built our UI using web technologies so we can ultimately go cross platform. We render it using a WKWebView (not Electron).
Fig is free for individuals and always will be. All completion specs - the templates used for generating CLI suggestions - are open source and anyone can contribute [0]. We plan to monetize by supporting autocomplete for companies' custom scripts and internal CLI tools. Ultimately, we want to bring other process documentation (like SRE runbooks or deployment workflows) closer to the environment where it's used. You can see an early iteration of Fig in this HN thread from last July. [1]
Fig is designed to be private. All processing happens locally on your device. None of your keystrokes are ever transmitted or stored by Fig.
We'd love to hear your feedback on what we’ve built! We're still in private beta (so things may break!!), but we are letting HN users skip our waitlist today and tomorrow using the link above! :)
----Edit----
We really appreciate all of this feedback! Brendan and I want to address some of the most common concerns below:
Telemetry: Fig has basic telemetry in order to help us make product decisions. We currently give the you option to opt out of all non-essential telemetry by running `fig settings app.disableTelemetry true`. This removes everything except for one daily ping. We use this ping to help us understand how many people were using Fig.
Adding this ping was a mistake. We have already removed it and will be pushing this change in our next build (v1.0.43).
Business Model: Under the hood, we've built an API layer on top of the terminal. This API lets you create visual apps. Autocomplete is the first app we've built using this API. We have many more planned for things like interactive runbooks for SREs and automating deployment workflows. You can see some early prototypes here. [2] We plan to monetize these team-based apps by charging per-seat.
Autocomplete will always be free for individuals. We will never sell your data.
[0] https://github.com/withfig/autocomplete
https://news.ycombinator.com/item?id=27277819&p=2
(Sorry for the interruption. Comments like this will go away when we turn off pagination.)
My first thought is why not use built-in shell autocompletion functions instead of redefining them in JS?
Zsh completions are super powerful: https://github.com/zsh-users/zsh-completions/blob/master/zsh...
Typing `git a<TAB>` yields this in my terminal:
(btw, broken link at the bottom of this page: https://fig.io/docs/getting-started - https://fig.io/concepts/dynamic-suggestions should be https://fig.io/docs/concepts/dynamic-suggestions)The reason we created our own standard is because traditional shell autocomplete doesn't always provide metadata, like descriptions, priority or icons. Also it is a little tricky to write by hand, unless you're pretty familiar with shell scripting.
For python argparse, there is argcomplete in the same vein
[0]: https://github.com/akinomyoga/ble.sh
Deleted Comment
PS: I read the fine print and I (and many others, I'm sure) would really, really like to pay some money for you to not send ANY telemetry data at all. Would be great if you kept this demographic in mind.
Congrats on the launch, and all the best!
[1]: https://github.com/zsh-users/zsh-autosuggestions
1. Cannot identify any killer features above what I already have with forever free tools with much larger support communities.
2. Less trust in you as a YC startup. What if you fail? What if you sell out?
3. Requirement of email.
4. Telemetry and privacy concerns raised by others.
5. Not available for Linux, and I get the feeling that Linux would forever be an afterthought since you released for Mac first (presumably, this was driven by financial reasons).
> 3. Requirement of email.
> 4. Telemetry and privacy concerns raised by others.
Dovetailing on these...
Like why is a CLI tool VC backed? Is the business model just selling our data? Is the VC backing for another product and the CLI tool is just a PR thing?
> Investors: We've raised several million dollars from amazing VCs like General Catalyst and Kleiner Perkins, and angels like Jason Warner, Adam Gross, Olivier Pomel, Scott Belsky, Will Gaybrick and a handful of other impressive dev tool founders and executives.
The fact that a CLI tool raised millions of dollars while also being basically powered by open-source contributions is also kind of a wtf moment to me, but what do I know.
Autocomplete is our first product. The bigger vision that Fig can enable an ecosystem of terminal extensions. Here are some early prototypes we built [0] and here is the discussion from when we were posted on HN last summer [1].
> Is the business model just selling our data?
We will never sell data. That just isn't the business we want to build - Brendan and I like hacking on the terminal because it's interesting and we get to solve our own problems.
We've been lucky enough to find investors, most of whom have an engineering background, who understand how important the terminal and believe there is a lot of room for improvement.
Obviously, we would like Fig to become a sustainable business. We plan to monetize in the short term by offering autocomplete for internal CLI tools and scripts. Longer term, we think that there is a lot of stuff that developers do in the browser that make more sense in the terminal. Fig's autocomplete product is powered by an API that lets anyone build graphical extensions that are connected to the terminal.
[0] https://fig.io/videos/old-sizzle-reel.mp4
[1] https://news.ycombinator.com/item?id=23766980
Agreed. Take a look at Nabu Casa, the developers of Home Assistant and Home Assistant Cloud. They are 100% self-funded by their revenue from HA Cloud and the hardware they sell.
Because of this, I don't have to worry about investors demanding a return on investment by any means necessary and potentially generating revenue from users' private data.
I don't know anything about this product's intentions, but it's easy to imagine the possibilities once you start getting permission to pop something up in someone's terminal window.
Deleted Comment
I think on Linux it would make more sense to directly modify one of the many existing terminal emulators to add this functionality or you'll have to severely limit the supported configurations.
Our macOS approach might not work everywhere.
I would honestly feel less skeptical if this was a Show HN and the founders had just organically launched an app that did autocomplete and asked for some money to buy a license. I'd put that along side similar attempts like Xiki.
VC-backed changes it though, it feels different. It'll start with a subscription model and if this requires elevated privileges to run as what could essentially be a keylogger, it won't be long before the privacy promise goes away and the marketing team takes hold.
I'm intrigued by this but not 100% sure I follow. Is the implication that VC-backed startups are more likely to suffer from a supply-chain attack, or just more general reluctance to incorporate any new tech into the stack as it increases the attack surface area?
#5, maybe but that's fine. Lots of things are Mac-only or Linux-only. It's a proof of concept. Moreover they appear to be working on some kind of standard specification for completion meta-data, which other tools can start to adopt and use if it turns out to be a useful spec.
#2-4, it's open source (at least it looks like it's open source from the website). If the startup sells out, the project can be forked.
The software market has very effectively figured out how to make things "open source" in name only (offhand, Canvas is the one that's killing me these days), and unfortunately now all such claims must be taken with a huge grain of salt.
#2-4 Firstly, just because it can be forked is not to say that it will. It's not easy to maintain a whole project in your spare time. Also, this may be a moot point since the completion engine is supposedly proprietary (as per another commenter).
As for the telemetry concerns, I totally get that. We've tried to strike a balance and it seems like we've got it wrong. This will be fixed in the next update.
Then why on earth did you go out of the way to implement this in JavaScript instead?
Care to share more about this? Which terminals are you planning to support?
It does have the features I want, although not enough to convince me to switch right now. cli can be painful if you are working on commands you are not familiar with. IMHO, this is a better interface than the ones in Fish/Zsh, that provides richer information regarding command choices, hence can be a huge improvement for discoverability.
Imagine that you are not familiar with AWS EC2 and want to spin up an instance to play with. If you do that via awscli, first you need to run a bunch of `--help` commands to find the correct subcommands(`aws ec2`, and then `aws ec2 run-instances`), after that, there are 40+ flags for `run-instances`, some are mandatory, some are optional. If you do that from the web console, there's a very friendly wizard with several pages breaking down by networking, storage, OS...etc, intuitive and easy to understand.
I’m guessing people like me who use the shell as a means to an end. Honestly most of the time I’m using git bash “coz it’s there” and hate typing in commands. I actively avoid it. I installed LENS for kubernetes to avoid it.
I’d rather write a script in an IDE and run that than be working at the command line. Because then I can treat it like code, review before running and it’s repeatable.
I really get the benefits of this tool but I won’t use it because I prefer to avoid excessive command line use - preferring GUI and scripts BUT I do get why it is useful if I have to do interactive command line sessions
Those scripts are usually supplied by the CLI tool itself. For example for terraform: https://www.terraform.io/docs/cli/commands/index.html#shell-...
Since switching to it from the default shell of Mac OS terminal (zsh I think) I have found it immensely productive. Some of the things it does seem Magic like auto completing uncommitted files when I say “git add <tab>”
https://github.com/danisztls/dotfiles/blob/main/shell/zshrc
I am amazed that a CLI tool isn't made for Linux
Startups are good for free trials as they have VC money to spend or finished deals (purchase once, consume once, forget about them).
Can those who know what zsh mean do a better job with existing tools or custom made scripts? 100%, but that doesn't matter.
Beyond that, you can level up even further by firing up Emacs and never again needing a terminal for things that require completion.
If they use their institution's infrastructure, it's managed by the dedicated system admins. No way they're going to allow this tool to be installed.
Fig's declarative schema makes building the completions for subcommands, options and arguments very easy. This means we can support much more powerful autocomplete for many more CLIs.
Fig's standard format also makes it possible to suggest shortcuts for standard workflows (similar to aliases but more visual).
Finally, zsh and fish have good support for traditional autocomplete, but bash does not. Fig works the same across all shells (even when in an SSH session or a docker container).
How is that a standard when you just came up with it? Any other existing autocompletion format is more standard than whatever you just released.
Agree RE bash but at some point doesn't one just use the tool with the featureset one wants?
Deleted Comment
Deleted Comment
This decision alone removes my trust in your product and your company, sorry.
We should probably add this explanation to the login page because I can see how this would be confusing.
https://temp-mail.org