Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google Is 2B Lines of Code, All in One Place

wired.com

Post reply on HN
Print view View original

91–100 of 347 posts

Re: Google Is 2B Lines of Code, All in One Place

#91

Post by travelton »

comrh wrote: post #33
ChuckMcM wrote: post #17

I will say that I saw and experienced many things that changed my definition of 'large' at Google, but the most amazing was the source code control / code review / build system that kept it all together. The bad news was that it allowed people to say "I've just changed the API to to support the initiative, code released after this commit will need to be updated." and have that effect hundreds of projects, but at the…

> With the orb on their desk telling them at that their integration and unit tests were passing. Anymore info on this? Is it in house hardware?

I built something similar as a hack project... Closet dome light fixture turned upside down. Rip out the innards. Install RGB LED. Connect LED up to Arduino and pull information from an API. Adjust LED based on your conditions. I spent around $75, but that was years ago, probably far cheaper now.

Re: Google Is 2B Lines of Code, All in One Place

#92

Post by RogerL »

ChuckMcM wrote: post #17

I will say that I saw and experienced many things that changed my definition of 'large' at Google, but the most amazing was the source code control / code review / build system that kept it all together. The bad news was that it allowed people to say "I've just changed the API to to support the initiative, code released after this commit will need to be updated." and have that effect hundreds of projects, but at the…

Can you (or somebody) explain how that works in practice?

Here I am ready to deploy some new feature to gmail. In the meantime, I'm getting a steady stream of API changes. Can I build and release gmail to a specific revision number, and only incorporate the changes when I am ready, or are all release essentially off of the tip of the tree.

I don't need specifics, just the general idea. Where we work basically every project lives in its own branch, which makes it essentially impossible to synchonize changes. Things have to get merged to trunk, then pulled into the appropriate branch, and I don't like it at all.

Do you have version numbers for libraries/components: projext X uses version 1.5.4 of Y, 32.4.18 of Z, and so on, do you pull by revision number, are you all on tip?

It'd be very interesting to hear how you manage this.

Re: Google Is 2B Lines of Code, All in One Place

#93

Post by trollian »

devit wrote: post #22
ChuckMcM wrote: post #17

I will say that I saw and experienced many things that changed my definition of 'large' at Google, but the most amazing was the source code control / code review / build system that kept it all together. The bad news was that it allowed people to say "I've just changed the API to to support the initiative, code released after this commit will need to be updated." and have that effect hundreds of projects, but at the…

The solution to the excessive API change problem is to force whoever changes the API to fix all the consumers himself before the change is accepted. The Linux kernel generally uses this policy for internal APIs for example.

This makes it harder to change APIs. Which has advantages and disadvantages.

Re: Google Is 2B Lines of Code, All in One Place

#95

Post by Touche »

nevir wrote: post #90
dekhn wrote: post #81

I'm a google software engineer and it's nice to see this public article about our software control system. I think it has plusses and minuses, but one thing I'll say is that when you're in the coding flow, working on a single code base with thousands of engineers can be an intensely awesome experience. Part of my job- although it's not listed as a responsibility- is updating a few key scientific python packages. When…

Being able to make sweeping changes to a shared piece of code, and ensure that everyone's up to date (Hi, Rosie!) and not broken by your change (yay TAP train!) is phenomenal as well.

How is this a side effect of it being in the same repository/

Re: Google Is 2B Lines of Code, All in One Place

#96

Post by sp332 »

kazinator wrote: post #86

I am unable to believe that Google has 2B lines of original code written from scratch at Google. Maybe they are counting everything they use. Somewhere among those 2B lines is all the source code for Emacs, Bash, the Linux kernel, every single third-party lib used for any purpose, whether patched with Google modifications or not, every utility, and so on. Maybe this is a "Google Search two billion" rather than a conv…

Yes, that is counting everything. It's "the software needed to run all of Google’s Internet services" (so probably not Emacs, but the other stuff). But it's all in the repo, and it all has to be maintained.

Re: Google Is 2B Lines of Code, All in One Place

#97

Post by ksk »

Its interesting that they compare LoC with Windows. I suppose that this article wants us to be amazed at those numbers. However, my experience with Google's products indicates a gradual decline in performance and a simultaneous gradual increase in memory bloat (Maps, Gmail, Chrome, Android). Which ironically, FWIW, hasn't been the case with Windows. I have noticed zero difference in performance going from Windows 7 to 8 to 10.

Re: Google Is 2B Lines of Code, All in One Place

#98

Post by Touche »

durin42 wrote: post #89
sytse wrote: post #39

So a monolithic codebase makes it easier to make an organization wide change. Microservices make it easier to have people work and ship in independent teams. The interesting thing is that your can have have microservices with a monolithic codebase (as Google and Facebook are comprised of many services). But you can also have a monolithic service with many codebases (like our GitLab that uses 800+ gems that live in se…

Google has tons of services internally that talk via RPC. The monolithic repo means that it's much easier to hunt down and find people that are (say) using an outdated RPC method and help them fix their code. (Just one example of how it's useful even when things are mostly services.)

This discourages you from ever making breaking changes to an API. On the face of it that sounds good but sometimes you do have to make breaking changes. My guess is that there are many duplicate projects in the Google code base for when a breaking change is needed. This is a way to sidestep the problem.

Re: Google Is 2B Lines of Code, All in One Place

#99

Post by utexaspunk »

bluedino wrote: post #94
k33n wrote: post #4

Comparing "Google" to Windows isn't really a fair comparison. I'm sure all of the code that represents products that Microsoft has in the wild far exceeds 2B lines.

Windows, Office, things like .NET, other sites like MSN and Bing...

SQL Server has got to be a few lines...

Re: Google Is 2B Lines of Code, All in One Place

#100

Post by roxmon »

kazinator wrote: post #86

I am unable to believe that Google has 2B lines of original code written from scratch at Google. Maybe they are counting everything they use. Somewhere among those 2B lines is all the source code for Emacs, Bash, the Linux kernel, every single third-party lib used for any purpose, whether patched with Google modifications or not, every utility, and so on. Maybe this is a "Google Search two billion" rather than a conv…

Google has been around for 17 years and employees roughly 10,000+ software developers. I think it's reasonable to assume that the 2B LOC metric is accurate...
Post reply on HN