As far as I can tell, the main difference is this uses proxies to trigger side effects as opposed to virtual dom diffing. Perf wise, I like that people are pushing the boundaries, but also obviously React is still very popular and that indicates that its level of performance is good enough for a lot of devs .

In terms of features:

- This was already pointed out in another comment, Aberdeen doesn't seem to be JSX compatible, but it supports similar hyperscript-like syntax (e.g. $('div.foo:hi') vs m('.foo', 'hi'))

- Unclear what the level of support is for various features that exist in Mithril. e.g. Router appears to be an add-on/example, and I don't see anything about HTTP request utils or SVG/MathML. Mithril is meant to be sort of a one-stop shop for SPAs; it could just be that the focus of the two libraries is slightly different, and that's ok if that's the case.

- Mithril has hooks to access the raw DOM and uses RAF for batching, it's not clear to me how integration w/ other DOM-touching libs (e.g. dragula) would work here.

I like the idea of using proxies as a way of implementing reactivity in principle, and I even played around with that idea. IME, there were a couple of things that made it problematic w/ POJO models IMHO. The first is that proxies are not friendly to console.log debugging, and the second is that implementing reactivity in collections (Map/Set/Weak*) was getting a bit too complex for my minimalist tastes.

Uber just got included into the SP 500. One of the pre-requisites for that is being profitable on a GAAP basis.

Don't even get me started on anything money related :)

I love seeing language projects that implement their own compiler backends. There really aren't enough of these around. Anything that helps bridge the knowledge gap between newbies and production grade compilers is a net positive in my books.

And extra brownie points for writing it in C. Think whatever about memory safety and language age but C code is abundantly explicit about what's going on with the code, which is something I really appreciate when approaching some new code to learn stuff.

The locals were alegedly just going along with the westerner film makers, partly because in their eyes, participating in a mockumentary was an amusing opportunity that doesn't come along every day.

He then tried to get them to show him how they really fish, and it turns out they use modern gear like flippers and wet suits but also do incredibly dangerous things like breathing out of a tube connected to a machine on a small boat in the middle of the night.

The video doesn't get into the exact science, but it also looks like the fishing isn't sustainable either, as divers reported needing to progressively dive deeper/take bigger risks over time to find high yields.

Possibly the most devious nuance is whether the spec's appendix B applies, which affects whether html comment syntax is valid (yes, this is a thing). The html comment token can therefore be parsed either as a comment or as a series of operators depending on the grammar being used.

Effectively, this means it's possible to craft a program that does different things in CJS vs ESM mode.

As for why this happens, I have no idea. I've had Google Maps completely black out on me and then eventually magically fix itself many months later.

As for reliability, I would probably have agreed if it was a "simple" system (which the original Google was). Today, I'm not so sure. I at least understand that Google today is made up of a large number of subsystems, and subsystem failures like the ones I'm experiencing (and bad search results as others have also reported) do in fact erode my trust in the product. "Your 99.9% is not my 99.9%" feels like an apt quote here.

I'm not really sure what to make out of these discussions about how X or Y Google engineering is, while the production service is broken for an end user like me.

Uber's[0] implementation, for example, does some more sophisticated speculation than just picking up whatever is sitting on the queue at the time.

Queues come with quirks, e.g. small PRs can get "blocked" behind a giant monorepo-wide codemod, for example. Naturally, one needs to consider the ROI of implementing techniques against aberrant cases vs their overall impact.

[0] https://www.uber.com/blog/research/keeping-master-green-at-s...

As a very simple example, if your CI takes 10 minutes, your CI time budget is 6 merges per hour.

This is because if you merge two things in parallel without validating CI for the combined changes, your main branch could end up in a broken state.

Merge queues run CI for groups of PRs. If the group passes, all the PRs in the group land simultaneously. If it does not, the group is discarded while other group permutations are still running in parallel.

This way you can run more "sequential" CI validation runs than your CI time budget allows.

In our monorepo, we get a volume of 200-300 commits per day with CI SLO of 20 mins.

Without a queue, our best case scenario would be getting capped at ~72 commits per day before seeing regressions on main despite fully green CI (in real life, you'd see regressions a lot earlier though because throughput of PRs is spiky in nature)

As terrible as a pedestrian death is, the reality is there's news about Tesla accidents and near-accidents on the news all the time and people still love the brand. Sometimes it's easy to forget that Uber/Amazon/M$/etc hating is not as widespread in the general population as it is among tech bros.

As for Otto, my understanding is Uber pivoted similarly on the freight side, with a partnership w/ Volvo Autonomous Solutions.

Uber has pivoted to doing partnerships with any self driving player that is looking for a customer base. Waymo doesn't have the tech nor the desire to figure out logistics to compete with Motional or Cartken in the delivery space, for example. None of these players can instantaneously ramp up to millions of vehicles on the road; they physically don't have enough hardware and the age of money burning for growth at all costs is behind us. I can't imagine Waymo has bigger utilization than Bolt, or even Alto.

The way I see it, Uber is more like McDonalds: "easy" to copy from conceptual perspective but also a globally recognizable brand with an undeniably strong customer acquisition arm.

Waymo still has a lot to prove to themselves in terms of ROI. Customer acquisition would be even more expenses on top of the already expensive tech, partnering with Uber to offload these costs to a proven customer acquisition player makes sense for them.

IME, yes there's comparatively far more CRUD roles than platform roles. But bluntly speaking as someone who's been on both sides of the fence, platform roles are not for everyone. For these roles, there is a expectation of quality by very technical stakeholders and this creates some pressures and incentives that don't necessarily exist in orgs that cater to non-technical faceless stakeholders.

In practice, a big challenge is to avoid being someone who is "not hardcore enough" (i.e. incapable of implementing large scale reusability due to lack of ability, tendency to cave to timeline or other pressures, or distaste for "office politics") but also avoid being "too hardcore" and being constantly in the weeds chasing some cool clever idea that might not align w/ overall picture.

One thing that is often overlooked in open source projects with sizable communities is the amount of cat herding you need to do. People have all sorts of ideas for "features and improvements" and sometimes your job as a BDFL may be to say "no" to your most ardent supporters. This also happens a lot for staff level platform work.

My two cents is US people are the ones who have an unusual take on the word "America". Outside the US, it's not very idiomatic to call the country "America", or even "USA". "US" is more common (and in both Spanish and Portuguese, it's almost always called "Estados Unidos").

The term "american" is mainstream both in Canada and elsewhere. I imagine that's probably at least partly a function of "unitedstatesman" being too much of a mouthful. (BTW, if you think that's a ridiculous word, in portuguese "estadounidense" is an actual word, albeit with a connotation of being something a "woke" person might say).