Learning Erlang? speedbump thread, common, small problems

Question

Hi, I just want know all the small problems that got between you and your final solution when you were new to Erlang.

For example, here are the first speedbumps I had:

1. Use controlling_process(Socket, Pid) if you spawn off in multiple threads. Right packet to the right thread.
2. You going to start talking to another server? Remember to net_adm:ping('car@bsd-server'). in the shell. Else no communication will get through.
3. Timer:sleep(10), if you want to do nothing. Always useful when debugging.

Answer 1

Making IO work between nodes.

Answer 2

controlling_process()

Use controlling_process(Socket, Pid) if you spawn off in multiple threads. Right packet to the right thread.

Answer 3

net_adm:ping()

You going to start talking to another server? Remember to net_adm:ping('car@bsd-server'). in the shell. Else no communication will get through.

Answer 4

timer:sleep()

Pause for X ms.

Answer 5

The thing that took me the most time to get my head around was just the idea of structuring my code entirely around function calls and message passing. The rest of it either just fell out from there (spawning, remote nodes) or felt like the usual stuff you've got to learn in any new language (syntax, stdlib).

Answer 6

Integrating it into msvc 6, so I could use the editor, and see the results in the output window.

I created a tool, with

command - path to erlc

arguments - +debug_info $(FileName)$(FileExt)

Initial Directory - $(fileDir)

Checked Use Output Window.

Answer 7

• Learning to browse the standard documentation

  Once you learn how the OTP documentation is organised it becomes much easier to find what you're looking for (you tend to need to learn which applications provide which modules or kinds of modules).

  Also just browsing the documentation for applications is often quite rewarding - I've discovered lots of really useful code this way - sys, dbg, toolbar, etc.

• The difference between shell erlang and module erlang

  Shell erlang is a slightly different dialect to module erlang. You can't define module functions (only funs), you need to load record definitions in order to work with records (rr/1) and so on. Learning how to write erlang code in terms of anonymous functions is somewhat tricky, but is essential for working on production systems with a remote shell.

  Learning the interaction between the shell and {start,spawn}_link ed processes - when you run some shell code that crashes (raises an exception), the shell process exits and will broadcast exit signals to anything you linked to. This will in turn shut down that new gen_server you're working on. ("Why does my server process keep disappearing?")

• The difference between erlang expressions and guard expressions

  Guard expressions (when clauses) are not Erlang expressions. They may look similar, but they're quite different. Guards cannot call arbitrary erlang functions, only guard functions (length/1, the type tests, element/2 and a few others specified in the OTP documentation). Guards succeed or fail and don't have side effects. Erlang expressions on the other hand can do what they like.

• Code loading

  Working out when and how code upgrades work, the incantation to get a gen_server to upgrade to the latest version of a callback module (code:load(Mod), sys:suspend(Pid), sys:change_code(Pid, Mod, undefined, undefined), sys:resume(Pid).).

  The code server path (code:get_path/0) - I can't count how many times I ran into undefined function errors that turned out to be me forgetting to add an ebin directory to the code search path.

• Building erlang code

  Working out a useful combination of emake (make:all/0 and erl -make) and gnu make took quite a long time (about three years so far :).

  My current favourite makefiles can be seen at http://github.com/archaelus/esmtp/tree/master

• Erlang distribution

  Getting node names, dns, cookies and all the rest right in order to be able to net_adm:ping/1 the other node. This takes practise.

• Remote shell IO intricacies

  Remembering to pass group_leader() to io:format calls run on the remote node so that the output appears in your shell rather than mysteriously disappearing (I think the SASL report browser rb still has a problem with sending some of its output to the wrong node when used over a remote shell connection)

Answer 8

• Debugging is hard. All I know to do is to stick calls to "error_logger:info_msg" in my code.
• Docs have been spotty -- they're correct, but very very terse.
• This is my own fault, but: I started coding before I understood eunit, so a lot of my code is harder to test than it should be.