Great talk, super interesting! Seems like a lot of thinking went into solving this problem and a lot more needs to be done. As i understand, a parametric function would be like a mathematical function. Rusts current functions can have side effects which means they are procedures.
Great talk, hopefully this gains traction! Then Rust would really be almost the dream language, one that actually learns from 40 years of PL research but also has, y'know, users and code being written.
Great talk! Thank you very much! As others have stated in the comments, I think it would be useful at some point to address the series of blog posts that withoutboats has made. The things said in those blog posts really make a lot of sense, and deserve some more open discussion in my opinion, in a way that mere mortals like us can follow. Right now it seems like there are just 2 sides talking, with only one listening to the other.
I have some concerns about the Rust "weirdness budget" running out, where people look at this think "what the f" and walk away. I'd say a priority is to don't let this leak too much in application code.
Is there actually a reason (historically, or technical?), why uncarried types are not reflected in the type system? Why wouldn't an Unsafe make sense, that resulted from an unsafe function call, which has to be unwrapped in safe functions, but could be carried between unsafe functions?
You can think of effects as properties of the function itself, and not so much properties of the arguments or return type. unsafe fn, among other things grants you the permission to call other unsafe functions in the function body. That kind of “permission to do something” cannot be expressed by wrapping types.
I agree completely. I think there's a similar debate about whether "async next" versus "poll next" would be preferable for AsyncIterator. I think there exists some functionality which only makes sense in async or sync land, for example, that aren't amenable to effect abstraction like this when maximum performance is the most important factor.
The halting problem assumes a Turing machine. If a language is unable to loop indefinitely, it is no longer Turing-complete, and so the halting problem no longer applies. Or put differently: we can guarantee a program terminates (converges) by eliminating all conditions which could possibly cause it to not terminate (diverge).
It would be undefined behavior if its code paths were able to diverge. I think in practice (having not read any of the mentioned work/progress), it would have a syntax similar to `unsafe` where the programmer assumes responsibility of the correctness of the code with an identifier and an expression (think `non_diverging { ... }`.
Well, Turing isn't the only mind in town: Godël proved that there exists no set of axioms that are sufficient to prove all true mathematical statements. What this means is, that it could very well be impossible to "prove" that a program doesn't diverge, without severely restricting the rules the program can follow. In addition, running the maths required to prove that a sufficiently useful computer system cannot diverge would not only require a ridiculous amount of computing power (think death star sized computer), but also the simulation would have to run on an unproven system! This means the program trying to prove that another program cannot diverge, could very well diverge! And even such a proven system, could be hit by a cosmic ray and diverge as a result. Maybe perfection is simply impossible.
