Choosing a programming Language and Framework for BFFH

Status: accepted
Date: 18.02.2020 (?)

Technical Story: Decision regarding programming language and framework to use in BFFH / the backend code of FabAccess

Context and Problem Statement

Programming language Dicussions are the perfect bikeshedding topic. Regardless at some point a decision has to be made so that people can start writing code and being generally useful. Since FabAccess started as a project with several potential developers and even more stakeholders interested/relying on the success of the software this discussion was extra spicy. The relevant discussions were had in the timeframe from about November of 2019 to March of 2020.

Decision Drivers

Available developers, both short-term and medium-term should the project become a successful staple of german/european/terran makerspaces
Barrier of entry for new / additional developers.
Tooling support, esp. regarding non-developers (documentation, ease of self-compilation, …)
Library support / ecosystem in the problem domain
Existing projects that could be extended as to not invent the wheel again
Language Features

Considered Options

Python
TypeScript
Rust
Erlang
Ruby
Haskell

Decision Outcome

Chosen option: "Rust", because the project ended up mostly being developed by FabInfra whos cost/benefit analisys skews in favour of type safety over speed of development.

Positive Consequences

Type safety of Rust strong compared to all other options barring Haskell
Single statically linked binary with very few dependencies makes deployment trivial
Compiled software close to the metal allows running the server on low-powered hardware such as Raspberry Pis even for medium-sized deployments.

Negative Consequences

Speed of development suffers short-term. Rust is a lower-level language than all other evaluated options and requires more thought and developer time to implement high level features.
Available developer pool is small and expensive. Rust is not a good first programming language and comparatively hard to get into for developers if they don't have experience with C++. Developers are available to hire but salary expectation of Rust developers is high compared to Python / Java.
Small ecosystem / few libraries. Rust is a very young programming language and despite being rated as the most popular language on SO for several years and being commercially used has fewer libraries than most other options. Support for e.g. LDAP is not mature. But problem domain of FabAccess is in the area that Rust has the most support for.

Pros and Cons of the Options

Python

Good, because large available developer pool
Good, because of the developers interested in developing it large parts have experience with Python
Good, because Python is easy to learn and a good first language
Good, because Python has extensive library support and an ecosystem geared towards automation
Bad, because comparatively slow. Slowest or second slowest option considered.
Bad, because highly dynamic typing and mediocre static analysis has potential for edgecase bugs being hidden for long times
Bad, because Python gives little control over the crash process. Catching exceptions is very coarse.

TypeScript

Good, because stronger typing than Python and Ruby
Bad, because interpreted language and while faster than Ruby/Python still much slower than the compiled options.
Bad, because the Node.js ecosystem is large but not all that much geared towards low level automation

Rust

Good, because Rust has a good type system allowing to prevent many bugs and crashes using static analysis built into the compiler.
Good, because Rust code is very efficient.
Good, because many people are very interested in learning Rust and are only lacking a reason to.
Bad, because speed of development is slower than for most other options.
Bad, because only one developer in the group has any experience with Rust.
Bad, because available developer pool is small.

Erlang

Good, because specifically built for highly-available, crash-resistant software
Good, because it offers an extremely fine-grained crashing system with encapsulated processes that can not take each other down
Good, because the ecosystem and libraries of Erlang are generally geared towards the problem domain of FabAccess
Good, because Erlang allows for significant static analysis compared to TypeScript, Pyton and Ruby
Bad, because Erlang has a worse type system than Rust and Haskell.
Bad, because only one developer in the group has any experience with Erlang.
Bad, because the developer pool is the second smallest.

Haskell

Good, because strongest type system allowing to prevent many bugs and crashes using static analysis built into the compiler
Bad, because only one developer has any experience with Haskell.
Bad, because the developer pool is the smallest.

5.5 KiB Raw Permalink Blame History