Portable Cloud Programming with Go Cloud • Hacker News Board

Re: Portable Cloud Programming with Go Cloud

#141

Post by gant » Wed, Jul 25, 2018, 1:19 PM UTC

atombender wrote: post #137

gant wrote: post #35

Earlier quoted context omitted.

I'm a little bit concerned because the last package that Google seems to have purpose-built for Go+Google (AppEngine?) was context, that gave us things like context.Context, a generic KVS that needs reflection, heavily relies on convention and doesn't work in linear time and "just make every function take a context and use context.TODO if you don't need it". It also seems to be one of the biggest points of controvers…

Context is a pet peeve of mine. It's a design mistake as implemented, even if it serves an important function. It infects everything, forcing every method to pass contexts around, and it conflates multiple separate concerns (cancellation, deadlines, and key/value data). Given that all of a Go program sooner or later will need contexts somewhere, it would be much cleaner to let goroutines have this stuff implicitly. I…

People really seem to dislike context in the standard library too:

https://github.com/golang/go/issues/20280

Re: Portable Cloud Programming with Go Cloud

#142

Post by liveoneggs » Wed, Jul 25, 2018, 1:39 PM UTC

erik_seaberg wrote: post #64

liveoneggs wrote: post #53

ironically terraform is already written in golang. https://github.com/hashicorp/terraform Go 96.1%

A frustrating choice. I spend a few minutes per week running Terraform on a recent laptop. If it were written in Python, it might use more memory and require a few dependencies (which I don't care about at all) but then I could write plugins without having to deal with IPC and weird language-specific serialization (which Java should have convinced us is a bad idea).

heh I thought you were making a funny sarcastic joke and then realized you were serious :)

Re: Portable Cloud Programming with Go Cloud

#143

Post by gant » Wed, Jul 25, 2018, 1:42 PM UTC

skybrian wrote: post #51

Interesting that they built a new dependency injection framework, much like similar things in Java. I guess this doesn't replace Context, though? https://github.com/google/go-cloud/tree/master/wire

Oh no, not another code generator.

That seems to be a common thing in Kubernetes too, if you don't want to spend the time writing actual code and Go is too "boilerplate heavy" for you, just write a code generator and bring the complexity of other languages right back!

Re: Portable Cloud Programming with Go Cloud

#144

Post by justinclift » Wed, Jul 25, 2018, 2:09 PM UTC

cflewis wrote: post #27

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 t…

Why the MySQL support?

Seems pretty weird to include support for an Oracle offering from the get-go, especially given the bad blood between Google and Oracle.

Re: Portable Cloud Programming with Go Cloud

#145

Post by herval » Wed, Jul 25, 2018, 2:28 PM UTC

gant wrote: post #135

herval wrote: post #122

Earlier quoted context omitted.

I keep shooting myself in the foot _the same way_, all the time - and it's incredibly easy to do so: - not knowing if "Foo" being returned is a struct or an interface, so you're not sure if you should "if foo != nil" (it could not be nil if it's a struct) - channels freezing (specially unbuffered ones). I still can't figure out how to debug those well. - (the most common of all) spawning goroutines on a for loop, and…

1. Get IDE support. There is no convention of adding a suffix like "Interface", and I personally am very happy with this. C# ISomething naming conventions have annoyed me quite a bit. 2. Always limit the scope of your channels. I like using unidirectional channels with structs that have more unidirectional channels. (For instance, a chan of workRequest{workData, returnChan} where return chan only receives responses f…

1. Naming conventions don’t solve syntax warts. Modern languages solve this as part of their null safety (eg optional monads or the ? on kotlin and swift)

2. Yes, I know how to “properly” do it. Does not eliminate human error.

3. Closures in any other language, afaik. I rarely code in Js, fyi

Re: Portable Cloud Programming with Go Cloud

#146

Post by stouset » Wed, Jul 25, 2018, 5:29 PM UTC

sjellis wrote: post #128

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…

> It seems to be more about the person trying out the language than the language itself. This is true, but Go does have a clean and mostly familiar syntax, by design: you can mostly follow along with a piece of Go code even if you haven't learned the language. I think that what the OP is pointing at is a related issue: readability. This is explicitly a high-priority design goal for Go: lots of things in the language…

On the flip side, I personally find go extremely difficult to read.

First, repetitive error handling makes it overly tedious to actually get a quick intuition for what a function is doing. With Rust as a comparison, it’s extremely easy to see what the happy path is trying to accomplish without having the downsides of arbitrary and unexpected exceptions. Go is inarguably worse here.

Second, the inability to express higher-level concepts (due to, yes, lack of genetics) seems like it forces every function to deal with the nitty-gritty details of whatever it’s trying to accomplish, rather than being able to express ideas at a higher level and deal with the specifics in smaller code units. Yes, you don’t get “surprising” behavior, but the cost of this is that you’re forced to keep both the high level goals and the low level details in your head simultaneously, which I find to be a massive hindrance.

As sort of a side effect of both of these, there ends up being a ton of repetitive boilerplate. This actually hides bugs since it’s easy to miss minor differences between overly similar blocks of code dealing with errors or looping. As an example, languages like Rust and Ruby that have proper functional-style iterator methods prevent so many bugs through their inclusion it’s absolutely baffling to me how someone would opt to design a language today without such things.

Re: Portable Cloud Programming with Go Cloud

#147

Post by Walkman » Wed, Jul 25, 2018, 5:42 PM UTC

jhabdas wrote: post #99

vsekhar wrote: post #83

Earlier quoted context omitted.

PM for Go Cloud here (and poster of the Azure feature request). "Unplanned" on the issue tracker just means we haven't assigned it to a sprint milestone for the team yet. Azure and more clouds are very much in the works. As an open project, there are many approaches and we're open to all of them. One other point: since Go interfaces are implicitly fulfilled, anyone can write and share implementations of Go Cloud for…

Hi PM guy. If project is to remain independently cloud-gnostic and people file a lot of bugs and pull requests it'll definitely help Google or Alphabet or whatever deliver that k8s abstraction y'all've workin' on. That's great for you. My my question is, what if developers want access to innovations in specific cloud providers, such as reduced redundancy storage on S3? Wire up or own provider? Will there be some sort…

Usually if you want to use a library like this, you can't really do anything else, but implement the smallest common subset of the services combined.

In the minute you implement something provider specific, you just lost the whole point of this library and you did not needed it in the first place.

Re: Portable Cloud Programming with Go Cloud

#148

Post by lazyhacker » Wed, Jul 25, 2018, 6:19 PM UTC

justinclift wrote: post #144

cflewis wrote: post #27

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 t…

Why the MySQL support? Seems pretty weird to include support for an Oracle offering from the get-go, especially given the bad blood between Google and Oracle.

It's more important to us to address what developers want and many developers are using MySQL even on clouds.

Re: Portable Cloud Programming with Go Cloud

#149

Post by [deleted] » Wed, Jul 25, 2018, 6:27 PM UTC

go-question wrote: post #125

cflewis wrote: post #27

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 t…

Is there a session or talk on this at Cloud Next?

[deleted]

Re: Portable Cloud Programming with Go Cloud

#150

Post by gant » Wed, Jul 25, 2018, 7:37 PM UTC

herval wrote: post #145

gant wrote: post #135

Earlier quoted context omitted.

1. Get IDE support. There is no convention of adding a suffix like "Interface", and I personally am very happy with this. C# ISomething naming conventions have annoyed me quite a bit. 2. Always limit the scope of your channels. I like using unidirectional channels with structs that have more unidirectional channels. (For instance, a chan of workRequest{workData, returnChan} where return chan only receives responses f…

1. Naming conventions don’t solve syntax warts. Modern languages solve this as part of their null safety (eg optional monads or the ? on kotlin and swift) 2. Yes, I know how to “properly” do it. Does not eliminate human error. 3. Closures in any other language , afaik. I rarely code in Js, fyi

Regarding 1, I (and seemingly everyone else writing libraries) usually return (value, error) and treat a nil value as error. We have quite a bit of old code at work that might segfault because it wasn't done like this.

Most of our Kubernetes code looks something like this

    _, err := clientInterface.Update(object)
    if err != nil {
      if machinery_errors.IsNotFound(err) {
        //handle nil case
      } else
        // handle unexpected case
      }
    }