Tea418
Whether or not the playback error rate of your product significantly spikes depends on the number of older non-Chrome browsers that are using Widevine. Probably mostly Firefox installations that don’t receive regular updates by their users. Chrome itself is doing pretty well with pushing updates for plugins such as the mentioned CDM.
Analytics tools will certainly help to determine how many users will be affected after December 6. Perhaps something for Bitmovin to provide a smart metric for exactly this.
My personal hypothesis is that many libraries follow the official Go release policy[1]. Due to the fact that generics were introduced with v1.18 and we now have v1.19, libraries would be bound to the features that were available with v1.17, unless they spend effort on working around this by implementing the respective build flags that make generics available exclusively for >=v1.18. However this is just an assumption.
According to the Go Developer Survey 2022 Q2[2], 1 in 4 respondents said they've already started using generics in their Go code and 14% have started using generics in production code.
[1] https://go.dev/doc/devel/release [2] https://go.dev/blog/survey2022-q2-results
One of these other things is understanding the kind of problem I want to solve and its environment, by collaborating with stakeholders and domain experts. As soon as I understand their expectations, I decide on the tech stack.
That being said, if I want to make an estimation which tech stacks are likely to be relevant in the long run, I would start with understanding which business requirements will be relevant. Based on that (and maybe more), I can assess which stacks could be a promising fit.
And if I'm wrong, don't neglect the experience I make mastering or learning a tech steck.
[1] https://docs.hetzner.com/robot/dedicated-server/general-info...
[2] https://www.heise.de/newsticker/meldung/Guenstige-Rootserver...
Request manipulation is not the duty of a cache - even though other CDN providers mix request manipulation functionality with caching. In my opinion, they don’t need to be in the same product.
If you still need request manipulation, because you don’t control the origin or you don’t want to introduce another service between CloudFront and the origin, you would use CloudFront Functions, which is cheaper than Lambda@Edge and easy to set up.
The Go blog has always good insights and details around things like this: https://go.dev/blog/context
I feel like it’s getting harder to estimate importance properly as the complexity of an abstract system grows. People tend to click the same error message they don’t understand away each day, because it hadn’t had any negative impact (so far).