Niko Matsakis

>redux, react are heavily influenced by concepts from functional programming

Functional programming concepts don't require learning category theory

>rust has novel concepts from type theory

Type theory isn't category theory. Rust's borrow checker was not inspired by affine types.

https://smallcultfollowing.com/babysteps//blog/2012/02/15/regions-lite-dot-dot-dot-ish/

>data engineering in the cloud age leverages a lot of algebraic concepts to achieve massive data throughput

This doesn't requite category theory and those are basic concepts from algebra that you can learn outside of the context of algebra.

>We have parser combinators, lambdas, stronger typing, map and flatmap

These don't require category theory either.

Before writing a completely asinine comment like this, you might consider that I, having been paid real American dollars to design this language, might know more than you about the relationship between GATs and HKTs and the design of Rust as a whole. Your comment evinces a total ignorance of the type theoretical issues that actually informed our decision on this issue.

Fortunately, Niko Matsakis blogged about our design discussions at the time. You can read more here and in the linked predecessor posts (at the time we were calling GATs "ATCs") https://smallcultfollowing.com/babysteps/blog/2016/11/04/associated-type-constructors-part-3-what-higher-kinded-types-might-look-like/

Sorry to disappoint you but if Rust had adopted higher-kinded types they wouldn't need to write a function `try_for_each` because it would just be a generic fold-and-collect-effect function that works for all effects not just Try:

traverse_ :: Foldable t => (a -> ExceptT e IO b) -> t a -> ExceptT e IO ()

Of course I'm not saying Rust should have this (there are good reasons why this isn't a good fit for Rust, see http://smallcultfollowing.com/babysteps/blog/2016/11/09/associated-type-constructors-part-4-unifying-atc-and-hkt/) but it really caught my eye that you called `try_for_each` obscure; it could have been an everyday function if it had a bit more expressiveness.

I am confused by your responses because the "reborrowing" mechanism in the Rust compiler is pretty widely discussed.

https://smallcultfollowing.com/babysteps/blog/2013/11/20/parameter-coercion-in-rust/

https://haibane-tenshi.github.io/rust-reborrowing/

https://stackoverflow.com/questions/62960584/do-mutable-references-have-move-semantics

Meanwhile, you are insisting on reasoning about Rust from first principles and making lists of links to documentation that is, at best, tangentially relevant.

For example, the fact that `&T` implements Deref is not relevant here. Applying Deref::deref to a &T returns a &T. For most intents, it's a no-op.

There haven't been any serious proposals yet, but some ideas have been floating around from time to time. For example this blog post has some ideas that might allow them https://smallcultfollowing.com/babysteps/blog/2024/03/04/borrow-checking-without-lifetimes/

The hardest problems I think is that this requires a fundamental change to the language that something might be already borrowed just by existing. It also likely needs to introduce a notion of "stable" places that will not move when you move a prefix of them, e.g. to allow moving a `Box` holding self-referential data. In other words, there's a lot of bikeshedding to do.

> It's important to remember Rust's borrow checker was computationally infeasible 15 years ago.

The core of the borrow checker was being formulated in 2012[1], which is 13 years ago. No infeasibility then. And it's based on ideas that are much older, going back to the 90s.

Plus, you are vastly overestimating the expense of borrow checking, it is very fast, and not the reason for Rust's compile times being slow. You absolutely could have done borrow checking much earlier, even with less computing power available.

1: https://smallcultfollowing.com/babysteps/blog/2012/11/18/imagine-never-hearing-the-phrase-aliasable/