Dr. Erlang Love or: How I Learned to Stop Worrying and Love Crashing

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Dr. Erlang Love or: How I Learned to Stop Worrying and Love Crashing

Mniot: May 22, 2003; Not the one you know

MononcQc posted:

Sorry for the thread necromancy, but I was wondering if anyone in here planned to be around for the Erlang Factory Lite in September, in New York City?

I'm not a frequent poster to the forums, but I'll be there and it would be fun to say hi.

I've only just started learning Erlang, and your book was highly recommended by my coworkers.

# ¿ Aug 29, 2013 19:21

Adbot: ADBOT LOVES YOU

# ¿ May 10, 2024 04:04

Mniot: May 22, 2003; Not the one you know

Cocoa Crispies posted:

Did you have coworkers at Erlang DC?

Unlikely; they're mostly in California. I'm in the Boston area, myself. I know they went to the last SF conference.

# ¿ Aug 30, 2013 14:47

Mniot: May 22, 2003; Not the one you know

Sir_Substance posted:

I eventually resorted to just copy-pasting his code, I'm running it from erlide in eclipse.

Are you using erlide to do the interactive parts of the post, too? I'd recommend using 'erl' on the command-line. I have had lots of problems in the past with Eclipse's console not dealing with programs that want to do readline or curses style IO.

# ¿ Feb 8, 2014 13:27

Mniot: May 22, 2003; Not the one you know

Sir_Substance posted:

Is there a known fix, or alternatively another IDE for erlang that offers similar conveniences?

Use Emacs.

Seriously, though, I haven't tried any IDEs with Erlang. How much is erlide getting you?
I wouldn't write Java without an IDE to type 90% of the boilerplate for me, but Erlang's concise and the only editor help that seems useful is indentation and making sure I don't misspell variables.

Edit: Also, going to the Erlang prompt to do 'c(module).' is not the typical way to compile your code. You'd normally use the 'erlc' program, called from a Makefile or (better) by Rebar. I have no idea how well Eclipse handles those, but they don't involve the buggy console.

Mniot fucked around with this message at 14:19 on Feb 8, 2014

# ¿ Feb 8, 2014 14:16

Mniot: May 22, 2003; Not the one you know

I've only been doing Erlang for a few months, but I have not been missing any IDE because my Erlang workflow is very different from my Java workflow.

In Java, I type a little then press "run" then type a little more then press "run" and so on. I might run my code as much as 6 times in a minute with little edits in between. When I'm debugging, I set some careful breakpoints to get me near the problem and then I step along until I find it.

In Erlang, I spend a lot of time thinking then type a little then think some more. I typically only run my code after at least an hour of editing. When debugging, I put trace statements at the tops of my functions (I bet there's an automatic way to do this) and run. Each function is small and when you see the function inputs it's immediately apparent what the bug is.

# ¿ Feb 8, 2014 15:25

Mniot: May 22, 2003; Not the one you know

Otto Skorzeny posted:

Is kerl the best way to maintain an up-to-date Erlang VM on my machine? My distro is stuck on R15B1.

Yes. I've tried Homebrew on the Mac and various Linux packages and run into too many headaches with missing crypto libs or not finding the exact version I want. Kerl has always worked perfectly the first time and lets me swap between multiple versions at will. (YMMV)

If you want to keep trying it pre-packaged, though, try Erlang Solutions' packages: https://www.erlang-solutions.com/downloads/download-erlang-otp

# ¿ May 1, 2014 05:29

Mniot: May 22, 2003; Not the one you know

I have some limited production Erlang experience and would be be happy to look it over for you. MniotSA@gmail.com

# ¿ Aug 17, 2014 16:36

Mniot: May 22, 2003; Not the one you know

I think it's valuable even to people who don't intend to use Erlang, because MononcQc does a nice job of characterizing the problems that appear once you scale beyond a few hundred users and the ways to solve them. A good read.

# ¿ Aug 19, 2014 03:10

Mniot: May 22, 2003; Not the one you know

Anyone played with Docker at all? I never got comfortable with relx stuff, but I've been playing around with containers as a way to skip all that.

I make a Dockerfile like

code:

FROM correl/erlang:17.1

ADD ./erlang.mk /opt/app/erlang.mk
ADD ./Makefile /opt/app/Makefile
WORKDIR /opt/app
RUN make deps

ADD . /opt/app
RUN make app

CMD erl -pa ebin -pa deps/*/ebin \
         -noinput -config app.config \
         -eval 'application:ensure_all_started(my_app).'

and things seem to work great. Hopefully I'm not missing something terrible, because this is pretty fun and easy to work with.

# ¿ Dec 31, 2014 04:15

Mniot: May 22, 2003; Not the one you know

MononcQc posted:

Never been a fan of erlang.mk personally.

I've started work along with Tristan Sloughter (_tristan3) on rebar3, which we hope to make easier to work with than alternative.

I like Rebar's configuration, but my development cycle with this setup involves rebuilding the container when code's modified, and `rebar compile skip_deps=true` is crazy-slow compared to `make app` with erlang.mk. I'm not sure why that would be...

Edit: 17.3 is totally broken (like, it crashes if you try to make an TLS connection). 17.1 can connect, at least. I'll give 17.4 a shot.

Mniot fucked around with this message at 14:56 on Dec 31, 2014

# ¿ Dec 31, 2014 14:49

Mniot: May 22, 2003; Not the one you know

MononcQc posted:

On the other hand, you won't be using hand-patched makefiles, and it will do conflict resolution (maven-style -- top dependency wins)

Maven's an interesting comparison. I really enjoyed having Maven take care of my dependencies, but if I had to do `mvn package` to see anything I'd get pretty cranky. But Eclipse's incremental compiler is snappy and so I'd code and test with that and only fire up Maven when I was done writing.

Your "How I Start" post seem to say that you just don't test your code until you're done writing. I really wish I had something recompiling and reloading my code for me behind the scenes.

MononcQc posted:

While I can't deny the speed of erlang.mk, I can't wrap my head around the idea of "hm yes I'd love to move more of my build stuff to makefiles",

Well maybe you haven't spent hundreds of hours in grad school making gMake do awful things.

Makefiles are incredibly versatile: an Ops guy once told me he does all his shell scripting in Make rather than Bash: no screwing with "set -e", sane command-echoing, and you can always put bash inside your Make so you don't lose any power at all.

It's not as pretty, but it's a lot more hackable. For example, I got some libraries that do Rebar but not erlang.mk, and they were compiling their sub-dependencies down in sub-sub-directories. Rather than figure out how to do it cleanly, I added this rule to my makefile:

code:

link:
	find $(PWD)/deps -name \*.beam -exec ln -s '{}' $(PWD)/ebin/ \;
	find $(PWD)/deps -name \*.app -exec ln -s '{}' $(PWD)/ebin/ \;

That symlinks every .beam and .app under the deps/ directory into my ebin/. With a little more work, I could make it a breadth-first traversal to get the top-wins dependency resolution with warnings that you're talking about.

Anyway, not that makefiles are the best, but I find it very easy to wrap my head around "I wish a Makefile was controlling this".

# ¿ Dec 31, 2014 17:03

Mniot: May 22, 2003; Not the one you know

MononcQc posted:

That really depends on the project. For a state machine from a known specification and such a small program, I really did my testing in a REPL. There were like 4 states possible and little more than one or two possible transitions between them.

The bigger the project, the faster I am to shift away from the REPL and into a test suite -- there will be more and more behaviours to test in an ever-increasing scope, and REPL sessions rapidly lose their attractiveness in favor of automation for everything.

I think a big part of it is that I'm not experienced enough with Erlang to write for long stretches. I'm generally going "Does this call returns a binary or a list? What can I match against to pull out that username? Will this function do what I'm expecting?" And I get there by compiling all my code, starting 'erl', running 'application:ensure_all_started(my_app).', and then poking around. But every time I need to change something (like my Cowboy handler needs a callback added to it), I exit the REPL and start again.

# ¿ Dec 31, 2014 21:06

Mniot: May 22, 2003; Not the one you know

I did some LISP/C IPC a while back and found the easiest thing was to start out in Lisp and fork the C code as a child process, even though the two programs were conceptually peers. Lisp went first because I was running the Lisp code inside an interpreter, so the launch process was complex while the C code was a statically linked executable.

Doing C/Erlang communication over a socket should be fun and easy. Erlang's binary matching means you can just send and receive packed binary structs in C. (I think this is not actually kosher, but if you only use one compiler it's great.)

# ¿ May 18, 2015 02:08

Adbot: ADBOT LOVES YOU

# ¿ May 10, 2024 04:04

Mniot: May 22, 2003; Not the one you know

I've been using rebar3 for some new projects and really enjoying it. The speed feels way up from the last time I tried it (or rebar) and it's doing a pretty great job of building things the way I expect. "rebar3 eunit" and "rebar3 dialyzer" both work well, and it makes it really easy and fun to write my code with tests and type-specs. The deps system (where there's a "rebar.lock" that pins itself to a specific commit, and you have to "rebar3 upgrade" if you want to change it) took some getting used to, but I'm pretty happy with it in my workflow now. Thanks for working on it!

I've also been using Spacemacs with EDTS enabled. It's not quite perfect as a rebar3-aware flymake, but it's really close. If you like Emacs for Erlang but aren't an Emacs pro, I recommend checking Spacemacs out.

# ¿ Jun 5, 2015 21:26

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Dr. Erlang Love or: How I Learned to Stop Worrying and Love Crashing