Incredibly trite article given the huge scope of the work they’ve done. They like the logo, the tools are “great”, generics would be nice and it’s quickish - and that’s it.
500k lines (even of go, which is quite verbose) is a chunky codebase and it’s clearly been done under load and presumably their existing engineers had to learn a new language while doing it. Wish they’d said more about the details.
Their original article about Goliath honestly went into a lot more details; this is more the, “we’re done!” post, as far as I can tell. (That post also talks about why Kotlin, which is what I wanted when I was still there, lost out to Go.)
(And that article, in turn, had a number of lead-up posts discussing the massive Python refactoring required to enable this “change the wheels on the running train” program, including e.g. writing the Slicker Python refactoring tool. It’s worth tracking back through the links if you want all the gritty details.)
I left before this project really moved much, but I don’t think so. .NET Core didn’t exist yet (or was very new; I forget which), and no one wanted pure Java.
I hope to write more about the Goliath project overall and how we’ve been running it. We’re actually not done yet.
Just for fun, this year I started giving out badges internally for things that were essentially random, e.g. who committed the 500,000th line of Go. When we hit that particular milestone, I decided to take a survey and get people’s opinions about the language, and then I took those results and wrote the blog post. To me, there was something to the fact that things were going essentially to plan with no big surprises. Not quite as interesting as if our conclusion had been “Go is terrible, we’re switching to Rust” :)
I’m happy to answer other questions and will take requests for future posts. We’re pretty open about our tech :)
The GraphQL post that @gecko linked to has details of how we’ve migrated while everything stays in motion. We will have more to say about our graphql client code (used for service-to-service calls), which has some interesting bits to it.
I don’t think learning Go has been much of a stumbling block for folks. We have had discussions around things like “when do you wrap errors” or “do you return a NotFound error or just nil if something is missing from the database”, but I’m not sure that most of those sorts of details are interesting.
I hope to write more about the Goliath project overall and how we’ve been running it. We’re actually not done yet.
That would great and very useful - my interest is partly because I have now personally seen one or two troubled Python->Go rewrites (and no successful ones yet). The sad nature of things is that rewrites that don’t work out do not lead to any blog posts but at least it should be possible to read about the ones that did. Look forward to reading what you write next
I wouldn’t be surprised if ones that are “troubled” are ones where they either didn’t have full org support, or where they didn’t have their eyes wide open about what they’re getting into. We did a lot of investigation early on to be able to size the work and have a realistic sense of just how much it was and everyone was on board all the way up through the board of directors.
I do wanna say @dangoor that I am really impressed by how smoothly this process all went, and I’ve really enjoyed the series of posts from you and others on the team over the last four years. I’m genuinely disappointed I wasn’t around to see that all go down/to help with it. Congratulations!
Thanks for sharing. I enjoy reading these retrospectives both when they’re fresh as well as when they’re a few years down the road. I’ve been looking at Go on and off for a few years but haven’t built anything in it yet. I am trying out a graphql server with it at the moment and find it a bit confusing at times, but overall pretty nice.
It’s good timing for me to see these types of posts when I’m evaluating some python lambdas I have currently that need to be changed significantly for a new system of record.
Incredibly trite article given the huge scope of the work they’ve done. They like the logo, the tools are “great”, generics would be nice and it’s quickish - and that’s it.
500k lines (even of go, which is quite verbose) is a chunky codebase and it’s clearly been done under load and presumably their existing engineers had to learn a new language while doing it. Wish they’d said more about the details.
Their original article about Goliath honestly went into a lot more details; this is more the, “we’re done!” post, as far as I can tell. (That post also talks about why Kotlin, which is what I wanted when I was still there, lost out to Go.)
(And that article, in turn, had a number of lead-up posts discussing the massive Python refactoring required to enable this “change the wheels on the running train” program, including e.g. writing the Slicker Python refactoring tool. It’s worth tracking back through the links if you want all the gritty details.)
[Edit: and you might also like this article on how GraphQL was used to phase in things slowly. So there’s a lot of meat there; just not in this particular post.]
Did they seriously look at anything other than Kotlin and Go?
I left before this project really moved much, but I don’t think so. .NET Core didn’t exist yet (or was very new; I forget which), and no one wanted pure Java.
I hope to write more about the Goliath project overall and how we’ve been running it. We’re actually not done yet.
Just for fun, this year I started giving out badges internally for things that were essentially random, e.g. who committed the 500,000th line of Go. When we hit that particular milestone, I decided to take a survey and get people’s opinions about the language, and then I took those results and wrote the blog post. To me, there was something to the fact that things were going essentially to plan with no big surprises. Not quite as interesting as if our conclusion had been “Go is terrible, we’re switching to Rust” :)
I’m happy to answer other questions and will take requests for future posts. We’re pretty open about our tech :)
The GraphQL post that @gecko linked to has details of how we’ve migrated while everything stays in motion. We will have more to say about our graphql client code (used for service-to-service calls), which has some interesting bits to it.
I don’t think learning Go has been much of a stumbling block for folks. We have had discussions around things like “when do you wrap errors” or “do you return a NotFound error or just nil if something is missing from the database”, but I’m not sure that most of those sorts of details are interesting.
That would great and very useful - my interest is partly because I have now personally seen one or two troubled Python->Go rewrites (and no successful ones yet). The sad nature of things is that rewrites that don’t work out do not lead to any blog posts but at least it should be possible to read about the ones that did. Look forward to reading what you write next
I wouldn’t be surprised if ones that are “troubled” are ones where they either didn’t have full org support, or where they didn’t have their eyes wide open about what they’re getting into. We did a lot of investigation early on to be able to size the work and have a realistic sense of just how much it was and everyone was on board all the way up through the board of directors.
I do wanna say @dangoor that I am really impressed by how smoothly this process all went, and I’ve really enjoyed the series of posts from you and others on the team over the last four years. I’m genuinely disappointed I wasn’t around to see that all go down/to help with it. Congratulations!
Thanks! We’re not done yet, but we’ve made huge progress and it has gone smoothly overall. Lots of work by lots of folks.
Would’ve been great to have you be a part of the project, but I hope you’ve been enjoying your work in the intervening years!
Thanks for sharing. I enjoy reading these retrospectives both when they’re fresh as well as when they’re a few years down the road. I’ve been looking at Go on and off for a few years but haven’t built anything in it yet. I am trying out a graphql server with it at the moment and find it a bit confusing at times, but overall pretty nice.
It’s good timing for me to see these types of posts when I’m evaluating some python lambdas I have currently that need to be changed significantly for a new system of record.
Glad you found it helpful!
[Comment removed by author]