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

The Austral Programming Language

austral-lang.org

Post reply on HN
Print view View original

101–110 of 124 posts

Re: The Austral Programming Language

#101

Post by olodus »

mrkeen wrote: post #16

This language looks super promising. With the exceptions of 'no type inference' and 'no arithmetic precedence', I really like its anti-features list. With regard to 'no arithmetic precedence', I tried printLn((1 + 2) + 3); and printLn(1 + 2 + 3); Sure enough, the first one compiles, but the second doesn't. Also, (n-1) is a parse error unless you put a space after the minus. I got curious if recursion was properly han…

I disagree with you about 'no type inference'. I understand why some swear by type inference, but personally I prefer the complete clarity it provides to avoid it. If writing those characters annoys you, have tooling help you with avoiding that.

Re: The Austral Programming Language

#102

Post by crabmusket »

webkike wrote: post #94
zetalyrae wrote: post #67

Earlier quoted context omitted.

Declarations don't need `end function` because it's always clear what you're closing. Statements need an `end if`, `end for` etc. because it lets you find your way in nested code. The rationale for the syntax explains it a bit: https://austral-lang.org/spec/spec.html#rationale-syntax FWIW I will probably get rid of the `module is ... end module.` bit because it adds unnecessary nesting.

Why? No ability to nest functions? Why do you need a semicolon at the end of "end"?

> No ability to nest functions?

Correct

> Why do you need a semicolon at the end of "end"?

Per the rationale[1], "The purpose of the semicolon is to provide redundancy, which aids both reading and parser error recovery." Also, "For many people, semicolons represent the distinction between an old and crusty language and a modern one, in which case the semicolon serves a function similar to the use of Comic Sans by the OpenBSD project."

[1]: https://austral-lang.org/spec/spec.html#rationale-syntax

Re: The Austral Programming Language

#103

Post by olodus »

zetalyrae wrote: post #64
angiosperm wrote: post #50

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.

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

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.

Re: The Austral Programming Language

#104

Post by zetalyrae »

ZoltanAK2 wrote: post #82
thesuperbigfrog wrote: post #2

Has Austral been used for any real-world, production projects? If so, what?

Almost certainly not, and there are good reasons for that. Work on Austral was initiated by Borretti in 2021, but its earnest development really only commenced in January this year. So we're talking about a language that's, for most intents and purposes, less than a year old. Even if the January release was stable, there would not have been time for anyone to develop and deploy significant projects in it. But it is n…

If you have the time, I would be delighted to hear about your experience, especially the things about Austral that were inadequate.

Re: The Austral Programming Language

#105

Post by juunpp »

> As in the real world, an object cannot be copied or destroyed without first filling out a lot of forms, but on the other hand, the transmission of objects is relatively painless.

This is fantastic. Clearly, bureaucracy is what we needed all along for memory safety.

Re: The Austral Programming Language

#106

Post by gcoakes »

Is no one going to talk about their capabilities system? That shit looks cool. A compile time permissions system for which resources can be used. I wonder how fool proof that can be made. Are there escape hatches in the form of arbitrary assembly/linking? Could a leftpad module security issue be deterred with this?

Re: The Austral Programming Language

#107

Post by andyferris »

gcoakes wrote: post #106

Is no one going to talk about their capabilities system? That shit looks cool. A compile time permissions system for which resources can be used. I wonder how fool proof that can be made. Are there escape hatches in the form of arbitrary assembly/linking? Could a leftpad module security issue be deterred with this?

Yes, any leftpad-like security issue could be mitigated by the fact that you’d need to inject strange capabilities like network access to the leftpad function.

It is assumed this would raise eyebrows from the user of this function. Furthermore if you were to take a “safe” function and replace it with a dodgy one in a later version, the function signature would change and users would need to update their code. So nothing quite so brazen would get past.

Of course if you are mixing in arbitrary assembly/machine code in your binary via linking that might make a syscall and that could potentially be unsafe.

Re: The Austral Programming Language

#108

Post by adastra22 »

angiosperm wrote: post #50

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.

You missed a chance to learn something.

Re: The Austral Programming Language

#109

Post by becquerel »

ZoltanAK2 wrote: post #82
thesuperbigfrog wrote: post #2

Has Austral been used for any real-world, production projects? If so, what?

Almost certainly not, and there are good reasons for that. Work on Austral was initiated by Borretti in 2021, but its earnest development really only commenced in January this year. So we're talking about a language that's, for most intents and purposes, less than a year old. Even if the January release was stable, there would not have been time for anyone to develop and deploy significant projects in it. But it is n…

Thank you for the sober and interesting comment. I would also be interested in a blogpost or similar extended writing about this experience.

Re: The Austral Programming Language

#110

Post by _0w8t »

ZoltanAK2 wrote: post #98
_0w8t wrote: post #97

Earlier quoted context omitted.

Yet Austral returns optional types from any memory allocation function rather than calling abort. And stack overflow is a memory allocation failure, so why is the discrepancy? I.e. for the language focusing on correctness this is an unfortunate omission. On the other hand none of popular or semi-popular system languages allows to explicitly control stack consumption. Zig has some ideas, but I am not sure if those wil…

There is discrepancy because things the programmer can prevent are handled differently from things the programmer cannot prevent. The programmer can always statically ensure that the program doesn't experience a trapped overflow, and that the stack size is not exceeded. All the information to do that is available when the programmer runs the compiler. But there is no way to prevent a memory allocation failure when us…

To statically ensure a stack overflow does not happen requires that recursion is rejected by the type system. Austral does not do that so the stack overflow is a dynamic condition similar to memory allocation failures.
Post reply on HN