lhorie

(mithril.js author here)

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 </shrug>.

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.

There's many pockets in Toronto with high density of Chinese commerce, the area around Steeles east of the IBM campus is one. Pacific Mall mentioned in the article is only one of the commercial centers in the area. There's also Metro Square a few blocks west, the T&T plaza next door, Skycity on Midland/Finch, and various other small plazas around the area, full of Chinese food goodness.

No, it's operating profit.

That's a somewhat outdated narrative to still be parroting.

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

Uber has four office buildings in SF mission bay. One was never used, the other 3 were underutilized, so employees are going to be moved/consolidated into 2. These buildings also have street-front retail lease spaces, so presumably by having more people coming into the area, that increases foot traffic for those spaces as well.

Uber has several different APIs for users. A naive purist might think that's silly until you realize a rider is user, a driver is a user, a courier is a user, a restaurant owner is a user, a line cook is a user, a doctor's secretary is a user, a Uber employee is a user, a freight broker is a user, an advertising manager is a user... people can simultaneously be multiple types of users and have multiple profiles as a single type of user, and did I mention that you have to properly secure PII due to being in a high regulated industry? And that's just users.

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

Adding my two cents of positivity:

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.

I saw a video on YouTube recently from an independent content creator who went to look for these mythical sea nomads, and apparently what he found was that the idyllic scene of a remote tribe living off the land with highly refined but primitive fishing techniques was largely fabricated.

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.

JS has two top level grammars, one defaults to loose mode and the other defaults to strict mode, among other nuances.

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.

The "boring" way is go do some sales and get clients to pay for something, then scale up as cash flow increases. That way, if it doesn't work out, at worst you just lost time instead of being half a million in the red on a business loan.

Small update: It's definitely not extensions, it's giving the same result on two different devices (mobile and laptop). I've narrowed it down to there being something going on w/ being logged into specific accounts. On my work account, I get no results (and this is a query that used to return results under the exact same setup just last week). Trying on an old personal gmail account, I'm getting the UI localized to what seems to be mandarim for who knows what reason (I don't speak mandarim, and don't even use this account on a regular basis).

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 stumbling into this thread right after experiencing what appears to be a pretty catastrophic failure of Google's main product. As I write this, the search results for "Google stock" (among other queries) returns zero results ("Your search - google stock - did not match any documents").

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.

That's a strange way to frame it. Every skill is useful in some context. As a parent, I think a more productive way to think about it is to ask whether teaching kids anything is in line with your values. For me, I'd prefer if my kids were well rounded from being exposed to many different things, so they can make informed decisions later in life. That means they have lego mindstorms, but if they say they like tennis or they spend time drawing sidescroller games and not twirling to nutcracker ballet videos, then so be it. For some parents, laser focusing on something might be considered preferable.

Merge queues are, as the name implies, queues for pull requests/merges. They're kinda useless if your commit traffic is low (e.g. <10 per day), but become necessary once it grows past your daily CI time budget, roughly (which can happen on large monorepos).

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)