Portable Cloud Programming with Go Cloud
51–60 of 158 posts
Re: Portable Cloud Programming with Go Cloud
#52Hey 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…
Re: Portable Cloud Programming with Go Cloud
#53Re: Portable Cloud Programming with Go Cloud
#54Maybe 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?
Your people can pick up go reflect package or go routines/channels and co in 1-2 weeks and start contributing? impressive... most people can pick up for loops, if,switch statements, variable and function declaration in a week in any language as well...
In fact, a lot of non programmers use JS regularly to write scripts in the browser. I imagine your people know how to program before hand... So what do you think takes longer to learn? mastering go threading model or being able to add interactivity to the DOM?
Re: Portable Cloud Programming with Go Cloud
#55Earlier quoted context omitted.
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…
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,…
Question is, how it will move beyond that, if ever.
Re: Portable Cloud Programming with Go Cloud
#56Earlier quoted context omitted.
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…
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,…
There's boilerplate, and then there's boilerplate. If boilerplate is just a formality, with clean, competently designed underlying concepts, then it should be fine. Someone smart will build a code generator for that part of the project, you have your type safe-whatever and the project goes on its way. On the other hand, if your code base is just numb-nuts and people are just cut & pasting lava-flow code all over the place and rampantly putting business logic into ORM routines, then yes, that's going to impact hiring.
not having certain expressive means (whatever they may be) has a price, and for certain kinds of problems, this price may be high
This is also true. Even fairly innocuous boilerplate can build up to the point where refactoring can become tedious. There is no utopia, only constantly changing cost/benefit tradeoffs.
Re: Portable Cloud Programming with Go Cloud
#57Hey 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…
The libraries that support it have now all their function signature way longer, and it is not well understood if it is a "Request for cancellation" or something else
Re: Portable Cloud Programming with Go Cloud
#58Interesting 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
Re: Portable Cloud Programming with Go Cloud
#59Earlier 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…
I also hate the inconsistent behavior when you check multiple errors in a row, the first one will get := but not the second one (if you don't put those in a if statement, which I never do). But now if for some reason, you remove the first := statement, the code will error on the second one, that needs to be changed from = to :=
Re: Portable Cloud Programming with Go Cloud
#60ironically terraform is already written in golang. https://github.com/hashicorp/terraform Go 96.1%
I do think it's an excellent configuration management and provisioning tool, but Go Cloud solves a different problem.