Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
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.
Yup yup! I agree wholeheartedly! WordPress is indeed a whole other mess. Never been a big fan of the php CMS systems ( WordPress joomla Drupal).
I've seen the mess that can become firsthand ( though i wasn't working on the project ).
Go has peaked my interest as well ( for terraform modules and/or kubrrnetes operators ). I wonder if the owncloud project is working out better ( performance wise ). That aims at a different market segment than NC though. It was written in go though I think.
It isn't opensource anymore I think? ( didn't google - very possible that I'm wrong ).
Best of luck to your go project ( I'd you decide to kickstart it ). I'd contribute if I could, though you'd probably be better off code-quality wise with somebody with more experience :D.