3 ms·

Your Golang mention reads as a total non-sequitur. I'm not even sure what it means. I think you are mad that they didn't provide a way to pin dependencies built

Your Golang mention reads as a total non-sequitur. I'm not even sure what it means. I think you are mad that they didn't provide a way to pin dependencies built-in to the language from the get-go? But few if any languages provide that. In every case I can think of, package management is done by an external tool. The only exception is... oh right, Golang now builds it in, including the ability to pin old versions. Sure it took a while, but what does that have to do with anything else you say here? If anything Golang is a counter-argument to your thesis about why GCP isn't taking off. You're right that Google has done abysmally with its commitment to keeping services running for the long haul. But Go itself has been remarkably stable and compatible over the years since its introduction. Far moreso than Python, Rust, or JS in the same time period.

spricket 8y ago
It's an example of how they treat "old" code, services or otherwise. Fixup your code to use new version or you can't build. Replace "build" with "deploy" and you have the policy of GCP. Now it's been a few years and they may have fixed this, but Go was the only language I've ever used that didn't let you pin dependency versions
- 1-KB-OK 8y ago
  It's a fair criticism of the older versions of Go - it did not have good dependency management out of the box. Probably due to the famous Google monorepo and how they did not need to tackle that issue head on themselves. However the past few years Go has really addressed this problem, first through the dep project (which has your standard .lock file for pinning dependencies similar to Node) and now go modules (included in the latest Go versions). Now you get dependency management out of the box. Your point is valid but does not reflect the modern state of Go.
- LoneWolf123 8y ago
  You may want to use this small script: "Like 'go get' but with pinned package versions. A tiny shell script". https://github.com/joewalnes/go-getter https://github.com/joewalnes/go-getter

spricket 8y ago

It's an example of how they treat "old" code, services or otherwise. Fixup your code to use new version or you can't build. Replace "build" with "deploy" and you have the policy of GCP. Now it's been a few years and they may have fixed this, but Go was the only language I've ever used that didn't let you pin dependency versions

1-KB-OK 8y ago
It's a fair criticism of the older versions of Go - it did not have good dependency management out of the box. Probably due to the famous Google monorepo and how they did not need to tackle that issue head on themselves. However the past few years Go has really addressed this problem, first through the dep project (which has your standard .lock file for pinning dependencies similar to Node) and now go modules (included in the latest Go versions). Now you get dependency management out of the box. Your point is valid but does not reflect the modern state of Go.
LoneWolf123 8y ago
You may want to use this small script: "Like 'go get' but with pinned package versions. A tiny shell script". https://github.com/joewalnes/go-getter https://github.com/joewalnes/go-getter