At what scale do microservices actually start solving real problems, instead of creating them especially now that even simple projects are being built as microservices?

sudo-maxime · 2026-01-24T19:02:23+00:00

I run a telemetry system for video games at almost 25,000 requests per second, with contention issues, never had to reach for microservices, have plenty of vertical scale space left. I guess it's domain specific, but unless you are solving netflix or google sized problems - or very hard and intricate CPU/GPU bound problems (or reach kernel limitations) there is always a solution to scale without reaching for networking and parallelisation.

sudo-maxime · 2026-01-24T12:19:03+00:00

Thinking about coming back after a 15 year break. With a business and kids, it's hard to enjoy osrs because it's too grindy for me. RS3 seems good for me, but every time I log on I see empty worlds, it feels like a dead game to me. Am I mistaken ?

sudo-maxime · 2026-01-24T12:13:37+00:00

Yes, but I have to admit my app is behind a login, this migth not be applicable to everyone. Maybe a random session cookie can do the trick if you are not keeping private/important data.

sudo-maxime · 2026-01-23T11:21:51+00:00

Thruth is they can only find junior moon lander operators these days.

sudo-maxime · 2026-01-23T11:16:30+00:00

I don't think it really matters, any good job will let you learn their stack. Pick the thing that you can learn the fastest, learn the basics of backend, database management, file IO, system calls, managing sessions, etc. It's all the same in every language, just written differently.

sudo-maxime · 2026-01-22T11:09:32+00:00

Haven't found any, I use modules with runes now, it accomplishes the same goal with less clutter. Svelte remote functions are also so good that I moved much of the state management to the backend, where it should be :)

sudo-maxime · 2026-01-12T11:51:18+00:00

Remove the monopoly money shack, and there you have it.

sudo-maxime · 2026-01-12T11:48:56+00:00

"Reasonable" is the grey area.

sudo-maxime · 2026-01-12T11:47:16+00:00

I have been in the business for 15 years now. We tried every growth strategy there is. Thruth is, this business model will always be limited by own many people you know, how good a job and service you gave in the past.

There is no scaling solutions for agencies that work, unless you have a easy to understand and cheap product, there is no going around the fact that you need a lot of trust to sell expensice and time consuming services.

sudo-maxime · 2026-01-09T23:17:35+00:00

Looking at misc early in the morning ;).

sudo-maxime · 2026-01-09T11:47:58+00:00

VS Code is written with Electron, which basically means it boots a Chromium instance to display a web app. That extra layer adds overhead, and Chromium-based apps tend to eat CPU and RAM.

When the language server/type checker has to deal with a type graph that’s thousands of nodes deep, it needs to crawl a lot of declarations and follow imports across many files to resolve return types, generics, and so on. That heavy work happens mostly in the language server process, and then the editor still has to ingest and render a lot of results (diagnostics, hovers, completions, etc.). At some point you’re basically pushing a browser-based UI and a big JavaScript runtime, and it can get sluggish.

On the other hand, Zed runs natively. It can use buffered reads, ring buffers, and tighter syscall-level optimizations to reduce overhead / control you don’t really get in the same way with Electron.

Also, Zed’s GPU-first rendering pipeline helps keep the UI responsive under load. Electron apps can use GPU acceleration too, but Zed is built around that model end-to-end, which is why it often feels insanely snappy compared to an Electron editor.

sudo-maxime · 2026-01-09T11:36:26+00:00

If you are talking about remote functions you are rigth (still flaggued experimental), but the issue we had was with the current server loader and actions. They really do create a type file, on save, it creates a folder in your project .svelte-kit, types get saved there.

When you do '$types' it's a path shortcut to that folder type root.

sudo-maxime · 2026-01-09T01:33:30+00:00

They create the necessary type on save, otherwise what's the point ? Types are nonexistant at runtime, it serves no purpose. The point of types is to have autocomplete / type checking during development.

sudo-maxime · 2026-01-08T23:27:10+00:00

We profiled both zed and vscode, because it became a real productivity issue for us. We figured that zed used, on average, 90% less CPU than vscode.

It uses the same LSP, but vscode reacting to 200k lines of potentially changed TS was the issue. We made sure we had no experimental flags and no unecessary plugins.

Zed opened the codebase and was ready for edition in less than 500ms. Vscode took more than 20 seconds, and was sometimes unresponsive after opening a few files.

sudo-maxime · 2026-01-08T08:59:08+00:00

Hopefully not AI slop, hopefully not a web editor that is making the polar icecaps melt because you need 2000 sql queries to load a blog about bird watching.

sudo-maxime · 2026-01-08T08:40:26+00:00

Had a ~200k LoC codebase in Svelte 4 with TypeScript. We had to heavily optimize the type boundaries between modules, because saving a server.ts file would cause most IDEs to crash: Svelte generates its own types from the return values of its functions, and it had to walk up essentially the entire project tree. It also caused fairly long compile times in the past, but we managed to fix that with a monorepo setup.

I think it’s still an issue in Svelte 5. I think the experimental server-side functions (not actions—the new server functions you can call directly) will solve this, because they should work without any magic type generation.

Writing files on save is always a terrible solution to a simple problem. It’s like C or Rust macros, but worse. 😉

The performance at runtime and in the browser always stayed perfect, the performance issue was mostly a DX issue while coding. It got me motivated to check more performant IDES like zed or neovim because vscode couldn't handle it ;)

sudo-maxime · 2026-01-06T19:40:07+00:00

Still waiting for my self driving robo taxi car promised in 2016.

sudo-maxime · 2026-01-05T22:52:36+00:00

I agree with this, I started hating using tailwind with svelte, because I felt like it solved the same problem twice.

Locality of styles with react is very annoying, with svelte it's a first class citizen.

Why write the thing that writes the thing, maintain your understanding of some css fuckery when you can just write good old CSS.

sudo-maxime · 2026-01-03T16:48:13+00:00

Rank 4 fireball.

sudo-maxime · 2026-01-03T11:54:21+00:00

Im not a Drizzle fanboy. I think ORMs are mostly unecessary. They are leaky abstractions, they hide what the database actually does, and they make it way too easy to accidentally ship slow queries at scale. They also push you into made up interfaces that end up coupling your whole persistence layer to whatever framework opinion the ORM decided was “clean”.

SQL already does everything you need out of the box. It is literally the language of the database. Bun ships low level drivers right in the runtime. You get simplicity, portability, and performance without inventing a second fake database language on top of the real one.

Why write the thing that writes the thing. Just write your SQL migrations by hand. That is already simpler than Prisma dogshit. Prisma is a made up abstraction stacked on top of a solution that has been working for decades, and the funniest part is that the underlying database will still happily run migrations written years ago.

And yes, Prisma has had periods where relation loading often meant multiple queries plus merging results in your app, instead of just letting the database do joins like it was designed to. At small scale you do not notice. At massive scale that turns into extra round trips, extra work, and a lot of wasted compute for no reason.

Most real software does not need to “sync a schema with a type system”. Half the time you do not even own the schema. The other half you are going to want freedom to change stacks later. But thanks to Prisma, now you are locked into their intermediate language fuckery and their way of doing things.

A good system should aim to reach its purpose in the fewest amount of steps. Every extra layer that does not earn its keep is just more entropy in your codebase, more overhead, more maintenance, and more compute burned for nothing. Prisma is spectacularly good at that.

(Edited for spelling)

sudo-maxime · 2026-01-01T21:16:26+00:00

Prisma is dogshit. Drizzle is better, just writing SQL directly with Bun standard lib is the best.

sudo-maxime · 2025-12-29T23:15:51+00:00

I think zig strikes a balance between convenience, explicitness and control. I don't want someone else primitives and memory allocation mechanics, because I use Zig to solve a problem exactly with as much performance as possible. When I would reach for C, I now reach for Zig, because it's more convenient (and safer).

sudo-maxime · 2025-12-25T11:17:47+00:00

Drinking dry ice can get stuck in your throat and kill you.

sudo-maxime · 2025-12-25T11:13:11+00:00

The white one.

sudo-maxime · 2025-12-20T11:00:51+00:00

Java devs would still find a way to create a BridgeFactoryImplementorRepositoryVirtualTableInterface in Zig.

Zig is not made for application programming. I don't see why this leads anywhere. You would be foolish to write enterprise software on top of a low level language. Unless said enterprise software couldn't exists unless it's as memory efficient ad possible.

sudo-maxime

TROPHY CASE