[senbrow]

Total nitpick, but:

Why would you name an option "disable_ai" with a default value of false instead of calling it "enable_ai" with a default value of true?

Are there some mechanical semantics I'm missing here that make this beneficial?

Negative booleans (ie that remove or suppress something when true) are generally a source of confusion and bugs and should be avoided like the plague in my experience.

[vouaobrasil]

Technically, "enable_ai" doesn't imply that all AI features are really turned off. Without context, it might imply that some basic AI features exist and "enable_ai" just enables further features. "disable_ai" is unambiguous.

[whilenot-dev]

Enable/disable are the only two dichotomies in the whole of all possible states regarding this AI feature, so I'll have to bite: What's your "Technically," referring to here?

[vouaobrasil]

First of all, enable/disable is a dichotomy, and is not a set of two dichotomies.

Second, imagine an editor that has AI running in the background, scanning your files. "Enable_AI" could just mean enable the visibility of the feature to actually use the results. On the other hand, it would sound more suspicious if there were some background AI tasks running, even for training purposes, if "disable_AI" were "True" as compared to "Enable_AI" to be false.

In other words, Enable_AI COULD have the connotation (to some) of just enabling the visibility of the feature, whereas Disable_AI gives more of a sense of shutting it off.

Imagine for example you're in a court of law. Which one sounds more damning?

======= Prosecutor: You still have AI tasks running in the background but AI_Enable is set to false?

Defendent: But Enable_AI just means enabling the use of the output! ====

==== Prosecutor: You still have AI tasks running in the background, but AI_Disable is TRUE?

Defendent: Uh.... ====

[bheadmaster]

> Enable_AI COULD have the connotation (to some) of just enabling the visibility of the feature, whereas Disable_AI gives more of a sense of shutting it off.

Personally, I don't feel much difference between the two. I doubt that an average reasonable person would either.

[vouaobrasil]

Well, I do feel a distinct connotational difference, but then again, I could be the only one I suppose. And if the average person doesn't care, then why argue about it at all? And how many average people will be using Zed anyway?

[bheadmaster]

> why argue about it at all

Because double negatives are confusing. Enable_AI = true is much clearer than Disable_AI = false.

[criddell]

I don't buy your argument.

> ==== Prosecutor: You still have AI tasks running in the background, but AI_Disable is TRUE?

Defendent: But Disable_AI just means disabling the use of the output

[vouaobrasil]

Well, I guess we'll see then. Or not.

[whilenot-dev]

======= Prosecutor: You still have AI tasks running in the background but AI_Disable is set to true?

Defendent: But Disable_AI just means disabling the use of the output! ====

==== Prosecutor: You still have AI tasks running in the background, but AI_Enable is FALSE?

Defendent: Uh.... ====

...it cuts both ways, sorry.

[vouaobrasil]

Perhaps. I could be the only one that senses a difference, but for those that hate AI like I do, "disable" sounds better than "enable".

[anttiharju]

My pet peeve is CGO_ENABLED compiler option in Go. It's set to 0 or 1 to enable/disable (can never remember which mapa to which)

If it was just CGO=true or CGO=false I think so much confusion could have been avoided.

I think similar thinking applies here. It's convoluted to disable something by setting ai_disable=true because I read it like: setting false true instead of just setting boolean.

[oreilles]

> It's set to 0 or 1 to enable/disable (can never remember which mapa to which)

That's crazy. Boolean logic is the most fundamental notion of computer science, I can still remember learning that in my very first course on my very first year.

[anttiharju]

I've no issues with boolean logic (&&, ||) but unfortunately all my schooling has done those with the notion of true/false instead of bits iirc.

[scbrg]

This follows a convention that was well established and felt pretty ancient when I learned about environment variables in the nineties (i.e. 30 years ago). Variables that are flags enabling/disabling something use 1 to enable, and 0 to disable. I'd not be surprised if this has been pretty much standard behavior since the seventies.

This is not unique to Go.

[whilenot-dev]

I always thought that an unset boolean env var should define the default behavior for a production environment and any of these set with a value of length>0 will flip it (AUTH_DISABLED, MOCK_ENABLED, etc.). I thought env vars are always considered optional by convention.

[anttiharju]

At least in the case of cgo_enabled it does define the default behaviour

[anttiharju]

I don't doubt any of that but why stick to such old conventions when there are explicit and immediately clear options?

I don't think me writing an if condition

if boolean != true

instead of

if boolean == false

should pass code review. I don't think my pet peeve is necessarily different from that. I understand there's a historical convention but I don't think there's any real reason for having to stick to it.

Hell, some of the other compiler options are flags with no 0 or 1, why could this not have been --static or any flag? I'm genuinely curious.

Moreover, 0 here maps to false but in program exit codes it maps to success which in my mind maps to true but then we have this discrepancy so it does not appear to be the right mental model.

[kjksf]

It makes sense, historically.

They had AI features that were always on.

Some people complained so they introduced a flag to, wait for it, disable the ai features.

So they didn't think too deeply about it and named the flag "disable_ai" because it mapped into how they were thinking about it.

You overstate the problem with negative booleans. It's trivial for them to add a function:

  fn isAiEnabled() { return !disable_ai }

and just use that.

[andoando]

I mean you may equally want

if(disable_ai) { //disable shit }

[elicash]

They are trying to communicate that disabling AI is a product feature to some customers.

I think it's reasonable to, for example, have a field that is labeled "Do Not Track".

[comprev]

The wording implies that disabling a default feature is used by a handful of edge cases and Zed has done their best to accommodate these users.

From a business perspective, investors want to hear that AI is indeed part of the shipped product.

It's all about optics.

"disable_user_tracking: false" vs "enable_user_tracking: true"

"disable_adverts: false" vs "enable_adverts: true"

Fewer people would actively _enable_ user tracking or adverts compared to those who would take extra steps to _disable_ them.

[wanderingstan]

I concur. Same thing in many UI frameworks where you’ll have a Boolean “isHidden” to control visibility. Makes it so hard to reason about.

[Rexxar]

IMHO, in this case it should not even be a boolean but an enum {Visible, Hidden}.

[roguecoder]

Even with working with an existing framework, we can define a constant `HIDDEN=true`

[jeffbee]

IMHO flags like this should always reflect the planned steady state. If you plan for a feature to be on in general, then the flag should be a disabling flag that eventually goes away.

[nlitened]

It's good and predictable that all boolean settings to be false by default (when not set). And the default behavior is the one that is compatible with older version — changing the defaults is a breaking change that should usually be avoided.

[zzo38computer]

Yes, this is especially useful if the boolean settings are stored in a bit field, in my opinion. In the case of Zed, according to the article, it uses JSON, but if a program uses a bit field instead then it would make sense.

[echelon]

I think AI-enabled is going to be the default for all future code development. Autocomplete is just so good, and I never want to go back.

I spent 20 years without it. That's enough for one lifetime.

[cardanome]

How long did it take for you to get used to the autocomplete?

I completely hated it when I tried it out. It breaks my flow. Those weird pauses are so painful. Feels like someone grabbing the steering wheel while I am driving.

I heavily use the agent mode but I don't understand the appeal of the autocomplete feature but maybe I am missing something.

[roguecoder]

You spent 20 years without autocomplete? I started using Eclipse's autocomplete & shortcut macros in 2002.

It is fascinating to me how much of the enthusiasm around AI seems to be the result of people not knowing about/using the deterministic tools that already exist.

[echelon]

That's not at all the same.

AI autocomplete can generate the entire `match` tree for a very complex Rust enum, and also generate all of the associated tests. It then takes me to the next places in the code where changes need to be made. It's wildly good at knowing exactly what I want to do next.

2002 macros and autocomplete were not that and cannot possibly be compared in the same light.