What is next after memory safety?

1

"After memory safety, what do you think is the next big step for compiled languages to take?"
Interesting read especially for Rustaceans-
https://graydon2.dreamwidth.org/253769.html#cutid1

1 Like
2

I'm way under-qualified to comment, but I'd like new static analysis / maybe global optimisation tools.

It would be nice to know my program isn't going to panic in various ways or deadlock, in case I made a mistake.

3

I would like to see tight, type-system-level integration with a database. (Preferably done using a library or a codegen tool, not as a myriad of specialized features which do not belong in a general-purpose language.)

Having to map domain models manually to flat tables is a pain and error-prone, and ORMs don't help with that. Especially when your domain model contains – oh the horror! – algebraic sum types.

Not to mention the enormous power of DBs which ORM users are missing out on. If I had a cent for each time someone tried to build a non-recursive tree representation in a relational DB without being aware of rCTEs, I would be rich.

3 Likes
4

More memory safety.

impl<T> Option<T> {
    pub fn insert(&mut self, value: T) -> &mut T {
        *self = Some(value);

        // SAFETY: the code above just filled the option
        unsafe { self.as_mut().unwrap_unchecked() }
    }
}

Assigning more work in the area of program verification should make this work without the use of unsafe, eventually.

3 Likes
5

One thing I'd like to see: more non-turing-complete subsets.

Analogously to how in rust I have to opt-in to unsafe, I think we might eventually decide that defaulting to being subject to Rice's Theorem and the Halting Problem is undesirable.

For example, essentially all the code I write is expected to terminate, and for most of it the fact that it terminates should be relatively obvious. But in general, that can't be proven.

I would love for someone to come up with a reasonably-ergonomic way to have the compiler ensure this. Thus for the simple cases it confirms for me that it'll definitely terminate, require me to annotate things that I actually don't expect to terminate, and probably have some unsafe-like escape hatch to say "look, I know you can't prove that this terminates, but I solemnly swear it will".

This is called typestate, and Rust actually had it pre-1.0, but it was removed. It looks like rust - What is typestate? - Stack Overflow talks about it some. It's very common in various other languages -- TypeScript relies on it heavily, for example, and more and more languages are having a form of it related to null-checking.

4 Likes
6

That's the Lean programming language. Every program written in Lean terminates.

7

I would like a capability secure subset of Rust along the lines of what has been done for Java, https://www.ndss-symposium.org/wp-content/uploads/2017/09/met.pdf.

8

Something declarative. Compiler figures out what to do.

Another more specific:
Getting rid of .unwrap() or compiler verifies all uses don't panic.
Reminded of this; 10m in

9

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.