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

81–90 of 124 posts

Re: The Austral Programming Language

#81

Post by tialaramex »

zetalyrae wrote: post #70
adamrezich wrote: post #66

Earlier quoted context omitted.

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

Realistically your provided build tool won't be everything. Cargo is enough to build my toy projects and even some fair size software written mostly in Rust, but it's not enough to build Mozilla, or Linux, or Android, or other large systems with a bunch of Rust in them - including Rust's own compiler and standard library.

But, when you get big enough to where this sort of provided tool isn't enough, chances are tooling is now somebody's actual problem anyway, if you're a for-profit somebody's job is to look after the tooling, you can invest in learning a specialized tool or even writing one because that's a proportionate effort, it makes sense.

Re: The Austral Programming Language

#82

Post by ZoltanAK2 »

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 not stable: it still under construction, with certain inherent instabilities. Notably, recent updates changed the borrow syntax and FFI pragmas. Similarly, the surrounding infrastructure (compiler and standard library) is far from production-ready yet.

I built an Austral interface for the seL4 Core Platform (https://github.com/zaklogician/libmantle/tree/main), and ran some Austral apps on hardware. The purpose of this was experimental (we wanted to know how Austral can help us design fail-safe seL4 Core Platform APIs, and it was a success), but probably among the closest anybody came to "production": I wrote more Austral code than currently included in the Austral standard library.

It revealed several bugs, including a typo in Standard.Buffer which leads to the invariant check for the Buffer type always failing, and issues related to the compiler's handling of large unsigned literals.

Austral shows great promise, and has already provided us with valuable insights about linear API design, and exciting glimpses into its future capabilities. Using Austral in production code, however, might require a few more years of maturation and stabilization. So if you want something that people use for writing production code, check back in a couple of years.

Re: The Austral Programming Language

#83

Post by sk0g »

meindnoch wrote: post #78
jll29 wrote: post #51

For me, this is of interest: Austral’s module system is inspired by those of Ada, Modula-2, and Standard ML, with the restriction that there are no generic modules (as in Ada or Modula-3) or functors (as in Standard ML or OCaml), that is: all modules are first-order. Modules are given explicit names and are not tied to any particular file system structure. Modules are split in two textual parts (effectively two files…

>It was a mistake how C++, Java and other languages forgot to split interface declaration from implementation definition Huh? C++ is split into header files (interface) and cpp files (implementation)...

I guess there is no "strict separation" in C++, since that mechanism is, I believe, optional. Adding implementations to your header files might never pass PRs, but still.

It does enable header-only libraries though.

Re: The Austral Programming Language

#84

Post by __d »

jimbob45 wrote: post #42
hardwaregeek wrote: post #26

Earlier quoted context omitted.

Ehh C is a pretty miserable language to parse. No function definition keyword means you have to get pretty far to realize that you're parsing a function. Pointer syntax is ambiguous with expression grouping. And let's not even get started with the preprocessor. I'd say a good model for simple syntax is Go. Rust has a nice compromise of syntax too, but there are some awkward edge cases.

Shame they never fixed this. Would have been nothing to add a fn keyword at the beginning of all function definitions and then use the MS EEE strategy to bring it into the standard. Of the many changes the committee could make with C, I have to believe a function keyword would be among the least contentious.

Least, perhaps? But certainly contentious.

In my view, the job of the C committee should be to eliminate undefined behaviour and any remaining specification ambiguities (or errors) and otherwise leave the damned language alone.

If you want a new language every 3 years, you can always use C++.

Re: The Austral Programming Language

#85

Post by crabmusket »

zetalyrae wrote: post #68
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 bit…

Don't forget ternaries and null-checking operators too. `x ? y : z ?? "oh boy"`

Re: The Austral Programming Language

#86

Post by verdagon »

saghm wrote: post #77
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…

For a language that seems to market itself based on being secure, this is pretty troubling

Austral is still alpha, so this kind of thing is expected. It's heading in a good direction, give it some time.

Re: The Austral Programming Language

#87

Post by crabmusket »

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…

This is pretty great to hear! I really hope that as Austral develops it can find a niche as a "minimum viable safe language" with a small surface area, spec, competition in implementations etc.

Re: The Austral Programming Language

#88

Post by crabmusket »

I really love the Design Goals and Rationale sections of the specification[1]. I have an interest in the landscape of new low-level languages like Odin[2], Vale[3] etc. Austral has the clearest "statement of intent" about how it is designed and where it is going.

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

[2]: https://odin-lang.org/

[3]: https://vale.dev/

Re: The Austral Programming Language

#89

Post by crabmusket »

fs_tab wrote: post #45

> designed to be simple enough to be understood by a single person Interesting that this was mentioned. Are there languages that are not simple enough to be understood by a single person?

I think the author sees Rust as a language which, even if it's not beyond the mind of a single person yet, trends in that direction. He puts it pretty fairly in a recent blog post[1]:

> Rust does something very practical: it says what properties it will enforce, but doesn’t say how. That is, you know references have to uphold the law of exclusivity, but how the compiler achieves this is subject to change. So the borrow checker is allowed to evolve over time, in the direction of accepting more programs and becoming more ergonomic while retaining safety.

> The upside is that most of the time you can use Rust without thinking about lifetimes or the borrow chchecker. The downside is that the borrow checker is hard to spec (it’s basically “whatever rustc does now”) which makes is hard to have multiple implementations of Rust. Some people argue that’s fine or a good thing because multiple implementations waste effort. This argument has merit, but I think languages being specification-defined is a good thing from a stability perspective. It’s what they call a tradeoff.

[1]: https://borretti.me/article/type-systems-memory-safety#rust

Re: The Austral Programming Language

#90

Post by fijiaarone »

stephenr wrote: post #53
RussianCow wrote: post #34

Earlier quoted context omitted.

With syntax highlighting being ubiquitous, does it really matter whether the keyword is "function" or "fn"? And at that point, why not make it terse instead of taking up more space and adding unnecessary noise?

If you're going to take that approach why have any keyword? `foo(){}` is just as clear as `fn foo(){}`

A block is a namespace that has an entry point, and optionally a return value and arguments.

There is no need to distinguish between functions, modules classes, lambdas, or whatever.

Hence, no need to distinguish their start or ending with keywords, as long as you can determine their scope.

Brackets determine scope, and unlike indentation or words, that is all they are used for.

Post reply on HN