[HN Gopher] What Austral proves
___________________________________________________________________
What Austral proves
Author : animaomnium
Score : 50 points
Date : 2023-02-18 10:57 UTC (1 days ago)
(HTM) web link (animaomnium.github.io)
(TXT) w3m dump (animaomnium.github.io)
| fwlr wrote:
| 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."
| zozbot234 wrote:
| > 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.
| andrewflnr wrote:
| 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.
| olodus wrote:
| 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.
| zozbot234 wrote:
| Rust will also get true linear types most likely, since they're
| required for future improvements in async support, especially
| async-drop.
| joeatwork wrote:
| "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.
| djha-skin wrote:
| 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.
| aredox wrote:
| 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.
| speed_spread wrote:
| 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.
| mamcx wrote:
| 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.
| bsder wrote:
| > 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.
| andrewflnr wrote:
| 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.
| pyrolistical wrote:
| This seems like there is quite a bit of overlap with zig
| [deleted]
| elcritch wrote:
| > 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.
| TwentyPosts wrote:
| 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.
| inamberclad wrote:
| This won't replace Ada (nothing will, because there's no code to
| replace...) until it has the same or similar type system.
| Hemospectrum wrote:
| 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.
___________________________________________________________________
(page generated 2023-02-19 23:02 UTC)