After my private Gmail was leaked somewhere, I’ve started to receive an enormous amount of spam that came through into my inbox, which made me switch to Proton and a self-hosted SimpleLogin setup.
So I decided, I might as well dirch Google entirely, for private and work-related stuff.
While Proton already covers Mail and Calendar, I’m in search of alternatives for the following services to replace.
- Meet: I like the idea of starting a quick meeting by simply sending a link to a customer, who can join instantly. What would be an equivalent software to do that? I tried Mattermost, but it seems more like a Slack alternative, with invites, etc. and is overkill for my case. Revolt chat looks like a Discord alternative.
- Drive: In short, If possible, I’d prefer one consolidated place to access and edit files. Docs, Excel, PDFs, pictures, videos, etc… Is Nextcloud really the only option here, with the corresponding plugins for onlyoffice and memories (photos)? I tried running thst on an intel nuc, and it’s slow as hell.
I mean. There’s plenty of languages that have this overhead.
A base Laravel or symfony installation shows a landing page in 30-50ms (probably).
I’ve written ( in a lightweight framework rather that no longer exists ) a program to encrypt/decrypt strings using XML messages over http requests.
The whole call took 40-60ms. About 40-50% of that was the serializer that needed to be loaded. The thing was processing a few hundred request per minute in peak. Which is a lot more than the average nextcloud installation. The server wasn’t really budging ( and wasn’t exactly a beast either ).
I’m definitely not refuting that the JIT compiler adds overhead. But as in my example above, it’s also not like it’s adding 100ms or more per request.
If you have a very high performance app to the point where you’re thinking about different transport than HTTP because of throughput you’re likely better off using something else.
Circling back to the original argument my feeling remains that the same codebase in GO or RUST wouldn’t necessarily perform a lot better if you just calculate in php speed and the overhead of the JIT compiler.
If you’d optimize it in rust/go. It likely will be faster. But I feel like the codebase could use some love/refactoring. But doing that is more difficult when you already have:
You don’t want to piss off your entire userbase. Now I feel like I’d like to try it myself and look at the source though :'). ( I’m not saying I can do better though. It’s been a couple of years).
ok… valid point, and I also agree on the refactoring argument.
To mitigate the compatibility issue, they could release a new major version, and let plugin developers simultaneously (or not) rewrite their codebase to make it compatible. That’s how WordPress plugins work, although WP is a whole other mess, and not the best of examples, but they also have a large userbase and plugins.
lol, I too was thinking about trying to kickstart a similar project in Go. I’m by no means a professional go-dev (former PHP-dev, currently Node), but I think it shouldn’t be that hard.