Imagining the Ideal Language for Writing Free Software

a FOSDEM 2021 presentation by codesections
  • Talking about an important question
    • what makes a language good?
    • *specifically* for Free Software
  • First, I'd like to introduce myself
  • Dive in
  • what makes a programming language good for Free Software?
  1. Free Software projects are different

  2. Some excellent languages aren't excellent for writing Free Software

  3. The ideal Free Software language should have different design goals

  • 'different' in 2 ways
    • Different from other types of software development
    • Different from the image people have of Free Software

What is Free Software?


  • People talk about Linux, Firefox, and other high-profile Free-Software projects
  • Cathedral?
    • group of architects
    • many builders/execute-ers
  • Bazaar?
    • Many people working along similar lines
    • little/no central organization
    • But, somehow, order emerges
  • Nuclear?
    • more recent comparison
    • Team pours a lot of time & energy
    • hoping for a self-sustaining reaction


All of those analogies miss one thing

Linux is a penguin

  • Most Free Software projects are really small
  • RedMonk study
  • logarithmic scale
    • half had only 1 contributor/year
    • 70% 1 or 2 contributors/year
    • 87% 5 or fewer contributors/year
  • Another study
    • More graphic term 'Truck Factor'
    • but still derived from contributor count
  • 'Popular' is narrowly defined
    • started with the 100 most-stared repos in 6 langs
    • removed any that were in the bottom 25% in other measures of popularity



  • Somewhat randomly chosen
  • Highly recommended
  • Would be counted as outside the RedMonk 87%
    • 16 contributors in first year
    • But let's look closer
          • not a story of large group collaboration
            • a couple of main authors
            • joined by others
          • not minimizing the role others play
            • ability to upstream improvements makes Free Software great
            • I did so myself when using Impress
          • But still, just 2 main developers
          • Not actually 2 developers
            • 1 in 2012
            • 1 in 2018 on
            • really, it's had one maintainer
          • remember: first year: 16 annual contributors
            • so part of RedMonk's exceptional 13%
            • only 1 with more than 3 commits

          Writing Free Software is like writing a novel

          • 1 author (or a small handful of coauthors)
          • Many, many others contribute
            • for books: editors, agent, publishers
            • for software: contributors, bug reports, docs
            • invaluable – but not the author
          • Author is likely part of a community
          • But the actual writing is largely solitary

            Exciting Languages

            • 3 very different languages
              • TypeScript: js superset that adds types; transpile-to-js
              • Go: compiled, GC'ed lang targeting fast compile times
              • Rust: compiled w/o GC, aiming to equal C in perf
            • But all have 1 thing in common
              • The sort of organization that first created them

            “Go is a programming language designed by Google to help solve Google's problems, and Google has big problems.”

              Big Tech
              • Large team
              • High turnover
              • Paycheck
              Free Software
              • Small team
              • Low turnover
              • Self-motivated
              • So, what *technical* values does Big Tech have?
                • And how do they contrast with ideal values for Free Software?
              • Free Software == typical Free Software (novel)
                • Firefox is FS, but atypical; Big Tech
              • "???" not because there's nothing to put there, but b/c there's too much
                • ideological; enjoy helping; to scratch own itch; to learn (maybe $ later)
              • standard format:
                • tools like gofmt, rustfmt, prettier.js
              • one way to do it:
                • standard library design
                • minimal syntax (especially overlapping)
                • limited language customization (operator overloading)
              • avoiding dialects
                • really bad if Bob can't read Alice's code
                • explicit goal for Go
              • familiar syntax:
                • everything looks like C
              • easy to learn:
                • if is someone only there for a couple years, they can't spend long learning
                • again, Go is explicit about this value; Rust talks about it a lot
              • popular – the only thing better than teaching quickly is not teaching
              • want to be tactful and precise
                • many *amazing* programmers work for big tech/for $
                • but the thing is, _everyone_ likes $
                • so, even if most are great, there will be a chance that some do the minimum
              • prevents footguns – if it is both clever/dangerous, take it out
              • prevents corner-cutting – verbosity makes things explicit
              • reviewable code:
                • small diffs
                • discourage interactive programming
              • Again, those were *values*
              • still good for Free Software, but not the same priority
              • powerful – Free Software is the underdog
                • absolutely possible to beat Big Tech
                • impress.js is *better* than ppt; Mastodon is better than Twitter
                • but needs all the help it can get
              • expressive – one of the best ways to be powerful is to say more with less
              • composable:
                • Free Software projects have small # individually, but big collectively
                • No licensee difficulties
                • Unix philosophy
              • rewards mastery – there's time for deep learning to pay off
              • support DSLs
                • a language you *always* have to teach newcomers
                • but offer great power/ability to impose constraints
              • expressive: (for 2nd time)
                • Main reason to limit expressiveness is to prevent code other's can't read
              • friendly, welcoming & inclusive
                • if you're not paying someone to put up with unpleasantness, they won't
                • (more about the language community, but very important)
              • expressive ×3:
                • one non-monetary motive is self-expression/aesthetics
              • fun – people have to *want* to do this


              • Probably not surprised that I think Raku does an excellent job on these values
                • (exactly how and why is long enough to fill another presentation)
              • but not perfect – probably no language ever will be
                • I hope we keep these values in mind as we improve Raku
                • I hope Raku helps Free Software flourish