VPN enrollment is scanning a qr code nowadays. Or site2site, with a "plug this box into your network' really shouldn't be an obstacle in the year of the lord 2026

That's as a self-hosting hobbyist. Sqlite is great for that. It stops being great when you have thousands of users, and good luck using it with millions.

One docker container > ten micro services

Well that depends. Are you going with micro services because it's fashionable or because different parts of your backend work with completely different data and don't need to communicate with eachother that much?

I'm of the opinion that anything that needs to share one database should be one service, and things that are so easily detached that you can just plop the tables over into a separate database, can be separate services, because that will allow you to scale up one without scaling the other and one database's I/O won't get in the way of the other database's I/O (assuming they're on different machines of course). I'd say:

Microservices ~ monolith > Distributed monolith

Distributed monoliths suck.

From what I remember, Vscode has quite a fair bit of native code in various areas to make it perform better. So it may not be the representative Electron app for comparison.

You could just use the standard library and refrain from using third party libraries? That's how you get a smaller binary size in just about any language.

I haven't gotten deep enough into it to see what's wrong, but pretty much any Electron or CEF application I've used has been pretty slow, though it could be that I have a very weak PC since I only have a Ryzen 5700 and 32 gigs of DDR4 and my NVMe drives (root and home partitions being separate physical drives) are only running on PCIe 3.0, not 4.0 or 5.0. Perhaps I ought to see if things like Steam or Discord run better if I upgrade to a mid-range PC with a Ryzen 9900x, faster RAM and faster drives, but I'm not made of money.

Games run smoothly, mind you - those don't require very beefy hardware after all. It's only extremely visually and IO demanding applications like Steam or Discord that run like absolute dogshit for me. Slack used to be pretty bad too, but I don't use it these days, don't need it. Ditto for Mattermost. I have one computer dedicated to Microsoft Teams, it's got a 12th gen i7 in it which can't really handle the task, but that's just Microsoft for you, everything they've made in the last decade has been shit.

If you didn’t automatically register that requiring spawning full OS processes to scale performance immediately disqualifies a language from a whole plethora of use-cases

That's way too broad of a statement to be true in any absolute sense. It really depends on what you're doing, and sure, there are plenty of ways to do it stupidly, but a lot of people that are smarter than you and me have thought about ways that the overhead of spawning processes can be mitigated. All I can say is that I've had perfectly good success using multiprocessing.Pool and getting near perfect speedups. Is it as fast as threading? No. But it's good enough. If it's not good enough for you, then maybe we just have different use-cases, but without talking about concrete examples, we can't make any specific claims.

And we didn’t even get to low level stuff yet. People are already failing at the macro level. Sad.

What do you want to talk about? Are you writing kernel drivers in Python or something? Why would we talk about writing low level code in Python, that sounds absurdly stupid. Most of the high performance libraries people use are written in Fortran or C. The entire field of data science uses Python, if performance were not a heavily optimized problem, then a lot of people out there must really love wasting their money on compute. Python is a glue language for high performance low level code, everybody knows this already.

Frankly this thread has been very illuminating. My perception of the average p.d user and their concrete knowledge was very inflated.

At least we agree on something!

TFW you want to reply but don't want to actually read the content to understand what you're replying to.

This seems like a pretty good article, if you like to think

Well, makes sense why it's so downvoted now.

And why so many commenters obviously didn't read or even glance at the article before replying.

Memory cache hits are destroying performance? Is this profiled or just guesswork? I don't understand how that's tied to perceived performance degradation specific to web-based toolkits like Blink and Webkit

Why is how nodejs or cef does I/O worse than any other GUI toolkit's I/O layer?

If you didn't use a profiler, then how can you be sure that the issue was Python and not something else? If the slowness really is evenly distributed through the code as you suggest, then a profiler would show that almost instantly and it's very easy to do that in Python using cProfile.

On top of that, the Python standard library is built for convenience, not performance. The nature of it being a standard library means that the implementation has to be simple. fastregex uses LLVM and SIMD for example, that's something that's wildly impractical for the Python stdlib to support. In contrast, I have no idea what regex or JSON library you used for your Rust code, but if it were outside the stdlib, chances are high that it had much more leeway to optimize performance because it didn't have all the other maintenance obligations that stdlib code needs to support.

All of this is just pure speculation on my part, but ultimately I'm trying to make a point that it is hard to say that the difference was caused by a language issue and not something else. There are lots of other things that could be contributing to this difference and you can't really say for sure without meaningful diagnostics.

As an example of this, look at Nicholas Nethercote’s excellent series of blogs on making the Rust compiler faster: https://nnethercote.github.io/

The “bottlenecks” they find result in 1% speedups.

The kinds of software that you and I write on a daily basis is nothing compared to pieces of software that get millions of man-hours per year. Assuming you're not Linus Torvalds or Ted Ts'o hiding behind a funny alias, of course. I don't think anyone is suggesting that it's a good idea to write a compiler in Python (outside of prototyping purposes perhaps) since it's obviously not I/O bound, but if you and I are trying to optimize something we wrote ourselves, we're more likely to be in the "nice small hotspot" domain you described, rather than the 1% bottleneck speedups discussed in the link you posted.

Very cool link though by the way, I look forward to reading as much of it as I can....

If you didn't automatically register that requiring spawning full OS processes to scale performance immediately disqualifies a language from a whole plethora of use-cases (which is what the intellectually deficient OP tried to argue against), then I'm not sure you're qualified to opine on the matter (hint: spawning a thread per task is already too much overhead for many workloads). And I don't mean any disrespect to you here. Your replies were far from the worst in this thread.

Frankly this thread has been very illuminating. My perception of the average p.d user and their concrete knowledge was very inflated.

And we didn't even get to low level stuff yet. People are already failing at the macro level. Sad.

Sqlite is amazing! It's simple to set up, there is no db server process, you get extremely low latency. Testing is simplified because you can run tests against an in-memory database.

I haven't tried rqlite, but I have an API service that runs Litestream. That gives me a database backup that I can rewind to different points in time, and it lets me recreate the production database state locally for troubleshooting.

That's what Open Telemetry is for, honestly, specifically tracing. I'm in the process of adding tracing for all of our web handlers, http client calls, database transactions/individual queries, and asynchronous jobs. Should give us a pretty good view into the performance of the system, and allow us to monitor for things like performance regressions without any dedicated profiling needed (though we certainly could add additional profiling information through Otel down the road). Since I know you're a Haskeller (recognize your handle), the hs-opentelemetryecosystem is quite solid and has integrations with a lot of libraries in the wider ecosystem, like wai, persistent, postgresql-simple, conduit, and a bunch more. I haven't needed to write too much of our own instrumentation, aside from our job system since that's a bespoke system.

I was in a meeting with a senior software engineer, who makes a shit ton more than me. While sharing my screen he saw flame graph I had for one program I was working on. They asked "what is that?", I was taken back, and said it's for looking at which functions are taking more time. Then I was asked "where did you find it?" I was shell shocked, didn't know how to answer that. Similar things have happened before where I taught them certain things, and they go "great find", like dude, I didn't find it just now. That's basic knowledge if you work with database.

I am not even a developer hire, I'm self learned, and because the company doesn't have many developers they gave me some of the tasks and I'm doing it because it's more fun than my job responsibilities, and when I don't have enough tasks.

Self hosting is getting really exhausting lately... Maybe I will just gate everything behind a VPN and stop sharing my services with relatives :/

Did you use a profiler to find the bottlenecks?

No. It was a simple enough program that there were no areas for improvement anyway. I also did not use a profiler for the Rust code.

good Python devs know how to find bottlenecks in their software and replace them with fast implementations

In my experience this is also a sweet sounding lie to make people feel ok with using Python. Yes in some case you make a big mistake and there's a large bottleneck you can easily remove... Or your program has a nice small hotspot where it spends most of its time and you can just write that bit in C++ (AI is the obvious example).

But most programs are not like that. They're more like MS Word. Slowness is evenly distributed through the code. There is no hotspot to remove.

As an example of this, look at Nicholas Nethercote's excellent series of blogs on making the Rust compiler faster: https://nnethercote.github.io/

The "bottlenecks" they find result in 1% speedups.

Had the same experience when I was testing zed. Was thinking it would be a lot better since it's written in rust but there wasn't any difference in memory/CPU usage between it and VSCodium, which is electron app.

My only caveat: I really haven’t tried Fable due to cost. Anyway, be well, mate. Enjoying the conversation despite disagreeing.

Well, that's why we're disagreeing 😄

I agree with everything you've said if you're using models weaker than Fable. The latest models (Astra, Opus 5.5, maybe Argon I haven't used it much) are a significant step up. Way more than the benchmarks suggest. It really is "ask and you shall receive". You might have to ask a few times but still...

Also caveat on my end: I've only tried vibe coding with Rust, because it's the best language available for humans and AI seems to like it too (lots of static checks). I have no idea the quality of code you'd get in other languages. I would be cautious before having it write C++ for example... though it's probably fine.

There are no bad languages

Malbolge. ;)

Yeah, I long ago switched to ddg and I also turn off the ddg ai stuff. I hear the paid search is also out-performing Google for people that care their search results are accurate.

Profiling complex systems can be quite difficult. That said, I believe in the adage "Profile twice, optimize once.", adapted from the old carpenters adage of "Measure twice, cut once."

Slowness is rarely essential, but I can be far away from where you expect it.

Why not just use the faster language?

Because the other language is more developer-friendly or faster to write/read even if slower to execute. Some code doesn't need to be fast because it is always waiting on other things anyway.

Some languages effectively prevent whole classes of runtime failures / bad code. But, they do that by doing more which takes longer, at compile-time, run time, or both.

Some programs can't avoid graph-structured data dependencies. In that case, the simplest solution is a garbage collector, and one built into the runtime is capable of being more efficient (and less buggy) than one written for a specific program.

Anyway, there are many factors that determine which language is "best", and not all of them are objective. That's why we don't just use the fastest language. (Currently, I do all my coding in either Idris or Purescript, but I'm also unemployed and just programing for myself, for now.)

Then its the Test environment that is slow, not Python.