Hacker News Reader

Comment by make3 | Hacker News Reader

my time at Google has made me hate GCL so much.

I am pretty sure you placed the hate on the wrong target, you probable are hating borgcfg, instead of the GCL/BCL language.

Disclaimer: was borgcfg owner 2016-2019.

you are probably right. Felt like the documentation for borgcfg was extremely hard to just find. Maybe I'm wrong about this. This is also not the place to discuss this probably.

But GCL made it so whatever variable was actually being used by borgcfg was obscured by layers upon layers of imports.

well, if people testing their BCL, like what they do with c++, things will be better. But you know what, if they do that google officially will be a company built on BCL...

I had my own qualms with the language itself too. My team had very complex Borg configs, so complex they took more than a minute to evaluate. Luckily the GCL team at the time was working on a new interpreter (gclx? IIRC), which was indeed much faster (I wrote a mandelbrot PNG generator in pure GCL to prove the big speedup and convince my team that switching was worth the effort).

Unfortunately there was no formal spec of the GCL language, so the new impl was based IIRC on reverse engineering the spec from the first implementation of the interpreter. It turned out our configs hit several cases where the original behaviour was either unsound (and thus the new impl sacrificed backwards compat) or we hit a bug in the new impl.

The main problem with the language (as opposed as issues with the implementations) was that finding the root of those behaviour differences was very hard. It was very hard to follow where the variables came from. The GCL scoping rules (and lazy evaluation) were indeed very unfriendly for debugging.

This was an extreme case of a pain that was felt on a daily basis by a lot of people I've been talking to.

Talk to the borgcfg team, and let your organization's tech leaders know as well.

A few executives are not friendly to borgcfg. Their agenda, appeared to me, has been to deprive it's resources so it can die from rotting. That's bad engineering and totally unnecessary. A healthy BCL/borgcfg will die easier, because they'll allow an easier path migrating to something new.

I left the company half a decade ago. Just to be clear I actually loved borgcfg, just shared a war story. I'm happy to hear that the tooling improved. I'm unsurprised to hear that many still have mixed feelings towards GCL and ecosystem.

FWIW I'm the current maintainer of https://github.com/bitnami/kubecfg whose name is shameless xoogler bait.

I was going to say, this looks a lot like GCL. Dynamic scope, recursive lookup in parent scopes, templates [1], everything. GCL is neat and all, but I'd almost rather write my job configs by building thin python or lisp scripts to emit json or protos.

1: https://github.com/cuelang/cue/blob/master/doc/tutorial/basi...

AFAIK, cue is written by the author (or one of them?) of GCL, and purports to fix a lot of what is wrong with it.

> I'd almost rather write my job configs by building thin python or lisp scripts to emit json or protos

This is what Facebook does: Python emitting JSON.

Well, why don't you? Job configs in borg are protobufs. GCL can produce the required protocol message but so can any other language or tool. You could use Guile or whatever your heart desires.

Weird flex, but ok.

Is it true that there are dozens of internal language and DSLs? Why does G have so many?

1. use plain .textproto as your config

2. find a use case where you want a config with ~700 lines, most of it just a repeated variant of something

3. add more fields to your config to reduce the verbosity

4. realize that your configs are now obscenely complex, and build a limited-purpose DSL

5. five teams now use your limited-purpose DSL and make more feature requests

6. cry because you now maintain a DSL

7. ???

8. promo for cross-team impact

Reply on news.ycombinator.com