babashka/doc/surveys/2020-11.md

## Survey November 2020

The raw data from the babashka survey held in November 2020 is now available
[here](https://nl.surveymonkey.com/results/SM-8W8V36DZ7/).

We had about 100 respondents (just below the free tier of SurveyMonkey). Next
time I'll probably switch to Google forms and add an optional contact field,
since I would have liked to go deeper into some of the answers.

Here are the ten questions from the survey followed by the summarized outcome
and my commentary.

Thank you all for taking the time. This provides useful input for the future
development of babashka.

### Q1 What are you using babashka for? Work / hobby

*Outcome:* 75% work, 76% hobby

*My comment:* Most people use it both at work and for their hobby
programming. This is more than I could have hoped for when I started babashka.

### Q2 What features or namespaces in babashka do you use most?

*Outcome:*

```
- clojure.java.shell      *******************************
- cheshire.core (json)    ****************************
- babashka.curl           ************************
- clojure.java.io         *********************
- clojure.string          ******************
- babashka.process        **************
- clojure.edn             *******
- clojure.tools.cli       *****
- http (in general)       ******
- clojure.data.xml        ****
- clojure.data.csv        ****
- clj-yaml.core           ****
- dates / java.time       ****
- nREPL server            ****
- sql / jdbc              ****
- org.httpkit.client      ***
- i/o flags               ***
- clojure.pprint          **
- org.httpkit.server      *
- babashka.wait           *
- multi-file project      *
- docopt                  *
- ProcessBuilder          *
- java.util               *
- transit                 *
- core.async              *
- clojure.data            *
- aero                    *
- clojure.zip             *
```

*My comment:* Shelling out is a popular thing to do in babashka:
`clojure.java.shell` is the most widely used namespaces. The `babashka.process`
namespace is already used quite a lot despite its recent appearance.

Other popular ways to use babashka:

- http (`babashka.curl` or other)
- JSON (cheshire)
- file interaction (`clojure.java.io`)
- string manipulation (`clojure.string`)

Nothing surprising there for a scripting tool. Closely following is `tools.cli`,
and several other data formats (edn, csv, xml, yaml). The transit format isn't
that widely used from babashka.

Some people are using babashka for interacting with SQL databases. There are two
ways to do this: compile babashka with extra [feature
flags](https://github.com/babashka/babashka/blob/master/doc/build.md#feature-flags)
enabled or use
[babashka-sql-pods](https://github.com/babashka/babashka-sql-pods/).

According to the above outcome, babaska isn't that widely used for small web
applications yet. The `core.async` library had only had one mention although
nobody mentioned it as redundant in question 5.

### Q3 Which babashka pods are you using, if any?

*Outcome:*

```
- sql (mostly postgres) ***************
- file watcher          ****
- clj-kondo             ***
- kafka                 **
- tabl                  **
- tzzh-aws              **
- etaoin                **
- brisk                 *
- lanterna              *
- tzzh-mail             *
- bootleg               *
- parcera               *
```

*My comment:*

The [sql](https://github.com/babashka/babashka-sql-pods) and
[filewatcher](https://github.com/babashka/pod-babashka-filewatcher) pods are the
most popular, closely followed by the
[clj-kondo](https://github.com/borkdude/clj-kondo/#babashka-pod) pod.

The pod concept isn't widely understood yet. In 2021 I might give a talk, if the
opportunity arises, on babashka pod usage and how to develop them. Pods are an
extra thing to install which may be a barrier for adoption for some. This ties
into the next question.

### Q4 What functionality is currently missing in babashka?

*Outcome:*

```
- easy usage of libs and pods ***********
- java.nio bindings / fs lib  ****
- clojure.spec (+ gen)        ****
- database / jdbc             ***
- raspberry pi support        ***
- hiccup                      **
- compile script to native    **
- spire as pod                *
- docs and examples           *
- packaging                   *
- ssh                         *
- nrepl                       *
- http server                 *
- easier creation of pods     *
- sqlite                      *
- java-time lib               *
- better REPL                 *
```

*My comment:*

Clearly users want an easier way to include libraries and pods. We are thinking
about that in [this](https://github.com/babashka/babashka/issues/473) issue.

The second most mentioned missing feature was a library around files. This is
work in progress [here](https://github.com/babashka/fs).

### Q5 What features or namespaces in babashka are redundant and could be left out?

Most people did not suggest anything should be removed, maybe also related to
the most given answer to Q9. A few people expressed confusion about multiple
ways of making http requests.

*My comment:* If have attempted to write about HTTP request in babashka
[here](https://book.babashka.org/#_choosing_the_right_client) and
[here](https://github.com/babashka/babashka/wiki/HTTP-client-and-server-considerations).
The summary is that both `babashka.curl` and `org.httpkit.client` have different
optimal use cases. In most small scripting scenarios `babashka.curl` will
do. For making many small requests `org.httpkit.client` is more optimal since it
won't create an OS process. For downloading big files, `babashka.curl` is more
optimal, since there is no way to prevent `org.httpkit.client` from holding the
response into memory all at once.

In the future both of these clients may be superseded by a client based on
`java.net.http` (probably exposed as `babashka.http-client`), but this client
isn't there yet and it may take a while before the Java 11 client space has
crystallized. Meanwhile you will have to do it with either of these
clients. Luckily both clients accept and return Ring-like maps, so upgrading to
the future client should not be hard, unless you are depending on something very
specific. I plan on keeping `babashka.curl` in babashka no matter what, since
it's a very thin layer over `curl` and doesn't complicate the compilation
process of babashka much. There will be a transition period of having both
`org.httpkit.client` and the `java.net.http` client after which
`org.httpkit.client` will be phased out and `babashka.http-client` will be the
recommended HTTP client in babashka.

### Q6 Babashka prints the last value of an expression or script. Should this change?

*Outcome:*

```
- Yes: 7.8%
- No: 69%
- It depends: 23%
```

*My comment:*

The most given answer is: no, keep it this way. Most of the "it depends" answers
said: I don't really care. Some suggested that printing should always be
explicit and maybe should be controlled using a flag.

The reason babashka always prints the list value of a script, unless it is
`nil`, is that in the very beginning, babashka was intended as a Clojure-in-bash
one-liner utility. We only had the `-e` option and not the `-f` option for
executing scripts from disk. When the `-f` option got added, it was handled
exactly the same as `-e`, with the difference that the expression was read from
a file.

Since the majority of people expressed that this should not change, we will keep
it this way. This will also avoid breakage for scripts that depend on
this. Stylistically it might be better to use explicit printing in scripts. If a
script returns `nil`, nothing will get printed for you, which aligns nicely with
how `println` and `prn` behave.

### Q7 When would you use babashka instead of JVM Clojure?

*Outcome:*

The majority of people use babashka as a replacement for `bash`, `python` or
`jq`. The fast startup is the main reason they favor it over the JVM when
writing small and short-running scripts that are cross-platform. In this
scenario babashka is used for CLI utilities, ETL (data processing) scripts,
automation / CI / devops and scripts ran from editors like emacs and vim. Some
people use it in places where they want to avoid or can't have a JVM
installation or in memory constrained environments. Some people answered:
whenever I can.

*My comment:*

Babashka's original goal was to be a Clojure replacement for shell scripting and
based on the answers, it seems to have pulled that off.

### Q8 What operating system do you run babashka on?

*Outcome:*

```
- Linux:   80%
- macOS:   58%
- Windows: 16%
- Other:    2% (raspberry if possible, AWS Lambda)
```

*My comment:*

It's interesting to compare the outcome of this question with the answers to
"what is your primary development OS" in the Clojure 2020 survey
[here](https://clojure.org/news/2020/02/20/state-of-clojure-2020#_deep_dives).

Note that I didn't ask about the development OS but where scripts are run and
multiple answers were allowed.

### Q9 Is the binary size of the bb executable important to you?

*Outcome:*

```
- Yes:     13%
- No:      87%
```

*My comment:*

The people who care about binary size report that it should not grow beyond the
range of 10mb and 512mb. But most people don't care about it.

I do personally care about it from the perspective of not cluttering babashka
unnecessarily during its lifetime. Related, adding more stuff challenges GraalVM
compile time and memory usage during compilation. Hitting the limit on free CI
might mean I will have to charge for building binaries in the future or come up
with some business model to finance the builds.

### Q10 Any other feedback on babashka?

*Outcome:*

Lots of encouraging words. Thank you all!