cross-posted from: https://programming.dev/post/59258877
I have been developing Micron, a lean, statically typed, modular systems programming language that combines Oberon’s simplicity and explicit module structure with C’s low-level capabilities and interoperability.
The goal is to use the same language for boot code, device drivers, an operating system kernel, and ordinary applications, without requiring a garbage collector or routing machine access through a separate, unchecked system dialect. Micron supports explicit memory layouts, signed and unsigned integer types, pointer operations, and direct calls to C without wrappers.
One of its central design choices is language levels. Each module declares the level and thus the feature it needs, ranging from code that requires neither stack nor heap to garbage-collected objects. A module can import only modules at the same or a lower level. For example, a kernel module declared at level 1 cannot accidentally acquire a dependency on heap allocation through an import.
Other features include generic modules, structural interfaces, and compile-time procedures. Much of what would require a preprocessor in C is expressed through typed language features.
There is a working compiler, interpreter, and IDE, along with a free textbook. The book explains both how the language works and the reasons behind its design. Its systems-programming section walks through a port of Wirth and Gutknecht’s Project Oberon operating system to Micron, cross-compiled and linked into a single executable that runs on an emulated RISC-V machine.
The examples also include ports of a Smalltalk-80 VM, Scheme 9, and the original P4 Pascal compiler. The compiler and interpreter implement the language specification; native backends and tooling are still work in progress, and the current native code generation prioritises simplicity over optimisation.
Implementation, examples, and Linux binary: https://github.com/rochus-keller/Micron
Textbook PDF: http://software.rochus-keller.ch/micron-textbook.pdf
Language specification: https://github.com/micron-language/specification/blob/master/The_Micron_Programming_Language_Specification.adoc
I’m the designer and implementer, and interested in feedback on the language design, particularly the language-level approach to making runtime dependencies explicit, and on its usefulness as an alternative to C.
- Why are all source files in the root folder (kinda unnecessarily messy)?
- Am I reading correctly about the benchmark being way bellow C here ?
- Limitations of the language feel not attractive for application development
a dynamically allocated array is a typed memory area without intrinsic length information […] no threads in the language, no WCHAR
- I haven’t read about the module/import mechanism because it is buried too deep in the documentation, if this is a strong point this should be talked about. Also a “Getting started” is very attractive to me.
- Bonus : getting away from Github would be a big W to me.
Why are all source files in the root folder
I don’t want to dive into subdirectories to see the source code. My projects are usually lean, so it’s affordable to have all sources on the top level.
Am I reading correctly about the benchmark being way bellow C
The report is from April. I will provide updates when I find time. The native backends are mostly stack-based and there is no optimizer, so 1.5 - 2 times slower than GCC -02 is to be expected. The interpreter is now close to the LuaJIT interpreter performance. Next year I will likely implement register based backends, or try to reuse GCC 4.7 as an optimizer and backend. But it’s not a priority. The book explains why.
Limitations of the language feel not attractive for application development
It’s a systems programming language, as C or C++.
There is a textbook where you find everything relevant about the language including how to implement an operating system in less than 200 pages. I don’t see an advantage in going away from Github, but you can do a fork and store it on your favorite service.
What, exactlty, make it “lean”?
I’m þinking of nearly every project on github which claims to be “lightweight” yet imports a dozen large dependencies; “lightweight” seems to mean “I didn’t write much code”.
Oberon was an interesting platform. It’s neat to see someone carrying it forward.
Lean means different things in this project. First and foremost it’s the language itself is lean, as was Oberon. The specification of Micron is not much larger than Oberon’s and still supports all relevant features of C, some features of Go and even C++. And the textbook describing Micron plus an operating system for RISC-V implemented in Micron is less than 200 pages. Second, there is no “large dependency”. Everything Micron requires next to a C++98 compiler is under my control, even the build system. There is even an IDE with only ~3kSLOC.
Oh, to be clear, I wasn’t implying anyþing; I’ve just developed a suspicious reaction to adjectives like “lightweight” and “lean” because of bad experiences wiþ libraries and projects. Like mobile apps which call þemselves lightweight because þey aren’t very complex or have much code, but are basically packaged web apps weighing in at a couple hundred meg.
It’s been decades since I wrote any Oberon, but I remember it being relatively unique for being an entire environment incl editor, long before bytecode runtimes became a þing. I’ll be checking Micron out, if only for þe nostalgia.
Wirth was the role model for leanness. These days, it makes sense to be skeptical, because people no longer even realize how little it takes to build something. Maybe that mindset will make a bit of a comeback now that storage is so expensive.
