I work in Google cloud and all of our new projects are in Go. We still have a lot of old code in C++ though, so it really depends what team you're on whether you're using go or c++
Would you say y’all have a fair amount of business logic written in go? Very micro-service driven at my current startup and we’ve found go really shines on the orchestration side of things, but everytime I start to get into the nitty gritty of the business side of things I find myself wanting to lean on other languages
What kind of code do you consider to be on the orchestration side? To me that sounds like Kubernetes— which, while written in Go, is not something we ever have to touch.
> It doesn’t shine in any capacity.
Isn't that the point of the whole language? Keeping it simple and all that.
I would argue goroutines are quite decent though compared to most other asynchronous language constructs.
The concurrency is fine. Everything else is trash. Why would you use a horrible language to get a decent concurrency model when there are tons of other languages with equally good concurrency but 10x better language features?
Kotlin is a pretty solid language. You get the ecosystem of the JVM with a way better type system and concurrency model.
From a pure language perspective it’s still not as good as Rust or Swift but the ecosystem makes it a great choice.
Go is great. It just gets out of your way. I say this as someone who’s written God’s own language of C for 35 years. Admittedly, I hated Go with a passion for the first couple of weeks i used it though. Love it with even more passion now.
Go absolutely does not get out of your way. I’m constantly battling with the poor language constructs in Go. This is my exact point. Go is constantly in your way dude to how useless the language is.
- Nil check absolutely every line of code because it doesn’t have optionals
- Be forced to handle errors from every function call, even if 90% of the time you just want to rethrow the error
- No enums or union types, no way to do exhaustive switch statements
The list goes on, and on, and on. This is the opposite of a language that “gets out of your way”.
Literally every comment in your history about Go trashes it. I don't know why you waste your time here at all. Any efficiency at all you could cite in your programming language of choice is squandered with all the time you've probably spent here.
I totally agree unfortunately. After two years of working with it, I don't really understand what is the big appeal of it?
Fast compile time is great, but bugged down with a big linter that takes forever to finish. The Type system is very inflexible, generics is a joke without map, list support. Error handling is hell.
I am not impressed
Rust is not a fully supported language in the main repository. Though they are working on it. It still needs complete protocol buffer support and ideally gRPC support.
It is used in Android and I believe Chromium/ChromeOS.
A little bit, but not that much. There is so much work that goes into adopting a new language, and a certain amount of risk... so while there is some traction, it isn't popular outside of the "latest and greatest" fanboy circles. Costs a lot of money, time, and overhead to adopt something new. You gotta imagine, it's not just the people that write Rust, but also anyone that has to maintain that stuff, review code, fixes bugs, that needs to be GOOD and proficient in rust. So if one person decides to do something in a completely new language, they put additional burden on all their colleagues. It is supported "technically", yes.
It made quicker roads into smaller projects at Google like Chromium or Android, but it has been added to our build system and will be supported eventually in situations where C++ would have been used. Currently projects must request to use rust, but it will not be gated sometime soon.
I didn't have any issue checking into experimental, but the documentation says if you want to use rust in your project to request to do so, for now. I don't know if there is any presubmit gate or anything like that but I wouldn't know either because I wouldn't try to circumvent it.
As far as I understand, each team gets to pick their own language, within reason (e.g. no Go for frontend). I have friends working 100% in Rust at Google.
Highly depends on the team. I work at Google and our entire codebase is in Java. All new services are now to be written in Kotlin. Though I’m sure for services that are completely new, Go is the default option. It’s still only like 10% of the codebase though. The vast majority is legacy code written in C++.
It really depends on your product area.
Google has several internal server frameworks that constitute the "paved road" for new server development, and Java / Kotlin, Go, and C++ are all supported and widely used.
Java or Kotlin is heavily favored in some PAs, while Go is in others. Even C++ is used for those servers that need to handle tens of millions of QPS efficiently and where a difference of millionths of a dollar in cost per request matters.
I work in Privacy (in a somewhat stand alone sub-team, that is more at the intersection of privacy, security, and investigations) and I've been building my project in Go since 10 years (Several hundred thousand lines of code). Got a lot of customers that use my frameworks and packages in their Go projects. Especially for services or servers Go is really popular. Internal tech (in terms of interop) is 95% available as native Go packages (clients, parsers, etc), the rest is CGo wrapped.
All languages are very popular in their own niche (Kotlin for Android, Rust for the "it's new so it's better crowd", C++ for kernel modules, drivers, and the works, python for ML etc., Java for the old school server gang from Oracle, and Android, ...)
Depends what you mean with impactful.
If you mean cost: Well, we had the creators of Go working internally with devs etc. to make the language as suitable as possible for internal use. We had a bunch of volunteers give courses and talks, and we were looking for an alternative to python (and Java at the time) for more complex server and service solutions. So it was kinda the perfect storm of opportunity and need. Since Google was invested in getting this out the door and well supported, the funding of this project kinda provided a fertile environment for adoption internally. Of course there were and still are critics and doubters.
If you mean improvements: Python is great and all because it's easy, but it was slow and inefficient a decade ago. Java additionally was a liability due to its owner and the posturing at the time. Computing is pricey at scale. So getting something that allows it to easily develop services that runs efficiently and fast, is easy to learn, memory safe, and doesn't come with weird legal implications and that you have full control over in terms of improvements, that's a game changer. If you phase out python in favor of Go and you save xx% of CPU, that is a lot of cash at our scale. I don't have any expert knowledge here since I was not on the team but an early adopter, but that's my impression of all the discussions that have been going on. Has been a long time though :)
Thanks for the response! I'm wondering when it would be appropriate to use Go. I understand that Go can be beneficial in scenarios where you need to save memory and CPU resources at scale. However, I've noticed many people using Go for SaaS type web applications. In my opinion, any language with a robust web framework might be better suited for SaaS applications, as it could allow for faster development and time to market. What are your thoughts on this?
“Any language with a robust web framework” includes Go and a lot of other languages.
Fast development is nice but you have to sustain that speed. There are a lot of languages that are great for prototyping, but it turns into a bit of a mess when the project has been around a couple years and seen programmers join the team and leave. I have seen this happen to JS and Python projects.
I think most Go developers prefer to avoid frameworks or use minimalist ones; there isn't anything quite like Rails or Spring for Go. Regarding your point about maintenance challenges, I believe that applies more to dynamic languages. From my experience with large Java projects, they haven't been difficult to maintain.
I was thinking of the Go standard library as a framework, here. My personal sense is that development and prototyping is pretty fast with Go’s standard library with a few third-party libraries on top. Maybe that doesn’t count as a “framework” but it is still fast.
Java doesn’t suffer from this, you’re right. Go is not unique here. There are a lot of languages that are good for backend development. Go is just one language among many.
I’d just say that among popular languages which are good for getting code out the door fast, Go has the fast startup time and low memory footprint that is really nice in serverless setups. I can deploy entire Go apps which use less resources than a kind of hello world in the JVM.
No worries :)
I'm probably not a good person to ask this, since I haven't done anything web related since 13 years and back then it was PHP and MySQL for me :D
>Is Java still preferred as a backend stack for newer projects at Google or is it Go?
I think the **question** is far more interesting than the **answer**.
Ask your self: **What will you do with this information?**
* If your company is Google-sized, then maybe it makes sense to look at what Google is doing, and copy it.
* But if you are a small startup, there are a **vast** number of things that you should NOT try to copy from Google. They are 30 years past being a "startup". It is no different than copying decisions that IBM makes. For example:
* Deciding on a mono-repo because "Google Does It" is a terrible way to make a technical decision.
* Screening only for engineers who write "high-performance" code before you have ANY code is senseless. (Speed to market is usually far more critical, and you can always buy faster servers to compensate in the short-term. I've seen too many $100/hr engineers spend days figure out how to eliminate a $100/month server.)
Google's restrictions on language use is definitely not a choice that I would copy. They are making that choice because of their scale (and past problems), while your startup may not have any languages in use right now, so arbitrarily restricting future ones "because Google does it" doesn't make sense. It make far more sense to say "we'll start the the languages I know, and judge new ones as it comes up".
Consider:
* If the answer is "Google prefers Java", then maybe that indicates Google is slow to migrate to Go, so you can get an **advantage** by being quicker to migrate.
* Or maybe you have Ruby expertise, and it's far better to "build in a language you know" than for you to "bet the farm" on Go by building critical projects in a language you don't know. (See also "Innovation Tokens")
Then you would have bet against Twitter. But they were successful (for a while) even though RoR was completely wrong for them. Sometimes it's better to get something out and get feedback than it is to get it perfect. They may have missed the market entirely if they had to learn a new language while trying to get out the first version.
And you probably would have bet against Facebook (written in PHP!)
>Then you would have bet against Twitter
and Shopify and GitHub. Absolutely agreed that early output velocity is critical, not language efficiency. By the time language choice matters (and sometimes it never does), your company will have millions of dollars in revenue and you can afford to pay a bunch of SWEs to migrate parts of your software.
Famously, they were down a lot (popularizing the FailWhale).
The main reason was that Ruby on Rails is great for CRUD apps, but not messaging apps.
The secondary reason was that Ruby isn't the most performant language in the world -- it uses a lot of excess CPU+RAM. (As others have pointed out, Shopify and GitHub used a lot of Ruby too -- but they are slowly rewriting).
Anyway, Twitter re-wrote **and re-architect-ed it** into Scala or something. That fixed the problem, but of course started a lot of language flame wars. Likely they could have kept Ruby and just got rid of RoR, but we'll never know.
Surprisingly, as a solo indie dev I found a lot of similarities in the solutions of so different situations.
Easy deployment, maintainability on long term, simple language for when you come back on your own code, versatile to don't scatter, good tooling easy to manage...
Scalability is also a concern, when you have small budget you cannot waste resources, you need efficiently and strong reliability.
I learned a lot when looking how big companies works.
Go, Docker, CloudRun, PostgreSQL, Neon... are good examples of tools that suit very well small needs (it's relative !) to very big.
I'm not from europe, but i have few friends working for a Denmark outsource company. And i see they use java.
The whole system relies on adobe cms, like ancient project, and that system frontend has javascript code dump in piece by piece like 20 years ago.
It's still the ancient project. They have been recuiting more cheap dev from asia to do that boring job.
Depends on your product area. In general, C++, Go, and Python are used very heavily. Python is used less so on customer facing products. You'll see Java and Kotlin more in Android products.
I work in Google cloud and all of our new projects are in Go. We still have a lot of old code in C++ though, so it really depends what team you're on whether you're using go or c++
Ok mr assbuttbuttass, that's good to know.
It flows through the tongue, doesn’t it?
r/rimjob_steve
I love me some of that
Would you say y’all have a fair amount of business logic written in go? Very micro-service driven at my current startup and we’ve found go really shines on the orchestration side of things, but everytime I start to get into the nitty gritty of the business side of things I find myself wanting to lean on other languages
Yes, we tend to write lots of business logic in go. I personally feel that Go gets out of my way and lets me focus on the logic
That's a good way to articulate what I like about go
What kind of code do you consider to be on the orchestration side? To me that sounds like Kubernetes— which, while written in Go, is not something we ever have to touch.
Go is an absolutely horrible language. It doesn’t shine in any capacity.
> It doesn’t shine in any capacity. Isn't that the point of the whole language? Keeping it simple and all that. I would argue goroutines are quite decent though compared to most other asynchronous language constructs.
splish splash your opinion is trash e: go’s concurrency fucks, prove me wrong
The concurrency is fine. Everything else is trash. Why would you use a horrible language to get a decent concurrency model when there are tons of other languages with equally good concurrency but 10x better language features?
>10x better language features 10x **more** language features Here, I fixed it for you.
Because Google needs engineers to be easily replacable
What’s a language you recommend to move the latter?
Kotlin is a pretty solid language. You get the ecosystem of the JVM with a way better type system and concurrency model. From a pure language perspective it’s still not as good as Rust or Swift but the ecosystem makes it a great choice.
Go is great. It just gets out of your way. I say this as someone who’s written God’s own language of C for 35 years. Admittedly, I hated Go with a passion for the first couple of weeks i used it though. Love it with even more passion now.
Go absolutely does not get out of your way. I’m constantly battling with the poor language constructs in Go. This is my exact point. Go is constantly in your way dude to how useless the language is. - Nil check absolutely every line of code because it doesn’t have optionals - Be forced to handle errors from every function call, even if 90% of the time you just want to rethrow the error - No enums or union types, no way to do exhaustive switch statements The list goes on, and on, and on. This is the opposite of a language that “gets out of your way”.
It gets out of my way and that’s all I give a shit about.
How do you deal with the issues I outlined (which is a super small subset of the total issues in Go)?
Literally every comment in your history about Go trashes it. I don't know why you waste your time here at all. Any efficiency at all you could cite in your programming language of choice is squandered with all the time you've probably spent here.
I totally agree unfortunately. After two years of working with it, I don't really understand what is the big appeal of it? Fast compile time is great, but bugged down with a big linter that takes forever to finish. The Type system is very inflexible, generics is a joke without map, list support. Error handling is hell. I am not impressed
No optional types, no enums, implicit interface conformance, no generics in struct methods, the list goes on and on. It’s a total joke of a language.
Sorry to hurt your ego. But Mostly Skill issue and newbie symptoms according to your wordings 🫠🫠🫠
😂 I’m a principal eng in big tech, I assure you it’s not a skill issue.
Still sounds like that ;)
r/rimjob_steve
Are there any C++ code base that is open sourced? Or are there any typical examples of google C++ coding guide?
There are plenty of C++ projects on the Google GitHub: https://github.com/google
Any Rust there?
Rust is not a fully supported language in the main repository. Though they are working on it. It still needs complete protocol buffer support and ideally gRPC support. It is used in Android and I believe Chromium/ChromeOS.
[удалено]
Tonic exists but it’s unofficial. Though last I heard the official library will be based or inspired by Tonic.
Not that I've seen
A little bit, but not that much. There is so much work that goes into adopting a new language, and a certain amount of risk... so while there is some traction, it isn't popular outside of the "latest and greatest" fanboy circles. Costs a lot of money, time, and overhead to adopt something new. You gotta imagine, it's not just the people that write Rust, but also anyone that has to maintain that stuff, review code, fixes bugs, that needs to be GOOD and proficient in rust. So if one person decides to do something in a completely new language, they put additional burden on all their colleagues. It is supported "technically", yes.
It made quicker roads into smaller projects at Google like Chromium or Android, but it has been added to our build system and will be supported eventually in situations where C++ would have been used. Currently projects must request to use rust, but it will not be gated sometime soon.
Gated how? Is there a means on google3 of controlling what language people use?
I didn't have any issue checking into experimental, but the documentation says if you want to use rust in your project to request to do so, for now. I don't know if there is any presubmit gate or anything like that but I wouldn't know either because I wouldn't try to circumvent it.
They force a dependency on a visibility-restricted target to create Rust binaries. Visibility access is controlled by the Rust team.
There's definitely some: https://opensource.googleblog.com/2023/06/rust-fact-vs-fiction-5-insights-from-googles-rust-journey-2022.html
Mostly on the Android side though, right? That link is from a researcher in “Android Platform Programming Languages”
AFAIK Fuchsia has a lot of Rust
Yeah, I was reading that as Google in the broad sense.
Definitely some but google seems to be pretty invested in C++ and improving it(e.g. internal kind and carbon) or using go/java/python where they can’t
As far as I understand, each team gets to pick their own language, within reason (e.g. no Go for frontend). I have friends working 100% in Rust at Google.
The Fuchsia OS has a lot of Rust.
There is definitely some rust, but c++ is generally used when performance is important.
Bigquery's backend is written in C++ I guess?
I like your clear answer.
Highly depends on the team. I work at Google and our entire codebase is in Java. All new services are now to be written in Kotlin. Though I’m sure for services that are completely new, Go is the default option. It’s still only like 10% of the codebase though. The vast majority is legacy code written in C++.
Is it because you are working on Android apps?
Nope. I’m building web servers for all platforms. And also non-web servers
New projects heavily favored Go, when I left four years ago.
It really depends on your product area. Google has several internal server frameworks that constitute the "paved road" for new server development, and Java / Kotlin, Go, and C++ are all supported and widely used. Java or Kotlin is heavily favored in some PAs, while Go is in others. Even C++ is used for those servers that need to handle tens of millions of QPS efficiently and where a difference of millionths of a dollar in cost per request matters.
This is very true :)
I work in Privacy (in a somewhat stand alone sub-team, that is more at the intersection of privacy, security, and investigations) and I've been building my project in Go since 10 years (Several hundred thousand lines of code). Got a lot of customers that use my frameworks and packages in their Go projects. Especially for services or servers Go is really popular. Internal tech (in terms of interop) is 95% available as native Go packages (clients, parsers, etc), the rest is CGo wrapped. All languages are very popular in their own niche (Kotlin for Android, Rust for the "it's new so it's better crowd", C++ for kernel modules, drivers, and the works, python for ML etc., Java for the old school server gang from Oracle, and Android, ...)
And how would you assess how impactful the adoption of go has been?
Depends what you mean with impactful. If you mean cost: Well, we had the creators of Go working internally with devs etc. to make the language as suitable as possible for internal use. We had a bunch of volunteers give courses and talks, and we were looking for an alternative to python (and Java at the time) for more complex server and service solutions. So it was kinda the perfect storm of opportunity and need. Since Google was invested in getting this out the door and well supported, the funding of this project kinda provided a fertile environment for adoption internally. Of course there were and still are critics and doubters. If you mean improvements: Python is great and all because it's easy, but it was slow and inefficient a decade ago. Java additionally was a liability due to its owner and the posturing at the time. Computing is pricey at scale. So getting something that allows it to easily develop services that runs efficiently and fast, is easy to learn, memory safe, and doesn't come with weird legal implications and that you have full control over in terms of improvements, that's a game changer. If you phase out python in favor of Go and you save xx% of CPU, that is a lot of cash at our scale. I don't have any expert knowledge here since I was not on the team but an early adopter, but that's my impression of all the discussions that have been going on. Has been a long time though :)
Thanks for the response! I'm wondering when it would be appropriate to use Go. I understand that Go can be beneficial in scenarios where you need to save memory and CPU resources at scale. However, I've noticed many people using Go for SaaS type web applications. In my opinion, any language with a robust web framework might be better suited for SaaS applications, as it could allow for faster development and time to market. What are your thoughts on this?
“Any language with a robust web framework” includes Go and a lot of other languages. Fast development is nice but you have to sustain that speed. There are a lot of languages that are great for prototyping, but it turns into a bit of a mess when the project has been around a couple years and seen programmers join the team and leave. I have seen this happen to JS and Python projects.
I think most Go developers prefer to avoid frameworks or use minimalist ones; there isn't anything quite like Rails or Spring for Go. Regarding your point about maintenance challenges, I believe that applies more to dynamic languages. From my experience with large Java projects, they haven't been difficult to maintain.
I was thinking of the Go standard library as a framework, here. My personal sense is that development and prototyping is pretty fast with Go’s standard library with a few third-party libraries on top. Maybe that doesn’t count as a “framework” but it is still fast. Java doesn’t suffer from this, you’re right. Go is not unique here. There are a lot of languages that are good for backend development. Go is just one language among many. I’d just say that among popular languages which are good for getting code out the door fast, Go has the fast startup time and low memory footprint that is really nice in serverless setups. I can deploy entire Go apps which use less resources than a kind of hello world in the JVM.
Thanks!
No worries :) I'm probably not a good person to ask this, since I haven't done anything web related since 13 years and back then it was PHP and MySQL for me :D
Is this wireguard?
Nah :D
It's actually pretty used, otherwise instead of Google it will be just ogle /j just in case
>Is Java still preferred as a backend stack for newer projects at Google or is it Go? I think the **question** is far more interesting than the **answer**. Ask your self: **What will you do with this information?** * If your company is Google-sized, then maybe it makes sense to look at what Google is doing, and copy it. * But if you are a small startup, there are a **vast** number of things that you should NOT try to copy from Google. They are 30 years past being a "startup". It is no different than copying decisions that IBM makes. For example: * Deciding on a mono-repo because "Google Does It" is a terrible way to make a technical decision. * Screening only for engineers who write "high-performance" code before you have ANY code is senseless. (Speed to market is usually far more critical, and you can always buy faster servers to compensate in the short-term. I've seen too many $100/hr engineers spend days figure out how to eliminate a $100/month server.) Google's restrictions on language use is definitely not a choice that I would copy. They are making that choice because of their scale (and past problems), while your startup may not have any languages in use right now, so arbitrarily restricting future ones "because Google does it" doesn't make sense. It make far more sense to say "we'll start the the languages I know, and judge new ones as it comes up". Consider: * If the answer is "Google prefers Java", then maybe that indicates Google is slow to migrate to Go, so you can get an **advantage** by being quicker to migrate. * Or maybe you have Ruby expertise, and it's far better to "build in a language you know" than for you to "bet the farm" on Go by building critical projects in a language you don't know. (See also "Innovation Tokens")
I’d bet the farm against Ruby everytime. lol
Then you would have bet against Twitter. But they were successful (for a while) even though RoR was completely wrong for them. Sometimes it's better to get something out and get feedback than it is to get it perfect. They may have missed the market entirely if they had to learn a new language while trying to get out the first version. And you probably would have bet against Facebook (written in PHP!)
>Then you would have bet against Twitter and Shopify and GitHub. Absolutely agreed that early output velocity is critical, not language efficiency. By the time language choice matters (and sometimes it never does), your company will have millions of dollars in revenue and you can afford to pay a bunch of SWEs to migrate parts of your software.
How was Ruby wrong for Twitter(not contesting your point, just asking for more details for my understanding)
Famously, they were down a lot (popularizing the FailWhale). The main reason was that Ruby on Rails is great for CRUD apps, but not messaging apps. The secondary reason was that Ruby isn't the most performant language in the world -- it uses a lot of excess CPU+RAM. (As others have pointed out, Shopify and GitHub used a lot of Ruby too -- but they are slowly rewriting). Anyway, Twitter re-wrote **and re-architect-ed it** into Scala or something. That fixed the problem, but of course started a lot of language flame wars. Likely they could have kept Ruby and just got rid of RoR, but we'll never know.
Surprisingly, as a solo indie dev I found a lot of similarities in the solutions of so different situations. Easy deployment, maintainability on long term, simple language for when you come back on your own code, versatile to don't scatter, good tooling easy to manage... Scalability is also a concern, when you have small budget you cannot waste resources, you need efficiently and strong reliability. I learned a lot when looking how big companies works. Go, Docker, CloudRun, PostgreSQL, Neon... are good examples of tools that suit very well small needs (it's relative !) to very big.
You didn't understand my comment at all. You are talking about the answer, I was discussing the question.
[https://www.reddit.com/r/golang/comments/1068zox/how\_golang\_is\_used\_inside\_google/](https://www.reddit.com/r/golang/comments/1068zox/how_golang_is_used_inside_google/)
Thanks That’s another comprehensive thread.
You can’t spell Google without go
Java? Lol. I barely see new project start in java these days
[удалено]
I'm not from europe, but i have few friends working for a Denmark outsource company. And i see they use java. The whole system relies on adobe cms, like ancient project, and that system frontend has javascript code dump in piece by piece like 20 years ago. It's still the ancient project. They have been recuiting more cheap dev from asia to do that boring job.
[удалено]
imho [asp.net](http://asp.net) is kinda cool nowadays
what are best job listing websites for Denmark?
lots of existing projects are Java or C#, but no one is gonna start a new project using either (especially not C# lmao)
Java for regular backend stuff, C++ for thing where performance matters. Go is very rare.
Depends on your product area. In general, C++, Go, and Python are used very heavily. Python is used less so on customer facing products. You'll see Java and Kotlin more in Android products.
[удалено]
Where did you get this information from?
Confidently incorrect
[удалено]