What Austral proves | Hacker News Reader

What Austral proves

animaomnium.github.io

62 pointsanimaomnium21 comments

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

> Another thing that Austral gets right is capability-based permissions for packages, in recognition of the growing danger of supply chain attacks.

inb4 Java did it first.

Not really. It's dubious at best for applets; I haven't used it, but I don't know of any mechanism in the applet environment that prevents libraries from accessing the same APIs as main(), and executing the same side effects. Outside that context, I know there's no such mechanism. Libraries can open whatever files and sockets they feel like, no capability-based permissions required.

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

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.

Good example projects to test new languages? I don’t know of any ready-made resources. It might be a good project to pick a few “new languages that took off and became popular languages” and study what projects they started with, then make examples out of those. Rust and Elixir come to mind. Maybe a web server is a good stress test of a language?

The programs in the Benchmark Game for example?

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

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.

Rust will also get true linear types most likely, since they're required for future improvements in async support, especially async-drop.

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

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.

I mean, that's the case for literally every technology that improves on what comes before. If you follow that logic you can never rewrite anything... which, granted, might be a decent idea, but not one that has anything to do with Rust.

On the other hand, "a new kid in town" is not a good reason to declare a rewrite a failure. Did it make your life better? Did it reduce bugs with a reasonable amount of effort? Maybe it was a good decision after all, given what you knew and what was available at the time.

Meanwhile, delaying a decision indefinitely just in case better options appear later is probably a road to death. Again, Rust doesn't come into the question all that strongly.

In practice, there are so many things to write to make even a simple language useful that the transition time can be fairly long: libraries (especially non-trivial ones like date&time), tooling, best practices...

There's a lot of overhead that can't really be reduced.

To me Rust's main advancement isn't technical. It's that software development is first and foremost an ongoing social activity rather than the finite output of a single mind. Rewriting something in Rust shouldn't be about fixing potential bugs but about making the code safely accessible to a wider range of coders than the original (C) codebase was. Rust itself evolved mostly as a collective effort and nurtured a strong and mostly wholesome community and culture which IMO is what gives it staying power.

And that his like the point of Rust? It put in the spotlight this stuff.

You could see the seeds of Rust from years ago, but having a nice language as the start is just... the start.

Rust do that AND all the other things: tooling and docs and..

So, the thing that will replace Rust will need that, and is likely you will not see any proper* contender in the next 5 years, maybe even more...

*ie: One where it worth to rewrite the codebase. You will see several experiments, maybe a few very good, but consider this: To rewrite from C/C++/.. to Rust have a lot of leverage: C performance, superior tooling, superior error messages, superior docs. Your Rust replacement should be BETTER than that.

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

This is nothing new ...

See: the mid-to-late 1990s and Perl, Python, Tcl, etc.

The only way to predict the furture is to create it.

Rewrites will be much cheaper because of advances in program synthesis.

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

Well, of course it won't, but it doesn't need to. It also doesn't need to replace Rust. We can all benefit from finding new and improved compromises between ergonomics and safety requirements.

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

In theory yes, there should be an overlap as the philosophy are similar (no hidden control flow) in practice they are very different.

For example Austral has no macros whereas Zig relies heavily on comptime.

Austral is to Ada and Rust what Zig is to C..

I'd say that Austral is even more focused on safety and correctness than Zig. Zig is older than Austral, but Austral is simpler, which implementation is going to be reliable first? I don't know, there's a (small) 'ecosystem' around Zig, is there one around Austral?

Reply on news.ycombinator.com