Will be interesting to see how it fares when it does come to the US. It seems like there are some cars that already have the tech installed. But the US is allegedly more interested in the cellular version, which I am guessing is not as easy to pick up with a simple receiver?
My gut feeling is that this seems like one of those things likely to face a lot of backlash when it becomes widely known.
I guess we only find out if some people order those chips and check if there is some data. From my understanding the idea is the same like maps showing air planes or ships (for ships it’s AIS). So without volunteers/pioneers who participate we won’t know. It seems like traffic lights and trams also can send data.
Yes, I was planning a similar experiment with UCall (https://github.com/unum-cloud/ucall), leveraging the NUMA functionality introduced in v2 of Fork Union. I don’t currently have the right hardware to test it properly, but it would be very interesting to measure how pinning behaves on machines with multiple NUMA nodes, NICs, and a balanced PCIe topology.
That's outrageous.. and I don't agree with your assessment, because smol is in the same niche as Tokio (that is, an async execuutor, which isn't necessarily optimizing for CPU-bound workloads) and isn't nearly as slow.
I think performance is a very critical property for Rust infrastructure. One can only hope that newer Tokio versions could address overheads which make everyone slower than necessary.
Thanks! Maintainer of MOTIS here. We're planning to bring support for NeTEx, SIRI and OJP to MOTIS and with those formats a lot of features that are only available with those formats but not with GTFS(-RT) (yet). But having them implemented will also help us to quickly activate them for GTFS(-RT) once GTFS(-RT) gains support.
IMO it's safe to say that Elm is dead and won't come back with this attitude of the core team (which is not the only problem of the language). We never switched to Elm 0.19 from 0.18 but moved on to rewrite in Svelte 5 with TypeScript and never looked back.
I saw these threads pop up here and there over the years, always funny to read comments (even in this very thread!) about how (paraphrasing) "good ideas take time" and "the creator shouldn't add everything people are asking for into the language," meanwhile the last release is still 0.19 in 2018 and I honestly don't know what Evan and the core team have been doing with regards to Elm since then.
There's a vast gulf between being prudent with feature additions, and doing effectively nothing at all. Of course a language that preaches the former but materializes the latter would die sooner or later, as people get fed up with the lack of updates. And in the meantime, TypeScript just gets better and better.
Like even no updates since 2018 might be ok if Evan et all communicated more about the goals and direction of the project
Evan especially wrote and spoke a lot about his philosophy re: the project which I think can be fairly summarized as “everyone just sit down and shut up.” But that’s not a lot to go on when trying to evaluate if a project has staying power, mature governance, and so on.
Just found this and couldn't find anything about it but it looks interesting. Does anyone have experience with it? Seems like a competitor to CUDA from AMD and Intel?
Regarding the size I would guess that if htmz would be extended to have the same features as htmx, it would also be similar in size? Would it make sense to modularize htmx in order to only pay for what you really use to support adding features without necessarily increasing the downloaded size?
I think you could do a smaller htmx by dropping a lot of the event and config stuff & adopting modern tools that produce smaller javascript. Clever use of JavaScript features could probably knock it down as well, but i'm anti-clever in most cases. As it stands, htmx is ~17ms to download over slow 4G and should be cached after the first download, so, while I wish I could make it smaller, every time I've tried to it ends up not moving the needle too much.
We are going to get a chance to remove all the IE-related syntax in 2.x which should help a bit.
Looking at the benchmark where C++ is worst compared to other languages, it's depending on the library used. I would guess if they used Google's re2 Regex library instead of Boost's, the result would be different.
