<commit_before>This is a very nascent attempt at creating an alternative to syslog
that is more application oriented (as opposed to systems oriented).

Specific the goals are:

* Make it extremely easy to use from any part of any app code.

* Minimize the impact to application performance (e.g. queue requests
  and process them out of band).

* High level fault tolerance (spool to local files in the case of network
  failures, etc).

* Provide a powerful interface for searching/filtering logged events
  based on the structure of the events.

* Provide a lickable interface for doing standard reporting operations
  on collected events.

* Scale lots.

We will likely be developing the python client first and foremost and
that is what we would like to use at our day job but we definitely
welcome submissions for other languages from other contributors.

I would need to write a lot more to fully express the reasoning behind
our experimenting with this approach and I think a working prototype
will do a better job of demonstrating so I am going to focus my time
on getting things working rather than writing a better description.
Maybe by then if no one else has written a better description, I'll try.<commit_msg>Add bullet point about clients in different languages to README.<commit_after>This is a very nascent attempt at creating an alternative to syslog
that is more application oriented (as opposed to systems oriented).

Specific the goals are:

* Make it extremely easy to use from any part of any app code.

* Minimize the impact to application performance (e.g. queue requests
  and process them out of band).

* High level fault tolerance (spool to local files in the case of network
  failures, etc).

* Provide a powerful interface for searching/filtering logged events
  based on the structure of the events.

* Provide a lickable interface for doing standard reporting operations
  on collected events.

* Provide clients for lots of languages.  Ensure a consistent
  interface and featureset across clients in different languages (by
  having the clients supported by the core team instead of random
  helpful folks).

* Scale lots.

We will likely be developing the python client first and foremost and
that is what we would like to use at our day job but we definitely
welcome submissions for other languages from other contributors.

I would need to write a lot more to fully express the reasoning behind
our experimenting with this approach and I think a working prototype
will do a better job of demonstrating so I am going to focus my time
on getting things working rather than writing a better description.
Maybe by then if no one else has written a better description, I'll try.
{'fraction_non_alphanumeric': 0.02582073035780155, 'fraction_numerical': 0.0, 'mean_word_length': 4.245647969052224, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1908409', 'n_tokens_mistral': 628, 'n_tokens_neox': 612, 'n_words': 433}