Erlang Blog Posts

Learning Resources Blogs & Podcasts
1

Erlang blog posts thread :smiley:

See main-blog-post-threads for others in this series.

There are two ways to post links to your blog posts here.

  1. The first is the standard method of simply posting it in one of the main-blog-post-threads (such as this one) for the BEAM language your blog post is about.

  2. The second is posting it via Devtalk inside any of the blog posts sections - and weā€™ll automatically cross-post here in a dedicated thread as well so long as your accounts both here and there have the same username as well as primary email address :smiley:

What are the advantages to the latter? Quite a fewā€¦

  • Your blog post gets a dedicated thread here as well as on Devtalk.
  • Your blog post gets tweeted by our account here as well as the Devtalk account.
  • When itā€™s cross-posted here we automatically add a blogs_by_yourname tag where yourname is your username. This lets people follow your blog posts easily, or, if theyā€™re not to that personā€™s tastes, to mute them.
  • We remove the rel=nofollow attribute for all posts that feature on the Devtalk homepage system.

How to post via Devtalk

  • Simply ensure your account there has the same username and email as your account here (youā€™ll need to register one if you donā€™t already have one there).
  • When you create the thread there ensure it is in one of the blog posts sections and donā€™t forget to include the tag for the BEAM language your blog post is about (if itā€™s about more than one just include the tag for the primary language - threads tagged with Erlang will be posted here and those tagged with Elixir will be posted on the Elixir Forum).
  • As soon as you initiate thread creation there, paste the link in the title field - this is what will remove rel-nofollow from the link on the Devtalk frontend (you can change the title once the link has registered).

When might you want to use each method?

  • If you just want to quickly post a link to your blog post use the option 1.
  • If you want more exposure or if you self-host your blog and want to improve your search engine rankings, use the second option.

Enjoy! We canā€™t wait to see more Erlang and BEAM bloggers :023:

This also works for podcasts.

4 Likes
2

I just published one on Erlang Battleground todayā€¦

5 Likes
3

Great :ghost: Halloween :ghost: post!

3 Likes
4

Excellent blog post.

I will take the opportunity to explain what is happening in the compiler when it warns or remains silent. Consider this example, similar to the one in the blog post:

warn(X, Y) -> X+Y;
warn(6, 6) -> six.

Here an early optimization pass in the compiler will see that the first clause will always match because all patterns are (distinct) variables and there is no guard. Therefore, the compiler will remove all clauses that follow it, and at the same emit a warning for each clause that is discarded.

I call warnings that are emitted when the compiler optimizes or attempts to optimize the code opportunistic warnings. Here is another example that produces an opportunistic warning:

atom_arith() ->
    X = 42,
    Y = a,
    X + Y.

The compiler will substitute the values of X and Y into the expression, get 42 + a and try to evaluate it. When the evaluation fails, the following warning will be emitted:

t.erl:7:7: Warning: evaluation of operator '+'/2 will fail with a 'badarith' exception
%    7|     X + Y.
%     |       ^

It might seem that opportunistic warnings are a great way to get useful warnings for free with no downsides, and I also thought so when I first implemented them. I was wrong.

Because of the opportunistic nature of the warning, the compiler could remain silent for code that is very similar to code that produces a warning. For example, the compiler will not emit any warning for this code (but Dialyzer will):

atom_arith(X) ->
    X + a.

The reason is that the compiler never attempts to evaluate X + a since X is unknown.

Many such ā€œmissing warningsā€ have been reported as bugs to the OTP team over the years.

Another downside is that when we introduce new optimizations in the early optimization passes, the compiler could start warning about legitimate code. We would have to add extra code to the compiler to ensure that no false warnings were emitted.

Because of those downsides, we donā€™t plan to introduce any new opportunistic warnings in the compiler, but we will keep emitting most of the opportunistic warnings that are currently emitted.

14 Likes
5

Amazing explanation! Thank you very much, @bjorng :pray:

3 Likes
7

just found this very detailed insight into an incident at Klarna.

11 Likes
8

Fantastic write-up, thanks to the author.

Iā€™m going to keep this one (on single state entry extraction) in mind. :slight_smile:

3 Likes
9

Hi All. Did you hear about the Erlang spellchecker called Sheldon that Felipe Ripoll developed when he was at Inaka?
Thanks to amazing mentoring by @elbrujohalcon, I was able to write my first article dedicated to how I reviewed and improved this library.
Check it out at Erlang Battleground!

5 Likes
10

Maybe someone already seen it, but Iā€™m see it a first time:

$ erl
Erlang/OTP 24 [erts-12.0.3] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1]

Eshell V12.0.3  (abort with ^G)
1> et:phone_home(1, from, to, msg, opts).
hopefully_traced
2>

:upside_down_face:

3 Likes
11

But compiler behaviour like this is quite common. Lots of C compilers can only detect certain warning causes when certain optimisations are switched on and also donā€™t find all of them, e.g. from gcc manual:

The effectiveness of some warnings depends on optimizations also being enabled. For example -Wsuggest-final-types is more effective with link-time optimization and -Wmaybe-uninitialized does not warn at all unless optimization is enabled.

I think its in the nature of warnings that they are somewhat fuzzy.

5 Likes
12

Hi All. Check out what new topic about new rebar3 plugin on Erlang Battleground for spell checking of the source code with Sheldon which we made together with @elbrujohalcon.

3 Likes
13

https://medium.com/erlang-battleground/the-rebar3-plugin-a-simple-rebar3-template-to-fast-build-your-plugins-71ab0129456b

Hi folks! New week - new topic! In this topic together with @elbrujohalcon we are describing a great rebar3 template(GitHub - vkatsuba/rebar3_plugin: The rebar3 plugin template) what we made for fast building your own rebar3 plugins.

6 Likes
14

I just republished one that I wrote a decade agoā€¦

https://tealfeed.com/oldies-goldies-scaling-erlang-yi51p

4 Likes
15

Hi folks! New week - new topic! In this time described stuff about how to contribute into Erlang Open Source. Enjoy! Special thanks to @elbrujohalcon , @garazdawi, @bjorng!

9 Likes
16

Another old one that I brought back from the web archiveā€¦

4 Likes
17

Hi folks! New week - new topic from Ukrainian Erlanger for Erlang Battleground. In this time we discuss pretty interesting stuff about Erlang/OTP and ASN.1.

5 Likes
18

To keep up with the trendā€¦ a new republished article.

3 Likes
19

New week, new year, new old articleā€¦
This one from #2016, about the lessons that HernƔn Wilkinson shared at
Inaka on a TechDay, but translated to Erlang

4 Likes
20

Talking a bit on peer in upcoming OTP 25.
peer: distributed application testing ā€“ The Erlang Journey (max-au.com)

15 Likes
21

Great stuff! Iā€™m looking forward to using peer to test some distributed code later this year :grinning:

3 Likes