upvote

points

by varun_ch16 hours ago |
comments
upvoteby phoyd14 hours ago|
next
[-]
I am more shocked by the "overnight" aspect. I tried running clang-format on the Chromium source (68,281 .cc files, 21 million lines according to wc):

$ find chromium-149.0.7826.1/ -name ".cc" -exec cat {} + | wc 21640925 55715244 833460441

And that took less than 6 minutes on a single E5-2696 v3 from 2014:

$ time find chromium-149.0.7826.1/ -name *.cc | parallel -j 16 clang-format $x>/dev/null

real 0m5.666s user 1m13.964s sys 0m13.373s

That’s orders of magnitude faster, especially if we assume they’re not running their workloads on potatoes like mine. Is Ruby’s syntax really that much more complicated than C++, or is this a tooling problem?

reply
upvoteby deets8713 hours ago|
parent|
next
[-]
I don't think the post necessarily means it took multiple hours to format the codebase, I think they're probably just saying they worked on it off-hours and landed it while no one was working so that it didn't run into merge conflicts.
reply
upvoteby christophilus13 hours ago|
parent|
prev|
[-]
My guess would be tooling. I think the Ruby formatters are written in Ruby. I’d guess the clang one is written in C.
reply
upvoteby riffraff7 hours ago|
parent|
[-]
Nah the article says it's rust and calling into a C library for parsing.
reply
upvoteby bruckie15 hours ago|
prev|
next
[-]
Only 25 million? :) Google had billions a decade ago...

https://research.google/pubs/why-google-stores-billions-of-l...

reply
upvoteby Groxx14 hours ago|
parent|
[-]
iirc they also vendor(ed) many of their dependencies, several layers deep, which still counts for "stores" though it's rather different than "wrote" / "maintains".
reply
upvoteby bruckie9 hours ago|
parent|
[-]
Very true. It was still hundreds of millions of lines of first party code a decade ago, and could easily be over a billion at this point.
reply
upvoteby Groxx8 hours ago|
parent|
[-]
Yeah, I can definitely believe that Google would break over a billion handwritten. It's a big company that has been around for a long time.

It's still absurd. But believable.

reply
upvoteby jsnell16 hours ago|
prev|
next
[-]
Right, where is the rest of the code?
reply
upvoteby mr_mitm16 hours ago|
prev|
next
[-]
They're up to 42 million now, as per the article
reply
upvoteby lukan16 hours ago|
parent|
[-]
That sounds even more insane to me, but I guess most of that code does not really touch financial transactions, otherwise it would be a nightmare being responsible to verify that.
reply
upvoteby clintonb15 hours ago|
parent|
[-]
Ruby code touches financial transactions. Card payments were migrated to Java when I left in 2022. Non-card payments (e.g., ACH, checks, various wallets) were still processed by Ruby.

PCI-related/vaulting code lived in its own locked-down repo. I think that was a mix of Go and Ruby.

Once you have the foundations in place for account balances and the ledger, processing a payment isn’t that daunting. Those foundations, however, took a lot to build and evolve.

reply
upvoteby jamesfinlayson12 hours ago|
parent|
next
[-]
> Once you have the foundations in place for account balances and the ledger, processing a payment isn’t that daunting. Those foundations, however, took a lot to build and evolve.

Pretty much. I've worked at places with PHP payment processing that worked just fine, and at a place with C++ payment processing (and no testers) and it worked just fine. I wasn't around when the systems were first built though so not sure if there were tears along the way.

reply
upvoteby varun_ch13 hours ago|
parent|
prev|
[-]
> migrated to Java

I want to know more about this

reply
upvoteby deathanatos14 hours ago|
prev|
next
[-]
My (much smaller than Stripe) company is well over 4.5M at this point, and the graph is very much exponential.

AI has been a huge problem here: the amount of code is just exploding. Quality of the produced code is another matter.

reply
upvoteby Neywiny14 hours ago|
parent|
[-]
^^^^^^^^^^^^^^^^^^^

I recently wrote a very esoteric Python script. 100 lines of code. No classes, no functions, but yes argparse.

I've tried out the latest open source models on the task. They go bananas. It's like Enterprise fizzbuzz (https://github.com/enterprisequalitycoding/fizzbuzzenterpris...). They love classes and imports and reinventing the wheel. A great way for me to tell trash AI slop code is it'll define a useful constant then 15 lines later do it again with a different name.

They love making code that looks impressive. "Wow look at all the classes and functions. It's so scalable. It's so dynamic. It validates every minutae against multiple schema and solves a problem I never thought about." But it was trash code. One really was 400 lines and it didn't even look like it would work. Can't even imagine what it means for 4.5M moderately good human lines to become what? 27M fluffy filler repeat lines that don't even make sense?

reply
upvoteby manoDev13 hours ago|
parent|
[-]
The bad part of LLM is it got trained on bad examples because us humans also don't know WTF we're doing.
reply
upvoteby Neywiny11 hours ago|
parent|
[-]
Yeah maybe I need to do the old "you are a veteran engineer" nonsense. I've had some success telling it to implement everything it suggests and be production ready. I hate when it takes a shortcut and says I'll have to change it. That's kinda the whole point of me not writing the code...
reply
upvoteby e28eta8 hours ago|
prev|
next
[-]
Unless I’m mistaken, it’s a monorepo. So it’s not 25M LoC in a single app, it’s (all?) of their server-side code and shared libraries. There’s also a variety of other languages in use.

16 years and thousands of engineers write a lot of code.

reply
upvoteby il-b5 hours ago|
prev|
[-]
Imagine lots and lots of models and stubs generated from swagger, protobuf, sqlc etc.
reply