Show HN: The Aria Programming Language

[egranata_aria]

Aria is a modern, dynamic scripting language. It is meant to be a "sweet spot" language, easy to pick-up and enjoyable to use.

It comes with a familiar C-style syntax, and draws inspiration from a variety of languages. It has a small but usable standard library and strives to be a low-ceremony-get-stuff-done kind of language.

It is currently at version 0.9 and I would love feedback as I work towards getting it to 1.0.

[thenulldevice]

You do a good job on explaining the what of the language, but I cannot quickly find the why of the language. What is the language's purpose? Why should or could I use it?

[egranata_aria]

This has been a pretty frequent source of feedback, and while I had ideas on that in my head, clearly I did not communicate them well enough

I updated the website & README with more of a rationale/viewpoint of why Aria exists. Please take another look: https://github.com/egranata/aria/blob/master/README.md

[mrbluecoat]

Agreed. Feels like "a scripting language for C developers who hate JavaScript"

[nottorp]

That can be a decent "why" though...

[egranata_aria]

I kinda like that :-) Maybe instead of "hate JavaScript", a scripting language for systems people?

[account-5]

I feel like I keep harping on about Nushell but as scripting languages go it's right up there for me. Built with rust too and comes with a ton of stuff built in.

What's the niche this fills? I came across roc-lang recently which seemed interesting too, again built with rust, and opinionated on certain things common in older languages.

It doesn't have to, and obviously it's your project, but what is this offering over other languages. Why would I reach for it?

[egranata_aria]

I hadn't really looked at Nushell, but it (process control) is definitely something I plan to improve in Aria (https://github.com/egranata/aria/issues/21). Right now I have a simple system() wrapper, but not much in terms of advanced subprocess control. Maybe worth investing some time in cleaning up?

I have tried to fill the niche of "scratch my itches, please", which means Aria is intended to feel smooth, pleasant and simple to write in. There are still things I want to improve before calling it a 1.0, but the general theme is, a general purpose scripting language with just enough structure and as little ceremony as possible.

It may be that I struck the wrong balance somewhere (and I know of a few places, e.g. operator overloading - I plan to rewire the syntax), and that would be great to get eyes on and get feedback!

[norman784]

Just a side note, roc-lang is being rewritten in Zig[0]

[0] https://gist.github.com/rtfeldman/77fb430ee57b42f5f2ca973a39...

[ofalkaed]

What would this offer me over more established scripting languages? Main thing I want to know when I see a new offering. On a quick look I find the almost but not quite C syntax more difficult to read, like the lack of parenthesis on the if statement's test and this is my biggest issue with C like languages, they change things just enough that I have to think about it and I don't see what the change offers beyond those used to C syntax having to stop and think.

[egranata_aria]

Good news is I can offer you parentheses, but they are indeed optional on conditionals/loops. I am fairly sure there are other C-style syntaxes that leave those out. See https://stackoverflow.com/questions/2061593/why-do-c-languag... - you can't have the same ambiguity if you have mandatory braces around the body. Would there be a reason to require them?

With that said, this will work just fine and you wouldn't have to think about it too hard, if at all:

  func main() {
    if (1 == 2) {
      println("oh no!");
    } else {       
      println("phew!");
    }
  }

On the more general point, why this vs. anything else? That's a great question. I have tried to hit a balance that I think is pleasant to write code in (e.g. I like not having __init__.aria files around to define modules :-), and I like having proper enums, and so on...). I like to think someone would pick up Aria because it is a fun little language to try out and experiment with, not because it would change the world.

Mileage may of course vary and you may think that balance is actually nowhere to be seen. That's great, hit me with it.

[plainOldText]

Judging from the small example in the readme, the language looks pleasing to the eye.

What’s under the hood though? What are some of the technical choices, performance characteristics and longer term goals?

[derdi]

The current implementation looks like a compiler to a stack-based bytecode with a straightforward textbook interpreter. For example, here is the interpretation of the Add bytecode: https://github.com/egranata/aria/blob/master/vm-lib/src/vm.r...

So to a very rough first approximation, performance characteristics should be in CPython's ballpark.

[egranata_aria]

I just noticed this comment a few days late, so sorry for the delay in answering

Goals are documented in a roadmap doc: https://egranata.github.io/aria/ROADMAP.html as well as issues on GitHub, and ideas are always very welcome, so please bring yours! I'd love to chat

I am not (yet) focused on performance, it's still at a point where the language and the library are changing. It runs decently well (as mentioned it's a stack based VM) such that you could actually use it to write some real programs. Good enough for a 0.9 I think

Technical choices, I have a few big ideas that stand behind the overall design: - easy to pick up, flexible, run with, write code, "pleasing to the eye" is what you called, that's #1; - a simple module system that works with you (with more improvements in the roadmap); - easier to reason about errors (lots of things are Maybe/Result-style enums vs. exceptions) - this is somewhat inspired by Midori where errors are classified according to whether you can and should handle them (with exceptions as a somewhat middle ground); - using Rust under the hood provides stronger memory safety guarantees than things written in C/C++ would out of the box (I have seen the occasional stack overflow error, and even that I would consider a bug, but no segfault core dump using Aria); - no inheritance, prefer composition, reuse via mixins which are first class in Aria - I found this works quite nicely (for example, I can provide all comparison operators based on one function + a mixin: https://github.com/egranata/aria/blob/master/lib/aria/orderi...)

Thanks for all the questions!

[pshirshov]

Does it support higher-kinded types and typeclasses? Does it support call-site expansion?

[egranata_aria]

No. Should it? i.e. would it be useful/valuable to do for a scripting language? I am happy to hear suggestions and thoughts on that. Open a GitHub issue & let's chat?

[pshirshov]

In my opinion these features (and powerful type systems in general) would be useful for any language regardless of the execution model.

[egranata_aria]

I am happy to have the discussion. What would help me is a GitHub issue with some example/rationale why you think this would help. That would be an ideal starting point. As-is, I am a bit lost how typeclasses would work with dynamic typing and all that, but maybe I am missing the point.

[drumnerd]

Why the name conflict with aria the technology?

[egranata_aria]

I am not familiar, can you point me in that direction?