[erlang-questions] idea: service pack one

[Kenneth Lundin]

Hi,

As responsible for the Erlang Open Source Distribution and the
Erlang/OTP development at Ericsson
I have to comment Joes idea.
I am just as Joe filled with entusiasm after the Erlang conference but
still don't agree with everything that Joe suggests.


On Nov 13, 2007 10:27 PM, Joe Armstrong <erlang@REDACTED> wrote:
> Hi everybody,
>
> I got fired up with enthusiasm at the Erlang conference - it seems to
> me that there are a lot of *simple* things we
> can do that we should have done years ago. The reason was that even
> though many aspects of the system
> suck and can be *easily* improved we have learnt to live with the
> system (warts and all).
The general goal that I think many of us in the Erlang community agree
upon it to broaden the use
and knowledge about Erlang so that it can get the attention it deserves.
It is not necessarily changes and additions in the product, the
language etc. that will make this happen,
I think the distribution is good enough to get more attention even as
it is today.
But of course we need improvements as well but since we can't
implement everything in zero time
it is important to take the steps in the right order.
>
> Now that the book is done my thoughts returned to the Erlang system.
>
> Erlang is becoming popular and now needs to address the problems that
> our new users encounter.
>
> To do this I propose a project called "service pack one" (( its an
> add-on that can be bolted on top of OTP))
"Service Pack" gets me thinking about Microsoft and packages with
bugfixes more than new features.
So not a very good name in my opinion.
>
> (( I don't want to change anything in OTP - just add a free-standing
> set of scripts that modify the behavior
> of the system ))
Hmm? First you say "don't want to change anything", then you say
"modify the behavior of the system"
I thought modify was almost synonymous with change?
I think there is need to have many different "AddedValue Packs" with
additional features and functions
relative a Basic distribution. The distribution of today should then
be divided into Basic and a number of
Additional packages. And this is in our plans during 2008.

> Here's a few very simple things to do:
>
> (each of the things starting +++ is a little project --- now I'd like
> volunteers for each project - most of these are pretty easy
> to hack together a quick and dirty prototype - but needs a little care
> in getting all the details right)
>
>
> 1 +++  fix nicer error messages (Done - Kenneth showed this)
>
> 2 +++ experiment with inheritance (Richard mentioned this) (( I hacked
> this together today, together with
>        some code that checks for missing calls in imported libraries))
> - I can post a longer explanation if you like
I don't think this one of the most important things to do. To support
inheritance
properly you need support in the VM and in the Compiler so this does
not fit very well in
an AddedValue pack. We as Erlang developers are interested in this as
well and may very well
include it as an experientnal feature in the Basic package.
>
> 3 +++  make Erlang start fast so that people stop winging about it
> starting slowly. And fix a
>         *small*  distribution - here's a minimal version.
>
I am not aware of many complaints about Erlangs slow start. From where
do they come?
>     ((aside - who cares if Erlang starts slowly - it was designed to
> start once and never stop - we have systems
> that have run for 5 years - a two seconds start-up time amortized over
> 5 years is not *too* bad))
>
>    (( If you want to make it fast redo the boot scripts - it's all in
> the documentation ! ))

The Erlang/OTP distribution should be viewed as a Development System.
As a development system the current boot scripts are ok I think. There
is a faster
boot script used when "erlc" is used.
When a user develops a program thas is to be deployed and distributed
it might sometimes be important
to have a quick startup and because of that it is documented how to
make your own boot scripts.
This need of course to be improved especially when it comes to changes
regarding
modules and processes in kernel and stdlib.
>
>   (I tried this yesterday) it's really easy
>
>
>   1) make a boot file (jboot.erl)
>
> {script, {"tiny","1.1"},
>  [{preLoaded,[erlang,erl_prim_loader,prim_file,prim_inet,init,otp_ring0]},
>   {primLoad, [tiny]},
>   {kernel_load_completed},
>   {apply, {tiny, start, []}}]}.
>
>  2) write a minimal erlang program
>      tiny.erl
>      start() -> erlang:display'hello world'), erlang:halt().
>
> 3) compile the boot file
>     systools:script2boot("jboot").
>
> 4) run
>     erl -boot jboot
>
> This runs in 0.29 secs on my macbook
>
>    (( for comparison erl -s init stop takes 1.6 seconds)
>
> 5) you also need the erl script:
>
> #!/bin/sh
> ROOTDIR=`pwd`
> BINDIR=$ROOTDIR
> EMU=beam
> PROGNAME=`echo $0 | sed 's/.*\///'`
> export EMU
> export ROOTDIR
> export BINDIR
> export PROGNAME
> exec $BINDIR/erlexec ${1+"$@"}
>

> 6) copy erlexec and beam from the distribution to a local directory.
> (these can be stripped to remove symbol table info)
>
> 7) the result is
>
> $ wc erl erlexec beam jboot.boot tiny.beam
>
>      10      20     172              erl
>       58     277   22012          erlexec
>     4247   35423 1097316  beam
>        0       5     203               jboot.boot
>        5      20     708             tiny.beam
>     4320   35745 1120411 total
>
> 1.1 MB and 6 files - not *too* bad
>
> 8) for fun I packed stdlib/kernel/compiler in an archive using
>     boot_tools:mk_lib() which packs everything a single 1.14 meg archive
>    (boot_tools is in $DIST/otp_src_R11B-4/erts/boot/src
>
> This means we can pack the compiler and base otp system into half a dozen files
>  and under 2.5 Meg
>
11> (( this was my old sae sysytem that never really made it to the
main release))
>
> 4 +++ compile the @spec definitions in comments into code that
> *dynamically* checks types
>         who cares if it's slow and can't be checked statically - the
> dynamic check is very useful
>         while developing
Now we have the "-spec(foo/1:..." syntax for contracts we should use
that one for
this purpose. Dialyzer can find much more errors "statically" with
help of these.
The @spec syntax in edoc will be made the same as the -spec syntax as
soon as possible.

Don't forget that one of the strengths with Erlang is the productivity
advantage compared with
C++, Java etc. In Erlang we can concentrate on solving the problem
without need to write
tons of declarations before we can write and test executable
statements. Contracts will always be optional
and should be used with care i.e not everywhere. The most important
use in my opinion is in the
exported functions intended to form a public API.

> 5 +++ bundle ejabberd (or yaws) in a standard configuration that ships
> with Erlang.
>           I talked to Mickael R. about this - if we shipped ejabberd
> with every Erlang
>           we could easily get tens of thousands of ejabberd servers up
> and running in
>          the twinkling of an eye.
Agree that is would be nice to have both Ejabberd and Yaws as part of
some official distribution so that
it gets easier to get all the good applications from one wellknown place.
>
> 6 ++++ fix BIFs for regexp, searching binaries etc - so people stop winging

I can almost promise that we will add this to the basic distribution during 2008
>
> 7 ++++ fix c(Mod) and erlc so that they throw *everything* at them ie
> dynamic type checking,
>               xref, cover, dialyzer *without* you having to do anything fancy
>              the defaults for compilation should be to throw all
> checks possible into the compile
>              cycle
Since not all of these things are well suited to be done at the same
phase and with the same
parameters I don't agree completely with this.

Dialyzer and xref should not be applied to each module, they should be
applied over all modules
intended to be part of a product.
There is no reason to apply code coverage until test case execution.
Earlier you suggested that we must speed up the startup of an Erlang
system. here your suggestions will
(if taken literally) lead to very long compile and build times.
>
> 8 ++++ make an *erlang* packing mechanism (put the entire application
> in a .dets file - and NOT
> .tar.gz or zip file - then define a bundle structure (look at the MAC
> for inspiration) add application icons
> and a desktop interface.
>
I think packaging vs. icons and desktop interface are two very separate things.
Maybe you are referring to installation packages such as self
extracting exe files on Windows
using MSI for installations? This is OS dependant.
I think the basic distribution should have tools for making this
packaging but maybe not
the final OS dependant part which might be better done with OS specific tools.

> 9 ++++ interface to flash using flex 2. Solve the GUI problem once and
> for all as follows
>
>       repeat after me: client = flash in the browser, server = erlang.
> Intermediate protocol = flash AMF

Flash looks interesting to interface but I don't think is is the once
and for all solution to the
GUI problem.
Take a look at WxWidgets and the Erlang binding hosted on sourceforge
under the name
wxerlang, it has potential to be a very good solution.

>
>
> There are probably more things I could add - feel free to add you pet
> annoyance that can be easily
> fixed and we'll put it into service pack one.
>
Lets take the items one by one I don't think all of what's mentioned
above is suitable to put in
the same package.
>
>
> Cheers
>
> /Joe Armstrong
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>

/Kenneth Erlang/OTP team at Ericsson