What Austral proves (opens in new tab)

This post demonstrates the fundamental flaw with RIIR arguments: it assumes that Rust is not only the best language now but will always be the best language. Getting halfway through a rewrite from C to Rust only to realize that Rust is no longer popular and there's a new kid in town would be pretty awkward.

Another thing that Austral gets right is capability-based permissions for packages, in recognition of the growing danger of supply chain attacks. See for example https://blog.phylum.io/pypi-malware-replaces-crypto-addresse... - a bunch of typo-squatting Python packages that use setup.py to write a JavaScript file into the developer’s filesystem (specifically the Windows Start Menu) and register it as a background process inspecting and altering the clipboard to replace crypto wallet addresses with the attacker’s own wallet address. Why can a setup.py in /home/user/.local/lib/python3.6/site-packages or wherever access the Windows Start Menu folder and write files there? Well, because code is almost universally permission-less. Austral’s solution is to give granular permissions: “capabilities can be arbitrarily granular. Beneath the capability to access the entire filesystem, we can have a capability to access a specific directory and its contents, or just a specific file, further divided into read, write, and read-write permissions. For network access, we can have capabilities to access a specific host, or capabilities to read, write, and read-write to a socket.”

So... has anyone used this thing to build projects that go beyond small toy examples?

Speaking of, what are some good 'example projects' to test the overall sturdiness of a new language? I have currently no interest in writing one in Austral, but I'm always curious to hear how well modern language projects work out when used in production.

I have also thought a lot about Austral lately. I have very similar conclusions as the OP.

I love the simpleness of the language. I work with a kinda high performance networking (DPDK use) as my day job so we work in C and while I love C quite a lot for its simpleness and clarity, it is so easy to do something wrong. Linear types seems perfect for helping to keep a track on ownership of pointers and make sure that everything is handled properly while still keeping the simpleness. I don't mind having to by hand write some destructor if someone helps me make sure they are called correctly - I probably prefer that for clarity. And it also seems easier to exaplin to someone: "Here is this type, if this type gets unhandled at the end of this function the compiler gets angry. Instead you have to call this function that you can clearly see by the types returns the Unit/a free type". (borrowing adds a bit more to that but still quite clear imo)

I like Rust for what it did to the space and I respect all the people working with it but it isn't THE solution and I am happy other things are entering the arena that caters a bit more to my preferred aesthetics I guess.

I have started coding some small networking things in Austral personally to get a feel about. Will see where it goes.

This won't replace Ada (nothing will, because there's no code to replace...) until it has the same or similar type system.

This seems like there is quite a bit of overlap with zig

> Rust, on the other hand, is a huge, complex language. In my mind, I pinned a lot of this complexity on Rust’s borrow checker and type system. Having worked with Rust for a while, I’d argue that a good amount of this complexity is accidental: when Rust took its first steps, no mainstream language sported a borrow-checker.

Definitely, along with other decisions. It follows the C++ route of unneeded complexity. I think many developers actually like that though. Figuring out how to prove some dynamic trait cast setup to the compiler does have a certain feeling of “doing smart CS stuff” and in my younger days that would’ve been attractive to me.

“Simple to implement” is an undervalued virtue in most of the systems we use. The internet and industry tend to pull things towards scale and complexity, and there is real value in systems that resist those forces to stay intelligible and human-scale.