Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Portable Cloud Programming with Go Cloud

blog.golang.org

Post reply on HN
Print view View original

21–30 of 158 posts

Re: Portable Cloud Programming with Go Cloud

#21

Post by didip »

pmontra wrote: post #18
spraak wrote: post #4

Maybe it's a biased and distorted perception that I have, but Go seems to be the most consistent and unsurprising language I've used, and I mean this positively. I haven't written any Go for over a year since my current job mostly uses Node, but I feel immediately comfortable jumping in to the examples in this blog post. I don't think that I'm explaining what I mean very well, but it's something I don't think is so t…

For me the big surprise is that we still have languages where we have to write things like func setupBucket(ctx context.Context) (*blob.Bucket, error) { sess, err := session.NewSession(&aws.Config{ Region: aws.String("us-east-2"), }) full of ( ) { } * and & as if we were still in the 80s. So Go is a very surprising language, but this is highly subjective. No hard feelings.

For a statically typed language, the number of sigils Go have is surprisingly low.

Re: Portable Cloud Programming with Go Cloud

#22

Post by stcredzero »

sbjs wrote: post #11
spraak wrote: post #4

Maybe it's a biased and distorted perception that I have, but Go seems to be the most consistent and unsurprising language I've used, and I mean this positively. I haven't written any Go for over a year since my current job mostly uses Node, but I feel immediately comfortable jumping in to the examples in this blog post. I don't think that I'm explaining what I mean very well, but it's something I don't think is so t…

Meh, everyone has a preferred type of language they find least surprising. To many Ruby is the least surprising, and Matz used "principle of [his] least surprise" as a guiding principle when designing it, but many other people find it enigmatic and confusing. Some people find Haskell the least surprising and most consistent, others say Java is. Every language has caveats and inconsistencies, even Go. Like how Go has…

Minimalism helps. Ruby has one kind of minimalism, but fails at minimalism in some other ways. The same with Go. People who like Haskell like the kind of reasoning it facilitates. People who like Java want a managed version of C++'s "good parts."

A lot of it has to do with expectations. Going beyond the principle of least surprise, there's also a principle of "no dismay." Go is like the dependable old Corolla. It sets modest expectations, and it delivers a high degree of utility very consistently, and if you're ever let down, it's very rare. C++ can cause you utter dismay due to rather subtle slip-ups. I've only seen this level of dismay in Golang around subtle resource release issues around prepared statements.

Re: Portable Cloud Programming with Go Cloud

#25

Post by elithrar »

sbjs wrote: post #15
sbjs wrote: post #11

Earlier quoted context omitted.

Meh, everyone has a preferred type of language they find least surprising. To many Ruby is the least surprising, and Matz used "principle of [his] least surprise" as a guiding principle when designing it, but many other people find it enigmatic and confusing. Some people find Haskell the least surprising and most consistent, others say Java is. Every language has caveats and inconsistencies, even Go. Like how Go has…

The article has two examples of how I already find Go to be inconsistent and/or surprising: w, err := b.NewWriter(ctx, "gopher.png", nil) ... _, err = w.Write(data) ... if err := w.Close(); err != nil Why is := used on the first line but = used on the second line, and then := used again on the third line? I get that you use := when introducing a new variable, and = when just assigning, the third line is not really in…

> the third line is not really introducing a new variable, since err is still in scope... or is it?

The "if" block creates a new scope.

Re: Portable Cloud Programming with Go Cloud

#26

Post by skj »

sbjs wrote: post #15
sbjs wrote: post #11

Earlier quoted context omitted.

Meh, everyone has a preferred type of language they find least surprising. To many Ruby is the least surprising, and Matz used "principle of [his] least surprise" as a guiding principle when designing it, but many other people find it enigmatic and confusing. Some people find Haskell the least surprising and most consistent, others say Java is. Every language has caveats and inconsistencies, even Go. Like how Go has…

The article has two examples of how I already find Go to be inconsistent and/or surprising: w, err := b.NewWriter(ctx, "gopher.png", nil) ... _, err = w.Write(data) ... if err := w.Close(); err != nil Why is := used on the first line but = used on the second line, and then := used again on the third line? I get that you use := when introducing a new variable, and = when just assigning, the third line is not really in…

The third line has a new err inside the if statement's scope.

It's equivalent to

    { // begin new scope here
      err := w.Close()
      if err != nil {
        foo
      } else {
        bar
      }
    }

Re: Portable Cloud Programming with Go Cloud

#27

Post by cflewis »

Hey ho. I worked on this project.

The majority of the team is in SF for Google Cloud Next to present this. I'm about to hop into the car to head up myself to watch, so I can do a little AMA throughout the day. Reply to this to make sure I see your question!

Here's a question I've already seen:

> Is this a Google project or a Go project?

It is a project led by the Go team, and we are very aware of our responsibility to be cloud provider neutral. At the same time, while the project is so new and evolving so rapidly, we need to have working examples that we can change atomically in a single repository (atomic changes necessary for rollbacks and such). We don't want to have cloud provider-specific code in the Go project, so the code is currently sitting under the Google GitHub org. When the interfaces to different products stabilize, the intention is to graduate them up to the Go GitHub org. Then anyone can code implementations to that interface for whatever cloud they like in separate repos, similar to the way `database/sql` is structured. The cloud provider-specific code will always live outside the Go project.

But things are very new, so change is possible.

Re: Portable Cloud Programming with Go Cloud

#29

Post by [deleted] »

sbjs wrote: post #15
sbjs wrote: post #11

Earlier quoted context omitted.

Meh, everyone has a preferred type of language they find least surprising. To many Ruby is the least surprising, and Matz used "principle of [his] least surprise" as a guiding principle when designing it, but many other people find it enigmatic and confusing. Some people find Haskell the least surprising and most consistent, others say Java is. Every language has caveats and inconsistencies, even Go. Like how Go has…

The article has two examples of how I already find Go to be inconsistent and/or surprising: w, err := b.NewWriter(ctx, "gopher.png", nil) ... _, err = w.Write(data) ... if err := w.Close(); err != nil Why is := used on the first line but = used on the second line, and then := used again on the third line? I get that you use := when introducing a new variable, and = when just assigning, the third line is not really in…

[deleted]

Re: Portable Cloud Programming with Go Cloud

#30

Post by pinkgodzilla »

I wonder what kind of monitoring and alert system must exist if any cloud provider changes their SDK or APIs (signature, logic, capability etc.) upstream while your go binaries are in production. Did Google manage to get cloud providers on board to register and update a 1 to 1 match between the upstream api and the go cloud api?

Secondly on the article's mention on multi cloud usage, you would need to be a pretty large place to need (or even bothering to assess and convince yourself that you need) to use multiple cloud providers at once. Just learning and tweaking settings in the cloud providers GUI console is half the battle won sometimes.

Saying all this, this, together with the data portability announcement, it is definitely great for competition and going to bring great resilience in your code base to be SDK agnostic.

Post reply on HN