> Usually this isn’t necessary and its better to just return the error unwrapped.
This is a terrible advice. Wrapping is extremely helpful in providing additional context for the error travelling up the call stack. Without wrapping, one typically ends up with software logging generic errors like "file not found" , which you can't act on because... you don't know where it's coming from. If you skip error wrapping, better be ready to enjoy quality time when production crashes.
I believe the idea is that 'panic' is considered something fatal. If it happens, the application should die unless you have a strong reason for it not to. If you can recover e.g. by returning HTTP 500 for a single request, it should be handled by returning errors up throughout the call stack, i.e., by error handling instead of panicking.
Nil pointer panics happen. When a DB column that was supposed to be non-null is null and the code unexpectedly accesses it. Oh schema won't help because legacy. There are rare though and we fix such issues as they are discovered, but just pointing out a benign case when crashing the whole server on panic may be a wrong approach. Our approach is to always recover from panics so the server keeps chugging, but raise an alarm so someone is paged and fixes the issue right away.
> I believe the idea is that 'panic' is considered something fatal.
I think opinions in 3rd party Go code on what “fatal” means vary, that’s the issue. Sure it was intended to mean “this error is so bad the entire program needs to die right now” but in practice there’s cases where it’s treated more like an unchecked exception in Java, i.e., “I can’t recover from this so _I’m_ going to give up but _you_ can keep going.” Or put another way, what a library might consider fatal the caller doesn’t. It can be argued whether or not that’s the right thing to do, but the fact is it happens in the wild, so for something like a server you probably should trap it.
> but in practice there’s cases where it’s treated more like an unchecked exception in Java, i.e., “I can’t recover from this so _I’m_ going to give up but _you_ can keep going.”
Java has a supertype for unrecoverable problems like out-of-memory-errors. It's called "Error", a subtype from Throwable. Exceptions are also Throwables, but they are NOT errors.
There's nothing unrecoverable about Error exceptions. If one thread hit a bug and threw StackOverflowError, it's not a reason to kill the entire application or even thread itself, just unwind stack, show some error and continue processing next task. The only tricky situation I'm aware of is OutOfMemoryError, because it can affect other threads. I'd prefer to restart the server. But again it's just because typical code allocated heap all the time. One can write code carefully without heap allocations and this code will work just fine with OOM errors thrown around.
> There's a reason why most FAANGs developed their own packages management and deployment system and keep using them. They are simpler, less bloated, easier to debug.
Most FAANGs developed their computing infrastructure before Kubernetes gained popularity. After all the investment into building it and fine tuning for their software services (like ads), they probably have a lot more reasons to not migrate to something different. Not just because their systems are "simpler, less bloated, easier to debug".
It doesn't work like this. If there is a hiring freeze in place, it means that internal headcounts are also limited. The "desperate team elsewhere" must have money to pay for the new engineer.
It is not harder, it is different. They just ask more system topics, while focusing less on coding. There is, however, a catch. If you get hired as a SRE-SWE, you can easily switch to a regular SWE. If you get hired as a SRE-SE, you may have to reinterview to change your job ladder. SE is okay, but you clearly have more possibilities as a SWE.
SRE-SWE and SRE-SE on the same team will have exactly the same expectation given the same level.
Depending on the project you work on, you might have a code-heavy project that requires you to work closely with the SWE team, or an operability-heavy project that doesn't have much coding.
Counterpoint: I have a HomePod mini in one of my rooms and it reacts easily to any mention of Siri in other rooms. So I am actually impressed with how good it is in reacting.
I had a similar issue where a HomePod mini in our living room always responded when in the kitchen, so I just disabled the microphone on the living room HomePod minis.
iCloud and Google storage plans are overpriced? I have always thought they are cheap storage plans. 50GB of iCloud costs $0.99 per month. 2TB costs $10 which is similar to other solutions such as Dropbox or OneDrive.
Yet someone could provide all of that for _everyone_ for literal 0-cost, and probably an actual ISP would provide at least some written guarantees on the redundancy of your data.
The business model of all these companies is to tie their software to their expensive storage.
I'm certainly far from finding excuses for Google, but I have strong doubts when reading stories like this. I wonder how is this possible? If you check their support packages at https://cloud.google.com/support/, they provide different options based on how much you are willing to pay. The premium package gives you 15 minute response time and a personal TAM. What am I missing here? They promise a service, but it doesn't work?
Have you ever tried to get one of those packages ? You need to have an interview etc.It’s not straight forward or cheap. We tried to sign up and have a TAM assigned but gave up. It was a lot of effort.
Amazon gives great support at an affordable price.
What finance jobs? The only companies in software engineering paying more than FAANG are trading companies like Jane Street. And AFAIK they have harder interview loops than Google.
Yes, trading companies and even trading divisions at banks.
I've interviewed at plenty of them (only one in recent years, though) and while I wouldn't say they were easy, they aren't doing completely irrelevant challenges like leetcode.
I've certainly never studied for one, unless you count flipping through a book or two just to remind myself of things I may not have thought about in a while. Like 1-3 hours tops.
This is a terrible advice. Wrapping is extremely helpful in providing additional context for the error travelling up the call stack. Without wrapping, one typically ends up with software logging generic errors like "file not found" , which you can't act on because... you don't know where it's coming from. If you skip error wrapping, better be ready to enjoy quality time when production crashes.