5 ms·

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

by make3 7y ago

akhilcacharya 7y ago
Weird flex, but ok. Is it true that there are dozens of internal language and DSLs? Why does G have so many?
- joatmon-snoo 7y ago
  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
saulrh 7y ago
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/basics/templates.md https://github.com/cuelang/cue/blob/master/doc/tutorial/basi...
- wstrange 7y ago
  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.
- madhadron 7y ago
  > 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.
- bt848 7y ago
  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.
justicezyx 7y ago
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.
- make3 7y ago
  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.
  - justicezyx 7y ago
    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...
- ithkuil 7y ago
  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.
  - justicezyx 7y ago

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

by make3 7y ago

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

akhilcacharya 7y ago

Weird flex, but ok. Is it true that there are dozens of internal language and DSLs? Why does G have so many?

joatmon-snoo 7y ago
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

saulrh 7y ago

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/basics/templates.md https://github.com/cuelang/cue/blob/master/doc/tutorial/basi...

wstrange 7y ago
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.
madhadron 7y ago
> 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.
bt848 7y ago
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.

justicezyx 7y ago

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.

make3 7y ago
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.
- justicezyx 7y ago
  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...
ithkuil 7y ago
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.
- justicezyx 7y ago