I was once in a waymo stopped at a red light. Prior to the light turning green I felt a split second where the car's brake had been released, anticipating the change and then accelerating immediately when the light changed.
Since this experience I've just assumed all waymos have some warehoused human drone pilot actually controlling it.
Physics. Have you ever played a competitive/reaction based video game with high ping? It is very, very hard. And it’s a game, where there are many tricks to hide latency from you.
Cloud console shows pings between Google data centers in us-west and ones that are in proximity of Philippines around 160-200ms. Then you also have inherent lag of wireless connection itself. Then you have also connectivity from google’s data center to Philippines.
If you want remote driving in uncontrolled environment, you reasonably can expect only the same city/county operators.
I’m obviously uninformed, but I’d expect the remote operators job (from another country) to be like “car is safe to proceed, based on that picture that I see” or, in the worst case scenario, put some waypoints in the ui and let car drive on its own.
> I was once in a waymo stopped at a red light. Prior to the light turning green I felt a split second where the car's brake had been released, anticipating the change and then accelerating immediately when the light changed.
This seems like it would be fairly straightforward to program, if not for all lights, at least for a lot (e.g. say half) of lights.
There are many other possibilities such as the system having learned the timings or another vehicle in the fleet observing the lights turn red at the other part of the junction.
The least likely possibility is a person controlling the vehicle directly over a variable latency connection that may fail completely at any time.
Behind all the new smart city tech I encountered here in Shenzhen and Shanghai are actually human operators (drones, cars, vending machines). You can find the job ads online.
I’m sure there are, but direct remote control of throttle, brakes etc in vehicles is _hopefully_ not part of that.
I could see certain situations where it could be authorised when a vehicle is stranded and unable to operate autonomously at all due to an error, but it would have to be extremely slow speed with a full-stop failsale on connection drop or high-latency detection.
That said I bet there are some who do not consider the safety implications and “move fast and break people”
The incentives for such a swapping system are completely busted.
Think of existing swap infrastructure out there, like propane tank swaps. People already use these systems to rinse defective or expired tanks all the time, and that overhead simply gets built into the price.
Now imagine if you could refill a propane tank at home by just plugging it in to your wall. The only reasons to use such a service are now exceptional cases like travel, or to move defective items.
For every new tank introduced to the supply, on average, how many good-for-good swaps will occur before the supplier gets a defective one? Take the cost of a new one and divide it by that average and that is the minimum overhead for a swap.
For batteries, that number is likely in the hundreds of dollars.
This is so simple and makes so much sense. I’ve seen a couple libraries that do something similar, but I feel like this is obvious and useful enough that it should just be a stock pattern, and it clearly isn’t.
Aside from what some other users have said, logging is fundamentally an observable side-effect of your library. It’s now a behavior that can become load-bearing — and putting it in library code forces this exposed behavior on the consumer.
As a developer, this gets frustrating. I want to present a clean and coherent output to my callers, and poorly-authored libraries ruin that — especially if they offer no mechanism to disable it.
It’s also just _sloppy_ in many cases. Well-designed library code often shouldn’t even need to log in the first place because it should clearly articulate each units side-effects; the composition of which should become clear to understand. Sadly, “design” has become a lost art in modern software development.
In Java world logging in libraries is effectively a no-op unless explicitly enabled by user, so side effects are negligible. And it actually does make sense, e.g. when a library is offering a convenient abstraction level over i/o, parsing or other stuff with initially unknown failure modes, where some logs may help clarifying the picture beyond handling an exception or error code. The way logging is done there is the art of good software design, which has never been lost (it may have not reached other platforms though). So I disagree with you and some other commenters: strict Verbot is dogmatic, and good design is never dogmatic.
It depends a lot on the language, but in my field libraries that have their own logging implementation and that don't provide hooks to override it cause big problems for me because I send all the logs to the same central logging client that forwards it to the same central logging server for aggregation. Your logging probably dumps it to a file, or it writes it to STDOUT, or something similar, in which case now I have to pipe all of that data in two places by doing something hacky.
There are some language ecosystems that have good logging systems like Java which I would be totally fine with. But systems languages like C/C++ that don't have a core concept of a "log message" are a pain to deal with when the library author decides to stream some text message somewhere. Which is probably a good argument for not using those languages in some circles, but sometimes you have to use what you have.
So it's not really a blanket "don't do it" but you should carefully consider whether there's some well-known mechanism for application authors to intake and manage your logging output, and if that doesn't exist you should provide some hooks or consider not logging at all except with some control.
The behavior of the library logging can be incompatible with the architectural requirements of the application in dimensions that are independent of the library functionality. It requires the user to understand the details of the library's logging implementation. Even if documented, design choices for the logging will automatically disqualify the library for some applications and use cases.
Is writing the log a blocking call? Does it allocate? Synchronous or async? What is the impact on tail latencies? How does it interact with concurrency? Etc.
For many people, the thing being substituted for an alternative is not "transportation into Manhattan", but more broadly "engaging in commerce in Manhattan"
What business or shopping trip into Manhattan is small enough that 9 dollars is a significant hurdle or increase in cost? It's there to disincentivize taking a car for no reason when you can use transit while being small enough to absorb if you have a reason to actually use a car.
reply