There are a few assumptions I find troubling here - the new proposals for error handling are not intended to replace existing error handling, merely to supplement it. So where you currently handle errors in a function with if err != nil {dosomething} nothing would change. They are simply intended to cover the cases where people use:
if err != nil { return err }
or multiple instances of
if err != nil { return fmt.Errorf("error at xxx:%s",err) }
And make them a little less verbose by allowing you to just use check function() instead. That is all. Errors are still values, and can still be handled individually at the point of failure (unless you choose to group the response), so this is really not a major change to the language.
The article proposes asserts as a replacement for check but this means we still have a proliferation of != nil in most cases, and it would if used liberally mean the error handling was always divorced from the code checking errors. IMO the only time handle{} should be used is for simple annotation of multiple errors, and the restrictions on its use enforcing this are a net benefit, not an unintentional problem. If you need to handle each error differently, use the original error handling.
In terms of concision, one thing I hoped to see but didn't in the Go 2 proposals was to allow gofmt to collapse if err != nil {...} onto one line where it contained only one line of code. This formatting change alone would make the presentation of go code much more compact without any semantic changes.
Thanks for posting, I've adjusted the link to say Video: at the start so it shows up under videos. This was a really interesting talk, though not something most people will end up doing, it's a good way to learn about networking.
I love that they call adding adverts inline into content enrichment :)
Some interesting notes here on how replacing the third party service was done.
It was like changing airplanes mid-flight. They slowly added the new infrastructure around their third-party service, and when it was ready, they would rip it out.:
They started by injecting the ad selector into the request path, having it purely as a proxy. The system did the same thing it was doing before, but with the ad selector in place. This allowed them to scale up requests through the ad selector without without actually doing anything.
Then, instead of just being a proxy, they implemented and rolled out native ad selection in the ad selector service. Now, the ad selector would process the requests internally, but still act as a proxy and pass the request to the third party. The system would still use the third party response.
Then, they added Event Logger to implement logging for native responses, and set up Kafka.
They continued building out the rest of services, starting with stub services, and added logic along the way.
Eventually, once everything was in place, they cut off the third party ad server.
I also like that they recommend using a framework/libraries - as long as the packages used are lightweight, importable as distinct units (no interdependencies) and don't get in the way, I think this is a really good idea. The main argument for this as I see it is consistency - if you have a large codebase or several services, the last thing you want is people choosing which library to use without constraints. It's better to have a common foundation for all the code, which typically is or becomes a framework (whether out of house or in-house). Low dependencies is great, but for things like logging services, it's essential that everyone uses the same thing. It's easier to navigate the code base, easier to get new hires up to speed, and easier to write new code, as decisions have been made for you. I suspect companies/people who don't want to use a framework end up writing their own anyway in piecemeal fashion - which is fine, but it's still a framework.
This really resonates with me - the vast majority of websites/apis can easily run on one process on one server, and just upgrade to handle traffic if required. Often even the smallest server can handle a surprising amount of load when using go.
The only thing I'd probably change is to use a separate database server/service, as this makes it trivial to scale up to n servers if that is required later, so this approach even scales well if you do happen to hit scale if you keep the data separately (it can be shared between services). Of course you can start with the db on the same server and just migrate it later too, it's not hard to do.
The other factor is that often as you hit scale the business will change dramatically, and the previous requirements become actively damaging, so you may well have to rethink your architecture anyway, so the highest priority should be getting something working now which fits the requirements of the business now, not attempting to plan for a future which probably won't happen or a scale where you don't understand what the real problems will be yet.
However there is an incentive for developers to over-complicate things because it gives them experience which then makes them more valuable on the jobs market, and makes their job more interesting as they get to use modern technologies that everyone is talking about (kubernetes etc), and I suspect hidden motivations like that come into play a lot more than people admit when they're planning infrastructure. There are some notable exceptions to this of course - if you're building a bank, or a trading or advertising platform you know if it has any success a all it's going to scale and requires that built in to the initial design, but for 98% of the websites/servers in existence, one server could comfortably handle the load throughout the lifetime of the business.
There's really not much here, so I won't be voting it up, however I've left it up in case anyone else finds it interesting.
Personally I also think that this vogue for imitating client-side js frameworks in wasm is a mistake - it would be nice to replace js in the browser and use the language used server side client side as well, but there's no need to repeat the mistakes of js frameworks which attempt to move all computation to the client side and replace the DOM entirely. I'd rather keep most of the work server-side (which is well understood, performant, and far easier to reason about), but use the same language for client-side work too where interactivity is required. These client-side frameworks are solving a non-problem on the vast majority of websites IMO.
Despite the flippant title this is s really interesting tour of the features (or lack of them), which make Go interesting.
if err != nil {return err
}
if err != nil {return fmt.Errorf("error at xxx:%s",err)
}
Thanks for posting, I've adjusted the link to say Video: at the start so it shows up under videos. This was a really interesting talk, though not something most people will end up doing, it's a good way to learn about networking.
It was like changing airplanes mid-flight. They slowly added the new infrastructure around their third-party service, and when it was ready, they would rip it out.:
This introduction also links to a page with more details.
Worth reading this article as well by Russ Cox which covers in more detail what is required to version code above version 2
This looks really interesting, thanks for posting. What have you used it for so far?
Not strictly go related but this is relevant to a lot of go developers I think.
This really resonates with me - the vast majority of websites/apis can easily run on one process on one server, and just upgrade to handle traffic if required. Often even the smallest server can handle a surprising amount of load when using go.
There's really not much here, so I won't be voting it up, however I've left it up in case anyone else finds it interesting.