tonygrue

(Ex-Waymo) Waymo tries really hard to compare apples to apple miles, considering a number of dimensions (weather, speed limits of the roads the miles are on, the specific cities, and more). This is one of the things that they feel distinguishes them in the space.

The data on https://waymo.com/safety/ reflects these apples to apples comparison.

They’ve also, when possible, done comparisons of the Waymo driver to an ideally attentive human driver. https://waymo.com/blog/2022/09/benchmarking-av-safety/

The biggest challenge is in sourcing the data. A lot of these datasets don't exist or have to be developed.

(The article itself, mixes and matches stats which is a common thing in general media).

You could make a list of all the metadata and pass it through a LLM to determine the quantity. You’ll need some sanity checking but if you prompt it with some examples it will do well. (Done something very similar myself.)

You’re likely thinking of the Veritasium episode https://youtu.be/gMlf1ELvRzc?si=Qwevl2GwHCzSFcsQ

I share all your concerns. I considered mentioning them but figured I should keep my reply focused on idea of freeing people up isn’t inherently bad.

In particular zero sum resources like land ownership will be an increased challenge.

And our governments have been slow to respond to things like climate change and we could be slow to respond here.

My thoughts are a few:

There is a lot of undone labor in the world. In developing countries the middle class has drivers, cooks, housekeepers. That’s only possible due to inequality. With automation we can all get that.

These people with tons of help by and large live fulfilled lives. You find fulfillment in family, friendships, and non necessary creation (art, research, etc); whatever makes you happy.

But most of all, the Industrial Revolution made people think we’d all be idle and nothing can be further from those predictions. Many more people, and many more jobs, and most of the world still lives in relative poverty and various forms of insecurity and unmet material and labor needs.

Finally there are a lot of problems we have (thousands of health conditions, the environment, autocrats) that will prob take centuries to tackle even with ai, robotics, and being freed up from menial labor.

There is an argument that if you need in process multithreading you should use a different language. But a lot of people need to use python because everything else they’re doing is in python.

There are quite a few common cases where in process multi threading is useful. The main ones are where you have large inputs or large outputs to the work units. In process is nice because you can move the input or output state to the work units instead of having to copy it.

One very common case is almost all gui applications. Where you want to be able to do all work on background threads and just move data back and forth from the coordinating ui thread. JavaScript’s lack of support here, outside of a native language compiled into emscripten, is one reason web apps are so hard to make jankless. The copies of data across web workers or python processes are quite expensive as far as things go.

Once a week or so, I run into a high compute python scenario where the existing forms of multiprocessing fail me. Large shared inputs and or don’t want the multiprocess overhead; but GIL slows everything down.

For me the point of thinking like this is to remain centered and not freak out. I see some people who feel like ‘everything is going downhill and this is the worse time ever’ and that’s just not very grounded.

The benefit is that you can be optimistic that the hard work we’re putting in, more likely than not, might continue the progress. Even if there are blips along the way.

I’ve used ImGui with success. I specially was also using webgpu so I used the glfw+webgpu backends. I had to fix a few issues in both halfs of the backend and there remain some little interaction bugs (mostly because browsers capture some keychords and mouse actions and you have to work around a number of them).

ImGui makes a specific design choice and isn’t amazingly documented. I don’t think it’s a good choice for larger scale apps. But good for tools or UIs in games, etc.

Accessibility is a nightmare with pretty much anything skipping browser layout of course.

https://www.wizconnected.com/en-us/about-wiz and https://www.signify.com/en-us

Wiz joined Signify in 2019. Signify is the new name for Philips Lighting (post spin out from Philips).

In my first job, management purposely prohibited developers from using really powerful machines because we needed to make the software faster. The problem was it was hard to make the software faster because it was so slow to run, measure, and verify changes.

Those managers were eventually all let go and one of the first things new management did was buy us the most powerful machines they could find and institute performance regression tests that rachetted down. Each change could only keep the existing performance or make it faster. And changes that made it faster set the new watermark. Regressions required management approval.

After performance having been unimproved for a year, it was largely resolved in 6 months.

Since then I’ve been a believer that you give your developers nearly the fastest platform money can buy but then have automated, gatekeeping tests for your lowest target platform, with spot checking to make sure your tests reflect actual user experienced performance on that platform.

As an engineer who loves the moonshots it breaks my heart. The core problem however is that from a dispassionate investor viewpoint, the uber for Y companies are more understandable and are perceived to deliver larger results more quickly in aggregate. Even accounting for these public failures. And since the dispassionate investor really only cares about return (regardless of what most say) they don’t invest in long term, capital intensive, unproven business. There seems to be an opportunity for entrepreneurs who can market the moonshots better to investors and hire the people to execute on them. But those two skills are very rarely in the same person.

As the article alludes, lack of a build your own, flexible yet affordable desktop option seems to be a pretty deadly aspect.

Pretty much Mac owners are on laptops. Even in the PC world few laptops can power VR. Those that do tend to be bulky for cooling and have nVidia GPUs; both things which MacBooks seem unwilling to have.

Having a extensible desktop at 1k that supports nVidia would probably go a long way.

It has to survive the trip there, be mostly autonomous, and most importantly operate in the low atmosphere and harsh environment of Mars. All things no off the shelf design will get you.

Here are some highlights: https://solarsystem.nasa.gov/news/472/10-things-mars-helicop...

Not an expert, but some digging in on this indicates there is one species folks advice against (topical milkweed); otherwise the advice is a species native to your region.

Some sites out there can help you pick a milkweed for your region. [https://blog.nwf.org/2015/02/twelve-native-milkweeds-for-mon...] and [https://monarchjointventure.org/images/uploads/documents/Mil...]

In January I built a personal project on the web with Rust and had the positive experience I was hoping for. The efficiency of execution plus the cleanliness and memory safety of a modern language was the draw.

It took me a week of battling with the compiler to understand what I was doing, but afterwards it felt fairly natural.

My biggest hurdle was I went all in on async (the bikesheded, nightly feature). But a pet peeve of mine is that desktop apps were all async in the 90s and here we have webservers hoarding processes and threads, simply waiting on IO.

I quickly ran into the limits of Rust's async ecosystem. Hyper is an excellent library but there wasn't a webserver framework on top of it at the time. Now there is warp, so I intend to switch over to that from having rolled my own, but I hear some rumbling on reddit that it can lead to compiled size explosion, so gonna watch out for that.

For sql, I'm using mysql-async, but it seems like a single persons passion project. It's quite painful because even with the good libraries (serde) it feel broken to do so much hand writing of sql given the rich type information available in my structs. Everyone seems to use diesel but afaict it's incompatible with the async approach. This is my only real pain point right now.

The whole async ecosystem is still nightly and in flux all the time. Though, amazingly, it's worked quite well. It's clear the community has rallied behind it as most projects are on the bleeding edge. But hiccups happen such as mysql-async not yet supporting the new, nearly-stable version of futures.

Another pain point i've run into is there aren't great crypto libraries. Some very incomplete pure rust stuff. Some poorly documented wrappers of c stuff.

Finally, a third party web api I'm interfacing with doesn't have a rust library so I had to roll my own.

For other random needs I've been surprised by how often I find a great library. AWS libraries, for example, are surprisingly good.

My conclusion is that for web backends rust isn't plug-and-play yet (especially if you want to go all async). But it's pretty darn close.

And yeah, it's crazy fast. Like working in Modern C++ but with iron clad memory safety.

I've built plugins with VSTO (for Outlook) when I was at MS, but my memory is that it’s dependent on a plugin being distributed and not available for native use embedded into the excel workbooks.

You have to install Visual Studio, compile a plugin, register the plugin, and then from VBA you can call out to that COM interface if you'd like. Even if Excel users could overcome those hurdles, you still break the collaboration flow (i.e. just sharing an excel file).

Looking a little deeper, it looks like they're starting to support Javascript for the newer cross-platform add-in system (and also VSTO), but it looks like you still have to distribute your JS add-in via a web-service as opposed to being fully integrated into Excel and XLSM files.

The bit of just being able to share the XLSM file and users using Excel with no other installs or special network access, is really the make or break for me and non-professional programmer user scenarios I've seen.

I'd be over the moon to see one change to Excel. Native support for a language other than VBA. Perhaps the CLR. Perhaps Java/Typescript. Just something (optional) for programmers who want to use Excel and not want to deal with the garbage that VBA is.

Some workarounds exist, but afaik they require collaborators to also have the tool install, which is dead in the water.

I know MS has considered it, I'm still pretty surprised they've haven't followed through.

Have you tried Alpaca (https://alpaca.markets/)? As I understand their pitch they're an API based brokerage with free trades similar to Robinhood. Not my space / haven't tried them, be interesting to see if they meet your requirements.

> More than one square mile, in Silicon Valley.

I was momentarily outraged, until I found it on a map. The San Andreas fault runs _right_ through the center of the property. Makes me glad it's basically a garden now and not a housing development =)

Paper here: https://arxiv.org/pdf/1903.07291.pdf

Page 14 and beyond show a number of examples vs previous methods.

IIUC, their contribution is a masking normalization layer (the 'SPADE' layer [see pg 4]) that allows the network to preserve the structure of the input segmentation/mask, leading to results quite a bit nicer than previous ones.

For me depends on what the knowledge is.

About Code: The only way I've found that works is comments in the code itself (or docs generated from code annotations).

Processes: Playbooks and Automation. Playbooks - DropboxPaper/Google docs that anyone can edit with things like "How to Build and Push XYZ Component", "What to do when the XYZ Server stops responding". Automation - When feasible turn the most used playbooks (or pieces of them) into scripts/tools. Make them the default way of doing things; and any time a break is discovered, fix the tool instead of working around it. Remove outdated/unused tools, so it doesn't feel like a wasteland.

Knowledge on how we do things: You don't want to write docs about 'how to do XYZ'. It will quickly be out-of-date and it'll be horribly micromanagey. But if you and your team collaborative define and document your team values or project/codebase/module principles, I've found you can onboard people quickly and reduce communication. They key here is referencing to the documents when you make a decision guided by them, to keep the docs fresh in peoples minds. And to regularly update the docs.

Wunderlist is where I landed 5 years ago after many failed alternatives. I like that it’s primary interface is a simple entry box with an add button. I can review my ideas periodically and add more detail. It’s very cross platform and very simple; and in the years I’ve used it the app hasn’t experienced the typical feature bloat.

afaict, this study looked at only two instances of fortune 500 companies who moved some people to open office plans and compared them to those who were not moved.

Additionally, they measured 'interactions', which was a self defined metric that afaict has no grounding in anything.

I'm not sure if one of two Fortune 500 companies, used to working in an office, generalizes to me. So, I'm not sure how much I personally weight the outcome of this study.

I've worked in both offices and open office plans, and there were things I did and didn't like about both. Offices required more formal mind-melding but I had more concentration time during peak business hours. Pit allowed me to feel more camaraderie, but required me to work off hours to get concentrated work done. If it were up to be I'd do 3 days in an office and 2 days in a open pit.

My guess is that the more detailed, dense map allows the car to precisely localize itself by using its view of the world to match against the map, yielding a location more precise than GPS (and for when gps doesn’t work); eg ICP point cloud matching/alignment/registration. More sparse maps would give you a less confident match, and you’d have to convert what the car is seeing to the sparse form.

As you speculate, some lines of research address aging by keeping you young. Your DNA is kept young, and as a side effect your muscles are kept young and the ability to quickly recover from injury is restored, like a 20 year old, instead of a 60 year old. I assume this strategy would also protect you from a number of diseases related to DNA aging. Of course, I also assume it wouldn't be a cure all, and we'd still need to address wear and tear in multiple ways.

https://www.sciencedaily.com/releases/2017/03/170323141340.h...

Something I’ve learned recently is that Target price matches amazon (and a number of other sites). It’s basically turned Target into a same day pickup Amazon warehouse for me. Yes, I’ve got to get to Target; but sometimes I want something the same day anyway, and even more crucial, I have a lot more confidence stuff isn’t counterfeit. (In this case though I’m sure they don’t sell this luggage brand :/)

(I worked on an early version of PyAnnotate.)

The main difference is that pytype is a static analyzer (i.e. it inspects the code and tries to figure out what types various things are), whereas PyAnnotate is a profiler hook, so you have to run your code and it observes types as your code runs.

Both have their pros and cons. While static analysis (in my personal opinion) would be ideal because you don't have to run your code, and in theory it can be much more complete, it's also much harder (often impossible) in Python. The runtime analysis of PyAnnotate has a lot of downsides (it doesn't give you types for code that it didn't observe run and it can't know if it has seen all the particular types for a parameter or return). The upside is that it was quick to implement something useful and it gets you quickly to pretty descent type annotations for your main code paths. Which is nice, because in a large untyped codebase it effectively lays down a rough draft of type annotations, making it a lot easier to fix up and fill in edge cases by hand.

I had to do a double take on the third letter after reading the return address of Microsoft Way. At first I thought Microsoft was issuing NSLs. Turns out the FBI and Microsoft happen to be next door neighbors in Charlotte. I feel like Microsoft ought to consider giving up the street name.

The short answer is yes, we use a fair amount of C++, and yes, we've eliminated writing the JNI code for developers on the team. We're planning on writing more about both of these topics in a future blog post and we're interested in sharing our tools with the community, though it will take some work to make them less specific to our code base.

Also amusing, WebGL is provided as an example of why perf is good, but is it really part of HTML5? The assumption that it is appears to be another myth.

http://www.w3.org/TR/html5/ http://stackoverflow.com/questions/10185554/is-webgl-part-of...