Joined 13 years ago
> XMPP was invented at a time, where communicating online meant sending a message from one device to another. However, the modern expectations for messaging apps are much more than that. Sending media, using multiple devices, deleting messages, editing messages, read receipts, notifications when typing, group chats, threads, and even managing communities are all things a modern messenger app should be able to do.
XMPP provides all of these features and manages to keep up with commercial products really well. Everything Slack or Discord offer is there in the XMPP protocol. And if it wasn't, it could be relatively easily added, thanks to it being extensible.
However, navigating the protocol and software supporting it requires a little bit of know-how. If the OP is interested in building a product incorporating instant messaging and the satellite features, I'd suggest partnering up with somebody with this know-how. Scalable servers would be MongooseIM or ejabberd, polished clients are Conversations or Movim.
If it's a question about which protocol to use for a homeserver, then maybe something focused on ease of setup would work best, like Prosody.
> The fundamental operating principle has shifted from mere message passing to synchronising a common state between all participants.
So it should all be based on blockchain, shouldn't it? ;)
Going from a JSON string to a type for it is actually one of the easier examples of inference I can imagine. JSON is a data description format in which all the base types are syntactically distinguishable, it has no variables, no arrows (i.e. functions), no generics. In the topic of type inference, you can't have a much easier example.
SQL is more complex, indeed, but still doesn't seem too crazy if you have access to table schemas. It's also a matter of whether triggers and stored procedures are taken into account, but I assume they're not.
There's a lot of prior art described in literature as well as practical programming implementations with much crazier, yet successfully working type inference.
Strictly speaking, Dialyzer has two big benefits over more traditional type systems:
1. It doesn't require type definitions to be present, it can type check code having none at all.
2. "Dialyzer is never wrong", i.e. it never returns false positives, i.e. it's an underapproximating checker.
These are the design decisions taken by the tool authors. There's rationale behind them, though the experience of using checkers for other languages might not be 1-to-1 applicable because of that. These decisions come with downsides, of course, some of which are covered in this thread, so I won't repeat them, but in general they were taken deliberately due to characteristics of the language(s) (it was originally created for Erlang, not Elixir) and the state of type system theory at the time. Please bear in mind Dialyzer was created in 2006, some 6-7 years before TypeScript.
Erlang already has a dual nature:
- the sequential part, which strives to be a pure and mostly side-effect free functional language
- the concurrent part, i.e. send, receive, process preemption, message delivery semantics, etc, which is inherently stateful due to interactions between stateful processes
Gradual typing fits this model well, because it provides soundness to the sequential part of the language, while leaves the message passing parts which _no one knows how to_ type dynamically typed.
BTW, I've spent a while to integrate Gradualizer with Vim - https://github.com/neomake/neomake/pull/2115
You might want to check out Grisp - https://www.grisp.org/ - Erlang VM ported to RTEMS. They also offer devboards with ample resources designed to run this thingy.
Elixir, on the one hand, is a new library and tool ecosystem. It's hard to compare libraries, but tool-wise, Elixir wins simply because it has them. Erlang has been underdeveloped in this aspect for years and it's not changing very fast.
Syntax wise they are pretty different, but it's trivial to use Erlang libraries from Elixir (not as easy and not always possible the other way around) and there's not feel that they're designed with different principles or feel foreign. Moreover, some standard Elixir APIs are simply old Erlang libs dressed up in slightly better clothes.
On the other hand, it's just the syntax which differentiates Elixir (the language, not the ecosystem) and Erlang. Only the compiler frontend is new in Elixir, from a certain point (an Erlang abstract syntax tree) it's Erlang all the way down to the bytecode/VM-executable code level.
Prosody doesn't scale horizontally / cluster [1]. It's a piece of cake to deploy it, but it's simply a different niche - you won't have a highly-available system serving hundreds of thousands of users with Prosody.
MongooseIM is a fork of ejabberd. The biggest benefit now (due to ejabberd catching up with some others) is an open-source huge XMPP compliance and integration test harness (ejabberd's open-source test suite is a joke and it's not known whether any closed-source suite exists). We pay more attention to failure scenarios in distributed setups (handle node downs, clean up transient data). Refactored code / cleaner internal interfaces improve iteration speed on customizations if you're interested in extending the system.
[1]: When I researched Prosody on this topic I found out that some clustering support was in development, but as far as I could tell it was far from usable. Honestly, I'd be grateful if somebody could shed more light on this.
Location: Poland
Remote: Yes
Willing to relocate: Maybe, only Europe
Technologies: Erlang/OTP, XMPP, scalability, C
Résumé/CV: https://drive.google.com/file/d/0B3mIvA-cFH9YMUd6bnBwdzd0aDA/view?usp=sharing
Email: [email protected]
GitHub: https://github.com/lavrin/
LinkedIn: https://www.linkedin.com/pub/rados%C5%82aw-szymczyszyn/3a/657/654