Falcon

Falcon is an open source scripting language and embeddable virtual machine, written in C++ and designed principally by Giancarlo Niccolai, an Italian software developer and IT consultant. It was built to solve a problem that most scripting languages of its era treated as an afterthought: how to drop a script engine into a large, heavily multithreaded C++ application under sustained message load, without the engine becoming the bottleneck or the source of contention.

The answer Niccolai arrived at was unusual on both ends. On the embedding side, Falcon gave every thread its own virtual machine and built its item model so that host data could be handed to scripts without an expensive marshalling step. On the language side, it went in the opposite direction from minimalism, advertising six integrated programming paradigms - procedural, class-based object-oriented, prototype-oriented, functional, tabular, and message-oriented - and inviting programmers to pick whichever ones fit the problem in front of them.

The project never reached a 1.0 release. Development of the 0.9 “Chimera” line effectively stopped in 2012, a rewrite stalled, and both repositories have been quiet since 2023. What remains is one of the more interesting design documents in scripting-language history: a serious, well-engineered attempt at a niche - the embeddable multithreaded scripting engine - that Lua largely won.

History & Origins

From HASTE to Falcon

The language began as a tool Niccolai wrote for himself. Around 2002, working on servers that streamed real-time financial data, he needed a way to express complex alert conditions - business-critical decisions and maintenance actions that had to be evaluated against data as it passed through the system. He wrote a small evaluator and called it HASTE, for Haste Advanced Simple Text Evaluator.

On 23 May 2002 he renamed the project Falcon, in tribute to Giovanni Falcone, the Italian anti-mafia magistrate assassinated by Cosa Nostra in the Capaci bombing on that date in 1992. The renaming fell on the tenth anniversary of the killing.

Building a Language, Not Just an Evaluator

The decision to make Falcon a full language rather than an expression evaluator came later. By Niccolai’s own account in Linux Journal, it was in late 2003 - after testing the available scripting engines against his requirements and finding all of them wanting - that he decided to write one from the ground up.

His objection to the incumbents was specific rather than aesthetic. As he put it in the project’s own “About” page, mainstream scripting languages were “born as stand-alone solutions, and then made embeddable”, and their behaviour under multithreading “ranged from hard […] to none.” The problem he cared most about was not raw VM speed but the cost of the boundary: converting host application data into script values and back again, at high frequency, could easily consume more time than running the scripts themselves.

Development continued privately for several more years. Falcon was released as open source in 2008, with version 0.8.8 reaching Ubuntu’s repositories in February of that year and the project’s custom licence dated March 2008.

The Open Source Years

The public phase was brisk. The 0.8 line ran through 2008 - distribution changelogs record 0.8.10 around June and 0.8.14 around December - and the 0.9 “Chimera” series opened in 2009, folding the threading module directly into the core engine. Releases arrived every few months: 0.9.2 in July 2009, 0.9.4 with functional generators in August, then the long-lived 0.9.6.x bugfix line through 2010.

Falcon picked up genuine, if modest, institutional attention in this period - the AuroraUX operating system, KDE’s Kross scripting framework, the Blastwave Solaris package community, an XChat plugin interface, a Linux Journal feature in 2008 and a Computerworld interview in 2009. Niccolai estimated the active developer community at ten to twelve people at its peak.

The 1.0 That Never Shipped

In April 2011 the project held a public roadmap meeting for release 1.0, and Niccolai began a substantial rewrite around a new engine he called the Organic Virtual Machine, along with a standalone parser and a reflection system for the syntax tree. Progress reports appeared on the project site through 2011 and into 2012.

The rewrite never landed. The last Chimera version, 0.9.6.9, is represented in Debian and Ubuntu by a source snapshot dated 6 June 2012, and no 1.0 was released. Niccolai made one further attempt: the Falcon2 repository, started in December 2017 under the Apache 2.0 licence, describes itself as “the new incarnation of the Falcon Programming Language.” Its last commit - “Bootstrapping the new Item infrastructure” - was in March 2023. The original engine’s repository received a build fix for modern C++ compilers in November 2023 and has been quiet since.

Design Philosophy

Six Paradigms, Pick What You Need

Falcon’s front page put the philosophy plainly: “you don’t have to master all of them; you just need to pick the ingredients you prefer, and let the code follow your inspiration.” Asked in 2009 which paradigm the language really belonged to, Niccolai answered “all and none.”

This was a deliberate rejection of the purism common in language design. Niccolai, a longtime C, C++ and Prolog developer, argued that existing dynamic languages were “too much unorganized” - that some liberties of untyped languages were barely exploited while others were pushed too far, and that there was no real reason to enforce a hard division between functional and procedural code, or to insist that everything be an object.

Zero Scripting in Libraries

The most consequential and most contrarian decision was the module policy. Every standard Falcon module was written in C or C++ - never in Falcon itself. The project quoted a user’s formulation approvingly: “scripts are like recipes, and libraries are like ingredients. When you start writing your ingredients with recipes, then there’s something wrong.”

The upside is that library calls run at native speed and integrate directly with the VM’s data-sharing machinery. The downside was one the project acknowledged frankly on its own comparison page, under a heading that began “This is our weak point”: a language whose standard library must be written in C++ grows that library far more slowly than one where any user can contribute a pure-script package. Falcon’s library never came close to Python’s or Perl’s, and the project’s proposed remedies - a dynamic C library loader (dynlib) and an automated binding generator (falbind) - were partial answers at best.

Designed Backwards From Embedding

Most scripting languages were designed as standalone tools and later fitted with an embedding API. Falcon inverted the order. Its concurrency model gives each thread its own virtual machine with no shared global lock, so that many scripts can run concurrently inside one host process without contending; its item model was built so that native structures could be mapped onto script objects rather than copied into them; and its module system assumes the host application, not the script, owns the process.

Key Features

The Two Unusual Paradigms

Four of Falcon’s six paradigms are familiar. The other two are what make it worth studying.

Tabular programming treats a table as a first-class language construct: columns are properties, rows are instances, and a cell may hold any Falcon item at all - a number, a string, a class, a function, or another table. The project’s argument for it was pragmatic rather than theoretical. Where adding a newly discovered dimension to a problem might force a class hierarchy to be redesigned, adding a column can be done at runtime. Tables were pitched as a natural fit for business rules, behaviour selection, and fuzzy-logic engines.

Message-oriented programming gives objects a publish/subscribe channel that reaches down into the virtual machine itself. Objects subscribe to named slots and receive broadcasts rather than direct calls, and - crucially for the embedding use case - a multithreaded host application can throw messages into the VM from many threads for serialised handling at script level. Messages can carry not just data but functions and whole functional sequences.

Here is subscription and broadcast in practice, from the language’s own sample suite:

class CmdManager( id, cmd )
   id = id
   cmd = cmd

   init
      subscribe( "declare", self )
   end

   function activation( extra )
      >> "Manager ", self.id, " activated on '", self.cmd, "'"
      if extra != nil
         >> " (on param ", extra, ")"
      end
      >
   end
end

The > and >> operators are Falcon’s print statements - > terminates the line, >> does not.

Ordinary Falcon

For everything else the syntax is a readable blend of C-family expressions and keyword-delimited blocks, with end closing every construct and no semicolons:

directive strict = on

function fib( n )
   if n < 2
      return n
   else
      return fib(n-1) + fib(n-2)
   end
end

> "Fibonacci of 30 is ", fib( 30 )

Closures and higher-order functions are first class, and from 0.9.4 they could be used as generators driven by a plain for/in loop:

function makeGen( vector )
   i = 0
   return function()
      if i == vector.len(): return oob(0)
      return vector[i++]
   end
end

f = makeGen( .[ 'a' 'b' 'c' 'd' ] )
for value in f
   >> value
   formiddle : >> ", "
   forlast : > "."
end

Two Falcon-specific ideas appear here. .[ ... ] is array-literal syntax borrowed from the language’s functional sequence notation. oob() marks a value as out-of-band - a side channel that lets a function return a normal-looking value flagged as meta-information, which is how a generator signals exhaustion without a sentinel or an exception.

The Rest of the Toolbox

Licensing

Falcon shipped under the Falcon Programming Language License (FPLL) version 1.1, dated March 2008 - a licence derived from the Apache License text - with GPLv2 available as an alternative; both licence files sit in the source tree. The Falcon2 rewrite abandoned the custom licence entirely in favour of plain Apache 2.0, which is generally the more practical choice for an embeddable engine.

Performance

Falcon’s performance claims need careful handling, because the widely-quoted numbers come from the project itself.

The Falcon site published a “Facts Table” comparing Falcon against Python, Ruby, PHP5, Lua and Perl. Its one quantitative row was “raw VM loop speed”, measured by running each engine on a program equivalent to this C code:

1
2

int a = 0;
for( int i = 0; i < 100000000; i++ ) a = a + 1;

Results were reported in thousands of loop iterations per second: Lua 1247, Falcon 1023, PHP5 670, Python 442 (2.x) and 340 (3.x), Perl 369, Ruby 116.

Every caveat that can attach to a benchmark attaches to this one. It was published and run by the language’s own authors, around 2008-2009, on unstated hardware, against unstated versions of the comparison engines, and it measures an empty increment loop rather than any realistic workload. The project said as much itself, noting that the figure “is not to be considered an overall speed indicator” but only “an indicator of the relative complexity of doing the simplest possible thing within the language boundaries.” Note also that Falcon did not win its own benchmark - Lua did.

The defensible reading is narrower and more interesting. Falcon’s design bet was never that its interpreter loop would beat everyone else’s; Niccolai said explicitly that speed “is not language specific” and that what mattered was the whole input-processing-output pipeline. The claim worth taking seriously is the architectural one: an engine that maps host data structures onto script items instead of copying them, and that avoids a global interpreter lock by giving each thread its own VM, has structurally less work to do at the embedding boundary than a runtime that must marshal values and serialise access. That claim was never independently benchmarked, and no current measurements of Falcon against a modern CPython, LuaJIT or V8 exist.

Evolution

Falcon’s arc compresses into about a decade. Roughly five years of private development (2003-2008) produced a working engine; four years of public development (2008-2012) produced a stable 0.9 line, a module ecosystem, packaging in the major Linux distributions, and a small but real set of adopters. Then the attempt to build 1.0 as a rewrite rather than an evolution consumed the remaining momentum.

The rewrite decision looks, in retrospect, like the pivot point. The 2011 “Organic VM” work was ambitious - a new engine, a standalone parser, syntax-tree reflection - and it was undertaken by a project whose bus factor was close to one. When it stalled, there was no incremental release path to fall back on, because the shipping line had been frozen in favour of the rewrite. The 2017 Falcon2 attempt repeated the pattern from an even smaller base.

Meanwhile the niche Falcon aimed at did not stay empty. Lua, already dominant in embedded scripting when Falcon started, kept its lead by being smaller and simpler rather than richer; LuaJIT arrived in 2005 and made the performance argument decisively; and JavaScript engines became embeddable at industrial quality. Falcon’s differentiators - a threading model without a global lock, cheap host-data interop, six paradigms - were real advantages that never accumulated enough users to matter.

Current Relevance

Falcon today is dormant. The falconpl/falcon repository on GitHub is still public and unarchived, with a last commit in November 2023 - a patch to make the 0.9 engine build against modern C++ compilers and libraries, which is to say a preservation commit rather than a development one. The Falcon2 rewrite has been idle since March 2023. The falconpl.org domain no longer serves the original site.

Debian and Ubuntu carried falconpl packages built from the June 2012 snapshot for several release cycles, which for a long time made Falcon unusually easy to install for a dormant language, but the package is no longer present in current releases of either distribution. Anyone wanting to run Falcon now should expect to build it from the GitHub source with CMake; the project’s own build instructions target Linux, and support for other platforms should be treated as untested.

There is no active community, no package ecosystem, no ongoing release schedule, and no active successor carrying the design forward - the Falcon2 repository is the only attempt, and it too is dormant. Its documentation survives largely through the Internet Archive.

Why It Matters

Falcon is worth remembering for three reasons, none of which is adoption.

It took the embedding boundary seriously as a design constraint. Most language designers treat the C API as something to bolt on once the language works. Falcon started from the question “what does a C++ server need from a script engine?” and let the answer shape the item model, the threading model, and the module policy. The specific insight - that marshalling cost between host and script can dominate execution cost - is correct, underappreciated, and directly relevant to anyone embedding a runtime today.

It rejected the global interpreter lock early. Falcon’s per-thread VM with message passing between agents - designed in from the outset and folded into the core engine with the 0.9 line in 2009 - is, in outline, the model that Python spent the following two decades trying to reach and only began delivering with the free-threading work of the 2020s. Falcon got there early by not having to preserve compatibility with anything.

It is a clean case study in why paradigm richness does not win adoption. Falcon offered tabular and message-oriented programming as first-class constructs - genuinely novel additions that no mainstream language has since matched - and it did not help. What sank it was the thing its own facts table admitted to: a small library, made small on purpose by a policy that forbade writing modules in the language itself. Falcon lost to Lua, which offers fewer paradigms and a smaller core, because Lua’s simplicity made it embeddable everywhere and its C API made bindings cheap.

The design ideas outlived the implementation. That is a common fate for ambitious niche languages, and it is why Falcon is more useful to read about than it ever was to program in.