121–130 of 158 posts
Earlier quoted context omitted.
> we are very aware of our responsibility to be cloud provider neutral Yet, Azure support is listed as unplanned. The language could mean that this is not going to be planned. The fact that y'all have not worked with Azure Go folks to get this moving is something to ponder. A reminder that Go is a Google language and isn't vendor neutral?
Maybe they're hoping Microsoft will do it?
Earlier quoted context omitted.
Go is certainly very easy to reckon with. But I was surprised at how little O cared for it when I tried it, given the hype I'd heard. The two things that immediately jumped out at me were error handling and generics. I understand both were deliberate choices but I'm still surprised they were made - I've been working with Swift a lot lately and it just feels like it makes so much more sense to me. I do love how opinio…
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.
- 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 all of them closuring over the same value (instead of one per item on the loop)
it's a surprising amount of sharp edges, for such a tiny language...
Am 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?
This is like those DB abstraction layers because "we need to change DB", but in the end almost no one doesn't the products lifetime.
Also given that most of our clients don't use these fashionable cloud APIs, rather their own infrastructure, makes also not that much relevant to me.
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…
After Google threw half of Android into "Google Play Services" I don't believe it. > Then anyone can code implementations to that interface for whatever cloud they like in separate repos, similar to the way `database/sql` is structured Of course they can, but you're working on a Google-centric version first right? Otherwise why would it be at Google Cloud Next? That makes all other cloud providers second tier, and I…
Please see the comment from our PM regarding Azure: https://news.ycombinator.com/item?id=17604358
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…
Earlier quoted context omitted.
I don't think cloud providers would just change their SDK or APIs without notice. It will break anyone using their SDK, not only go-cloud. For your second point, it's normal for small startups to shop around and pick the cloud provider that's more suitable for their needs. For example on my last job at a small startup, we switched from AWS to GCP for cost reasons, and I implemented an abstraction (similar to go-cloud…
They never change over the course of say 3 years? 5 years? If it changes frequently that's great - someone could be put to task to monitor. If it changes very rarely, you will have a surprise outage although I am guessing debugging and fixing it would not be an issue unless you have SLAs you need to keep up with.
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…
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 are designed so that developers can easily read and understand the code in the projects that they work on, and that memory use is never hidden.