Cursed Linear Types in Rust | Hacker News Reader

Cursed Linear Types in Rust

geo-ant.github.io

106 pointstodsacerdoti22 comments

The problem is that programming languages have always focused on the definition side of types, which is absolutely necessary and good, but the problem is that only limiting use by, e.g., "protected, private, friend, internal, ..." on class members, as well as the complicated ways we can limit inheritance, are barely useful.

We need a way to define how to "use" the types we define. That definitional structure is going to bleed from creation of instances into how they live out their lifetimes. It appears that Rust's design addresses some aspects of this dimension, and it also appears to be a fairly major point of contention among y'all, or at least require a steepish learning curve. I don't know, as I prefer to work in ubiquitous environments that are already featureful on 5-10yo distros.

One usage pattern many of us have found useful in our software for years is the "set once and only once" (singleton-ish) , whether it's for a static class member or a static function var, or even a db table's row(s). I don't know of any programming environment that facilitates properly specifying calculating something even that basic in the init phase of running the system, but I don't explore new languages so much anymore, none of them being mature enough to rely upon. Zig's comptime stuff looks promising, but I'm not ready to jump onto that boat just yet. I am, however, open to suggestions.

The real solution will ultimately require a more "wholistic" (malapropism intended) approach to constraining all dimensions of our software systems while we are building them out.

Rust's exclusive ownership can be used for things that can be called at most once (a method can require a non-copyable object as an argument, and takes ownership of it away from you, so you can't call the method again).

Rust also has wrapper types like OnceCell that have `get_or_init()` which will init the thing only once, and then it's guaranteed to be immutable. Unlike singletons, these don't have to be globally accessible.

> I don't know of any programming environment that facilitates properly specifying calculating something even that basic in the init phase of running the system,

The JVM has well-defined class loading semantics, including class initialization, that allow limited initialization capabilities before main is even run. Of course it has other problems too (defining the order in which these fire can be frustrating) but it always struck me as straightforward to work with.

Order is the soul of dataflow integration systems, which is programming. And this is because order is the sole purpose of the universe, itself, as it spreads change across time and space. And there are most definitely rules to what changes and how.

As above : so below :: the universe : our datablow integration systems. The challenge is to make ours perfectly clockwork, too.

What are you talking about man

If you can't know the order of your static class init routines' execution, you can't create some kinds of software systems, where such information must be known beforehand. Failing that we have to contrive our own init workflow launched from a single point of entry, instead of using something intrinsic for the guarantees we need. What that means is that this advanced feature of the programming environment should be avoided in certain cases, making it useless and (IMO) to be avoided.

I was asking about programming environments that facilitate certain kinds of clean init semantics.

Like a clock. Or something that is operationally clocklike, deterministic, like we should design and implement our software to be in terms of reliability.

"Set once and only once" is achieved well via Rust's OnceLock [1], and it's a pattern I use quite heavily in my Rust code. Especially because OnceLock only requires a shared reference and not a mutable one. It's a really good fit for cached results computed on-demand, scoped to whatever level is reasonable (individual type, thread, or whole process).

[1] https://doc.rust-lang.org/beta/std/sync/struct.OnceLock.html

> The problem is that programming languages have always focused on the definition side of types, which is absolutely necessary and good, but the problem is that only limiting use by, e.g., "protected, private, friend, internal, ..." on class members, as well as the complicated ways we can limit inheritance, are barely useful.

Virtually all software ever developed managed just fine to with that alone.

> I don't know of any programming environment that facilitates properly specifying calculating something even that basic in the init phase of running the system, (...)

I don't know what I'm missing, but it sounds like you're describing the constructor of a static object whose class only provides const/getter methods.

> or even a db table's row(s).

I don't think you're describing programming language constructs. This sounds like a framework feature that can be implemented with basic inversion of control.

>One usage pattern many of us have found useful in our software for years is the "set once and only once" (singleton-ish)

C# has this: https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

> C# has this:

This is only syntactic sugar to allow using object initializers to initialize specific member varabiles of a class instance instead of simply using a constructor and/or setting member variables in follow-up statements. It's hardly the feature OP was describing.

While mutation of init-only properties is sometimes done by e.g. serializers through private reflection or unsafe accessors, it otherwise can lead to unsound behavior if class implementation does not expect this. You cannot bypass this through normal language means.

Same applies to readonly instance fields.

Where does "syntax sugar" end and "true features" begin?

Anyway, trying to actually prevent a program from modifying its own memory is really hopeless, right? So any promises beyond “syntactic sugar” would be resting on a poor foundation, perhaps even dangerously misleading.

You can always mmap a memory range, place a struct there, then mprotect it. And on the language side you cannot overwrite readonly structs observed by readonly refs (aside from unsafe, which will trigger segfault in this case).

There are ways to do it. What matters is the user ergonomics, otherwise, by this logic, most higher-level languages would have even less of a claim to immutability, and yet somehow it's not an issue?

If there are exotic requirements - there are exotic tools for it. FWIW static readonlys are blocked from modification even through reflection and modifying their memory with unsafe is huge UB.

That's new since I've been tramping around VS.NET (F# 2 or 3 & C# from 10ya).

My immediate purposes require that I avoid depending on unique programming language/environment constructions, but it helps to learn, so thanks for levelling me up.

And Java will soon have StableValue: https://openjdk.org/jeps/8312611

Reading the JEP, isn’t StableValue about JIT constants?

In .NET it’s just 'static readonly'.

The basic feature set is at-most-once thread-safe initialization of values, which can then enjoy the same constant folding and other JIT optimizations one would get from `static final`, but can be initialized at any point during the program's run.

  Non-goals
  It is not a goal to provide Java language support for declaring stable values.

Hmmm

From context, I would infer that this means they are not changing the Java language itself. It’s a feature expressed through the existing language, like as a library feature. I could be wrong though.

Yes you're correct, the idea is that they're not adding any keywords or bytecodes, just some new standard lib APIs that will get some special treatment by the JVM.

The readonly property in PHP would fit the bill quite well as it can be set once and only once, no?

Plus the new PHP 8.4 version actually has asymmetric visibility for properties so you can have public properties that can not be mutated from the outside but still allow controlled mutation on the inside. The feature was borrowed from swift. I am super excited about it.

https://wiki.php.net/rfc/asymmetric-visibility-v2

I am not sure if this the same, but this reminds me of the Abilities system on the Move language[0]. It allows you to create linear, affine or other type constraints in a pretty flexible way.

[0] https://move-book.com/move-basics/abilities-introduction.htm...

Reply on news.ycombinator.com