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

> Amazon has acquired Fig's technology!

That's a euphemism. These companies "acquire technology" in the same sense that revolutionaries acquired Louis XVI's head.

The telemetry was the exact reason I never tried it. It looked amazing, but wasn't keen on fig getting every one of my inputs

They give a timeline of a few weeks, so presumably we'll see soon enough.

Yeah, that is my expectation about its future as well. I really enjoyed using Fig for clear CLI introspection for many of my common workflows.

I am fully expecting that I'll have to go back to zsh-autosuggestions once the current iteration is fully wound down.

Isn't Fig open source? Now'd be the time for people to fork it while there's still the opportunity to do so if they find genuine value in the project.

My favorite 'acquihire' story is when Oracle bought out MySQL and the creator forked it and made MariaDB.

Yeah this is cloud9 all over again. Killing new registrations, eventually forcing existing users to migrate to AWS, for a worse product as a service.

Acquisitions are usually great for the shareholders, and usually bad for the employees and the customers.

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.

There's no need for a new terminal. Their homepage literally says "IDE-style autocomplete for your existing terminal".

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.

You may be thinking of Warp (https://www.warp.dev/)

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

Yeah I just stopped paying for Jetbrains to move 100% to VS Code just a few months ago

I was using both before but the upcoming annual payment reminded me that its over

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.

> Hopefully their product will continue to exist

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

He’s thrilled because it’s good for him, not for the users.

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

Is this in any way related to the fish shell or is this just a very unfortunate name?

Just curious, do you have any intent on adding local model support?

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.

Where is open source alternative?

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.

Probably not the entire team.

Check out this cool research from UC Berkeley!

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

I was trying to get it working and it seems like running `fig login` in the terminal and then restarting the app enables the terminal autocomplete!

There is a note: ``` Note: While we integrate with AWS, Fig is currently not accepting new sign ups ```

I had never heard about them, but for the life of me, I cannot imagine sufficient paying customers: it's zsh/fish, basically. Sharing the settings is not really a $12/month productivity boost. Acquihire sounds likely.

very likely this will become part of AWS CodeWhisperer. I wouldnt be surprised if MSFT or GOOG going after WARP for example to counter balance.

Seems like direnv and shell scripts in a shared git repo could be similar:

https://direnv.net/

There is a Linux and (I believe) a Windows binary of Fig available. You might need to hunt a bit to find it, at least, I needed to last year. Their Discord used to be the place for that info.

Given that they're shutting down registration, it probably doesn't.

You join a startup in hopes of it getting acquired or going public some day. Fig was never going to go public so if I worked there I’d be happy about the acquisition assuming that I wasn’t stiffed on my stock options when joining.

Acquihires generally get a better comp deal than hires, they just don't tend to make much off the acquisition deal unless they are high up. If their comp includes accelerated vesting rather than the terrible Amazon slowcoach vesting it could be decent.

I had some exploratory conversations with them last year.

The product was nice, but their business plan made zero sense to me, so I decided to not continue the process.

We usually change such titles to something like "$Acquirer aquires $Acquiree" and I've done that above now.

That wording implies an asset sale which is for anyone involved in or doing business with Fig a big difference. In that case existing ownership and obligations stay with the original entity (probably something like Fig Inc, Delaware corp), the whole team gets hired on at Amazon, Amazon buys the tech they want for some payment the Fig board signs off on, and then someone goes in to clean up and wind down Fig Inc. It's common when big companies buy much smaller companies because doing a full purchase can be a lot more complicated.

> That's possibly the most inefficient way of saying "AWS bought Fig" but I guess it makes some people happier to frame it that way

Often that kind of language is employed when the actual transaction was structured as an asset sale coupled with en-masse hiring of the team, rather than a true acquisition of the company as a complete entity, which is not an unusual scenario when a company is in distress.

This seem like perfect replacement of Amazon's cloud shell thing

If the arrangement involved both a tech purchase and a contractual obligation for employees to stay with AWS for a set period, simply saying "Fig was acquired" wouldn't be accurate. Given that Amazon is a publicly traded company, making such misleading statements is a no-go.

Amazon buying Fig doesn't imply the team joins AWS.

Yep. Unfortunately great for the founders and (hopefully) for the team, but my first thought is always "another one bites the dust". Here's hoping we're both wrong.

Based on their frontpage example videos, it seems to be for Mac users who don't know any better. I don't see anything useful that isn't FOSS already.

Wait till you learn about Raycast. https://www.raycast.com

I've heard a lot of good things about Raycast. I'm very tempted to jump ship from Alfred. Still hanging on.

I reckon scripts and secrets sharing within teams is the primary feature customers pay for.

No, its free, just some "advanced" features cost money

It does more than just autocomplete and it does it well.

nobody's forcing amazon to do anything they dont want to do lol

but it is true that this is a rare devtools startup acquisition by amazon. i cant think of many here (cloud9 was the last one i know, and that was 2016) but that could be due to my ignorance.

To spare someone else a research, it’s another term for ‘talent acquisition’ [0].

[0]: https://en.wikipedia.org/wiki/Acqui-hiring

In times of employers market it's less likely to see aquahires

No, presumably these employees will be based on dry land

maybe don't comment then?

It's a legit cool product that, among other things, lets you use natural language in the unix command line.

leetcode and reducing self-respect

1. Wrong thread.

2. IMHO: Be in the wrong place at the wrong time. I've never heard a happy story about Amazon that didn't involve a metric ton of Kool-Aid.

[flagged]