41–50 of 158 posts
Earlier quoted context omitted.
> unsurprising language --- This is a valid Go program. import "fmt"; func main() { fmt.Println("Hello world") } This is an invalid Go program. import "fmt"; func main() { // fmt.Println("Hello world") } Surprising. --- Creating typed general-use data structures is impossible. Surprising.
neither of your example is a valid Go program.
Earlier quoted context omitted.
You're correct. I was in no way surprised by this language feature, and neither were any of my coworkers. Go is a thoroughly "unsurprising" language.
Rave about porting cat to go and we'll restore your karma.
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…
Seems like a very useful library. Any similar libraries for other languages?
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…
This looks great! Are there any beginner friendly issues for contribution? Didn't find a related tag in Github issues.
Earlier quoted context omitted.
Isn’t this just centralizing the cloud provider SDKs? Instead of AWS, GCP, Azure designing their own SDKs, they have a common contract to adhere to. I’d imagine as the cloud becomes more mainstream, you’ll see similar support in Java and .Net (a System.Cloud package for example)
It looks like it, but think of the power. If you write your app for S3 and Amazon raises their prices 100x you can be running on GCP in no time. Of course, you just create interfaces for your data model and implement them with your favorite service, but nobody has time for that.
Why should I learn go and use go cloud over AWS SDK?
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.
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…
The problem with inconsistencies and surprises in languages, is that these are often the basis of conundrums that are more expensive to detect, figure out, and fix by a factor of 10X or more. I say this with appreciation and without irony: It turns out that "Blub" is actually a good thing, so long as it's done right. All languages are going to suck, somewhere. The trick is to actually optimize a language for the diff…
"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, expensive parts of development." The catch is that difficult parts are also problem area-dependent. Go definitely found a sweet spot for certain kinds of problems, though.