3 ms·

Tried Matrix (and Synapse) the 3rd time a couple of months ago and gave up after a few days. Joining any larger federated room took days or did not complete at

by Jnr 5y ago

Tried Matrix (and Synapse) the 3rd time a couple of months ago and gave up after a few days. Joining any larger federated room took days or did not complete at all. And then the messages were also delayed for quite a while. That must be the stupidest design I have seen. If it was not so messed up, Matrix probably would have become huge by now. I agree with others in comments, devs should have probably improved the federation and written the official server in some compiled language and provided it as a single binary.

foxfluff 5y ago
I kind of disagree about the language. Not because I wouldn't want an implementation in a fast language, but because I think a well designed chat system must be performant even if your language is an order of magnitude (or two) slower than it has to be. If you need to start throwing brute force at it, something's up with the design. Get the design right first and demonstrate it is right by showing that even a slow system has no trouble with it.
- Jnr 5y ago
  Sorry, it was not clear that I do not hate the language (I write in python myself) and I fully understand that it is the design choice that is the problem. I simply think that having a single small binary can be advantageous for adoption.
Arathorn 5y ago
It might be worth reading the actual post to see how we're fixing slow joins. In terms of the language: it's not Python's fault at all. Instead, Synapse baked in a bunch of naive assumptions (being originally a prototype) which we have been steadily fixing... while also adding features, which pulls in the opposite direction. Given a choice between a featureful server that's resource-heavy (which we can then make go faster later) versus one which lacks the features to compete with centralised alternatives, we chose the former.
- Jnr 5y ago
  Sorry, it was not clear from my comment. I do not blame Python. Of course it was design/code issue. I just think that having a single binary would improve adoption. I like projects that provide a single binary. Without the need for docker, or setting up complex environments.

by Jnr 5y ago

foxfluff 5y ago

I kind of disagree about the language. Not because I wouldn't want an implementation in a fast language, but because I think a well designed chat system must be performant even if your language is an order of magnitude (or two) slower than it has to be. If you need to start throwing brute force at it, something's up with the design. Get the design right first and demonstrate it is right by showing that even a slow system has no trouble with it.

Jnr 5y ago
Sorry, it was not clear that I do not hate the language (I write in python myself) and I fully understand that it is the design choice that is the problem. I simply think that having a single small binary can be advantageous for adoption.

Arathorn 5y ago

It might be worth reading the actual post to see how we're fixing slow joins. In terms of the language: it's not Python's fault at all. Instead, Synapse baked in a bunch of naive assumptions (being originally a prototype) which we have been steadily fixing... while also adding features, which pulls in the opposite direction. Given a choice between a featureful server that's resource-heavy (which we can then make go faster later) versus one which lacks the features to compete with centralised alternatives, we chose the former.

Jnr 5y ago
Sorry, it was not clear from my comment. I do not blame Python. Of course it was design/code issue. I just think that having a single binary would improve adoption. I like projects that provide a single binary. Without the need for docker, or setting up complex environments.