Hacker News Reader

Comment by angiosperm | Hacker News Reader

I appreciated that it listed "no destructors" immediately after the top-line "no garbage collection", so I didn't need to read any further. What it means is it offers no ability to encapsulate resource management, so not useful for me. That doesn't mean it is not useful to others.

View on HN

No, on the contrary, Austral is entirely built around resource management. The central concept is linear types, which is about ensuring 1) resources are disposed of and 2) resourced are used according to their protocol, e.g. no use-after-free.

There's "no garbage collection" because Austral lets you have manual memory management without the danger, like Rust.

There are no destructors in the sense of special destructor functions which are called implicity at the end of scope, or when the stack unwinds. Rather, you have to call the destructors yourself, explicitly, and if you forget the compiler will complain.

This sounds verbose until you start paying attention to all the mistakes you make all the time that involve, in some way, forgetting to use a value. The language makes it impossible to forget to do something.

People might feel like it is too verbose, but I think it is good to have the clarity. I write C at my day job and I have no problem with the 'verbosity' if it provides clarity of what happens. What I want is the compiler to help if I ever forget who owns a particular data value and miss to clean it up. For that linear types are perfect. I also prefer their simpleness over Rust's affine types which easily gets very complicated (see the difference between theirs and your borrow checker). Linear types gives me an easy way to define basic "state machines" for how to handle the data using types and then verifies that I implemented them correctly. That is kinda all I need. Feels like a good "get shit done" language.

From my reading of it, it does have what you're looking for. Specifically, while there are "no destructors", you are required to call a function to consume the value. Failing to consume the value is a compile time error. You can roughly approximate thinking about this as having destructors, but you're required to explicitly call them and the compiler won't let you write code that doesn't call the destructor.

This is nice. It does seem mutually exclusive with any early return though, like exceptions.

On the phone now so I only read the page on linear types, but will look at this closer when back at my desk.

In my own language I am considering destructors purely so that early returns are viable. I'd like to see if there is any alternative to destructors that aren't 'defer' or similar.

Exceptions and linear types are difficult to combine. Implicit destruction is fine though, provided destruction can't fail.

the page "What are linear types?" seems to address "resources" and the management thereof. not my cup of tea (but then, neither are destructors and garbage collection), but it's an interesting idea.

At least linear types means you'll never forget it. It also solves the problem of what to do when your destructor needs to error (e.g. closing a file).

The big downside is the verbosity of covering every branch of your code with your explicit close calls unless another mechanism is provided.

And it doesn't seem like succinctness is a top priority for this language.

You missed a chance to learn something.

didn't read it yet, but that are other ways, specifically something like `defer` in go or zig

Reply on news.ycombinator.com