[erlang-questions] Erlang... Newsletter?

[Motiejus Jakštys]

Hi,

This issue was raised many times in this mailing list, and I stumble on
it over and over again.

As we know, OTP has many well-hidden pearls, that oft times you learn
about only after implementing your own (or, unfortunately, never). Same
for third-party Erlang libraries and applications, which often do not
get the attention they are worth.

I suggest a weekly* email to this mailing list**, which would present a
"product" from one of these categories:
1. In OTP, application building blocks.
2. In OTP aids for coding, testing, profiling, debugging.
3. Third-party library, an application building block.
4. Third party aids for coding, testing, profiling, debugging.

A write-up should have short description how it can be used, why, and a
link for more information. If applicable, with code examples or anything
you see fit. It should be lightly readable, kind of one that you can
absorb while you are having breakfast. Something that takes <3 minutes
to read and sticks.

Purpose of it is for everyone to see that a certain thing exists, and
remember that you have seen something similar when you actually need it.

Organization
============

For start, I suggest making it round-robin per category. If we see that
we have enough content to write, we can put 2 items per email (from
distinct categories).

Every email should go to a publicly available site. My suggestion is
github wiki, because it can be git fetched and pushed and I Markdown is
only half bad.

Target audience is somebody who has read a textbook about Erlang (or
LYSEFGG, for that matter). You should not speak about gen_fsm, mnesia or
running EUnit tests. The goal is to introduce what an average Erlanger
might not know. For example:
1. gen_event, inets, pg2, global
2. percept, observer, dbg, dialyzer, xref
3. piqi, ranch, apache thrift, gproc
4. PropEr, BenchErl, redbug, vimerl, wrangler

Questions for everyone:

1. While I can write about some things myself, participation of others
is essential. Would you be interested in reading this, or would you
create a filter which marks it as spam? Honesty and strong language
in answers to this question are most welcome.
2. Would you submit a 3-minute reading about part of OTP or your
favourite tool?

For now I have no idea how to answer a question "who posts this week",
but I think this question will answer itself as time goes. Remember,
more content -- better for everyone.

To get an idea how a write-up might look like, I made an example about
piqi, one of the best tools for Erlang RPC services out there. Anton,
sorry if something is incorrect, I tried to do my best.

Piqi example
============

About
-----
Piqi — a powerful data definition language. It is specially designed to
be used with Piq (data representation language, kind of JSON, but
structured and looks different), but also works as a schema language for
other data formats including JSON, XML and Protocol Buffers binary
format.

When you should use it
----------------------
When implementing a web API, often you have to expose an external
interface, which *must* be formally defined. Piqi gives you ability to
define an interface, which can be used by several transports:
* Google Protocol Buffers
* JSON
* XML
* Piq (the piqi transport)

Note that both XML and Google Protocol Buffers support interface
definitions. But then you are stuck with a single transport. Piqi gives
you flexibility to use any transport for the same data definition.

More information
----------------
Official website: http://piqi.org/
A biased introduction: http://m.jakstys.lt/tech/2012/04/erlmpc-and-the-awesomeness-of-piqi/

[*]: /biweekly/monthly. It just has to be periodic and not too frequent.
[**]: or a blog-like thing, or "planet Erlang".. Format does not matter.
Periodicity and content are what matters.

Regards,
Motiejus Jakštys
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

[Karolis Petrauskas]

Hello,

I would be happy to read such a newsletter.

Karolis

[Motiejus Jakštys]

On Mon, Oct 29, 2012 at 09:09:36AM +0100, Dave Cottlehuber wrote:
> Hi Motiejus,
>
> This would be great. I've just started a comprehensive dive into
> erlang debugging (redbug, archaelus's scripts, etc) and was going to
> be blogging all of what I've learned (a lot!). I'm still a beginner
> erlanger, but I'd be happy to assist coediting or coordinating this.
>
> How about an octopress site and people sending pull requests with
> their posts? Or even a simple github wiki?

Hi Dave,

Github requests/wiki are great. That way we can just pick up whatever is
available.

To start issuing peridically, we need:
1. interested participants
2. content

Content is just a matter of work, but if few are interested, then it's
just a vain work. :-)

You are the only one replied, although there were two questions in my
email. This makes me think that this kind of "newsletter" is not the
right way to achieve the goal.

Maybe "planet Erlang" kind of thing, were people blog about tools, and
subscribe to a feed where they can be found by someone who is
interesting. Like your case.

Regards,
Motiejus

[Jeremy Ong]

Sorry for the late response. I'd also be interested in a newsletter.

[Abhinav Singh]

+1 me too

[Michael Truog]

I think a newsletter would be a good opportunity to provide information about Erlang and open source usage of the language, if it avoids just trying to be a sales letter for a specific company (and/or product). One topic I would really want to see in a newsletter, is recent changes everyone should be aware of in the next release of Erlang, to make the release a bit more transparent... with any bugs mentioned explicitly as they are found, and bug fixes mentioned... in a way that is interesting. The current release notes do seem to list information, but the context of bugs mentioned is often unknown, and the description is usually quite short (for any item on the list).

Another good topic that would be good to mention in the newsletter is performance. Often, with new versions of Erlang, people complain about slower performance (faster performance doesn't get as many emails, strangely). So, it would be nice to have info specifically about Erlang performance, in very specific circumstances. Some people seem to believe that benchmarks should never be shared, and they should always be specific to someone's use case... however, that approach only encourages ignorance and a silo-ed environment. Some of the recent lock-free changes could be a great opportunity to show how these changes really improve Erlang, with simple examples (which no doubt exist somewhere, but few have seen).

An interesting topic would be what is currently regarded as the most stable Erlang for production usage, and what is regarded as the beta release of Erlang. If someone were to judge based on the Erlang version, all releases since 1998 are "beta" which might scare a newbie (I have heard scared newbies complain at a recent conference, because of this).

So, I see a newsletter as an opportunity for Erlang to show that it can be both open source and transparent, during its development, just to improve communication and education among the various programmers that use Erlang.