I am getting really tired of github. outages happen that's a given. but on so much stuff they don't even care or try. Github is becoming the bottleneck in my agentic coding workflows. unless I make Claude do it intelligently, I hit rate limits checking on CI jobs (5000 api requests in an hour). Depot makes their CI so much better, but it is still tied to github in a couple of annoying places.
PRs are a defacto communication and coordination bus between different code review tools, its all a mess.
LLMs make it worse because I'm pushing more code to github than ever before, and it just isn't setup to deal with this type of workload when it is working well.
> I am getting really tired of github. outages happen that's a given. but on so much stuff they don't even care or try. Github is becoming the bottleneck in my agentic coding workflows. unless I make Claude do it intelligently, I hit rate limits checking on CI jobs (5000 api requests in an hour). Depot makes their CI so much better, but it is still tied to github in a couple of annoying places.
Have you ever considered that this is the problem? GH never planned for this sort of pointless and unpaid activity before. Now they have a large increase (I've seen figures of 100x) in activity and they can't keep up.
It doesn't help that almost none of the added activity is actually useful; it's just thousands and thousands of clones of some other pointless product.
It helps with latency too or schedule padding. Bus schedules are unreliable because of all the stops which slow them down and encourage bunching of busses on a route with a lot of service.
Bus bunching is often blamed on traffic or scheduling, but in my experience in NYC, a lack of enforcement and/or accountability plays a role too. I live near one end of a bus line and commute to the other end 5 days day a week. On a daily basis, there are large gaps where buses miss their scheduled times. Then, as they approach the end of the line, they arrive and depart in groups of three or four, which only worsens the problem.
I started writing a program that needed to have a table with 1 million rows. This means it needs to be virtualised. Pretty common in GUI libraries. The only Rust GUI library I found that could do this easily was gpui-component (https://github.com/longbridge/gpui-component). It also renders text crisply (rules out egui), looks nice with the default style (rules out GTK, FLTK, etc.), isn't web-based (rules out Dioxus), was pretty easy to use and the developers were very responsive.
Definitely the best option today (I would say it's probably the first option that I haven't hated in some way). The only other reasonable choices I would say are:
* egui - doesn't render very nicely and some of the APIs are amateurish, but it's quick and it works. Good option for simple tools.
* Iced - looks nice and seemed to work fairly well. No virtualised lists though.
* Slint (though in some ways it is weird and it requires quite a lot of boilerplate setup).
All the others will cause you pain in some way. I think the "ones to watch" are:
* Makepad - from the demos I've seen this looks really cool, especially for arty GUI projects like synthesizers and car UIs. However it has basically no documentation so don't bother yet.
* Xilem - this is an attempt to make an 100% perfect Rust GUI library, which is cool and all but I imagine it also will never be finished.
I wouldn't bother watching Makepad. They're in the process of rewriting the entire thing with AI and (it seems to me) destroying any value they has accumulated. And I also suspect Xilem will never be finished.
Beyond egui/Iced/Slint, I'd say the "ones to watch" are:
* Freya
* Floem
* Vizia
I think all three of those offer virtualized lists.
Dioxus Native, the non-webview version of Dioxus is also nearing readiness.
> * Makepad - from the demos I've seen this looks really cool, especially for arty GUI projects like synthesizers and car UIs. However it has basically no documentation so don't bother yet.
Have you seen their intro that also has an image viewer building tutorial?
Unfortunately, it seems GPUI is no longer in development.
Iced looks great, but the developer is very open about it being a personal project (https://book.iced.rs/philosophy.html). That is appreciated, but for companies or even individuals wanting to adopt it, it's a big hurdle to get across.
I’m currently writing an application that uses virtual lists in GTK: GtkListView, GtkGridView, there may be others. You ruled out GTK because of its looks I guess, I’m targeting Linux so the looks are perfect.
Not just because of its looks to be fair. Not being native Rust is a pain, and GTK only really works nicely on Linux. At least without a ton of effort to fix everything (I think some apps like maybe Mypaint have done that, but I don't want to).
Def agree. It feels unnatural to be using gobject in Rust. Refcell everywhere. But the end result (at least on Linux) is fast, well integrated and looks nice.
Yeah, I need cross platform, and GTK looks quite foreign on Windows/macOS IMO. I toyed with custom themes, but couldn't find any I liked for a cross platform look (wanted something closer to Fluent UI).
I've been somewhat involved in a project using Iced this week, seems pretty reasonable. Not sure how tricky it would be to e.g. invent custom widgets though.
I believe latest Iced versions do have a `Lazy` widget wrapper, but I believe that effectively means you need to make your own virtual list on top of it
Custom widgets aren’t particularly hard to do in iced, but I wish some of those common cases would be committed back / made available.
Except the above virtualised lists, another case I hit was layered images (sprites for example). Not very hard to write my own, sure, but it’d be nice to have that out of the box as in eg. egui
That's a great idea, and I was just thinking about how it would pair with self hosted CI of some type.
Basically what I would want is write a commit (because I want to commit early and often) then run the lint (and tests) in a sandboxed environment. if they pass, great. if they fail and HERAD has moved ahead of the failing commit, create a "FIXME" branch off the failure. back on main or whatever branch head was pointed at, if tests start passing, you probably never need to revisit the failure.
I want to know about local test failures before I push to remote with full CI.
automatic branching and workflow stuff is optional. the core idea is great.
> automatic branching and workflow stuff is optional. the core idea is great.
I'm not sure if I fully understood. But SelfCI's Merge-Queue (mq) daemon has a built-in hook system, so it's possible to do custom stuff at certain points. So probably you should be able to implement it already, or it might require couple of minor tweaks (should be easy to do on SelfCI side after some discussion).
I can't take this comment seriously unless you are buying snow tires. If you have snow tires, and you still can't get where you want in the winter, sure get 4wd.
I had a RWD pickup with snow tires and went anywhere I wanted to through two utah winters and many vermont ones too.
I wish more programmers would pay attention to how productive power users in different can be with their tools. Look at CAD competitions. I wonder if there are video editting competitions?
I used to work as technical director for a touring live graphic design, 3D modeling, and animation tournament. It was kind of like iron chef for designers. They worked live in timed rounds with their screens projected overhead. It was sponsored by Adobe, Autodesk, and Wacom. It was pretty impressive to see how power users did their thing for sure.
Programming efficiency isn’t about typing/editing fast - it’s about great decision-making. Although I have seen the combo of both working out very well.
If you focus on fast typing/editing skills to level up, but still have bad decision-making skills, you'll just end up burying yourself (and possibly your team) faster and more decisively. (I have seen that, too.)
I interpreted the original comment totally differently - I thought they were saying that the programmers [who created these tools] should pay more attention to how productive [or not] power users can be with the tools [that they created]. And use that as an important metric for software quality. Which I definitely agree with.
> how productive power users in different [fields] can be with their tools
There are a lot more tools in programming than your text editor. Linters, debuggers, AI assistants, version control, continuous integration, etc.
I personally know I'm terrible at using debuggers. Is this a shortcoming of mine? Probably. But I also feel debuggers could be a lot, lot better than they are right now.
I think for a lot of us reflecting at our workflow and seeing things we do that could be done more efficiently with better (usage of) tooling could pay off.
In high school, I participated in a STEM-based competition. There were a ton of categories like CO2 dragsters (my favorite), architecture, 2D and 3D CAD, GIS, and numerous others I can't remember. Some categories had more of a business focus but most were science/engineering related. The 3D CAD one was pretty fun. I recall two parts. In the first half, you got a hand-drawn sketch of a bushing and had to recreate it in Autodesk Inventor as fast as possible and then generate a 2D drawing properly dimensioned (like what you'd hand to a machinist). The second half involved creating all of the parts for a basic ceiling fan and then making an animated exploded view that also spun the fan. I was really good at that stuff back then but I definitely wasn't the quickest. I'm sure it's a lot different now, so much of CAD now involved CNC and 3D printing that's there's probably aspects that include messing with gcode now.
My GIS competition was fun too. They gave me a bunch of map data and I had to produce a report on Washington DC storm surge flood zones and potential rescue helicopter locations all within a couple hours.
I recall there being a video production category too. I didn't compete in it but you'd be given props and dialogue to turn into a video over the course of a day or two. Very few of the categories were contemporaneous competitions, most were long term project presentations.
Although they do have a category for best editing, it's hard to call it an award for "best film editor" when it doesn't control for the overall quality of the film. For example, with the Oscars, it's extremely common (2/3 of the time) for a film that wins best picture to also win best editing.
Drop 10 hours of footage to the competitors on day 0, assign judges random groups of completed films on day N.
Maybe let each editor request one reshoot in the first week, a committee aggregates similar requests, all editors get all the reshoots once they're finalized.
Maybe include storyboards and a rubrik for what story the film is supposed to share and how we're meant to feel, but maybe not.
I think this may actually be two different things. Much like how being good at coding doesn’t mean it’s fun to watch you code. Though there are “performance” coders where it really is!
I recently integrated Lazy Polars and running analytics in background processes so I can reliably provide a fast table viewing experience on dataframes that would normally exhaust memory of the jupyter kernel. Analytics are run column by column and results are written to cache, if a column fits into memory individually, summary stats for the entire dataframe can be computed.
Here's a demo video of scrolling through 19M rows, and running background summary stats.
I love the listing the number of dependencies in the title. It tells me that serious engineering went into this. I will be incorporating this "feature" into READMEs of my own projects.
They spec the thinnest stuff they can get away with to add .0001mpg. Multiply that by all the Chevy 1500s GM makes or F150s Ford makes and you see the draw.
Sometimes it turns out that the thinnest stuff they can get away with just not quite thick enough at the margins or in transient conditions. And of course they stretch out the oil change interval to reduce on-paper TCO as well which doesn't help.
You can mitigate this with thicker oil (what GM did for the recall) by can go too far and create other oiling issues because thick oil drains back slower and going to some super high spec 0-W-<whatever> Euro oil may cause other problems related to soot and sludge so there's no silver bullet.
The "safe" advice most people give out is to use whatever the <nation with no emissions or fuel economy rules> version of your owners manual says to use for oil.
And if you have a high strung turbo engine you ought to take your oil change intervals seriously.
PRs are a defacto communication and coordination bus between different code review tools, its all a mess.
LLMs make it worse because I'm pushing more code to github than ever before, and it just isn't setup to deal with this type of workload when it is working well.
reply