The argument that you don't have to restart the server after editing a file? I mean I've used a couple of web dev environments and I know for a fact that Rails, Django and Express all come with some sort of automatic reloading in development - provided by the framework itself or by a library. Quite sure there is a solution for most environments.
You still need to contend with build and startup times with those setups though, even if a rebuild is triggered on file save. With PHP, there's no such thing as build or startup, because it's interpreted.
An Elixir Phoenix's page live-reload never took more than one second even on a fairly weak i3 laptop for me. And on my desktop Mac it usually takes 0.2s.
https://radiooooo.com/ doesn't work because it's trying to XHR the http version of the site which gets blocked. The other .app domain works fine though, like you said.
First time I hear about them, too. Googling Rails + Iodine doesn't yield much information. I'm going to try replacing Puma in one of my Rails apps. The benchmarks suggest that this could be a real win.
Zulip is using Python and Postgresql. Is this a great choice of stack for a chat app? I'd love to know how Zulip performs with hundreds of concurrent users.
I am currently looking into Rocket.Chat which is based on Meteor (NodeJS) and MongoDB, a stack which, for me, seems better suited for this kind of app. But hey, I don't know, I haven't done performance tests or anything.
Does anyone know about any hard limits with either Zulip or Rocket.Chat?
We tried RocketChat for about a day before switching to Mattermost. It wasn't great, but worked okay for a team of 20-30.
After a month or so of mumbling and grumbling on MM we went to Zulip, and brought on another dozen or so designers and PMs. Zulip lasted about 6 months before management implemented Slack company-wide and rolled out for the other 100 sales and support teams.
Zulip was the best for engineering, by far, but it was doomed from the start because the UX wasn't as simplified and polished as Slack. It didn't Just Work, you had to think and use it properly to see the benefits.
Back to your question: no limits I know of, and a t2.medium was 90% idle for an active team up to ~50 without a hitch. I think the docs (or launch announcement?) mentioned a large deployment around 1k, but I can't remember the details. You'll definitely want to test your expected configs and hardware to be confident.
We've been extremely happy with the Python 3 (with mypy static types) and Postgres stack. Like with any app, you need to take some care to design the database model right and avoid database queries in loops. But with our design, all the expensive operations are done in the database and cache, so Python is just as fast as anything else. And because our data model design and indexes are correct and Postgres is awesome, the database queries are all fast. We use Postgres' built-in full-text search, and people frequently praise Zulip's search as being unusually good for finding past conversations.
PostgreSQL is really really good, for any normal amount of data, or any normal number of users. If you can make Postgre do most of the work, it doesn't hugely matter what you build on it.
If you're Facebook or Google scale, you may need something with a different performance characteristics, but 99.9% of the world doesn't. Except that even Facebook doesn't: as I understand it they still use carefully sharded MySQL.
Yes I guess with the right hardware everything is possible. The question is if you can get away with smaller hardware when using non-relational databases. Well one would have to test this.
Python fits very well this use-case. If you design a chat app properly you should be doing very little computation. With Python's async you can scale up to large number of sessions / users / channels without issues.
I said concurrent users as in users that are online at the same time, each of them probably connected via WebSocket streaming and sending messages.... Thanks for the downvote...
Regarding Postgresql, are you denying that relational DBs are less suited for write intensive tasks than say a NoSQL DB like MongoDB is? And couldn't a chat with thousands of users be a more than average write intensive scenario?
Freudian theories were never science (as we define it today) - as Popper pointed out after trying to reconcile scientific inquiry with Freud's and Adler's work - since they cannot be falsified, see e.g. https://cogsci.stackexchange.com/questions/12451/why-did-kar...
They might be part of mainstream psychology (I have read conflicting accounts), but they are definitely not part of mainstream science; very little of psychology is.
