Reserved exit codes

[evuez]

I just started a Rust implementation and I was looking for exit codes to return on error, and I saw that you are using codes from 1 to 4. Wouldn't it be better to normalize those codes, avoiding 1 and 2 as 1 is for general errors and 2 is for builtins incorrect usage (see https://www.gnu.org/software/bash/manual/bash.html#Exit-Status and http://tldp.org/LDP/abs/html/exitcodes.html).

[nodesocket]

Just seeing this, sorry for the huge delay. So you recommend just switching to exit codes 3 - 6 since 1 and 2 are reserved?

[nodesocket]

Also just curious... How long does your implementation is Rust take to run set_get_delete_500?

Here is my result:

using python -m json.tool

➜  time ./set_get_delete_500.bash
./set_get_delete_500.bash  15.86s user 15.64s system 95% cpu 32.871 total

using jq (3.1x performance improvement)

➜ time ./set_get_delete_500.bash
./set_get_delete_500.bash  5.20s user 6.31s system 111% cpu 10.345 total

using yajl (3.9x performance improvement)

➜  time ./set_get_delete_500.bash
./set_get_delete_500.bash  3.65s user 5.94s system 114% cpu 8.359 total

[evuez]

For the exit codes, there has been a attempt to standardize them in /usr/include/sysexits.h. Relevant part:

#define EX_USAGE    64  /* command line usage error */
#define EX_DATAERR  65  /* data format error */
#define EX_NOINPUT  66  /* cannot open input */
#define EX_NOUSER   67  /* addressee unknown */
#define EX_NOHOST   68  /* host name unknown */
#define EX_UNAVAILABLE  69  /* service unavailable */
#define EX_SOFTWARE 70  /* internal software error */
#define EX_OSERR    71  /* system error (e.g., can't fork) */
#define EX_OSFILE   72  /* critical OS file missing */
#define EX_CANTCREAT    73  /* can't create (user) output file */
#define EX_IOERR    74  /* input/output error */
#define EX_TEMPFAIL 75  /* temp failure; user is invited to retry */
#define EX_PROTOCOL 76  /* remote error in protocol */
#define EX_NOPERM   77  /* permission denied */
#define EX_CONFIG   78  /* configuration error */

So I think it's a good practice to use them!

As for execution time, I get something close to yours using jq:

$ time ./tests/set_get_delete_500.bash 
real  0m7.825s
user  0m5.998s
sys   0m1.778s

I pushed the test file if you want to try it (it's basically the same as yours, though you'll have to manually drop the jsonlite directory first).

Now on my computer with Python I get this:

real  0m6.570s
user  0m4.479s
sys   0m2.467s

And yajl...

real  0m1.495s
user  0m0.363s
sys   0m1.521s

I guess I'm even worst at Rust than I thought I was! Now I don't know if it's the JSON encoding / decoding part that's slow or the reads and writes...

I thought it'd be mostly I/O bound but seeing your results I guess the JSON encoding / decoding is in fact quite intensive!