I bet y'all would enjoy reading the article after installing this Chrome Extension [Cloud To Butt Plus](https://chrome.google.com/webstore/detail/cloud-to-butt-plus...).
Portable Cloud Programming with Go Cloud
101–110 of 158 posts
Re: Portable Cloud Programming with Go Cloud
#102I'm working on a new kind of container that allows for lambdas with very-very low latency. (Suitable for running a game loop.) This is absolutely awesome! Programming against the auto-generated AWS golang APIs is pretty painful. It works, but it's not idiomatic and overly verbose. I'm going to give it a try and see if switching to GCP is that easy.
Have you looked at this: https://www.usenix.org/system/files/conference/atc18/atc18-o...
Re: Portable Cloud Programming with Go Cloud
#103Earlier 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…
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 the API changes too, then that's a much different thing, and gets back to the leaky abstraction which we want to avoid. If you can't simply wire new providers to your application code and have it Just Work, then we've done our job wrong.
But remember that it's all Just Normal Go, there's no magic here. It's just standard Go. If you want to write an app that ties itself to something specific on some cloud you can; just write the code you'd write now. But that necessarily means you're tied to that product.
Re: Portable Cloud Programming with Go Cloud
#104Earlier quoted context omitted.
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?
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. A lot of what makes anything hard to learn are the non-obvious gotchas. The design philosophy of golang is aimed at avoiding the non-obvious gotchas and the creep-up-on-you-at-scale gotchas.
Except channels. If you use channels it's non-obvious gotchas galore.
Re: Portable Cloud Programming with Go Cloud
#105Earlier quoted context omitted.
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. A lot of what makes anything hard to learn are the non-obvious gotchas. The design philosophy of golang is aimed at avoiding the non-obvious gotchas and the creep-up-on-you-at-scale gotchas.
Except channels. If you use channels it's non-obvious gotchas galore.
Concurrency is hard. Channels make it somewhat easier. Basically, see if you can do concurrency with only synchronous code.
Re: Portable Cloud Programming with Go Cloud
#106Am I the only person not excited by this? It seems to be based on the idea that you can just paper over the chasms between vastly different implementations. Putting aside the fact that the differences are important and you can't ignore them, doing this well is simply not scalable. How could it ever be all of: comprehensive, correct, up to date, elegant?
Re: Portable Cloud Programming with Go Cloud
#107Earlier quoted context omitted.
Except channels. If you use channels it's non-obvious gotchas galore.
Concurrency is hard. Channels make it somewhat easier. Basically, see if you can do concurrency with only synchronous code.
Concurrency is hard and channels make it somewhat easier. Agreed. That's not relevant to the fact that the use of channels in Go is full of gotchas.
Re: Portable Cloud Programming with Go Cloud
#108Will this compete directly with something like Terraform?
Re: Portable Cloud Programming with Go Cloud
#109Earlier quoted context omitted.
Concurrency is hard. Channels make it somewhat easier. Basically, see if you can do concurrency with only synchronous code.
Concurrency is hard and channels make it somewhat easier. Agreed. That's not relevant to the fact that the use of channels in Go is full of gotchas.
That's relevant to the fact that concurrency is full of gotchas. I also used Go to write an MMO all by myself. I think channels are great!
Re: Portable Cloud Programming with Go Cloud
#110Earlier quoted context omitted.
Concurrency is hard. Channels make it somewhat easier. Basically, see if you can do concurrency with only synchronous code.
Concurrency is hard and channels make it somewhat easier. Agreed. That's not relevant to the fact that the use of channels in Go is full of gotchas.
I think his point was that concurrency is riddled with gotchas regardless, and channels reduce them, but not remove them.