My research group at Stanford uses Zulip for instant messaging. I like it A LOT more than Slack. I'll list a few of the features I think most contribute to why Zulip > Slack (IMHO). Also, I'm not affiliated with the maintainers of Zulip at all. I am just a big fan of their software :).
- Zulip has something called a "topic" which is basically a Slack thread but with a name/subject-line. Unlike Slack threads though, every message you send has to be sent in a topic. Zulip makes it much easy to context switch between these topics too. Ever have a situation in Slack where two people are discussing something in a channel instead of using a thread or DM? That isn't possible in Zulip.
- The Zulip UI offers a lots of nice features compared to Slack too. For one, you can see the number of unread messages in each topic directly from the main page. Zulip also supports multi-line messages so you don't have to send a bunch of message one right after the other to break up text, you can add line breaks directly to your message.
- Zulip has a "message drafts" features which is nice when you want to draft a message (or multiple messages), but will send it later. Zulip will hang onto your drafts until you need it.
- Zulip has full markdown support. You can format links, images, and tables (which are all especially nice when using bots) using standard markdown syntax.
- Zulip has full color syntax highlighting when embedding code-snippets into messages! It has support for basically every programming language I can think of (including brain-fuck!).
- Zulip has support for latex equations in messages.
- Zulip is open-source! You can use the version of Zulip hosted at zulipchat.com or you can deploy your own Zulip server by grabbing the source code from github (https://github.com/zulip/zulip).
- In the time since I have switched from Slack to Zulip (about 1 years ago now), Slack has gone down 3-4 times and has had other connectivity issues; Zulip had maybe 1-2 minor interruptions that I can think of in that time.
Minor nit: I wish the "With great data come great neural networks" graph in the blog post had data points from real experiments instead of the hand-wavy curves that are drawn. I know the goal is to give intuition about DNNs v. classical methods, but I don't think I've ever seen a version of this graph with real data! I doubt the real curve would be infinitely differentiable like the ones plotted :P.
>> Neural networks have recently met success because of the rise and availability of large amounts of data.
I think that the improvement in computation power has had at least as much of an impact on the field as data! The only reason people have even bothered to collect the amount of data they have is because the DNNs that need the data are finally cost effective to run on modern hardware.
I feel like this article does not substantiate its core claim, "clever coders can beat tech giants." The main evidence given by the authors is that because Google lost to a much smaller company, Fast.ai, on a toy problem (training a model to 93% accuracy on the CIFAR-10 dataset) that small-time AI researchers can beat the big guys at their own game. This feels like a straw man argument and I'm not convinced.
That said, I do think smaller, independent AI research groups can be impactful even if they aren't going to beat Google in a head-to-head competition; they just have to find problems the tech giants aren't working on yet :).
The reason T-Mobile looks so bad is because the T-Mobile trace was from a 3G network with very poor conditions, while the others (AT&T and Verizon) were from LTE networks under relatively good conditions. You shouldn't compare the quality of the carriers from our results.
I have used tesseract and in my experience unless you train it for the particular type of text you want to recognize (font, background color, etc.) it will do quite poorly (including the recent lstm based versions). Would be great to see how it stacks up against these APIs though.
The cost savings are not the main advantage of AWS Lambda compared to EC2 (AWS recently announced EC2 will bill on a per second basis and a minimum of 1 minute). Instead, I'd argue that the programming interface, managed operations, and scalability are what makes it a better tool for these types of tasks! I'm looking into running other more general computations on Lambda right now as part of my PhD! (stay tuned for more soon). Until then, check out ExCamera (https://www.usenix.org/conference/nsdi17/technical-sessions/...) and PyWren (https://github.com/pywren/pywren).