It looks very likely chromium will be using jxl-rs crate for this feature [0]. My personal suspicion is that they've just been waiting for it to good enough to integrate and they didn't want to promise anything until it was ready (hence the long silence).
That was Mozilla's stance. Google was thoroughly hostile towards it. They closed the original issue citing a lack of interest among users, despite the users themselves complaining loudly against it. The only thing I'm not sure about is why they decided to reopen it. They may have decided that they didn't need this much bad PR. Or someone inside may have been annoyed by it just as much as we are.
PS: I'm a bit too sleepy to search for the original discussion. Apologies for not linking it here.
> The only thing I'm not sure about is why they decided to reopen it.
It's almost certainly due to the PDF Association adding JPEG XL as a supported image format to the ISO standard for PDFs; considering Google's 180 on JPEG XL support came just a few days after the PDF Association's announcement.
That would make sense, since they would then need support for JXL for the embedded PDF viewer anyway. Unless they want it to choke on valid PDFs that include JXL images.
I see! Thanks for pointing out this very interesting correlation. So we got something better only because someone else equally influential forced their hand. Otherwise the users be damned, for all they care, it seems.
I have been relentlessly shilling JPEG-XL's technological superiority especially against their joke of an alternative and a stain on the Internet they call WebP
I designed WebP lossless alone. The rest of the WebP folks added a RIFF header and an artificial size limitation (16383x16383) to match with the size limitation of lossy WebP.
In JPEG XL I believe I had more influence on the lossy ("VarDCT") format than anyone else, but stayed relatively far from the lossless part (except the delta palette, two predictors, 2d lz-codes, and a few other smaller things). I believe Jon and Luca had most influence there.
"Code frequency" for jxl-rs shows no activity from Aug 2021 to Aug 2024, then steady work with a couple of spurts. That's both a longer hiatus and a longer period of subsequent activity (a year+ ago isn't "recently" in my book.) What data have you based your observation on?
Pebble watches run on Cortex-M microcontrollers which have less than 1MB of flash storage and RAM, I like Kotlin multiplatform but getting it to run on them is extremely unlikely. I assume that for the foreseeable future Pebble apps will be only written in languages which are traditionally used for MCUs like Rust and C\C++
Calling rust traditional is a bit of a stretch, while it is being done it's pretty much bleeding edge (though if you do not use any of the manufacturer supplied code and libraries to begin with you should be fine).
It is honestly refreshing to see constraints like this again.
In my cloud infrastructure work (C++), we have gotten lazy. We bloat our containers because 'RAM is cheap'. Seeing a system designed to fit into 1MB reminds me that performance engineering used to be about efficiency, not just throwing more hardware at the problem.
I find this a little funny because as a firmware engineer the project I regularly work on only has 512kb of flash. This doesn't stop sales from constent new feature requests.
Embedded is definitely a fun balance of what we could do and how much we can do.
Rust moves are a memcpy where the source becomes effectively unitialized after the move (that is say it is undefined to access it after the move). The copies are often optimized by the compiler but it isn't guaranteed.
This actually caused some issues with rust in the kernel because moving large structs could cause you to run out the small amount of stack space availabe on kernel threads (they only allocate 8-16KB of stack compared to a typical 8MB for a userspace thread). The pinned-init crate is how they ended solving this [1].
With enough effort you could definitely do it. Just remember it is a device that came out in 2006 and it has 256MB of system RAM and 256MB of VRAM, at best you're running a quite small model after a lot work trying to port some inference code to CELL processors. Honestly it does sound a cool excuse to write code for the CELL processors, but don't expect amazing performance or anything.
This is a very important point, careful use of GCs for a special subset of allocations that say have tricky lifetimes for some reason and aren't performance critical could have a much smaller impact on overall application performance than people might otherwise expect.
Yeah, and it's even better if you have a GC where you can control when the collection phase happens.
E.g. in a game you can force collection to run between frames, potentially even picking which frames it runs on based on how much time you have. I don't know if that's a good strategy, but it's an example of the type of thing you can do.
It looks like the API of Alloy was at least designed in such a way that can somewhat easily change the GC implementation out down the line and I really hope they do cause Boehm GC and conservative GC in general is much too slow compared to state of the art precise GCs.
It's not an implementation thing. It's fundamental. A GC can't move anything it finds in a conservative root. You can build partly precise hybrid GCs (I've built a few) but the mere possibility of conservative roots complicates implementation and limits compaction potential.
If, OTOH, Alloy is handle based, then maybe there's hope. Still a weird choice to use Rust this way.
We don't exactly want Alloy to have to be conservative, but Rust's semantics allow pointers to be converted to usizes (in safe mode) and back again (in unsafe mode), and this is something code really does. So if we wanted to provide an Rc-like API -- and we found reasonable code really does need it -- there wasn't much choice.
I don't think Rust's design in this regard is ideal, but then again what language is perfect? I designed languages for a long while and made far more, and much more egregious, mistakes! FWIW, I have written up my general thoughts on static integer types, because it's a surprisingly twisty subject for new languages https://tratt.net/laurie/blog/2021/static_integer_types.html
> We don't exactly want Alloy to have to be conservative, but Rust's semantics allow pointers to be converted to usizes (in safe mode) and back again (in unsafe mode), and this is something code really does. So if we wanted to provide an Rc-like API -- and we found reasonable code really does need it -- there wasn't much choice.
You can define a set of objects for which this transformation is illegal --- use something like pin projection to enforce it.
The only way to forbid it would be to forbid creating pointers from `Gc<T>`. That would, for example, preclude a slew of tricks that high performance language VMs need. That's an acceptable trade-off for some, of course, but not all.
Not necessarily. It would just require that deriving these pointers be done using an explicit lease that would temporarily defer GC or lock an object in place during one. You'd still be able to escape from the tyranny of conservative scanning everything.
If you're curious the only brand I could find easily purchasable in the USA that uses borosilicate glass is oxo. Their are some other results if you do a search on amazon, but I'm not very convinced those are really borosilicate glass.
You can relatively easily check this before buying, just look for the tint (usually best seen on the edges of the glass). Blueish = borosilicate, greenish = soda lime.
Why wouldn't it be possible? All it really means is that you need to do the work to make incremental entirely on the local side and not on the remote side.
[0] https://issues.chromium.org/issues/40168998#comment507