> New users will not be able to sign up for Fig's products right now while we focus on optimizing them for existing customers and addressing some needs identified to integrate Fig with AWS.
This sounds a lot like the product is dead, and may emerge again at some point as an AWS hosted, Amazon branded product...
I'd never use a subscription + telemetry laden product like this in my core workflow, but sucks for the current users I guess.
To me the whole post read like "we are aquihired, but we cannot admit we are are aquihired". The closing of registration driving it home.
If AWS bought it for the product, what reason would there ever be to stop the current business model entirely rather than leaving it on its current trajectory for a few months, untill said "needs" are addressed?
I would never use a cloud-syncing cloud-connected terminal for simple security and privacy reasons alone, not to mention the fact that if it goes down I become basically disabled as a developer or admin.
Several companies have tried to SaaSify the terminal and failed, so I suspect I am not alone here.
"We've noticed that there's a component of the computing infrastructure that isn't sending everything you do to the cloud and charging monthly rent..."
These features are nice, but I've never liked the idea of having to use a whole new terminal application to get them.
I may be becoming a dinosaur, but it's not that I'm not willing to try new things. On the contrary, after many years of being rigid about having one true development environment, I've moved away from Emacs to VS Code, and work from more heterogeneous environments instead of being 100% Mac. So these platform-specific thick client apps no longer feel like the way to go.
Sticking to Vim and other very well-established CLIs is partially what enabled flexibility for me. As long as I have access to a *nix machine locally or over SSH, I have a capable dev setup that I'm well-versed in. Same thing for the past 8 jobs I've bounced around in, whether in-office or remote, with whatever security restrictions, with or without a desk, maybe with just a 13" laptop. It's the lowest common denominator. Meanwhile my teammates at my current job are constantly trying to protect their workstation setups so they can use their IDEs locally, and they've also been forced to switch IDEs twice in the past couple of years.
And this isn't coming from some FOSS ideology. I don't personally care about any of that, but the best tools are sometimes FOSS. I've got a Mac and can deal with Linux as needed.
To be honest I do think it's time we move on from emulating teletypes, but I also believe that whatever comes next has to be an open standard, with competing implementations.
There's a whole graveyard out there of "next-gen" terminal projects, and none of those still alive seems to be gaining dominance. I don't think writing down a spec would help this, but it would be great if whatever emerged victorious had one.
I think the part of this that feels wrong is that it steps into the realm of so many other perfectly good tools, and it seems like it’s there to enshrine crappy local development and deployment practices.
If you need reporting on the scripts your developers are running on their local machines, that probably means they have too much access to live environments. Guardrails and reporting should be in your CI/CD process and your source control.
Shells like fish or shell plug-ins already handle autocomplete nicely, so that feature isn’t that useful.
If you need env/dotfile management you probably need to spend time making a proper development environment rather than shimmying in a tool to make doing the wrong thing easier.
SSH key management is so trivially accomplished by numerous methods like configuration management or built-in solutions offered by cloud providers. Plus, most development teams almost certainly give out too much SSH access as it stands.
If you need to SSH regularly that means your application isn’t shipping logs and your local development tooling isn’t good enough.
Curious to learn more about your switch from Emacs to VSCode?
I'm a super confused soul, and currently I use all of them:
- Emacs (for clojure / lisps / big projects).
- NeoVim (for when I want to work in the shell, smaller scripts/playground, ssh).
- VScode (js / ts / frontend / figma / etc).
I've made both my vim and emacs keybindings / features almost identical, so there is limited context switching there.
I feel very slow in VSCode, I don't even have one of my most common task optimised in VSCode yet: grepping something and quickly moving to that buffer.
It's not a different terminal application, but an overlay that gives you autocomplete-style suggestions in your existing terminal emulator. I don't know all the terminal emulators it works with since it's MacOS only, but it works in both iTerm2 and the VSCode terminal, granted that you're not using a terminal multiplexer like tmux (which makes it useless for my workflow).
Interesting - I tried Fig for few days few months ago, it gave me more headaches than relief so uninstalled it. Surprised that it made into a viable product and shocked it actually got acquired.
Same experience. Tried a few times in different machines and it either froze the machine, ate up crazy memory, or other random behavior. I’m shocked this made it anywhere.
Congratulations! I've been using it for about a year or so. Hopefully their product will continue to exist... that's what their blog says now, but that's pretty much what everyone says at first.
They seem to have built a decent community, so I can see it continuing, provided the core/all code for Fig is open source. In the last 6 weeks, 57 new contributors took the time to create 62 issues and 111 new contributors took the time to comment. These are very heathy community metrics, but there hasn't been a lot of code activity, which would make sense if they were focused on the sale to AWS.
I love this product, have contributed several times to it, and I'm a little torn. One thing I am thinking about now, is that the completion specs are MIT-licensed, and it should be possible to use them to re-implement a basic open-source version of the autocompletion product... https://github.com/withfig/autocomplete
Congratulations!? I do hope that means AWS’s ever growing cli commands will be all fig now (or will be)? It’s getting a bit long in the tooth. What about support outside of AWS? Will fig still be as awesome in iTerm2 with what-ever-is-in-%PATH%?
> Within Butterfish Shell you can send a ChatGPT prompt by just starting a command with a capital letter, for example:
This is a dangerous assumption. Not all commands are lowercase. Interaction with an external service should be a deliberate, discrete action on the user's part.
I like that a lot! It would be awesome if the client running on goal mode had capabilities to request some search engine API + do some crawling. Imagine getting the info out of up to date github issues or directly from AWS docs.
i never thought fig or warp would ever work. requiring an account and a subscription to use CLI tools sounds ludicrous. but they seem to have found a silver bullet with AWS since having an account is a requirement anyway.
Fig works in any terminal though, and its free tier gives me useful enough recommendations and docs. It's very useful to be able to use IDE-like autocomplete inside my IDE, which is the terminal I use 99% of the time. As far as I'm aware, Warp is really a standalone gig.
Will be interesting to see what happens to this long term, but hopefully means good things. I use the tool personally but really for largely basic things.
The dropdown for autocomplete is far from necessary but a nice addition. Helping with completing commands that I don't use often but know the basics of like "aws s3 cp" is nice. But because of that I could just never justify spending money on it.
Hopefully it isn't abandoned, but maybe this will also mean they don't have to try to find artificial reasons (or bloat) to convince people to pay and can just focus on the core offering.
I had completely forgot about Fig, I remember trying it out on my previous laptop, it didn't offer anything more than my zsh-autocomplete, which made me send in my feedback before uninstalling.
The telemetry part didn't bug me that much, but the product itself was cool, reminds me of warp.dev
One of the most annoying thing is to learn about an interesting project by the post were they announce that they are aquihired, or even worse, closing down because of lack of interest.
This is very damaging for other startups. You create something, then you ask people to believe you and invest their time and sometimes money with you.
Then you, in act of desperation, sell out and sell your users...
The issue is, people are already super skeptical when these startups start asking for things, this just makes them even harder to get users to trust you as a emerging company or product with data and usage.
Startups don't have big reputations to protect unless they're tied to someone famous, and also they need a path towards acquisition for early investors to care. There isn't really a way around that.
[+] [-] the_duke|2 years ago|reply
This sounds a lot like the product is dead, and may emerge again at some point as an AWS hosted, Amazon branded product...
I'd never use a subscription + telemetry laden product like this in my core workflow, but sucks for the current users I guess.
[+] [-] berkes|2 years ago|reply
If AWS bought it for the product, what reason would there ever be to stop the current business model entirely rather than leaving it on its current trajectory for a few months, untill said "needs" are addressed?
[+] [-] api|2 years ago|reply
Several companies have tried to SaaSify the terminal and failed, so I suspect I am not alone here.
"We've noticed that there's a component of the computing infrastructure that isn't sending everything you do to the cloud and charging monthly rent..."
[+] [-] Tao3300|2 years ago|reply
That's a euphemism. These companies "acquire technology" in the same sense that revolutionaries acquired Louis XVI's head.
[+] [-] dangoodmanUT|2 years ago|reply
[+] [-] gpvos|2 years ago|reply
[+] [-] ryneandal|2 years ago|reply
I am fully expecting that I'll have to go back to zsh-autosuggestions once the current iteration is fully wound down.
[+] [-] giancarlostoro|2 years ago|reply
My favorite 'acquihire' story is when Oracle bought out MySQL and the creator forked it and made MariaDB.
[+] [-] LoganDark|2 years ago|reply
[+] [-] projectileboy|2 years ago|reply
[+] [-] masto|2 years ago|reply
I may be becoming a dinosaur, but it's not that I'm not willing to try new things. On the contrary, after many years of being rigid about having one true development environment, I've moved away from Emacs to VS Code, and work from more heterogeneous environments instead of being 100% Mac. So these platform-specific thick client apps no longer feel like the way to go.
[+] [-] hot_gril|2 years ago|reply
And this isn't coming from some FOSS ideology. I don't personally care about any of that, but the best tools are sometimes FOSS. I've got a Mac and can deal with Linux as needed.
[+] [-] veg|2 years ago|reply
[+] [-] rollcat|2 years ago|reply
There's a whole graveyard out there of "next-gen" terminal projects, and none of those still alive seems to be gaining dominance. I don't think writing down a spec would help this, but it would be great if whatever emerged victorious had one.
[+] [-] askew|2 years ago|reply
[+] [-] dangus|2 years ago|reply
If you need reporting on the scripts your developers are running on their local machines, that probably means they have too much access to live environments. Guardrails and reporting should be in your CI/CD process and your source control.
Shells like fish or shell plug-ins already handle autocomplete nicely, so that feature isn’t that useful.
If you need env/dotfile management you probably need to spend time making a proper development environment rather than shimmying in a tool to make doing the wrong thing easier.
SSH key management is so trivially accomplished by numerous methods like configuration management or built-in solutions offered by cloud providers. Plus, most development teams almost certainly give out too much SSH access as it stands.
If you need to SSH regularly that means your application isn’t shipping logs and your local development tooling isn’t good enough.
[+] [-] oxalorg|2 years ago|reply
I'm a super confused soul, and currently I use all of them:
- Emacs (for clojure / lisps / big projects).
- NeoVim (for when I want to work in the shell, smaller scripts/playground, ssh).
- VScode (js / ts / frontend / figma / etc).
I've made both my vim and emacs keybindings / features almost identical, so there is limited context switching there.
I feel very slow in VSCode, I don't even have one of my most common task optimised in VSCode yet: grepping something and quickly moving to that buffer.
[+] [-] chrysoprace|2 years ago|reply
[+] [-] yieldcrv|2 years ago|reply
I was using both before but the upcoming annual payment reminded me that its over
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] Brajeshwar|2 years ago|reply
Have seen Brendan talk a lot about it on Twitter.
[+] [-] jarek83|2 years ago|reply
[+] [-] e-clinton|2 years ago|reply
[+] [-] ibdf|2 years ago|reply
[+] [-] sdesol|2 years ago|reply
They seem to have built a decent community, so I can see it continuing, provided the core/all code for Fig is open source. In the last 6 weeks, 57 new contributors took the time to create 62 issues and 111 new contributors took the time to comment. These are very heathy community metrics, but there hasn't been a lot of code activity, which would make sense if they were focused on the sale to AWS.
Source for my insights from https://devboard.gitsense.com/withfig
Full Disclosure: This is my tool
[+] [-] rmorey|2 years ago|reply
[+] [-] gabereiser|2 years ago|reply
[+] [-] 404mm|2 years ago|reply
[+] [-] pbbakkum|2 years ago|reply
It's much more bare-bones than Fig but perhaps useful if you're looking for an alternative! Send me feedback!
[+] [-] politelemon|2 years ago|reply
This is a dangerous assumption. Not all commands are lowercase. Interaction with an external service should be a deliberate, discrete action on the user's part.
[+] [-] subw00f|2 years ago|reply
[+] [-] Hamuko|2 years ago|reply
[+] [-] xcdzvyn|2 years ago|reply
[+] [-] alexellisuk|2 years ago|reply
Is this effectively very similar to Atuin?
https://github.com/atuinsh/atuin
[+] [-] blondin|2 years ago|reply
good luck to them on what comes next.
[+] [-] dinckelman|2 years ago|reply
[+] [-] mullingitover|2 years ago|reply
Beyond that, actual GH Copilot does a damn good job of crafting any CLI command that you can describe.
[+] [-] mavamaarten|2 years ago|reply
[+] [-] mirekrusin|2 years ago|reply
[+] [-] nerdjon|2 years ago|reply
The dropdown for autocomplete is far from necessary but a nice addition. Helping with completing commands that I don't use often but know the basics of like "aws s3 cp" is nice. But because of that I could just never justify spending money on it.
Hopefully it isn't abandoned, but maybe this will also mean they don't have to try to find artificial reasons (or bloat) to convince people to pay and can just focus on the core offering.
[+] [-] Alifatisk|2 years ago|reply
The telemetry part didn't bug me that much, but the product itself was cool, reminds me of warp.dev
Congratz on the acquisition.
[+] [-] skinkestek|2 years ago|reply
One of the most annoying thing is to learn about an interesting project by the post were they announce that they are aquihired, or even worse, closing down because of lack of interest.
[+] [-] pbmango|2 years ago|reply
[+] [-] desireco42|2 years ago|reply
Then you, in act of desperation, sell out and sell your users...
The issue is, people are already super skeptical when these startups start asking for things, this just makes them even harder to get users to trust you as a emerging company or product with data and usage.
[+] [-] hot_gril|2 years ago|reply
[+] [-] Robdel12|2 years ago|reply
Congrats to the team on the sale! Sadly, seems like it’s dead now. Happy they got paid :)
[+] [-] myth_drannon|2 years ago|reply
[+] [-] bastardoperator|2 years ago|reply