No, I'm not sure if I've heard of that one. Will check it out.
Immediate reservation about Parsec is that it requires internet access to its cloud services for authentication, session discovery, and connection setup. For me, that immediately sucks, but I'm still going to give it a go to see how low latency it is.
I have used Sunshine/Moonlight for gaming in the past and it was fantastic, but for whatever reason it was janky to use for remote desktop.
I don’t want to hijack Evan’s post by posting a link, but if you’re interested I’ve implemented many of the ideas in that presentation in the language I’m working on. You can check out the latest link in my post history for a rundown of how it works and a demo.
I am on a $3k Macbook and scrolling on shaders.com yielded a few frames of blank screen jank before the rest of the page rendered. This is unacceptable performance for serious websites, but I appreciate the new heights that webshit attains each year.
The history of Web 3D APIs since their inception, regardless of the platform.
As the websites have no control what the browser does, it is a guessing game on how they actually perform on the client side, versus native applications that can work around possible bugs or various kinds of available hardware.
Personally (on Safari) I see the whole page load then the shaders appear after a short delay. Not ideal and I imagine possible to mitigate with loading a static image in the HTML then replacing it once the JS kicks in.
my understanding is Polars is faster, scales better without using external solutions, better API, +Rust. Pandas wins if you want to use what the vast majority of folks are using and have used in the past. Probably has a more complete set of helpers / recipes for the little things you bump into when using it thoroughly, but in the age of LLMs, I think that's minor.
>Pandas wins if you want to use what the vast majority of folks are using
Vast majority of skilled developers are now using Polars, unless they are constrained by lack of Narwhals support in their third-party library of choice (e.g. Great Expectations, SHAP). That's the more important trend to follow.
I also found myself reading the manual all the time.
I have a toy project I use for learning different tools. Given a CSV containing every MLB game ever played, calculate the win percentage for each team during its first season.
Pandas makes that kind of simple thing painfully unintuitive. Tools like Polars and dplyr and even SQL require code that's far closer to how people think.
Learn SQL and interface with Duck. You will be 100x faster than Pandas/Polaris duo at fraction of memory. Also SQL is supported literally everywhere with a much more capable than Pandas API. Duck outputs to a Pandas Dataframe, but just treat that like a dictionary. Do all your processing, filtering and aggregation in Duck.
Also, try fx.wtf as a replacement for jq. it comes with a in-built tui viewer that supports vi-keybindings. Ecmascript is built into fx.wtf so you can query the JSON with JS notation (where JSON was born). You can use any JS functions including map/reduce/filter or perform any kind of transformation instead of learning jq dsl that you will forget tomorrow.
Well if any labs want to scrape my knowledge of such things into model weights or faster training runs, I do consulting at movsoft.io :-)
It really is [as simple](https://github.com/ratatui/ratatui/pull/281#issuecomment-160...) as the Molly rocket video about terminals makes it seem; I am sure the models will catch up eventually. They have to overcome a lot of bad training data in most languages, but I find in Rust they usually do ok the first time.
reply