Live data from Hacker News

Google's Antigravity bait and switch

0xsid.com

351–360 of 369 posts

Re: Google's Antigravity bait and switch

#351
post #262

A bit off-topic, but I (as a non-native reader) find the "anti" in the name off-putting. Has it a special meaning beyond the (meta)physics or is Google just bad with naming?

I always thought it was a joke on the python xkcd: https://xkcd.com/353/ (Which, interestingly, also appears if you type “import antigravity” at the python repl).

Nice, thank you! Seems the most plausible explanation to me now that I know it :)

Re: Google's Antigravity bait and switch

#353

> The day was to begin like any other, with Antigravity open > This unexpected shift completely broke my preferred workflow it might not have been so unexpected if you knew you were one of ~15 people that start their day with Antigravity

> The day was to begin like any other, with Antigravity open (yes, there are tens of us!)

I think they know.

Re: Google's Antigravity bait and switch

#355

> The day was to begin like any other, with Antigravity open > This unexpected shift completely broke my preferred workflow it might not have been so unexpected if you knew you were one of ~15 people that start their day with Antigravity

> The day was to begin like any other, with Antigravity open (yes, there are tens of us!) I think they know.

don't think that was there when I read it the first time

Re: Google's Antigravity bait and switch

#356

"We should be able to trust that our tools will remain the tools we actually signed up to use." Yep... well that's what free software and open-source is for. You can't trust corporations so you MUST have the actual code. Harsh lesson but at least if something is learned and the mistake not repeated, that's OK.

OSS isn't sufficient. It must also be forkable by a small team. If the software grows complex enough, like Chromium, it doesn't really matter much if the code is open or not.

Re: Google's Antigravity bait and switch

#357

Earlier quoted context omitted.

Maybe I'm just a cranky old greybeard, but to me, the fact that these CLI tools are written in Node, React, etc. says a lot about the type of devs that are building them

Nobody is getting rewarded for reinventing the wheel.

I don't mind if they use nodejs for this, but the Ink/React stuff is annoying. It wastes space and even makes it hard to copy-paste. Wish it could open a few pipes for raw in/out as an alternative.

Re: Google's Antigravity bait and switch

#359
post #278

Earlier quoted context omitted.

Jetski/Antigravity is a better piece of software. The Gemini CLI codebase looks like someone tried to vibe-code a Claude code clone in nodeJS, as it's simply not maintainable. That being said, until recently Gemini CLI was better. It had support for persistent policies on what code could run without asking and had good extension hooks to allow you write extensions that influence policy (to perform complex logic like…

Maybe I'm just a cranky old greybeard, but to me, the fact that these CLI tools are written in Node, React, etc. says a lot about the type of devs that are building them

There's nothing wrong with writing CLI stuff in Node. It has interfaces to work with terminals built-in that aren't unlike what you'd find in any other language. I say this as someone who has worked with ncurses in C a decent amount (and there is a reason I try to avoid doing so anymore!)

React, however, I do find questionable, even having read about and understanding the idea behind Ink.

Re: Google's Antigravity bait and switch

#360

"We should be able to trust that our tools will remain the tools we actually signed up to use." Yep... well that's what free software and open-source is for. You can't trust corporations so you MUST have the actual code. Harsh lesson but at least if something is learned and the mistake not repeated, that's OK.

OSS isn't sufficient. It must also be forkable by a small team. If the software grows complex enough, like Chromium, it doesn't really matter much if the code is open or not.

I'm not sure, maybe the architecture itself is what matters. I'm thinking about the Linux kernel. Nobody, not even large companies, might be able to handle it, but each focuses on their own driver, some on specific parts, maybe it's manageable. So Chromium itself is too large but I'm not sure if the size of the team is the main criterium. There are other browsers (in fact I even have https://browser.engineering on my desk and I wrote my own toy browser) so I'm wondering what indeed makes a project manageable. Maybe its the expectations that make it impossible to handle and that it is used strategically, both in Android or Chromium, to make sure nobody else indeed can keep pace.
Post reply on HN