This very much feels like a random marketing post.
We’re working on making Go better for AI—and AI better for Go—by enhancing Go’s capabilities in AI infrastructure, applications, and developer assistance. Go is a great language for building production systems, and we want it to be a great language for building production AI systems, too. Go’s dependability as a language for Cloud infrastructure has made it a natural choice for LLM infrastructure as well. For AI applications, we will continue building out first-class support for Go in popular AI SDKs, including LangChainGo and Genkit. And from its very beginning, Go aimed to improve the end-to-end software engineering process, so naturally we’re looking at bringing the latest tools and techniques from AI to bear on reducing developer toil, leaving more time for the fun stuff—like actually programming!
The link behind production systems essentially boils down to Go being able to make HTTP Requests to some API endpoints.
And:
It’s dependability as a language for Cloud infrastructure has made it a natural choice for LLM infrastructure as well
What does that even mean? That you can run Go in a cloud? That kubernetes and terraform are in Go?
I get it, it’s a birthday blog post, but this feels s all like pure marketing blog.
Maybe it’s just bugging me because the blog used to have interesting bits for beginner and more advanced programmers.
Still a fan of Gon but I really miss their no-monsense stuff that originally made me curious about the language.
Go is a Google project, and Google is all in on AI. The person responsible for this blog post/press release no doubt has reams of internal guidance about how AI must now be mentioned in every Google product. I wouldn’t read too much into it.
The funny thing is that if you say go is a google project you will be told “oh no, it is not controlled by google. community blablabla”, yet this blogpost shows who is really calling the shots.
I’m not sure who would ever say that. It’s totally a Google project. All CLs must be approved by someone at Google, ostensibly for supply chain security reasons, but still. Maybe in the early days, there was a question of if it would become a community project someday, but it’s been clearly a Google joint throughout, since they never made a foundation to run it, which is the minimum to be considered not just a corporate project.
At least they let him put it in the end. If you read this paragraph and compare it with the others, you’ll notice it’s the only one that has literally zero content
It’s just that paragraph really; I had a bit of reader’s whiplash when I reached it and up to that point I found the post to be an informative overview of where they’ve been putting their energy recently. It doesn’t really make sense to say Go is good for AI more than it makes sense to say C is good for AI. As sibling says, clearly somebody was forced to jam it in.
I thoroughly enjoy working with Go. With the tooling, package management, channels, stdlib, and single binary to name a few, it really is hard to beat.
I sort of agree, but as far as mainstream languages go, it’s really nice to be able to tell at a glance what the program actually does and not have to worry about the spooky-action-at-a-distance stuff that I have to contend with in more ✨magical✨ languages. It’s definitely a boring language, but I think that’s a good thing.
My thoughts (almost-)exactly. The language is missing some really key stuff[0], and the verbose error handling is already well-trodden ground, but the built-in formatter is pretty nice.
Package management, though? I must be missing something. People like depending on GitHub repositories (rather than built binaries) as the source-of-truth for building? I will never forgive GoLang for the number of special-cases we’ve had to build into our CI flows because it has special snowflake authentication needs.
[0] which Gophers would probably call a benefit, because it makes the language simpler and thus easier to read. Though I really think that optional parameters, .map/.filter/.reduce, and an in-place slice.append would be net positives - the language could remain “boring” (a desirable quality!) while greatly increasing concision and flexibility. But I digress…
I will never forgive GoLang for the number of special-cases we’ve had to build into our CI flows because it has special snowflake authentication needs.
We’ve been using a script I wrote that just locally checks out internal repos during CI. The go.mod file has directives to point packages to resolve to the local paths. It works great, no special auth needed.
We use this same script to keep local checkouts in dev, that works great too.
Hmm, interesting - I’ll have a look, thanks! A different flavour of GoLang-specific magic (“checkout all dependencies locally” rather than “provide authentication so that go build can read from GitHub repos directly), but hopefully an easier on to wrangle.
What does this mean? I’ve read it like five times now. I wish I understood.
A core principle guiding our efforts is composable optimization: the impact of an optimization on a codebase should be as localized as possible, ensuring that the ease of development across the rest of the codebase is not compromised.
A counterexample, or “uncomposable optimization” (first time I’ve heard this term), would be something that forces wider changes to the codebase that are detrimental to ease of development. For example, introducing a specialized key/value data structure for one API, adding cognitive load and reducing interoperability between APIs, rather than just making Map faster.
This very much feels like a random marketing post.
The link behind production systems essentially boils down to Go being able to make HTTP Requests to some API endpoints.
And:
What does that even mean? That you can run Go in a cloud? That kubernetes and terraform are in Go?
I get it, it’s a birthday blog post, but this feels s all like pure marketing blog.
Maybe it’s just bugging me because the blog used to have interesting bits for beginner and more advanced programmers.
Still a fan of Gon but I really miss their no-monsense stuff that originally made me curious about the language.
Go is a Google project, and Google is all in on AI. The person responsible for this blog post/press release no doubt has reams of internal guidance about how AI must now be mentioned in every Google product. I wouldn’t read too much into it.
The funny thing is that if you say go is a google project you will be told “oh no, it is not controlled by google. community blablabla”, yet this blogpost shows who is really calling the shots.
I’m not sure who would ever say that. It’s totally a Google project. All CLs must be approved by someone at Google, ostensibly for supply chain security reasons, but still. Maybe in the early days, there was a question of if it would become a community project someday, but it’s been clearly a Google joint throughout, since they never made a foundation to run it, which is the minimum to be considered not just a corporate project.
At least they let him put it in the end. If you read this paragraph and compare it with the others, you’ll notice it’s the only one that has literally zero content
It’s just that paragraph really; I had a bit of reader’s whiplash when I reached it and up to that point I found the post to be an informative overview of where they’ve been putting their energy recently. It doesn’t really make sense to say Go is good for AI more than it makes sense to say C is good for AI. As sibling says, clearly somebody was forced to jam it in.
Yeah, but even though this was obviously just a corporate mandate to mention AI, I hope this means they finally figure out how to do SIMD in Go.
I mean, you can technically* do SIMD in Go.
* if you like writing (or even know how to write) inline assembly
But it would be great if someone were working on a friendlier way to do SIMD in Go, for sure.
I thoroughly enjoy working with Go. With the tooling, package management, channels, stdlib, and single binary to name a few, it really is hard to beat.
The language isn’t all that great but the great tooling still lets it come out on top of better languages
I sort of agree, but as far as mainstream languages go, it’s really nice to be able to tell at a glance what the program actually does and not have to worry about the spooky-action-at-a-distance stuff that I have to contend with in more ✨magical✨ languages. It’s definitely a boring language, but I think that’s a good thing.
My thoughts (almost-)exactly. The language is missing some really key stuff[0], and the verbose error handling is already well-trodden ground, but the built-in formatter is pretty nice.
Package management, though? I must be missing something. People like depending on GitHub repositories (rather than built binaries) as the source-of-truth for building? I will never forgive GoLang for the number of special-cases we’ve had to build into our CI flows because it has special snowflake authentication needs.
[0] which Gophers would probably call a benefit, because it makes the language simpler and thus easier to read. Though I really think that optional parameters, .map/.filter/.reduce, and an in-place slice.append would be net positives - the language could remain “boring” (a desirable quality!) while greatly increasing concision and flexibility. But I digress…
We’ve been using a script I wrote that just locally checks out internal repos during CI. The
go.modfile has directives to point packages to resolve to the local paths. It works great, no special auth needed.We use this same script to keep local checkouts in dev, that works great too.
Hmm, interesting - I’ll have a look, thanks! A different flavour of GoLang-specific magic (“checkout all dependencies locally” rather than “provide authentication so that
go buildcan read from GitHub repos directly), but hopefully an easier on to wrangle.It’s basically dependency vendoring with a little help from git. We are using the exact same method with other languages too.
The key ‘magic’ with Go is the directive in the
go.modfile:What does this mean? I’ve read it like five times now. I wish I understood.
A counterexample, or “uncomposable optimization” (first time I’ve heard this term), would be something that forces wider changes to the codebase that are detrimental to ease of development. For example, introducing a specialized key/value data structure for one API, adding cognitive load and reducing interoperability between APIs, rather than just making Map faster.