131–140 of 158 posts
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?
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…
Our company uses Go. Most people who join have no experience in Go yet usually they can get comfortable with the language in 1-2 weeks to start contributing. I know nothing about Node/JS but I'm sure that takes much longer?
I like how Google tries to masquerade their corporate goals behind the 'portability' banner. Google Cloud is in a distant third place behind AWS and Azure, so ofcourse they don't want developers to have tight coupling to their competitors. This portable cloud strategy is a mirage. I haven't seen anyone migrate providers easily (we tried in my last company). In reality, you have to break the cloud agnostic abstraction…
Earlier quoted context omitted.
I feel like a caveman typing out error handling code in go, but on the other hand (even as a beginner in Go) I _never_ run into unexpected conditions. There's tradeoffs of course but every time I find myself thinking about what kinds of error conditions may be happening in my Node code (where I spend most of my time), and whether I covered them all... i think I'd trade.
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…
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 for this request and is closed when no values are left)
3. I think you've been treated to well by JS closures, always hand over arguments you're going to use in the goroutine, this also allows the CG to clean up the stack of the function that started the closure goroutine.
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…
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…
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 don't know enough about the intervals to say whether this is feasible with the current runtime, though.
Earlier quoted context omitted.
There's a fine balance here. "You can't pay people enough to carefully debug boring boilerplate code. I've tried." (Yaron Minsky of Jane Street) While C++ goes to one extreme, not having certain expressive means (whatever they may be) has a price, and for certain kinds of problems, this price may be high. This returns to the idea I very much agree with: "The trick is to actually optimize a language for the difficult,…
Go is what Java 1.0 should have been. Question is, how it will move beyond that, if ever.
Earlier quoted context omitted.
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…
This is a great question. The main goal of Go Cloud is that the abstraction is not leaky and that you don't get access to specific features in the way you are describing in the application itself. Now if the specificity of the thing you want happens at provisioning time but the API is the same (e.g. choosing to use Aurora on AWS vs standard RDS), then there's no problem. Go Cloud doesn't need to know about that. If t…