Nit

Nit is a statically typed object-oriented language with a script-like surface and a research compiler underneath. Its home page promises “a fun language for serious programming” and shows the whole of Hello World as print "Hello, World", but the ideas that matter are structural: every value is an object, classes may inherit from several parents, any module may reopen any class - including Int - to add methods, attributes or even new superclasses, static types follow the control flow so that casts are almost never written, and null is confined to types explicitly marked nullable. Programs compile to C and then to native binaries, and the same source can be turned into a Linux executable, an Android APK or an iOS app.

The language is the work of Jean Privat, who designed its ancestor PRM (“Programming with Refinement and Modules”) for his 2006 doctorate at LIRMM in Montpellier under Roland Ducournau, and who has led Nit since 2008 as a professor at the Université du Québec à Montréal. Around him, a rotating cast of UQAM graduate students and interns built a surprisingly broad ecosystem - a documentation generator, a unit tester driven by doc comments, foreign-function interfaces to C, Java and Objective-C, a web server, a portable-app framework, a game engine, a package manager - almost all of it written in Nit. Development peaked in 2014-2015, the last tagged release is v0.8 of January 2016, and the project has been dormant-to-quiet since 2019, though it stirred again in 2024 and 2026.

History and origins

PRM at LIRMM (2002-2007)

Nit’s research page opens with a note that “some Nit team members has been working for more than 15 years on object-oriented languages and compilation techniques” and that the page “gathers works related to Nit (and previously to PRM, the ancestor of Nit)”. That lineage runs through Roland Ducournau’s group at LIRMM, the computer-science laboratory of the Université Montpellier II, whose interests were multiple inheritance (Ducournau co-authored the 1994 OOPSLA “Proposal for a monotonic multiple inheritance linearization”), covariance, and the implementation techniques - coloring, binary tree dispatch, perfect hashing - that make method invocation, attribute access and subtype tests cheap in the presence of multiple inheritance.

Privat’s contribution, beginning with a 2002 DEA report on type analysis and call graphs in separate compilation, was to reconcile two things that were usually traded against each other: the modularity of separate compilation and the efficiency of whole-program optimisation. With Ducournau he published “Intégration d’optimisations globales en compilation séparée des langages à objets” (LMO'04), “Raffinement de classes dans les langages à objets statiquement typés” (LMO'05) and “Link-time static analysis for efficient separate compilation of object-oriented languages” (PASTE'05, in Software Engineering Notes in 2006). The class-refinement paper proposed “two coupled notions of class refinement and modules, the first bringing flexibility and the second, structure”, in which “modules group a coherent set of class definitions and also have the ability to modify the classes defined in the modules they depend on” - the exact shape of Nit’s redef class.

The language that embodied this was PRM. Privat’s thesis, recorded by theses.fr as 2006MON20007 and titled “De l’expressivité à l’efficacité, une approche modulaire des langages à objets. Le langage PRM et le compilateur prmc”, presents “PRM, a language validating an approach to multiple inheritance, modules, and class refinement” and “an original compilation scheme that is both separate (modules are compiled independently) and integrates global implementation techniques”. The report “PRM, The Language. Version 0.2”, deposited on HAL on 2 October 2006, introduces it in words that would outlive the name: “PRM stands for ‘Programming with Refinement and Modules’. It is an open-source programming language that has a simple straightforward style and can usually be picked up quickly, particularly by anyone who has programmed before. It is object-oriented but allows a procedural style. prmc is a PRM compiler that produces efficient machine language executables.” An August 2007 LIRMM report by Ducournau, Floréal Morandat and Privat, “Modules and Class Refinement: A Meta-modeling Approach to Object-Oriented Programming”, used PRM as its showcase and noted that modules and refinement “are intensively used in the organization of its libraries and tools”.

The rename to Nit (2008)

On 9 July 2008 Privat committed “First NIT release and new clean mercurial repository”. The Changelog stanza for version 0.1 says only “First release under the NIT name”, and the README of that revision - “NIT is a statically typed object-oriented programming language. The goal of NIT is to propose a statically typed programming language where structure is not a pain” - still lists bin/prmc and bin/prmdoc among the tools; a commit of 26 November 2008 is titled “Remove some remaining PRM references”. The four features advertised, “Pure Object-Oriented, Multiple Inheritance, Realist typing policy, Light and clear syntax”, remained in the README for a decade. No public source explains the choice of the name, and this article does not guess at one.

The layout of that first release is the layout of the repository today: src/ holds “the NIT tool sources (written in NIT)”, c_src/ holds “C code of nitc (needed to bootstrap)”, lib/ the standard library, tests/ the non-regression suite and examples/ the sample programs. Nit was self-hosting from day one, bootstrapped from generated C that has been checked in and refreshed ever since (“Only one gcc pass for initial bootstrap”, 25 December 2008).

Montreal and the early releases (2009-2012)

The PRM papers were written in Montpellier, but Nit was developed in Montreal, where Privat is a professor in the Département d’informatique of UQAM; the project’s sponsors listed on every page of nitlanguage.org are LATECE (a UQAM research laboratory), NSERC (Canada’s research council), UQAM and LIRMM. Jean-Sébastien Gélinas, the second contributor in the NOTICE file, worked on the treatment of null: “Prévention du déréférencement de références nulles dans un langage à objets”, by Gélinas, Privat and Étienne Gagnon (the author of SableCC, whose generated parser Nit still uses), appeared at LMO'09.

Releases came at irregular intervals. Version 0.2 (6 February 2009) added automatic constructors and closures and was “the last Mercurial changeset, now we uses Git”; the GitHub repository was created on 6 October 2009. Version 0.3 (29 August 2009) introduced nullable types, “local variable moving static type”, a native garbage collector, an intermediate representation, syntax colouring for Vim and gtksourceview, and renamed meth to fun and attr to var. Version 0.4 (18 February 2011) settled the remaining vocabulary - package became module, special became super, universal became enum - and added or else, new-style attributes, “global nullable optimizations” and “better adaptive typing”. Version 0.5 (17 April 2012) added a for over several variables, coloured error messages, “hardened Virtual Type checks (but generics are still unsafe…)” and a native interface to C.

Meanwhile PRM had its scientific swan song. The OOPSLA'09 paper “Empirical Assessment of Object-Oriented Implementations with Multiple Inheritance and Static Typing” by Ducournau, Morandat and Privat reviewed “a significant subset of all possible combinations” of implementation technique and compilation scheme “and present[ed] a systematic empirical comparison of their respective efficiency with all other things being equal”; its “testbed consists of the Prm compiler that has been designed” for the purpose. The companion French paper at LMO'09 reports that the tests were run “with and on the compiler of the Prm language” and that global-optimisation schemes “show a significant gain compared to coloring, which serves as the reference”. These are the only performance figures the Nit lineage has ever published, and they measure dispatch mechanisms against each other rather than Nit against other languages.

A new compiler and a growing team (2012-2013)

Days after 0.5, the repository gained two new tools that would replace the original compiler: nitg, a “global” compiler (20 April 2012), and nit, an interpreter (26 April 2012). They were built on a “new metamodel” that separated the model of classes, properties and types from the syntax tree, and it was in nitg that the engines later exposed as --global, --separate and --erasure were developed. A full C foreign-function interface reached the compiler on 6 February 2013 and a GTK binding on 19 February; version 0.6 (29 July 2013) advertised the new metamodel, “New tools (nit, nitg, nitmetrics)”, wikidoc in nitdoc, triple-quoted strings, the new FFI and “new libraries (especially using FFI)”. On 16 November 2013 the Makefile was changed to “use nitg to bootstrap; drop bootstrap of nitc”, and on 10 December 2014 nitg was renamed nitc, so that the name of the original compiler now belongs to its successor.

The Changelog itself was retired with 0.6 (“This Changelog file is deprecated. Look at the newsletter … or the commits log”), and from 0.6.1 (31 October 2013) the project moved to roughly monthly tags: 0.6.2 through 0.6.11 in 2014, 0.7 on 2 January 2015 and 0.7.1 through 0.7.9 through 31 October 2015. Alexis Laferrière (who signs as xymus) and Alexandre Terrasa had joined in 2009 and 2011 respectively and became, after Privat, the two largest committers - roughly 3,300 and 2,100 non-merge commits - with Lucas Bajolet, Jean-Christophe Beaupré, Romain Chanoir and Jean-Sébastien Gélinas following.

The boom years (2014-2016)

2014 was the busiest year in the history of the repository, with roughly 3,800 commits, 644 of them merges, and 2015 was nearly as busy (about 3,700 commits). The list of first-commit dates reads like a product roadmap: serialization (1 February 2014), Android as a compilation target (25 February), nitls and the Java FFI (March), WebSocket support (April), the Nit virtual machine (11 June), emscripten (13 June), app.nit, nitserial and jwrapper for Java APIs (July), the nitcorn web server (22 July), nitpretty (August), the Objective-C FFI (27 August), a Markdown parser (3 September), the erasure compiler, nitpick, nitiwiki (22 September), Opportunity (29 September), the Rosetta Code examples (October), SDL 2 bindings (November), the iOS library (15 January 2015), MongoDB (May 2015), gamnit and the Java-emitting compiler nitj (July 2015), the renaming of standard to core (26 August 2015), nitcatalog (28 August 2015) and nitweb (December 2015).

On 8 January 2015 “The Nit Programming Language” reached the front page of Hacker News with 61 points and 76 comments. The thread was sceptical in the way such threads are - “It is going to take a lot to convince me that the world needs yet another statically typed OO programming language” - but it also drew out the project’s own explanation of its central idea. Laferrière wrote: “Classes and types are definitely static in Nit. Class refinement is applied at compilation and any ambiguity is reported at that time. After using this language for a few years, I’m now convinced that class refinement is an improvement to manage preoccupations in projects of any size … Nit uses classes to encapsulated data only, and modules to separate preoccupations.” His example was a game whose game_logic module defines Game and whose graphics module reopens it to add draw.

From early 2015 Privat published a “pseudo-monthly newsletter about the development and the progress of the Nit project” called Niteration on the nitlanguage Google Group; the July 2015 issue, the seventh, reported the website’s move to nitiwiki, UTF-8-aware strings, conditional importation as “the first Nit Enhancement Proposal” and nitj passing “~700/950 tests”. The last issue, dated 1 February 2016 and covering November 2015 to January 2016, announced version 0.8, which “marked the 10.000 commits in the main repository”, along with Gitter chat rooms, editor packages for Atom, Sublime Text and Emacs, RESTful routing in nitcorn, 2D and 3D frameworks in gamnit, and VR rendering through the Google Cardboard SDK. Version 0.8, tagged 31 January 2016, remains the current release.

Slowing down (2016-2026)

Activity halved in 2016 (about 1,750 commits) and nearly halved again in 2017 (roughly 1,100), as the students of the boom years graduated. The work that continued was still substantial: Ducournau, Pagès and Privat’s “Preexistence and concrete type analysis in the context of multiple inheritance” at PPPJ 2016 built on the Nit VM; an actor-model library arrived in September 2016; Terrasa’s documentation research led to “Using Natural Language Processing for Documentation Assist” (Terrasa, Privat, Tremblay, AAAI workshops 2018); the nitpm package manager (begun as picnit in February 2018) took its name on 3 March 2018; Florian Deljarry’s contract system landed on 19 April 2019. The Docker images were last pushed on 14 August 2018.

After 2019 (roughly 280 commits) the repository went quiet: about 60 commits in 2020, none in 2021, two in 2022, none in 2023. Then, between July and October 2024, Privat landed 130 commits - a rewrite of the nitcc parser generator, caching and array-based frames in the interpreter, tests for the nitin interactive interpreter, an AST-building API and the merge of Deljarry’s invariant contracts - and refreshed the website, whose pages carry a last-modification date of 19 July 2024. In August 2026 Laferrière returned with three pull requests, merged on 10 and 19 August, that moved the Docker images to Debian bookworm, updated Android support to API 23 with AGP 7.4 and Java 17, raised the iOS deployment target to 13.0 and fixed a Java FFI build collision. The metadata for this page calls Nit dormant; “maintained in bursts by its two founders” is closer to the truth.

Design philosophy

The home page lists Nit’s goals under three headings. Usability: “usable by real programmers for real projects”, the KISS principle, “script-like language without verbosity nor cryptic statements”, “painless static types: static typing should help programmers”, “efficient development, efficient execution, efficient evolution”. Object-oriented: “everything is an object”, multiple inheritance, “static open classes”, virtual types. Robustness: strong static typing and “no more NullPointerException”.

Two decisions drive most of the rest. The first is that a program is a collection of modules linked by importation, and that a module may refine the classes it imports. The object-oriented-principles page calls this “the Nit way to do open classes” and is careful about the vocabulary: “the correct world might be ’extend’ but it could be misinterpreted because of Java”. Refinement, unlike monkey-patching in Ruby or extension methods in C#, is resolved statically - the manual states that “in programs, the real instantiated classes are always the combination of all their refinements” - and it can add attributes and superclasses, not merely methods. The principles page’s rule of thumb for choosing between refinement and subclassing is characteristically blunt: “If you hesitate between refinement and specialization, then it is specialization.”

The second is a “realist” or “covariant typing policy”. Where Java and C# chose invariance for generics and Scala chose declaration-site variance annotations, Nit declares that Array[Cat] is a subtype of Array[Object] and that a subclass may redefine a virtual type or the return type of a method to something more specific. The principles page acknowledges the cost - “the main advantage of the covariance is the improved expressiveness” while “invariant languages (eg. Java, C++) have to use unsafe downcasts to achieve the same effects” - and the compiler pays it by inserting run-time checks, which the --no-check-covariance option (marked “dangerous”) will remove. Ducournau’s 2002 OOIS paper “Real World as an argument for covariant specialization in programming and modeling”, cited on the research page, is the philosophical defence.

Around those two are a set of “done right” rules for inheritance that the principles page spells out: “No repeated inheritance … A Cow is an Animal, there is no point to even ask ‘how many time a Cow is an Animal?’”; “No explicit transitive specialization”; “No hidden inheritance: specialization is public”; and “No static overloading: A method or an attribute introduced in a super-class is always inherited and cannot be mistaken with something different.”

Key features

Everything is an object, and refinement reaches everything

“In Nit, all data, even primitive stuff like integers and booleans, are objects”, and the site insists “it is not just some automatic boxing (a la Java 1.5)”: var a: Object = 5 and var b: Object = 3 + 2 satisfy a.is_same_instance(b). Because basic classes are ordinary classes, they can be refined. The canonical example from the manual:

redef class Int
    fun fib: Int
    do
        if self < 2 then return self
        return (self-1).fib + (self-2).fib
    end
end
# Now all integers have the fib method
print 15.fib # outputs 610

A refinement can also redefine methods, add attributes and add superclasses; “the kind or the visibility of a class cannot be changed by a refinement”, so one simply writes redef class X whatever X is.

Multiple inheritance with C3 and a CLOS-style super

Four kinds of class exist - interface, abstract class, class and enum - and “all these classes can be in multiple inheritance, can define new methods and redefine inherited method (yes, even interfaces)”. The manual explains that super “behaves more like the call-next-method of CLOS than the super of Java or Smalltalk”: redefinitions of a method are ordered by a linearisation “based on C3”, and each super calls the next definition in that order, which depends on the dynamic type of self. In the manual’s diamond, D inherits from B and C, both of which inherit from A, and (new D).derp prints "DBCA".

Class refinement as a module system

Modules import one another with three visibilities: import (public, “an analogy is using #include in a header file”), private import and intrude import, which “bypasses the private visibility and gives to the importer module full access”. Importation “cannot be circular”, and by default every module imports core. Visibility coherence rules ensure that a public signature cannot mention a private type. Laferrière’s summary on Hacker News - classes encapsulate data, modules separate concerns - describes how the Nit tools themselves are written: the compiler’s front end is a sequence of modules each of which reopens the AST classes to add a phase.

Adaptive typing and isa

Nit’s answer to the cast is adaptive typing: “the static type of a variable can change according to: the assignments of variables, the control flow, and some special operators (and, or, or else, ==, !=, and isa)”. A variable declared without a type has the upper bound nullable Object and takes the static type of whatever was last assigned; an isa test narrows it for the rest of the branch, including the right-hand side of an and:

var max = 0
for i in n do
    if i isa Int and i > max then max = i
end
print max # outputs 11

The manual gives the loop rule explicitly - on entry to a loop “the upper bound is set to the current static type; on exit, the upper bound is reset to its previous value” - and control flow is analysed purely structurally: “The real value of the expressions used has no effect on the control flow analyses”, so if true then return else return end followed by a statement is a compile error for unreachability.

Nullable types

Since version 0.3 (2009) null has been a value of its own that only fits in types written nullable T. A method on a nullable receiver is refused at compile time; x != null and x isa T adapt the type; x or else default supplies a fallback; x.as(not null) asserts non-nullness with a run-time check. The Gélinas-Privat-Gagnon LMO'09 paper is the design’s published rationale, and “No more NullPointerException” sits on the home page as one of the three robustness promises.

Virtual types and covariant generics

A class can declare a type as a property - type OFFICE: Office - that “subclasses can redefine (with redef) … The only requirement is that the new bound is a sub-type of the previous bound.” The manual’s Employee/Boss example uses it so that b.office.fridge.open type-checks for a Boss and fails for an Employee. Generic classes use square brackets (class Pair[E]), “must always be qualified when used”, and “unlike many object-oriented languages, generic classes in Nit yield a kind of sub-typing. For example, Pair[Int] is a subtype of Pair[Object].”

Syntax

Blocks open with do (or then) and close with end; newlines end statements unless “something … obviously needs more input”; parentheses are optional on argument-less calls and on the principal call of a statement (a.add 5, print a.length). Strings interpolate with braces - print "j={j}; j+1={j+1}" - and triple-quoted strings interpolate with {{{ }}}. Attributes declared with var get a public getter and a private setter, adjustable with is writable, is protected writable and so on, and “from an API point of view, there is no way to distinguish the read access of an attribute with a normal method”. Constructors are unusual: by default new “requires a value for each attribute defined in a class without a default value”, and subclasses “automatically collect” the additional attributes, so new Book("ABC", "Bla bla", 15.95, "John Doe") works with no constructor written. Operators (+, [], <=>, setters such as something=) are ordinary methods with special call syntax. Labels allow break label outer_loop.

Foreign-function interfaces and platforms

The FFI drew specific praise in the Hacker News thread (“one of the nicest part of Nit in my opinion”). Extern methods carry their foreign body inline in backquotes, and the compiler generates the glue; C support was completed in February 2013, JVM and C++ helper modules and the Java FFI followed in early 2014 and the Objective-C FFI in August 2014, with jwrapper and objcwrapper generating Nit classes from Java jars and Objective-C headers. The nitc manpage states that nitc can produce executables for other platforms “when specific modules are used” and that “currently, android and emscripten are supported”; the android module makes the compiler emit an APK, lib/ios documents compiling app.nit programs for the iOS simulator on OS X, and lib/emscripten targets JavaScript. Host support, per the FAQ, is “Linux distributions (tried on Debian, Ubuntu, Fedora) for 32bit and 64bit architectures; and on other Unix variants (tried on MacOSX and SunOS)”; the README gives Homebrew and MacPorts commands, and a separate page describes msys2 and Cygwin builds on Windows as “more than experimental”.

The toolchain

The compiler’s default trade-off is described in the manpage as “a good trade-off between the compilation time and the performance of produced executables. To produce more optimized executables, the current best option is --semi-global”, while --global warns that “the produced executables may become huge and the compilation time is prohibitive”. The repository’s benchmarks/ directory scripts the comparison of engines and of Nit against other languages for the team’s own use, but the project publishes no cross-language numbers, and the FAQ carries entries titled “Executables are really big and really slow!” and “The compiler is slow to compile”.

Libraries and programs

lib/ holds 113 top-level packages and the catalog at nitlanguage.org/catalog indexes them by tag. Beyond core, the highlighted packages are nitcorn, gamnit, android, popcorn, objcwrapper, benitlux, jwrapper and nitcc. Bindings exist for GTK 3, SDL 2, OpenGL ES 2.0, EGL, X11, curses, Cocoa, SQLite 3, PostgreSQL, MongoDB, Neo4j, libcurl, libevent, WebSocket, POSIX, pthreads, OpenMPI, GMP, gettext, readline, the Raspberry Pi’s bcm2835 chip and Stanford CoreNLP; formats include JSON, CSV, INI, Markdown, MessagePack, S-expressions and XML (DOM and a SAX parser called saxophonit). contrib/ and examples/ collect the programs that exercised these libraries: nitiwiki, Opportunity, Tnitter, xymus.net, Benitlux (an app tracking the beers on tap at Brasserie Bénélux), Tinks!, Action Nitro, Asteronits, model_viewer, a Brainfuck interpreter, pep8analysis and a set of Rosetta Code tasks (eight are listed in Rosetta Code’s Nit category as of August 2026). An experimental F-Droid repository, “nitdroid”, distributes the Android builds.

Current relevance

Nit today is a well-preserved research language with a small, mostly local community. The GitHub repository holds about 14,000 commits (11,700 excluding merges), 259 stars and 68 forks, some forty listed contributors, roughly 2,000 .nit files totalling some 360,000 lines, and nearly 800 test programs. Its documentation - the manual, the object-oriented-principles page, the tool manpages, the generated standard-library reference - is complete and consistent, and the Docker image nitlang/nit, though last built in 2018, is still published. Issues and pull requests on GitHub are the main channel; the Google Group appears to have carried only the Niteration newsletters and fell silent in 2016.

Whether it is “dormant” depends on the window. No release has been tagged since v0.8 in January 2016, and the years 2020-2023 saw fewer than seventy commits in total. But the 2024 burst was real work on the parser generator and interpreter, and the August 2026 platform updates - Debian bookworm, Android API 23, iOS 13 - are exactly the maintenance a mobile-targeting toolchain needs to stay usable. The project is best described as maintained by its two principal authors when they have time.

Why it matters

Nit is the most complete working demonstration of class refinement as a first-class language mechanism. Open classes exist elsewhere - Ruby, Objective-C categories, C# extension methods, Kotlin extensions, Swift extensions - but Nit made refinement static, modular, able to add state and superclasses, and central to how its own compiler is structured, and it backed the design with the LMO'05 and 2007 meta-modelling papers. Anyone studying the “expression problem” in a class-based setting will find in Nit a large, real codebase organised around the answer.

It is also a laboratory in which the trade-offs of multiple inheritance were actually measured. The OOPSLA'09 empirical assessment, run “with and on” PRM’s compiler, is one of the few systematic comparisons of dispatch implementations under equal conditions, and the nitc engines that grew out of it - separate, global, erasure, semi-global - are still selectable from the command line. The preexistence papers of 2015-2016 continued that tradition with the Nit VM.

Finally, Nit anticipated in one package several ideas that the mainstream adopted one at a time over the following decade: flow-sensitive narrowing that TypeScript and Kotlin would popularise as “smart casts”, nullable types (2009) and or else (2011) before Kotlin’s ?: reached a stable release, unified attribute/getter syntax, doc-comment-driven unit tests, and a single source tree compiling to desktop, Android and iOS. It never had the users to make those ideas famous, but it had them working, documented and tested in 2015 - and the language that “aims at elegance, simplicity and intuitiveness” is still there to be cloned, built with make, and tried with nitc examples/hello_world.nit.