Show HN: Alumina Programming Language • Hacker News Board

Re: Show HN: Alumina Programming Language

#51

Post by cercatrova » Sat, Sep 03, 2022, 9:49 PM UTC

WalterBright wrote: post #43

culi wrote: post #22

Earlier quoted context omitted.

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.

I hear about D often on HN but I never see it being used in the wild so to speak. When I looked at it, it seemed, like C++, a hodgepodge of features built up over time rather than being a more deliberately focused language.

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.

Re: Show HN: Alumina Programming Language

#52

Post by tibordp » Sat, Sep 03, 2022, 9:50 PM UTC

UncleEntity wrote: post #50

tibordp wrote: post #35

Earlier quoted context omitted.

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

It's not that it's hard, it's just that it is not inline, so it requires a context switch because the CM is defined outside, even when it's doing something specific.

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.

Re: Show HN: Alumina Programming Language

#53

Post by still_grokking » Sat, Sep 03, 2022, 10:01 PM UTC

tyingq wrote: post #36

aliqot wrote: post #7

Earlier quoted context omitted.

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

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

The parent will never "need" something as "complicated" as encryption as you can't write anyway any serous software with the stated mindset.

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…

Re: Show HN: Alumina Programming Language

#54

Post by still_grokking » Sat, Sep 03, 2022, 10:11 PM UTC

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.

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

Re: Show HN: Alumina Programming Language

#55

Post by pipeline_peak » Sat, Sep 03, 2022, 10:19 PM UTC

xpe wrote: post #39

pipeline_peak wrote: post #2

Quoted post unavailable.

Please try to offer some kindness. Or at least accept that people have various motivations and goals. Languages are regularly remixed. Also, "language designer" is not an elite term -- it can be a hobby, a way to learn, and even a way to inspire others. Perhaps I could invent a spoken language where disparaging remarks are possible but extremely lengthy, thereby discouraging negativity from people in bad moods.

> thereby discouraging negativity from people in bad moods

A little tough praising kindness with a whiff of passive aggression, not very “HN guideline like”.

Re: Show HN: Alumina Programming Language

#56

Post by pipeline_peak » Sat, Sep 03, 2022, 10:37 PM UTC

xpe wrote: post #37

wtetzner wrote: post #32

Earlier quoted context omitted.

What an odd comment when the post contains this: > It is mostly for fun and exercise in language design, I don't have any grand aspirations for it.

> What an odd comment when the post contains this "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 lo…

Aaaaaand no response from wtetzner

I gotta say getting this much coverage from one individual over my little comment is pretty odd, or is that “quite generous”?

Re: Show HN: Alumina Programming Language

#57

Post by xigoi » Sat, Sep 03, 2022, 10:37 PM UTC

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.

Semicolons, braces, double colons

Using "" as both operators and delimiters

Turbofish

Symbols instead of words (ref -> &, and -> &&, not -> !, …)

Inconsistency (Why [i64; 5] and not something like array?)

Re: Show HN: Alumina Programming Language

#58

Post by noncoml » Sat, Sep 03, 2022, 11:28 PM UTC

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.

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

Re: Show HN: Alumina Programming Language

#59

Post by chrismsimpson » Sun, Sep 04, 2022, 12:04 AM UTC

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.

Re: Show HN: Alumina Programming Language

#60

Post by lolinder » Sun, Sep 04, 2022, 1:01 AM UTC

chrismsimpson wrote: post #59

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

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