∴ikura

NOTP: a middle way

I’ve always considered Erlang to be an excellent
general purpose programming language. With that,
the one-off projects that aren’t systems or
servers always had the bloat of OTP, and never
felt right.

After writing
Yanni, a Machine
Learning suite in Erlang, one that needed to run,
then stop, it was time to have a tool that shed
the some sixty unused modules and just run my
Erlang code already — with little overhead.
Thanks to the final few pages in the Joe Armstrong
2nd edition Erlang book, the path was cleared and
the inspiration was founded for NOTP.

What is NOTP?

NOTP is meant to be used as a ‘deps’ dependency
inside textbook Erlang applications:
applications designed to just run some code,
then just stop; not unlike how ‘escript’ could be
utilized.

Applications that need to run forever should
utilize OTP and the apt target release tactics.

Getting started

You can use rebar[3] to bundle NOTP into your
Erlang application using the conventional deps
strategy.

The public repo for NOTP is as follows:

https://bitbucket.org/nato/notp

NOTP needs a file named ‘notp.config’ to be
present in your project root, as it’s called
from the ‘notp’ bootstrap routine.

The shape of ‘notp.config’ is as follows:

[
{notp, [
{support_modules, []},
{local_modules, []}
]}
].

Since the goal of NOTP is to minimize the modules
loaded for use, it’s up to you to dogmatically
list the module names of your application within
the ‘local_modules’ list. For example:

It goes without stressing that other deps, if any,
also need to be listed in this list.

Moreover, pretend that your Erlang application
uses the ‘math’ and ‘rand’ modules. While it’s
normally fine to assume these will be accessible
without thinking about it, with NOTP, you need to
list underlying OTP modules within the
‘support_modules’ list explicitly. For your
convenience, the ‘lists’ and ‘erlang’ modules have
already been accounted for, so you don’t need to
specify those two. Again, take the following for
instance:

If you neglect to include a needed module, you
will be greeted with an error down the road.

Interfacing modules

In order to execute your application, one or more
modules need to export a main/0 routine that the
NOTP executable will call. It’s good housekeeping
to have an API module that triggers all your code
in an isolated module. You can model this behavior
by taking a look at ‘src/notp_test.erl.’

N.B. these API module(s) ought not get included in
your ‘notp.config’ lists, but of course need to
be compiled.

Bootstrapping

In order to generate the various files to use
NOTP, your code needs to be compiled, and a
bootstrap call needs to be made. Here is an
example of how that is done when NOTP is a deps
and your ‘config’ file is up to snuff:

It should be noted that init:stop/0 is called by
the bootstrapper; no need to include it in your
erl command.

With that, you will be left with the notp
executable in your project root, along with a
requisite ‘notp.boot’ file. You may want to
keep these files out of your project’s
source control.

Usage

With all this in place, zippy Erlang code
execution is ready to go. Here’s an example on how
to use it:

./notp some_api_module_that_exports_main_0

Note, the argument has no suffix — it’s just the
name of a given API module. Also note, it will run
your code without entering an Erlang shell.

What can NOTP do?

I tend to run code and spit out the results to
standard out. But take a look at the exported
routines of ‘src/notp.erl.’ All those goodies are
available for use, and as such, quite a lot of
ground can be covered with NOTP as your Erlang
weapon of choice.