1. 12

  2. 21

    It’s kinda funny, because while Go values simplicity, clarity, and “straighforwardness”, a lot of these cloud tools written in Go are pretty much the exact opposite of that.

    1. 2

      HashiCorp has managed to keep things rather simple and orthogonal though.

    2. 2

      I think with the rise of Kubernetes and Docker. Golang become very popular.

      1. 3

        Same for the Hashicorp stack.

        1. 0

          True Soon it will become the most sought out skill in devops

      2. 2

        I wish it didn’t. My favorite example of how Go and tools written in it are broken is the S3 resource in Terraform. It happily allows you to create an illegal state (having a bucket both have redirected all requests and a webpage) and crashes when you try to deploy with a cryptic error message. This is trivial to express in a language that has ADT. HCL is also pretty bad for no good reason. And the Terraform deployments are very slow by default. I don’t know this is because Terraform devs are not particularly good with Go or because Go is mediocre to start with. It would be great to have an alternative to Terraform, using an ML configuration language (like Dhall), and the deployment code in an ML language as well (like OCaml or Haskell).

        1. 5

          Isn’t this true for any language? One will find bad experience in any tool ever written, no matter what language it has been written in.

          I’ve seen programs written in Haskell that just barf weird errors when data doesn’t match what they expect, and I’ve seen programs written in Perl that hold your hand all the way through the process.

          Regarding an alternative to Terraform, there is Pulumi, that allows you to use JavaScript, TypeScript, Python, Go, or any .NET language, including C#, F#, and VB.

          1. 1

            Between your Haskell and Perl examples, I wonder if you would find a different view in each for what constitutes valid data. When Perl was more common, I think it was also common to try and graciously accept broken inputs, for instance in what web browsers will try to render. Haskell is trying to model the correctness, and (perhaps rightfully) expressing that the inputs were simply wrong and need fixing. (Or perhaps that the program’s model of what the data should look like is incomplete, and needs revising.)

            1. 1

              I would definitely subscribe to the “Or” part :)

              We live in a messy world. Programs we write are tools that we use to solve problems in this messy world. If a program can’t handle messy input and barfs because of that, it just means it’s badly designed and badly implemented. Blaming the input and claiming that the programs are trying to model correctness is just sweeping the issues under the rug and pretending one is in an ivory tower.

              1. 1

                Well in the “or” case, Haskell can deal just fine, as long as that’s an acknowledged edge case. That’s the beauty of that sort of thing, because then that now-known problem is encoded in the data type, and anything that uses that data has to recognize the need to deal with it too.

                So sure, messy world, but now you can define the input as valid or broken, and then do something differently in that broken case. The problem with trying to always accept invalid input is that it leads to vulnerabilities in edge cases nobody planned for.

        2. 1

          I am surprised that Rob Pike did not expect people to write malware in Go.