Boson
Boson is a new programming language. It is intended to build on concepts from other languages like C and Go, while remaining extremely simple.
The fundamental idea of Boson is to develop a simple language with a very simple runtime, suitable for programming at any level from kernels to web applications. The language will take ideas (and sometimes syntax) directly from other languages.
Keep in mind reading these pages that the syntax and other things may be inconsistent. The language is still a work of imagination, and a lot of things have yet to be determined. These documents serve as points of exploration to develop and eventually concretize the language, it’s features, and its syntax.
Background
As new programming languages have been developed, they have addressed deficencies in their predecessors. However, they have also usually added a good deal of complexity. Go and Rust are good examples of these. Boson is an attempt to address deficiencies without adding a lot to either the language or the runtime.
The rest of the overview will discuss primary inspirations and why Boson exists.
C
The C programming language was developed along side Unix at Bell Labs in the late 60’s and early 70’s, evolving directly from several predecessor languages, BCPL and B.
C has gone through a long evolution process, but is extremely simple even today. A large portion of its behavior is defined in its standard library, which is optional. Useful programs can be written in C without the standard library - of course the standard library itself is written in C. It’s just a library after all.
These properties of C are still desirable - an extremely small, simple language which requires nearly no runtime support, supported by an optional standard library of functionality. C is not just a legacy programming language; new code is developed in C constantly, and there are a variety of compilers, standard library implementations, and too many other libraries to count. One might wonder why, after nearly 50 years, there are still situations where C is the best tool for the job.
C also has a number of deficiencies, most notably the complete lack of memory safety. The number of bugs and CVEs that have resulted from C’s lack of memory safety is staggering, and some companies are moving away from memory-unsafe languages altogether, including C. This leaves a vacuum where these languages once were. I believe this to be part of the emergence of our next-gen languages, like Go and Rust.
C has a large amount of implementation defined and undefined behavior. This means that there is a lot of “works for me” code that “works” sometimes and other times breaks. It’s easy to write programs in C that appear to work, but are actually broken.
C also leaves something to be desired around tooling. Makefiles, autotools, cmake, and many others exist, but all suffer from being add-on tools to a very old language. In the case of autotools, cmake, and many others, they also try to solve compatibility issues across operating systems, and deal with dependencies. While pkg-config has improved dependency detection, it’s still far from good. The C environment may be very different from system to system. This isn’t exactly the fault of the language, but it is the current state of affairs, and it makes writing portable C difficult.
Go
Go is a project originally conceived by Robert Griesemer, Rob Pike, and Ken Thompson.
The language was designed to solve several specific problems at Google, namely building software at a large scale. They wanted to enable many developers to work on huge systems, and with those goals in mind Go was designed.
Go clearly takes a lot of inspiration from the designers’ previous work, specifically Plan 9 C and Limbo. Go includes first-class support for concurrency, and manages memory with a garbage collector. While Go is a lot simpler than contemporary languages like C++ or Java, the concurrency and garbage collection requires a significant runtime.
Boson looks to Go a lot for hints about what a memory-safe, modern C might look like.
Rust
Rust began as the side project of Mozilla developer Graydon Hoare
Rust’s old FAQ says:
Rust exists because other languages at this level of abstraction and efficiency are unsatisfactory.
Rust appears to be an answer to the complexity and lack of safety in C++, and C++ developers seem to be its primary target. Even so, it has some nice properties and features that Boson learns from.
Rust’s enums behave like algebraic data types. Rust’s ownership rules ensure memory-safety, and Boson’s (much simpler) ownership system will be informed by that. Rust uses “references” over “pointers”, meaning that null pointers are not an issue you encounter when writing Rust. While you can use pointers, it’s not idiomatic. Boson will behave similarly, by not including null in the language.
Rust is a very nice language to work in, and the guarantees it provides through its novel ideas really make it stand out. However, it is still a large and complicated language.
Boson
So why Boson?
- C is crufty, slow to compile, unsafe, and has terrible tooling.
- Go is a great new tool, but the runtime is large, and due to its internal scheduler and garbage collection, it’s not suitable for everything. In addition, it still suffers from null references.
- Rust is also a great language, but the concepts and features are numerous and quite complicated to use. Writing a working program that does anything complicated takes a lot of time, reading, and looking at compiler output.
Go solves issues Google was having with C++ development scale, compile times, memory safety issues, and concurrency.
Rust solves issues at Mozilla with C++ usability, memory safety, concurrency, and tooling.
Boson solves issues with C memory management, memory safety, error handling, and tooling. I see this as the biggest difference between Boson and Go, Rust, and several other contemporary projects. It appears that Go, Rust, and others aim to be replacements for C++, Java, and the like. Boson will be a replacement for C.