Show HN: Alumina Programming Language (github.com)
Alumina is a programming language I have been working on for a while. Alumina may be for you if you like the control that C gives you but miss goodies from higher level programming languages.
It is mostly for fun and exercise in language design, I don't have any grand aspirations for it. It is however, by this time, a usable general-purpose language.
Alumina borrows (zing) heavily from Rust, except for its raison d'être (memory safety). Syntax is a blatant rip-off of Rust, but so is the standard library scope and structure.
Alumina bootstrap compiler currently compiles to ugly C, but a self-hosted compiler is early stages that will target LLVM as backend.
If that sounds interesting, give it a try. I appreciate any feedback!
Standard library documentation: https://docs.alumina-lang.net/
Online compiler playground: https://play.alumina-lang.net/
89 comments
[ 3.2 ms ] story [ 159 ms ] thread> It is mostly for fun and exercise in language design, I don't have any grand aspirations for it.
You are being quite generous in calling the comment "odd".
Here are five words to summarize that comment: disparaging, out of context, cruel, speculative, and pessimistic. pipeline_peak can do better. The HN guidelines are a good start.
>> pipeline_peak : Another Rust lookalike to reinvent the wheel, I wonder what’s gonna happen to it in 10 years.
I gotta say getting this much coverage from one individual over my little comment is pretty odd, or is that “quite generous”?
Perhaps I could invent a spoken language where disparaging remarks are possible but extremely lengthy, thereby discouraging negativity from people in bad moods.
A little tough praising kindness with a whiff of passive aggression, not very “HN guideline like”.
A counter punch from someone who feels attacked, right?
Alternatively, you could accept the well-intentioned and fair criticism.
I can see how you might think think my comment is passive aggressive, but it is not. Passive aggression is "the expression of anger, hostility, or resentment through indirect means, especially obstructive or uncooperative behavior: those who expected him to lambast his foes were always going to be disappointed; passive aggression is more his style." (Apple dictionary)
First, if you take my comment as a whole, you can see I was not indirect in my criticism of your comment. Second, I do not feel anger, hostility, or resentment about you or your comment.
Rather, I feel disappointment that this kind of thing happens so often. It is not just you (or any one person) that disparages creativity -- many people have done it, including myself.
The language design comment is sincere. It was a sort of thought experiment. I can also recognize that it is a pointed comment that led to some reflection (I hope), which is why it might have felt like an attack. Still, remember I criticized your behavior, not you.
The comment had the additional purpose of highlighting that language design has broad applicability, and perhaps might reduce some kinds of unwelcome behavior, whether it be bad-mood inspired negativity or error-prone programming abstractions. Rust and Alumina aim to have more expressive types than C, for example. Human language shapes culture and thought -- at least according to many linguists.
Well-established languages have tons of widely used, highly vetted libraries implementing functionality that doesn’t exist in the new language and would be totally impractical for an individual to implement themselves. For example, if I’m doing scientific computing, I need a good linear algebra library like Eigen or Armadillo (or Numpy/PyTorch/Tensorflow), all of which would be impossible for me to implement myself.
Therefore, for a new language to catch on, it needs a good foreign function interface. Yet FFIs are almost never brought up whenever new languages are discussed on HN. (Again, I realize that this is just a fun project and widespread adoption is not a goal.)
Check for example the language bindings to LLVM's C API (fairly low level) and Tree-Sitter which is used internally (a bit higher level bindings)
https://github.com/tibordp/alumina/tree/master/libraries/llv...
https://github.com/tibordp/alumina/blob/master/libraries/tre...
I think UFCS makes it quite nice for bindings, since external C functions can be used as if they were methods if the object is passed as the first parameter. So in many cases there might not even be a need to write wrapper structs for bindings that feel native.
Of course, it's still a manual process and since Alumina is just a compiler and stdlib for now (no llibrary ecosystem, no compiler driver), it's a bit cumbersome. But I like the approach Rust has with bindgen and cc crates, to automatically create bindings for C and C++ code.
https://github.com/bitloops/bitloops-language
Do you really intend to write your own library for a given task when there is a perfectly good and mature library that does that task and more freely available?
How long would it take for you to write your own Sqlite or your own Nginx?
In retrospect, it made sense given that in my community we make our own furniture, instruments, tools, foods from whole items. Code seemed like the next logical step. During travels, once there was a man who had a word in his language for this. He said it was an aphorism loosely translatable to "the beauty of struggle". As he explained it, this is the positive benefit gained in return for the time and effort to do something as an act of appreciation of the craft, and how the value in the experience surpasses the debt of time and sweat.
To put it in a more modern and eastern philosphical context, think of it like Kata.
https://en.wikipedia.org/wiki/Kata
If developing with high level abstractions wasn't challenging enough, your vision was too small. Surely you can think of a problem to solve that even Copilot would be of little use.
Imagine what you could build if you got a little more help from third party libs and a little more ambition?
https://en.wikipedia.org/wiki/Simple_living
https://en.wikipedia.org/wiki/Nonconformity_to_the_world
I'm sure this creates more questions than it answers, however, I hope it lends some context as to how we've both arrived at our own respective happy milieus.
Having done enterprise java for so long, I strive to be as reductionist and minimalist as I can be in order to avoid dependencies outside the JDK.
Vying for "you aren't going to need it", trying to keep things as simple as I can.
But it also comes down to not overcomplicating stuff we've already written.
Obviously there's an urge to reuse your own libraries, but you have to strive to not overcomplicate them as they're applied to new use cases as you drive the peg in to a rounder hole.
It's very easy to FactoryFactoryFactory in Java, but flexibility and configurability leads to complexity and black hole of combinatorial testing.
Almost better to fork the earlier library and hammer it to fit the new space without regard to its old use in the other system. But that leads to file replication (notably files of the same name doing subtly different things). And there it's a challenge to go "gee which one should I use" when you're working on version 3, when what should be happening is "pick the best one" and keep hammering.
We used to have our general purpose "catch all" library which, in the end, indeed, "caught all". "Oh look, somehow I have jars from Clojure, Groovy and Scala, when all I wanted was a URL Builder."
But sure, yeah, there's value in practicing your craft and making all the things.
[0] https://en.wikipedia.org/wiki/Not_invented_here
The whole point of modern tech and science is that everybody is standing on the shoulders of giants. Without that all you probably can get at max is low tech form 200 hundred years ago…
Nim, Zig and Rust do too, but they have semantics much closer to C, so it’s almost free (especially when they can all use llvm directly for code generation, and Nim’s preferred way is to compile through C in the first place)
I hate to compare and contrast but Rust comes to mind as one of the latter, probably because it has a somewhat more intensive and extensive RFC process for adding new features.
The people who use D tend to like it very much.
All this to say, I feel that any FFI that requires you to manually write bindings is rubbish.
[1]: https://zenodo.org/record/4711425
[2]: The paper should be up in a few days I suppose.
What if Rust provide a separate analyzer to analyze potential memory leak from this language.
The only potential problem I see that with the current C backend, the debugging information is very hard to trace back to the original Alumina source code, so it might be hard to see where the leaks are coming from. This is something I plan to address in the self-hosted compiler, once it is functional.
The overarching theme is to see how far you can go making a language that feels high level without having a garbage collector or RAII. I used to use Deplhi/Pascal a lot when I was younger and it was this kind of language.
Also, wonder how long it'll take until we see a "Aluminia" fork...
It's full of unnecessary noise and additionally very irregular. (With complete craziness thrown in between like the semicolon rule to "visually distinguish" procedures and functions, which must be a kind of joke I don't get).
I really don't understand how such a conceptionally well thought out language got this pretty ugly syntax.
(And no, you don't need such ugly syntax "because language features". Just have a look at Scala 3 that is much more powerful but maintains a clean, almost pythonic syntax).
Rust is in part designed to look familiar to C programmers. Rob Pike once famously described C syntax as able to survive a channel that mangled whitespace. That's less of an issue now, but habits die hard. Indentation in place of syntax is nevertheless controversial. That's a toy version of the bigger question: Why should text be required to carry a load that a smart editor can infer? In Clojure, some prefer ;; to ; because the comments stand out better. Um, syntax coloring? I dislike all comment characters, and for many years I preprocessed a practical version of "comments are flush, code is indented".
Ownership is nevertheless pure genius, and one can define more powerful operations on Rust's restricted notion of data than on general data. I'm imagining a "lisp without parentheses" that transpiles monadic parsers on steroids (aimed exactly at Rust data) to Rust. It will take me a while.
Rust may be accompanied by a design statement like that somewhere, but it actually does no such thing.
The majority of the lines I've ever written were in C. When I look at Rust, all I see is `{};`
(though in Rust's case I think it's more accurate to say it distinguishes between "statements and expressions" than "procedures and functions")
Yes, the distinction is important. That's why it's extremely annoying that this distinction is almost invisible if you don't look very close on the code using magnifying glasses. Like I said: Marking such an important distinction through something almost invisible like a (missing) semicolon is pure craziness.
Usually nobody reads semicolons! They are usually just line noise coming form a time as parsing code was actually still some kind of science and people made syntax with the explicit intent to be easy readable by archaic computers (and not humans in the first place).
I think `return`s are superfluous but given the choice between some more line noise in the form of a `return` statement and this semicolon brain-fart I would clearly prefer the `return`…
> (though in Rust's case I think it's more accurate to say it distinguishes between "statements and expressions" than "procedures and functions")
Since when? Did I miss something? (This could be, I'm looking only occasionally into Rust).
AFAIK leaving out the semicolon is only an option on the last expression of a procedure, turning that "procedure" into a function.
Leaving out (the completely unnecessary!) semicolons elsewhere is a syntax error to my best knowledge.
The above code would not compile, afaik, because the semicolon is missing on the first line of the procedure.The completely unnecessary semicolons are just one of the examples that make the Rust syntax heavyweight and needless noisy for no good reason. I don't get how a modern language can fall back to such antique syntax.
The very rare use-case where you really want to write some comprehensive one-liner could have been easy supported by optional semicolons. But in the general case one just doesn't need that line noise.
Rust is a great language, really! But they obviously didn't put any effort into the syntax. The result is that the language reads partly like C++, and I guess almost everybody could agree that C++ has one of the most terrible syntax out there.
Rust is "modern" language with a stone age look & feel. That's a big missed opportunity, imho.
Ackshually moment here, but they did put a lot of effort into chosing syntax which would require very little look-ahead on the part of the parser (given current or even decade+ old parser tech). I don't understand their reasons for doing so at all, but that's what they did.
The result is... not very human-friendly IMO.
But I don't get that either: Parsing is today the least problem. The time you spend parsing is negligible (if you didn't mess up the language completely, of course) compared to the time for type-checking and optimizations.
Avoiding look-ahead (or especially the need to re-parse parts recursively) is a very good rule of thumb, sure. But when you need to decide whether you make the language simpler to read for the machine or more heavyweight for the human the answer should be absolute clear.
A modern compiler spends anyway most of its time in the semantic analysis (and depending on language, later optimizing the output). Optimizing the lexical part for the win of a few milliseconds on tens of thousands of lines just makes no sense. Today's computers are even fast enough to parse spoken human language fast enough. Again it's the analysis that takes time there.
The thing with Rust's syntax is especially annoying as almost everything else in that language makes a lot of sense. The concepts are neatly put together. It's explicit about the right things. It's considerably small and simple. It's almost a kind of sweet spot in language design, imho. And than it was hit hard with the ugly stick. That's a really sad point. And so needless.
I still hope they will come to their mind some day, and will start to offer a kind of "light" syntax at some point.
I really wish Rust could be more like Scala 3 on the outside, with a clean, minimal pythonic look & feel, and not like how someone put it before in a comment in this thread "When I look at Rust, all I see is `{};`". The later is also exactly my impression, sadly.
Good error messages and robust error recovery for syntax errors are possible for almost any kind of language, even very weird ones, with today's modern parser technology. Just have a look at what for example Tree-Sitter does.
But the meat of good programming language error messages lies not in the syntax errors. It's in meaningful and informative semantic error messages. And these are almost completely independent of the language's syntax.
I personally find rust syntax pretty neat. It's designed to be unambiguous to machines, but that also means it's unambiguous to humans. It has no () around tests, but it mandates {} because that prevents goto fail. It has the classic ML `;` as a separator, not terminator. It's a pragmatic blend of C++ (with generics, namespacing, and the C influence), and ML (expression based, easy to parse, let-binding and type inference).
This is an incredibly arrogant and ignorant statement to make, especially for someone who self-describes as "looking only occasionally into Rust". A whole lot of thought has been put into Rust's syntax.
> The result is that the language reads partly like C++
My impression is that a certain amount of this was intentional; if their goal is to attract C++ developers, they can't scare them off with syntax that's wildly alien. Rust took the parts of C++ syntax that made sense to keep and that fit into Rust's semantics, refined/modernized/distilled them, sanded off the rough edges and ambiguities, and presented something cohesive that's still familiar.
The syntax isn't without warts - turbofish comes to mind - but overall I find it pleasant and comfy (and I'm not even a C++ developer). I appreciate that it makes a lot of things explicit that should be explicit. Fewer characters doesn't automatically mean better readability; in many cases it can mean the opposite.
> This is an incredibly arrogant and ignorant statement to make, especially for someone who self-describes as "looking only occasionally into Rust".
There is nothing arrogant or especially ignorant about my statement.
I'm primary using a language that has a shitload more features than Rust but gets along with a fraction of syntax.
So from my standpoint this is clearly something to criticize Rust for.
And this is very sad imho as I think Rust is a great language as such. A great language with a miserable syntax!
That's especially unfortunate as there are today no technical reasons to make ugly languages given how fast our computers are.
> A whole lot of thought has been put into Rust's syntax.
Who knows, maybe you're even right, idk.
But at least the result does not show, and that's the only relevant part.
> My impression is that a certain amount of this was intentional; if their goal is to attract C++ developers, they can't scare them off with syntax that's wildly alien.
That's imho nonsense. You can't "scare" C++ developers with syntax. They already endure one of the most broken syntaxes out there.
One does not use C++ because of its syntax, but in spite of that monstrosity!
One endures it as the language has other until lately unmatched properties. But C++'s look & feel is just a horrible historical accident all in all.
Rust would be attractive for its features no mater the syntax.
As we see it gets hyped and does very well for a newcomer even it's overly and needlessly ugly.
> Fewer characters doesn't automatically mean better readability; in many cases it can mean the opposite.
Sure.
But it's Rust that uses almost every ASCII char for some special purposes; imitating by doing so one or two of the worst examples history ever created.
The other thing is: Putting outright line noise everywhere only because that makes reading the code simpler for the machine is just the completely wrong priority. Less line noise makes reading code definitely simpler for humans. It has reasons why math notation looks like it looks after hundreds of years of optimization…
The whole point of good syntax is that you can mostly ignore the syntax and concentrate on the message. But Rust is like C++, you can often hardly see the actual content as it's burrowed under a pile of ugly needless syntax noise.
Copying a bad example is definitely nothing to be proud of. Rust failed in that regard miserably, imho. For completely incomprehensible reasons—which make it especially bad.
It's a real pity such a great language looks like a archaic accident!
Using "<" and ">" as both operators and delimiters
Turbofish
Symbols instead of words (ref -> &, and -> &&, not -> !, …)
Inconsistency (Why [i64; 5] and not something like array<i64, 5>?)
From what I gather, it might be more accurate to say that Alumina has no ownership model. Rust requires manual memory management, but offers the ownership model as a compile-time tool for doing so.
It would actually be pretty interesting to see some experimentation around alternative ownership models.
How difficult was it for you to design a whole programming language?
Do you have a theoretical CS background?
If I want to design my own, would learning Racket and other LISPs help?
I'm interested in formal methods and embedded systems.
Protocols were probably the trickiest feature of the language to figure out. As for the compiler itself, surprisingly, the biggest hurdle to get over was the name resolution. It's a tiny part of the compiler today, but everything else was much more straightforward.
I don't have formal CS background, but I have been coding for a long time. I read the Dragon Book and would recommend it to anyone writing a compiler, even though it's a bit dated.
I don't know Racket or LISP myself so I cannot comment on that part.
IMHO the way it’s used in Go is a workaround, of luck of destructors, not a feature.
Edit: not a criticism on your language OP, which is better than what I could have ever built. Just a comment in the “defer” trend.
I think one case where defer might be nicer is for things that are not strictly memory, e.g. inserting some element into a container and removing it after the function finishes (or setting a flag and restoring it).
This can be done with a guard object in RAII languages, but it's a bit unintuitive. Defer makes it very clear what is going on.
Some syntactic sugar, like Python’s “with” should help with that, shouldn’t it?
What I meant was something like this (could also be done with `contextlib`, but it's also verbose)
With defer this could be simplified toMaybe it’s just I’ve never used defer before but I do use python with whenever I get a chance. Not like that, I don’t really understand what the code is trying to achieve by removing the name at the end, but to close resources at the end of the block. And even then only if it makes sense for what I’m doing.
Using a context manager like your example is just busywork IMHO, easier to just write the code out linearly like the defer example.
The most common problem that defer is trying to solve is cleanup when the function returns early (ususally because of an error). Writing the cleanup code inline before the early return results in code duplication.
C#/Java/Javascript have try/finally for this, C has the "goto cleanup" idiom, and C++ and Rust have the guard objects. Go and Alumina have defer.
And then one can simulate defer in the spirit of the `atexit` module with a single context manager (say `finalizer`), defined only once, which could be used as:
The `__call__` of finalizer adds callables with their *args and **kwargs to a fifo or a stack, and its `__exit__` will call them in sequence.Basically, it is going to be a full-featured Compiler front-end foundation library with incremental parsing capabilities, error recovering, AST manipulations, etc, but written entirely in Rust, and hopefully with more user-friendly API for Rust devs.
May I ask you to give me some feedback on your experience with Tree Sitter, and the challenges you faced during the development of your compiler's front-end?
Thanks in advance!
The only two pain point I had is that the `node-types.json` that's generated only contains the names of the nodes, not the numerical IDs. This means that if you have some codegen generating Rust enums is difficult if you want to avoid matching nodes by string.
I wrote https://github.com/tibordp/tree-sitter-visitor for generating visitor traits in Rust for a given grammar. I actually did it a bit differently in the end for Alumina, but it might come useful.
The sandbox is running the code server-side in a nsjail container.
As for unwrap, I feel you! the try expression (expr?) is supported, which makes it look a bit nicer, but I'm still trying to figure out a good idiom for when you actually want to do specific things based on whether the result is ok or err.
Alumina does not have Rust-style enums (tagged unions) or the match construct, which makes it a bit tricky.
Were there similarities besides "syntax inspired by Rust"?