foobazgt

They could have gone one step further by reviewing all cases of default behavior for anything that might be surprising. That said, it can be difficult to assess what is "surprising", as it's often the people who know the least about a tool/API who also utilize its defaults.

Ditto!

A business is made of employees, but the employees are not the business. Sometimes that means decisions have to be made in favor (sometimes arguably) of the business over you.

Understanding the ephemerality of the situation can help you appreciate when it's going well and the people you work with, while helping you be prepared if and when something happens. Hopefully you will have gained a lot more experience, a bigger network of good friends, and have a decent nest egg to take you to the next job.

I remember appreciating how much nicer it was to run Java servers, because best practice for C++ was (and presumably still is) to immediately abort the entire process any time an invariant was broken. This meant that it wasn't uncommon to experience queries of death that would trivially shoot down entire clusters. With Java, on the other hand, you'd just abort the specific request and keep chugging.

I didn't really see any appreciable attrition to golang from Java during my time at Google. Similarly, at my last job, the majority of work in golang was from people transitioning from ruby. I later learned a common reason to choose golang over Java was over confusion about the Java tooling / development workflow. For example, folks coming from ruby would often debug with log statements and process restarts instead of just using a debugger and hot patching code.

Asking your session musician for something "melancholy" and having them pass off Stairway to Heaven as original would be unreasonable.

The vehicle would have to be smart enough to execute all the tactical parts of driving anyway. Adding remote piloting just adds more failure cases and complexity.

I am somewhat surprised it's not one of the actions you can customize on the hotbar. I have no doubts that if people complained about it, Tesla would add it.

You definitely don't want these systems intertwined. It has the side benefit of allowing you to do pretty aggressive things like using more modern hardware, software, etc. E.G. last time I checked, Tesla uses Godot for a decent amount of their UI.

Let's do completely discount remote pilots, please.

0) https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-5.ht...

In fact, it's even more wrong than that. The ability for managed runtimes to perform LTO across dynamic code loading means you're even able to get LTO across code your compiler has never witnessed - e.g. plugins written by 3rd parties.

I say this exact same thing to junior engineers who are acclimating to code reviews and might be suffering a bit from imposter syndrome.

I strongly agree that the safety comparisons aren't anywhere near the same ballpark. They are just too apples to oranges.

All that said, I don't think that means we can't evaluate whether they're safe in the limited contexts they're being deployed in. We just have to be aware those statistics are only as good as their context (weather, geography, terrain, traffic patterns/devices/laws, social norms, etc).

I'm initially most hopeful for constrained environments (city, low speeds, parking) and Waymo in particular, because of the house amount of investment and very thoughtful and cautious strategy in terms of deployment.

You can get lucky and sometimes avoid corruption, but eventually you're going to hit something important like leaving a libc heap allocator mutex locked when you kill a thread in the middle of an allocation.

What signal are you sending to the running thread? What's the handler look like? How does that translate to terminating the thread? How do you do this forcibly (without cooperation from user code)? Schemes that I have seen look more like generating/ instrumenting polling/checkpoints into user code.

For approximately two months, we had absolutely zero internet service, while Comcast continued to collect our monthly fees. We kept calling, and they kept sending out tech after tech. I don't recall what the final tech fixed, but they complained that all of the previous techs should have spotted the issue. We never got reimbursed for those two months of non-service, but we did magically start getting cable tv after the final tech visit. We figured it was their gesture of kindness for the Comcast hell we'd been through.