Everyone has an email account. Whether you use it for its intended purpose or not, it's all but required to use the internet today.  Most people I talk to primarily just use email to sign-up for sites, reset passwords, or get specific emails.  Their mailboxes are out of control, and for OCD people like myself, it can even be stressful.  Over a decade ago I outlined what I thought was a "better email", and shockingly, only about 30% of what I came up with has been implemented in one form or another today.

I knew that this undertaking was both massive and complex and that I would have to wait until I had the resources, knowledge, and capacity to write it.  That time has finally come!

We've submitted an application to YCombinator and should know April 16th if we've been accepted.  Fortunately, even if we don't get into YC we're going to pursue this anyway.  We have a private prototype strictly for YC's use only, but if you're interested in seeing a video demonstrating the very primitive functionality we've built out so far, take a look:

Again, it's a very minimalistic demonstration of what we are building, but it represents a replacement and integration for both email and Facebook.  The latter was one of our biggest concerns for integration, so we decided to undertake it as a proof of concept.

Remember Google Wave? When it came out, I thought perhaps Google had finally built what I had in mind.  However, they had two colossal mistakes that led to failure:

1. No mobile integration. While it was still the early days of mobile applications, no mobile application significantly hindered adoption for those of us with smartphones.
2. The switch mentality.  I set up my account immediately when Google Wave first opened it to the public.  However, none of my friends or family were there.  I convinced a few other people to give it a try, but convincing people to start using it in addition to email and other messaging platforms just wasn't going to happen.

The first public release of Courio will have complete mobile support (a no-brainer today).  The second issue though is to avoid forcing anyone to feel like they have to "switch".  We want to "add" and never limit anyone's options.  To do that, we are heavily focused on the unification of all of your current messaging platforms into Courio.  This means that you can talk to everyone you talk to today, but you can do it in one place instead of many places.

I just wanted to take a few minutes and outline my new endeavor.  Feel free to sign-up at https://courio.com to get updates as we move forward.

While we have some early funding, we are considering outside investment for early-stage development.  If this is something you'd be interested in learning more about, please contact me at matt@courio.com.

An intentionally provocative heading, but one I stand behind until someone can prove otherwise (and I welcome just that).  Scribe 1.x was pretty fast (http://www.matthicks.com/2017/01/logging-performance.html), but was not written with performance in mind.  When I came back around and realized just how fast log4j2 is, I could see no reason why a Scala logging solution shouldn't be able to run circles around it.

Note: the benchmarks below are tested using simple file logging to represent the most common production logging scenario.

Log4J Comparison

Now, for people like me that often want to skip all the blustering, explanations, and bravado, I'll cut straight to the result graph of the performance comparison between log4j 2.10.0 and Scribe 2.0.0:

Like I said, log4j2 is fast, but Scribe 2 is just shy of a 50% performance boost on that.  If we look at the over-time graph it provides additional insights:

You can see that log4j does well, but operations increase in cost partway through, while Scribe is smooth and steady for the entire run.

Method and Line Numbers

This is all compelling but practically speaking, 99% of applications won't even notice the difference between 1,500 nanoseconds and 800 nanoseconds per record logging.  Thus far I've been comparing Apples to Oranges though.  In Scribe, the method and line numbers are integrated into the log records by default.  If we add that to the logging (which any reasonable logging framework should have) we see a different story:

Shocking, right?  If you know Java, you'll probably realize why this is.  In Java, the only way to get access to method and line numbers in your logging is by walking the stack trace.  This is a very expensive operation to be doing and slows the logging to a crawl.  This is why it's not on by default, and why you don't see this talked about much in Java logging frameworks.  However, Scala Macros come to the rescue!  In Scribe, we get all of that for free.  The method and line number information are extracted at compile-time so you can see that Scribe is just as fast whether method and line number logging is enabled or not.

Typesafe Scala Logging

In 1.x my focus was the comparison with Scala Logging.  As you can see below, we're not even in the same ballpark:

It's a pretty pathetic comparison.  In Scribe, 1.x Scribe was noticeably faster, but this shows just how inefficient Scala Logging is.

All Loggers

If you'd like to see the side-by-side comparisons of all the competitors:

Though the log4jTrace and scalaLogging results dwarf the performance distinction between log4j and Scribe, if you've seen all the results here, Scribe is the clear performance winner here.  I'll make another post to show why it's also more powerful, but I'll save that for another day.

Sources

I'm not a master with log4j or Scala Logging, so it's possible I'm not giving ideal running circumstances for these loggers to "show their stuff".  The original source code is posted in the repository: https://github.com/outr/scribe/blob/master/benchmarks/src/main/scala/scribe/benchmark/LoggingSpeedBenchmark.scala

The JMH benchmark results were also saved to a JSON file if you want the raw results to make sure I'm not trying to pull a fast one: https://github.com/outr/scribe/blob/master/work/benchmark/2018.01.31.benchmarks.json

Getting Started

To learn more about Scribe and start using it, check it out here: https://github.com/outr/scribe

Please feel free to email me if you find any mistakes in anything I've said to set me straight, or you can publicly shame me by writing a comment on this post.  I welcome criticism and praise, but criticism gives me something to learn from, so it is more appreciated.

I've never been a fan of the setup of logging frameworks as far back as when I was a Java developer.  The hassle and complexity of configuring and managing the logging framework was always a big hassle and would often create serious problems in the application if not done right.  Even today in Scala it doesn't feel much better.  Certainly we have Macros that give some additional compile-time optimizations, but it's amazing how little has changed.

A while back I created a Scala logging framework called Scribe.  Honestly, the primary reason had more to do with giving greater flexibility to control configuration in code over performance or anything else.  However, by not building on top of log4j, logback, slf4j, or JUL, I found that the system was not only far more simplistic and configurable, but it was also faster.

I recently did a comparison between Lightbend's Scala Logging framework to see how it performs.  Without any additional optimizations the results were pretty impressive.  I configured both Scribe and Scala Logging to avoid writing to standard out as that would be the primary bottleneck of performance and simply wrote a custom Writer / Appender that would simply count the log entries:

Over sixty seconds I recorded how many records could be logged.  Scala Logging was able to log 474k records and Scribe was able to log 610k.  Now, obviously this is far more logging than any reasonable application should be doing, but the point was to prove that not only can Scribe keep up with the most popular Scala logging framework (Scala Logging) on top of the most popular Java logging framework (Logback), but it quite a bit faster.

The second thing I measured was memory consumption over the run.  Memory usage is a very important factor with regard to logging as it should have a very small footprint to give maximum allocation to the application itself.  Again, my finding were pretty strongly in favor of Scribe:

While Scala Logging utilized 704kb of memory Scribe utilized on 596kb.  Again, not a substantial difference when we're discussing hundreds of thousands of records being logged, but this is meant to prove that Scribe is the better performer.

Very often I hear that a developer won't use a framework because there aren't enough developers using it.  Obviously this creates a chicken / egg situation as you can't get developers using it because not enough developers use it.

Hopefully this short post will give some additionally credibility to the value of Scribe that people will start comparing features and see just how much it has to offer.  If there's something missing that your existing logging framework has, just create a ticket.

To my relatively small number of followers, it should come as no surprise that my biggest failing is actually getting much visibility for my vast number of open-source projects I write.  To that end I've been doing some research and asking other developers to give me some suggestions on how to get more visibility for me projects.  I've made it a goal for this year to get more visibility for my open-source projects so they will hopefully reach a larger audience.

I decided that I would post the results of my research in a blog post so hopefully others can benefit from this research as well, or at least I can have an easy place to reference back to it for myself.

Speaking / Conferences

The most common suggestion for visibility for a project was speaking about it both in local groups and at conferences.  Several developers said that's how they learned about a useful framework they are using.  This is a good idea and something I'm planning on doing more of this year, even though I really prefer to write code than talk about it, but this is a bit of a longer-term objective than immediate visibility.

Awesome

There are lots of "awesome" lists. Often more than one for each language. This is a no-brainer presuming you can get someone to merge your pull request: https://github.com/bayandin/awesome-awesomeness

Reddit

Apparently there are people that use that site and a common source of information for developers.  I must admit, I haven't been a big user, and this is something I think is going to have to change.  I'll have to get involved in the Scala group and reference my projects there.

Twitter

Yet another thing I am terrible about not keeping up with.  For a very long time I simply had all of my GitHub commits logging to Twitter, but I'm thinking that personalized messages on Twitter with relevant hashtags might be a very good way to get my projects noticed.  Many developers I talked to get most of their news and information from Twitter.

Mailing Lists

Though a bit old-school, this is something a lot of developers still follow and perhaps a good way to get visibility directly into people's inbox of a new framework that should be using.

Based on this research it's clear that my aversion to social media has a direct correlation to my difficulty in getting visibility for my projects.  Shocking right?  I suppose the moral of the story is, if you don't like people, don't expect them to like you either.