Google Chrome is using a Rust implementation. The existence and sufficient maturity of it is the reason they were willing to merge support in the first place.

Hmmm, check the jxl-rs repository. I wouldn’t call it mature. Not to say it’s buggy, but most of its code is very fresh.

JS/TS isn't my favourite language, but it's pretty decent these days. If I'm picking a different language and targeting the web, it's probably because I want to run the same code natively as well.

In Elixir you just call the Erlang function directly. It's basically the same as calling an Elixir function, just with a different naming convention.

In Gleam, you first have to declare the function type and THEN you can call the function directly.

This is probably the lightest way you can bridge between statically and dynamically typed languages, but it's not the same as Elixir.

Sorry, I've been unclear.

The runtime behaviour and cost of calling an Erlang function is the same in Elixir and Gleam, however the syntax is more verbose in Gleam as it asks for type information, while in Elixir this is optional.

> A vigilant C programmer who manually validates everything and use available tools at its disposal is less risky than a complacent Rust programmer who blindly trust the language

I agree with this. But for a component whose job is to parse data and produce pixels, the security worries I have are memory ones. It's not implementing a permissions model or anything where design and logic are really important. The security holes an image codec would introduce are the sort where it a buffer overun gave an execution primitive (etc.).

Rust programmers are far more likely to have the vigilant mindset than C programmers, or they wouldn't be using Rust.

You can get an awful lot done very quickly in C if you aren't bothered about security - and traditionally, most of the profession has done exactly that.

Possibly. It's the only way it actually works though, because of the Peter Priciple.

Imagine the other way - you have peopel dong a role, and the people who do the best job at that role get promoted to the next one. Some of them will be good and the new role, some of them won't. The ones who are good will carry on getting promoted. The ones who aren't will get stuck in that role. The problem is that everyone rises to a point at which they can't do the job, and every role is filled by someone who has been promoted one step too far.

In a healthy structure, it should be a halfway house - you shouldn't have to be doing the whole job that you're trying to get promoted to, you should be doing enough bits and pieces of it that you demonstrate that you CAN do it. That way the company has information that they're not promoting you to a position of incompetence.

Wayland is a significant improvement in one specific area (and it's not this one).

All programs in X were trusted and had access to the same drawing space. This meant that one program could see what another one was drawing. Effectively this meant that any compromised program could see your whole screen if you were using X.

Wayland has a different architecture where programs only have access to the resources to draw their own stuff, and then a separate compositor joins all the results together.

Wayland does nothing about the REST of the application permission model - ability to access files, send network requests etc. For that you need more sandboxing e.g. Flatpak, Containers, VMs

I think this article is missing the point a bit.

It's saying that the action of calling an async function (e.g. one you've written) isn't itself a yield point. The only yield points are places where we the call would block for external events like IO or time - `await asyncio.sleep(100)` would be one of those.

This is true, but surely fairly irrelevant? Any async function call has somewhere in its possible call tree one of those yield points. If it didn't then it wouldn't need to be marked async.

A good manufacturing process (with the appropriate level of testing) should result in yield variations, not quality variations. i.e. if the line is running less well for some reason, then you end up throwing more in the bin rather than shipping bad product.

I would only consider doing stuff on-prem because of services like Cloudflare. You can have some of the global features like edge-caching while also getting the (cost) benefits of on-prem.

That's not what they're demanding (or at least, that's only one way of giving them what they're demanding).

A legal guarantee that they'll allow people to configure their watches for an alternate app store would probably be sufficient, for instance.

I agree, I think that’s the intended interpretation — but I’m disappointed that’s not their stated redline then, though.

The ask there is for a future in app stores beyond Core Devices, not just for Rebble specifically. That is a call for Core to open their platform; what they have now is a call for Core to open their platform to them.