Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Alumina Programming Language

github.com

Post reply on HN
Print view View original

41–50 of 90 posts

Re: Show HN: Alumina Programming Language

#41

Post by markusde »

jimbob45 wrote: post #23
mhd wrote: post #12

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

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

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.

Re: Show HN: Alumina Programming Language

#42

Post by leni536 »

noncoml wrote: post #17

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.

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

Re: Show HN: Alumina Programming Language

#43

Post by WalterBright »

culi wrote: post #22
MontyCarloHall wrote: post #3

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 n…

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

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.

Re: Show HN: Alumina Programming Language

#44

Post by whartung »

aliqot wrote: post #18
Asraelite wrote: post #9

Earlier quoted context omitted.

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?

To me, there is value in the process and craft. It started as a one year challenge to use only stdlib in all projects, for work and personal code, and became a way of life. Though it may not work for everyone, or all languages, or all skillsets, it was a revealing experience. In retrospect, it made sense given that in my community we make our own furniture, instruments, tools, foods from whole items. Code seemed like…

I can certainly identify with this.

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

Re: Show HN: Alumina Programming Language

#46

Post by tibordp »

chaosprint wrote: post #40

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

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.

Re: Show HN: Alumina Programming Language

#47

Post by tibordp »

ducktective wrote: post #16

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.

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.

Re: Show HN: Alumina Programming Language

#48

Post by tibordp »

leni536 wrote: post #42
noncoml wrote: post #17

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.

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

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 = if output_filename.is_some() {
        let file = File::create(output_filename.unwrap())?
        defer file.close();

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

Re: Show HN: Alumina Programming Language

#49

Post by belmarca »

MontyCarloHall wrote: post #3

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 n…

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

Re: Show HN: Alumina Programming Language

#50

Post by UncleEntity »

tibordp wrote: post #35
noncoml wrote: post #34

Earlier quoted context omitted.

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

Python context managers are actually very similar to guard objects in C++ and Rust. What I meant was something like this (could also be done with `contextlib`, but it's also verbose) seen_names = {} class EnsureUnique: def __init__(self, name: str): self.name = name def __enter__(self): if self.name in seen_names: raise ValueError(f"Duplicate name: {self.name}") seen_names.add(self.name) def __exit__(self, exc_type,…

Honestly, the with example seems simpler if you ignore what it takes to build a context manager (which isn’t all that hard).

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

Post reply on HN