[erlang-questions] Erlang... Newsletter?
Mon Oct 29 20:48:24 CET 2012
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.
On 10/21/2012 10:51 AM, Motiejus Jakštys wrote:
> 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.
> 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
> 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
> 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.
> Motiejus Jakštys
> erlang-questions mailing list
More information about the erlang-questions