They're sort of an intelligence network for payment processors. Took a few days and it worked again, but just be aware that having a new credit card every payment might put you in a higher risk bucket.
That seems to be a common thing in Kubernetes too, if you don't want to spend the time writing actual code and Go is too "boilerplate heavy" for you, just write a code generator and bring the complexity of other languages right back!
1. Get IDE support. There is no convention of adding a suffix like "Interface", and I personally am very happy with this. C# ISomething naming conventions have annoyed me quite a bit.
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.
1. Naming conventions don’t solve syntax warts. Modern languages solve this as part of their null safety (eg optional monads or the ? on kotlin and swift)
2. Yes, I know how to “properly” do it. Does not eliminate human error.
3. Closures in any other language, afaik. I rarely code in Js, fyi
Regarding 1, I (and seemingly everyone else writing libraries) usually return (value, error) and treat a nil value as error. We have quite a bit of old code at work that might segfault because it wasn't done like this.
Most of our Kubernetes code looks something like this
_, err := clientInterface.Update(object)
if err != nil {
if machinery_errors.IsNotFound(err) {
//handle nil case
} else
// handle unexpected case
}
}
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 controversy for Go 2, with calls from "everything should have a context" to "context should go away".
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
Context is a pet peeve of mine. It's a design mistake as implemented, even if it serves an important function. It infects everything, forcing every method to pass contexts around, and it conflates multiple separate concerns (cancellation, deadlines, and key/value data).
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.
Absolutely. Makes it break in very obvious ways that prevent people from continuing using it as an internal TLD, probably before the domain is actually owned by someone.
There's a reasonable argument to be made that ICANN should not have sold an extremely desirable TLD like .dev to a company intending to use it internally rather than permitting open sale.
Not to mention that it was well-known to be commonly used for internal domains at other organizations, and they then intentionally acted to break everyone's internal workflows on a global scale. It'd be kind of like if ICANN went and sold .local (which Windows servers default to as internal domains.) The other correct option for ICANN was just to refuse to sell .dev and mark it as an internal use only TLD.
The way we allocate second level domains is already terrible (see also domain parking/domain squatting), why would I be okay with someone just throwing money at ICANN to get a bunch of generic top level ones too?
Oh I love HN Dunning Krueger smugness, especially with specifics of one particular network security spec that has a lot of alternatives. Truly, if you've never used IPSec, get out of my HN, you peasant.
What's the big deal? Wordpress can be lean on the code is delivers? It certainly can't be lean on the backend. There's also a helper functions for adding tons of classes to elements everywhere so you can "patch" CSS for certain sites / categories only, clearly not for the target audience that values minimalism.
