Dusty Pomerleau
@dpom.bsky.social
130 followers 160 following 530 posts
Web hobbyist • Leptos, Axum, Gel (he/him)
Posts Media Videos Starter Packs
Reposted by Dusty Pomerleau
Safari SVG filter bugs completely sap my energy. Just slowly, inexorably, progressing from "this effect is incredible!" to "my head is now on the desk..."
Knowing the exact reason does matter, because maybe I'm throwing compute at a problem I could solve just by modifying the dockerfile. Ops/infra is a blind spot for me.
I'm definitely interested in learning to manage it for the future, even if I won't use that specific provider. It was exiting with "status code 2." I couldn't find anything in Render's docs to tell me what that meant.
But to answer your question:

`time podman build .` in a VM with 8 CPU and 2 GB memory:
515 secs

`cargo clean && time cargo leptos build` using my full machine (Apple M4 Max Macbook Pro with 64 GB memory):
78 secs
Well there *are* logs, but there weren't any errors - it was just freezing, followed by a nonspecific exit code. I think the platform probably understood the problem, but I wasn't seeing those logs, just the logs from the container, if that makes any sense.
My favorite thing in the entire world is when a company puts all of the settings for their app on a single, scrollable page.
It's too early for me to comment on real-life usage costs, but the things I'm building aren't expecting massive scale—for me it's clearly a win.
If we assume that my app could run on a Starter instance on Render, but that I can't build on the standard pipeline, then I would need to spend a minimum of 19 + 25 + 7 = 51 USD/month just to get the app live, something I can do for 5 USD + usage costs on Railway.
Getting a better build pipeline on Render requires both the Professional workspace (19 USD/month) + an additional 25 USD/1000 minutes of build time. In contrast, Railway is basically giving away their build pipeline for free.
Of course usage costs depend on...usage, but getting 8 GB memory on Render requires a ProPlus instance (175 USD/month), and getting 8 CPU requires a ProUltra instance (450 USD/month). Obviously the exact CPU/vCPU specs matter.
That breath of fresh air with the build pipeline prompted me to compare the instance costs for the server: Railway's Hobby plan offers (up to/on demand) 8 GB RAM and 8 vCPUs, with base pricing of 5 USD, and the rest based on usage.
I eventually deduced (no thanks to the logs) that the deploy was just running out of memory. This prompted me to try deploying to Railway. The app deployed fully in < 10 minutes, without issues.
I was trying to deploy my app to Render using a Dockerfile, and their standard build pipeline was taking 2-3 hours to compile and deploy (ultimately failing). This was even after upgrading my workspace to Professional (19 USD/month) and my server instance to Standard (25 USD/month).
Leptos apps are efficient at runtime, but type complexity can lead to a lot of memory use during compilation, and they have the usual compile time CPU demands of any #RustLang app, so the resource-intensive bit is definitely deployment.
I rarely give this kind of commercial praise, but @railway.com is knocking it out of the park with their infra pricing model. Here's a little case study from deploying my latest web app:
Reposted by Dusty Pomerleau
i think the only way for atproto to succeed is for us to show what apps can do when every app sees every other app's public data, and they share an identity system. no technical or sociological argument is as convincing as seeing seamless interop and the lighthearted competitive landscape it unlocks
How many times in one lifetime can my build fail because OpenSSL requires Perl.
Are you using DaisyDisk? It really helps you find the high-yield deletions in this situation.
Do you really only have 256? I feel like you need to treat yourself to a proper dev machine :)
This is why everyone is switching to jj though. Why keep track mentally of which actions are destructive when you can just make all actions non-destructive?
When I first started with #RustLang, I had the impression that dynamic dispatch was very costly at runtime, but my actual observation is that experienced rustaceans use dynamic dispatch all over the place, and seem completely unconcerned about it. I now wonder if I should embrace it more often.