Photo of Andreas Rumpf
Andreas Rumpf
GitHub icon

Andreas Rumpf on designing and growing Nim

Hello, who are you and what are you working on?

Hi, I'm Andreas Rumpf, the inventor and lead developer of the Nim programming language.

Why did you start Nim?

I started the Nim project after an unsuccessful search for a good systems programming language. Back then (2006) there were essentially two lines of systems programming languages:

  • The C (C, C++, Objective C) family of languages.
  • The Pascal (Pascal, Modula 2, Modula 3, Ada, Oberon) family of languages.

The C-family of languages has quirky syntax, grossly unsafe semantics and slow compilers but is overall quite flexible to use. This is mostly thanks to its meta-programming features like the preprocessor and, in C++'s case, to templates.

The Pascal family of languages has an unpleasant, overly verbose syntax but fast compilers. It also has stronger type systems and extensive runtime checks make it far safer to use. However, it lacks most of the metaprogramming capabilities that I wanted to see in a language.

For some reason, neither family looked at Lisp to take inspiration from its macro system, which is a very nice fit for systems programming as a macro system pushes complexity from runtime to compile-time.

And neither family looked much at the upcoming scripting languages like Python or Ruby which focussed on usability and making programmers more productive. Back then these attributes were ascribed to their usage of dynamic typing, but if you looked closely, most of their nice attributes were independent of dynamic typing.

So that's why I had to create Nim; there was a hole in the programming language landscape for a systems programming language that took Ada's strong type system and safety aspects, Lisp's metaprogramming system so that the Nim programmer can operate on the level of abstraction that suits the problem domain and a language that uses Python's readable but concise syntax.

What were the early days like?

Back then the language was still called "Nimrod" (named after the biblical king), later we changed the name to "Nim" for marketing reasons. Nim was supposed to be a small, statically typed language that compiles to C. Targetting C was chosen for its portability and available code optimizers. This way I wasn't burdened with having to write an assembler producing, optimizing compiler backend.

The first implementation of Nim was written in Pascal/Delphi because I was most familiar with it and back then it had the best combination of static typing, runtime checking and a very good debugger. Then I wrote a tool called "pas2nim" that could translate the subset of Delphi that I actually used to Nim. So then I had a Nim compiler binary and the Nim compiler available as Nim source code so then Nim could compile itself, a process known as "bootstrapping". The first bootstrapping was successful in 2006 so that's the official birth year of Nim. "pas2nim" also proved useful in translating Pascal libraries and wrappers to Nim, giving us some libraries as a starting point.

Later I developed c2nim to be able to do the same with C code. However, C libraries are notoriously quirky, the preprocessor is abused in all sort of ways and there is hardly any type information available. C is also really hard to parse. So c2nim never worked as well as pas2nim did. However, c2nim still exists and it can automate the bulk of the wrapping process.

I remember that I thought "once Nim can bootstrap, it is essentially complete and done". Nothing could have been further from the truth, the real work began with the users coming to Nim, finding bugs and gotchas in the design, requesting more features. Of course, users also became contributors, speeding up the development process.

How have you grown Nim's usage?

Nim contributors and users (myself included) wrote articles about it and spread the word. We also produce development blog videos and video tutorials.

How have you gotten other contributors involved?

I think the fact that I was online on IRC helped quite a bit, people could and still can ask the man responsible for most problems directly. That encouraged collaboration.

How do you manage the workload and the community?

Incoming bugs are prioritized. Critical bugs are resolved quickly or at least a workaround is provided. I'm trying to establish a "pull request Friday" where every Friday will be reserved to go through the pull request queue and to ensure it shrinks.

How much time do you devote to Nim?

I work full-time on the language and I also employ two other full-time programmers to work on the Nim compiler, the tooling and managing the community.

What are the biggest obstacles you've had to overcome?

Good question. In retrospect, everything was harder than it first looked:

  • Designing an indentation based grammar.
  • Defining symbol lookup rules and scoping rules.
  • Compiling to C.
  • Writing and documenting a library that works on Linux, OS X, Windows, BSD, etc.
  • Maintaining the existing language features and standard library.

Modern programming languages are beasts: For example, closures are ubiquitous these days and most programmers take them for granted. But implementing just this one feature took us 3 rewrites of the transformation algorithm and roughly 3 months of full-time work. Or take subtyping and generics, these two can interact in complex ways and result in quite some complexity in the Nim compiler. Of course, people would blame the complexity on Nim's less common features like its macro system.

What are your hopes for the future of Nim?

That more software products make use of it. Nim is not the perfect programming language, but it's more versatile than most of its competitors. It is also very good at detecting errors at compile-time, something most versatile languages are rather bad at.

If you want to use a single programming language in your company instead of a plethora of different technologies that don't work well together, then Nim is for you. Nim's long development process and growing community also mean that Nim is mature - it's pitfalls are well known now and being addressed in the form of tooling and not by adding more and more special cases to the language definition.

I also hope to see more funding and donations, please support us on Open Collective or Patreon.

What advice do you have for other open source projects and maintainers?

Understand that not having Google's or Mozilla's resources behind a project can be a strength - creativity is often the result of constraints.

To find out more about Nim, you can visit the website or star the project on GitHub. For a bit more insight into the language design process, you can see Andreas's writings here:

Editor's note: Nim is an interesting step forward in programming language design. But it's not just a curiosity - it's designed to be an effective systems programming language for real-world use. Go and Rust are two other relatively recent languages, sometimes used as a point of comparison to Nim, which have also taken steps forward in this area and have also seen success. One big difference is that Go and Rust are backed by two large entities, Google and Mozilla respectively, whereas Nim has relied on outside donations and sponsorship. If you want to help advance the frontier of systems programming languages then consider making a donation, which will help catalyze the great work Andreas and the Nim team are already doing.