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

61–70 of 124 posts

Re: The Austral Programming Language

#61

Post by zetalyrae »

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 wouldn't rely on TCO being available, the bootstrapping compiler right now just emits very simple C (though GCC/LLVM might eliminate the recursion if they can).

Ideally I'd like stack overflow to be a clean abort rather than a stack overflow (just to make the error message more explicit) but I haven't got around to adding that.

Re: The Austral Programming Language

#62

Post by ralfn »

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.

[dead]

Re: The Austral Programming Language

#63

Post by khiqxj »

iroddis wrote: post #5

This quite a shallow observation, but I really wish new languages would cut down on verbosity and boilerplate. Making people type out “function” instead of “fn”, “def”, or nothing at all feels like unneeded friction. I’m not looking for APL levels of terseness, but I also don’t want to have my code mistaken for an essay filled with what amounts to scaffolding.

[flagged]

Re: The Austral Programming Language

#64

Post by zetalyrae »

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

Re: The Austral Programming Language

#65

Post by zetalyrae »

iroddis wrote: post #5

This quite a shallow observation, but I really wish new languages would cut down on verbosity and boilerplate. Making people type out “function” instead of “fn”, “def”, or nothing at all feels like unneeded friction. I’m not looking for APL levels of terseness, but I also don’t want to have my code mistaken for an essay filled with what amounts to scaffolding.

I'll say the Ada-style syntax grows on you.

Re: The Austral Programming Language

#66

Post by adamrezich »

zetalyrae wrote: post #60
pbarnes_1 wrote: post #9

This is cool but everything is too verbose. `austral compile hello.aum --entrypoint=Hello:main --output=hello` vs `go build` Etc etc.

The idea is the compiler has a bunch of explicit flags, but the build system (which doesn't exist yet) will have the `foo build`, `foo run` etc. commands and find the files using a package manifest. Essentially like `cargo` vs. `rustc`. I have a little prototype of the build system in Python but haven't pushed it up yet.

what's encouraging you to conceive of the build system and the language as separate things? I never understood why most people making new languages seem to want to have each of these be distinct—why not just define the build using the same language?

Re: The Austral Programming Language

#67

Post by zetalyrae »

imglorp wrote: post #49

Flashbacks to TA'ing freshman programming 101 in Pascal: every student got hung up on when to use a period or semicolon or end. And from Austral's fib example (snipped) module body Fib is function fib(n: Nat64): Nat64 is if n We here all understand BNF, Ada, Modula, etc and parsing but imagine explaining to the first day student: Why is there no "end function" like for the other contexts? When do I use a semicolon vs…

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.

Re: The Austral Programming Language

#68

Post by zetalyrae »

IshKebab wrote: post #38

> No arithmetic precedence. Interesting. I've wondered about this when making an expression parser. Obviously it makes parsing way easier and mistaken precedence is often a cause of bugs (especially in C where some of the operator precedence is plain wrong). But on the other hand that's got to be quite annoying surely?

In my experience you don't use nested arithmetic often enough to make it annoying. Most arithmetic in computing is basically `count := count + 1`?

What is more annoying to me is looking at an expression that mixes arithmetic and logical/comparison operators and mentally trying to recover the parentheses. Because precedence is not just PEMDAS: it involves all binary operators in the language, including logical and bitwise ones.

Re: The Austral Programming Language

#69

Post by epage »

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.

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.

Re: The Austral Programming Language

#70

Post by zetalyrae »

adamrezich wrote: post #66
zetalyrae wrote: post #60

Earlier quoted context omitted.

The idea is the compiler has a bunch of explicit flags, but the build system (which doesn't exist yet) will have the `foo build`, `foo run` etc. commands and find the files using a package manifest. Essentially like `cargo` vs. `rustc`. I have a little prototype of the build system in Python but haven't pushed it up yet.

what's encouraging you to conceive of the build system and the language as separate things? I never understood why most people making new languages seem to want to have each of these be distinct—why not just define the build using the same language?

So there's differing views on this, Zig famously has the build system built in.

To me, having them separate forces you to keep things simple, because the build system can't communicate with the compiler except through compiler-provided interfaces.

Also, I think I like about languages like C, Rust, is that: if I wanted to, I could implement the build system without forking the compiler. In C specially because Make will print all the compiler invocations for you. It lets people build tooling that is not part of the compiler.

I think it's good from a simplicity perspective that language users can figure out what set of compiler invocations a build file "compiles down" to.

Post reply on HN