* IRC doesn't easily meet their extensibility requirements. Adding a new field to an existing IRC message just isn't doable.
* IRC has no concept of contacts. Their are bots on some servers and some clients will whois a set list of nicks on join to emulate this feature, but having contacts as a real concept is obviously preferable for Riot's use case.
* XMPP is also a standard protocol. If ejabberd didn't meet their needs, it's hard to see any standard ircd meeting them either.
http://help.twitch.tv/customer/portal/articles/1302780-twitc...
If there was a language that let me define something in terms of an individual actor-modelled components, but then allowed you to optimize some of them into batched GPGPU passes (and apply strict simulation ticking and so forth in the process), I feel like it would "win" all sorts of domains. Erlang could be that language with a little work.
Sorry to veer off topic a bit, but as a Python-lover-but-outsider I've long been mystified by the almost proud unwillingness of the community to embrace Python 3. It seems like a better language to me. What am I missing?
1)The "latest version" of a programming language is not the same as having the latest version of Firefox. Having the latest version can actually be a detriment if you lose libraries as with Python3.
2)It may be unpopular, but I tend to follow the market to a certain degree. Python is my language of choice for home projects and employment. But almost all employers use Python2.x. So I follow them just to keep 1 less hassle out of my life.
3)Losing the long tail of libraries that 2.x has. Many things support Python3, and I'm not against it. I'm just waiting for the day when Python3 is more convenient than Python2 to move. I wasn't one asking for the Py3 changes, and they certainly weren't done for me. So I don't feel like being inconvenienced or doing any porting/heavy lifting in the meantime.
4)My petty reason. I think everyone should just do what's in their best interests. I advertised that "2 of course" because it is a given, but rarely stated. I've met a number of pushy Python3 folks and find them distasteful, which hasn't helped budge me in the slightest. They've probably made me a little edgy on that topic.
5)It's a programming language, so what helps you build something the fastest should be what we use. Today that's still Python2. Some people feel very passionately about Python3 and I hope they spend many hours porting and building the ecosystem for my arrival one day. What seems to be going on instead is they're hoping to convert more devotees that will go out there and do a bunch of free ports.
6)I'm more concerned with moving too early than I am too late when the Python3 ecosystem one day, maybe, eclipses Python2. They're just not that different, I've used both and it's no different from building software with 2. But they have vastly different breadth of libraries in 2's favor. They also screwed up on a few things with 3, it isn't really a flat "upgrade" either.
7)Python3 is just adding more bloat. I generally prefer features are REMOVED from a language until there's nothing left that could reasonably be removed from the core language. Ideally I'd like to see a small version of Python with the basics never touched and features added through addons or a macro system.
Latest version, upgrade, and support-ends-2020 are all political statements in regards to Python3 that mean nothing in reality. Latest version- what can't be backported? Upgrade- more like sidegrade once all things are considered. Support EOL- total smoke and mirrors, code will not stop running post 2020.
They're tossing every feature against the wall that they can to fix that. I'm one that holds feature-soup in disdain though so this is unattractive to me, and I prefer a well thought out "one way to do it" (Zen of Python) approach. Python is well beyond the basics at this point and not a small language, but at least 2.7 is frozen and I can choose to use the backports people provide if I want. I like a smaller core language if possible because I have to read other people's codebases.
To me something like Firebase could work for this?
It seems like when game dev companies grow they love to blow out all of their own in house solutions so they can have complete ownership and control. But is the cost of ownership of your stack really worth the maintenance costs? Why not outsource as much of the stack to another company that can take advantage of economies of scale?
If you're doing more than 20k concurrent users, odds are you can afford to hire someone to scale up or build out a team to do it, or find a 3rd party service and pay them to host your chat.
Openfire is a known server for XMPP:
ejabberd is an XMPP server written in erlang. As soon as I saw they talked about erlang I was pretty confident that ejabberd was the next name they would drop. Very surprised they suggest they rolled their own.
Dota 2 is churning along quite comfortably with integrated voice chat despite having more inter-region mixing. Any time this subject comes up the Dota 2 community nearly unanimously agrees that voice chat in no way encourages "toxicity" and more likely actually prevents it by assigning a human voice to the player as opposed to just disembodied words.
We'll never know for sure. There have been many times where I'll type in chat: "top", my message will appear, and then somebody else will say "top" immediately after. But, a asking a third person reveals that the second player's message actually arrived first, even though my client shows my message first.
The chat architecture is terrible.
I really wish more game studios would do this (Blizzard especially).
http://www.riotgames.com/articles/20150817/1697/our-engineer...
They also mention that their users warned them about this battle before hand which was really cool.
So, I know that I'm expecting too much, but remember that the only way CCP can handle large fights is to simulate them at 1/10th realtime, and get advance notice of said fights so that they can move the simulation for the target system to a single, beefy server ahead of time.
It's a goddamn shame that they don't have the resources available to figure out the -admittedly difficult- problem that is
* Reworking their simulation to be parallelizable across nodes
* Dynamically shifting slices of a battle within a system across physical nodes
I fired them because I'm a mature professional who can figure out how best to utilize my time, TYVM.
Find a company that people actually enjoy coming to work and collaborating in. I mean, if you're an engineer, you're already doing the #1 job in the country, why poison the well at a company with a mistrustful IT policy?
Sorry but I have no end of disrespect for that kind of bullshit. If you're at a job and you're jerking around, people will eventually figure it out regardless of stupid content filtering. And in this case, this is a lost learning experience for you, as the article is very interesting.
After working with (hacking around) OpenFire for two years, I 100% agree with your statement. The clustering plugin routinely fails (to the point where we have actually investigated not even clustering it anymore), the admin interface routinely displays "wrong" data, and other fun bugs we found along the way.
Does it work for us (with a lot of client XEPs and additional custom plugins)? Yes, it does an acceptable job. Would I choose the same product again, if given the choice? No.
"Scaling League of Legends Chat to 70 million Players" by Michal Ptaszek https://www.youtube.com/watch?v=_jsMpmWaq7I
In case anyone's interested, we just posted new content this week - an overview of our RFC process, and the continuation of a Docker&Jenkins tutorial: http://engineering.riotgames.com
