Show HN: Alumina Programming Language

Show HN: Alumina Programming Language(github.com)

107 points by tibordp 3 years ago | 87 comments

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/

MontyCarloHall 3 years ago |

I get that this is mostly for fun, but this is as good a place as any to bring up an issue I rarely see discussed with any post about a new language.

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.)

belmarca 3 years ago | |

We've been investigating coupling syntactic and low-level FFIs [1]. Our most recent work will be published at the upcoming Scheme Workshop [2], where we integrate Gambit Scheme with CPython. We share the concerns you have and have had quite good success with the Scheme<->Python interface! The syntactic interface makes it really enjoyable.

[1]: https://zenodo.org/record/4711425

[2]: The paper should be up in a few days I suppose.

tibordp 3 years ago | |

Totally agreed about FFI. I wanted to make it easy to interop with C code and write expressive bindings.

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.

girvo 3 years ago | | |

UFCS making C bindings a hell of a lot nicer is one of the things I love about Nim, so I’m happy to see another language try it!

danias 3 years ago | |

We are building a new language that is not for fun and we have thought of this important issue. We solve it with a Package Ports and Package Adapters. The Bitloops Language (BL) is a transpiled language with support for only TypeScript at the moment. Nonetheless, if it picks up we will be adding support for Java, C#, and C++ so that people can leverage their investments in their existing packages.

https://github.com/bitloops/bitloops-language

culi 3 years ago | |

What's an example of a language with "good" FFI?

beagle3 3 years ago | | |

LuaJIT has a pretty great FFi which was later ported to standard Lua; Python’s ctypes provides a decent FFI.

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)

WalterBright 3 years ago | | |

With the D programming language, to interface with C's stdio.h:

    import stdio;

    void main() { printf("hello from D!\n"); }

is all that's necessary, as D has a built-in C compiler that reads stdio.h, compiles it, and presents its interface to the D code.

williamstein 3 years ago | | |

Calling C functions from zig is very nice, partly because zig uses llvm to parse C header files and uses that information.

zyx_tony 3 years ago | | |

Nim is quite enjoyable to use. I do a decent amount of scientific computing, interfacing with various c/cpp libs

davedx 3 years ago | | |

Rust's seems pretty good. I've been doing some Rust/C interop and it works very smoothly

aliqot 3 years ago | |

Libraries are a farce. Stdlib or die. I 100% mean this and live this.

Asraelite 3 years ago | | |

That's a strange take. Do you mean that you would rather call external binaries directly, like Bash does, or that you would rather re-implement all functionality you need, however complex?

mypalmike 3 years ago | | |

Why even use stdlib? Or an OS? Just write everything every time down to the bare metal.

thesuperbigfrog 3 years ago | | |

Libraries are how software is shared and reused.

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?

tyingq 3 years ago | | |

Would that include things like encryption? No exceptions for your rule?

mhd 3 years ago |

I thought people got along with Rust due to its features and semantics and learned to live with the syntax. Not it being something one would copy. (I'm personally still hoping for a Ratfor/Coffeescript transpiler)

Also, wonder how long it'll take until we see a "Aluminia" fork...

jimbob45 3 years ago | |

What is it that people hate about Rust syntax beyond the terrible lifetime syntax? Seems pretty reasonable to me.

still_grokking 3 years ago | | |

Rust's syntax is just baroque.

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).

markusde 3 years ago | | |

Is lifetime syntax so terrible? Personally I like that all the subtyping relations are in the same place (lifetime outlives, polymorphism etc) and that they can be written inline until complicated enough to justify a ``where`` block.

xigoi 3 years ago | | |

Semicolons, braces, double colons

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>?)

aaaaaaaaaaab 3 years ago | | |

The community.

IshKebab 3 years ago | |

I assume he means the basic syntax like the fact that everything is an expression, `name: type` not requiring brackets for `if` and `for` etc. Most of the ugly Rust syntax is for advanced features like lifetimes and generics.

Surfactant7 3 years ago |

> Unlike Rust, however, Alumina is not memory-safe and it requires manual memory management.

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.

noncoml 3 years ago |

I really don’t like the cognitive load of having to remember to use defer. We already have the scope defined, why add something extra?

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.

tibordp 3 years ago | |

Scoped destruction is awesome in general, and I agree that it is superior to defer.

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.

noncoml 3 years ago | | |

> This can be done with a guard object in RAII languages, but it's a bit unintuitive

Some syntactic sugar, like Python’s “with” should help with that, shouldn’t it?

leni536 3 years ago | |

Except go's defer is scoped to the function, instead of the innermost enclosing scope.

tibordp 3 years ago | | |

That's a good point and also one of the things I kinda like about Alumina. You can do thing like this and the file will only be closed at the end of the function rather than the end of the if block.

    let stream: &dyn Writable<Self> = if output_filename.is_some() {
        let file = File::create(output_filename.unwrap())?
        defer file.close();

        file
    } else {
        &StdioStream::stdout()
    };

noncoml 3 years ago | | |

So less granular and can be assymetric. Don’t think that’s a good thing

girvo 3 years ago | |

Despite Nim having RAII of a sort, one thing I love is “defer”, because it lets me get the same semantic behaviour from bound C functions. Handy!

Eliah_Lakhin 3 years ago |

I'm currently working on a project similar to Tree-Sitter.

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!

tibordp 3 years ago | |

Honestly, Tree Sitter is fantastic, I can highly recommend it. By far the most user friendly and powerful parser generator I've worked with. The C API is very nice.

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.

ducktective 3 years ago |

Awesome!

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.

tibordp 3 years ago | |

I wouldn't say it was very difficult, but it did take quite a bit of time. Apart from some basic principles (no GC, no RAII, "everything is an expression"), I basically kept adding features whenever I hit some pain point trying to write actual programs in Alumina. If I were to do it again, I'd probably be more methodical, but anyway, here we are :)

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.

chaosprint 3 years ago |

Online playground! So it compiles to WASM? If you are gonna look like Rust. Please, no unwrap() everywhere.

tibordp 3 years ago | |

No native compilation to WASM yet, but since the compiler outputs self-contained C, it should be fairly easy to do it with Emscripten.

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.

revskill 3 years ago |

Love this.

What if Rust provide a separate analyzer to analyze potential memory leak from this language.

tibordp 3 years ago | |

Valgrind and Sanitizers should work on Alumina. I have not actually tried them myself yet, but I don't see any reason why they couldn't work.

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.

chrismsimpson 3 years ago |

Interesting no one here is discussing “Jakt”, which looks very similar in style and approach. Jakt is the language attempted by the SerenityOS team, which itself dispels the notion you can’t building something of substance from scratch without outside libraries. Jakt also implements fairly lightweight reference counting, making it memory safe. I think the potential of SerenityOS/Jakt can’t be overstated and strikes me as comparable to the excitement surrounding Linux in the early ‘90s.

lolinder 3 years ago | |

Jakt's #1 design goal is memory safety. The very first paragraph of Alumina's docs says that it intentionally keeps C-style memory-unsafety. For systems programming languages, that makes them philosophically quite at odds with each other.

Were there similarities besides "syntax inspired by Rust"?

renox 3 years ago |

So, as far as I understand its main feature is that it has a Rust-like syntax?

tibordp 3 years ago | |

As far as I know it doesn't have a single feature that is really unique. It's more like a combination of things I like from other languages, like syntax and expressions from Rust, defer expressions from Go, UFCS from D.

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.

nnoitra 3 years ago |

New language posts have to stop. There are tons of other CS topics to talk about but instead LIPSs ()()()()((((())))) and random langs taka the spotlight on HN.

nicoburns 3 years ago | |

Well we'll always need language designers and compiler developers, and new ones have got to learn somehow. Creating a toy language seems like a pretty decent way to go about it.

lolinder 3 years ago | |

I upvote any new language post I see because I find them very interesting and want more of them. The nice thing about HN is you can just scroll past posts you don't find interesting. The "tons of other CS topics" are also discussed on HN.