> The amount of people doing production web development in Rust won't be more than a single digit

Well, I'm pretty sure a few people at INRIA would be really happy if OCaml was used by a single digit percentage of the whole web community. If Rust reached this stage I think we could talk about its success in this field. Go is considered a pretty sucessful language for web back-end stuf and I'm pretty sure it's not used by more than a single digit percentage of web devs.

> I surely don't want to think about affine types when doing UI design in Storyboards, Android designer, WPF/UWP Blend designer.

I don't understand your point, affine type is something that helps you write more maintainable code : you can't have two different sections of your code mutating the same piece of data without you knowing it. It makes me think less actually. And if you need to have two owners for a given piece of data, you can opt-out the ownership system with reference counting and interior mutability. Those rules and mechanisms are difficult to learn and internalize, but once that's done it helps you and makes you more productive.

Affine types are still too hard to use by regular users without CS background.

Simple exercise, imagine a GUI builder regardless of for web or native code, for pumping out plain CRUD frontends, dragging components from a toolbox into the UI designer.

Components, of course, have a property designer that allows setting properties like database connections or data grid paging.

Now try to fit affine types into this kind of workflow, without forcing people to manually create some kind of auxiliary types and deduction helper functions like described on the Idris book.

I don't see what you want to explain. Could you be a bit more specific ? In the use-case you describe, what don't you think could be done with a language with affine type system ?

Because the editor needs to update the type relations according to your mouse clicks and property editor changes, given the semantics of affine types I only see it being possible with some kind of heuristics.

Very basic example,

1 - Drag component into the form, variable could be declared as owned

2 - Edit a relationship between the component and another one on the property editor, either generate code with borrows or update the owned declaration into a Rc one, Arc instead, or Rc with RefCell, Arc with RefCell,....?

The GUI editor needs heuristics to create declarations with the right set of affine types, or to update existing ones when the developer clicks around changing the document tree and relations among them.

Oh and the current state of the borrow checker in Rust doesn't handle closures for self in callbacks, which makes it a royal pain to write GUI event handlers.

> The GUI editor needs heuristics to create declarations

How about using move by default, if the compiler complains about moving the data, falls back to Rc<RefCell<T>>, and if the compiler complains about `Send` use Arc<Mutex<T>>. Or you could even use the later for everything in your UI designer, this way you get a memory management scheme which is like Swift's. (In first approximation at least, since Swift has CoW for some kind of things, but you could definitely copy the exact Swift behavior in Rust if you wanted).

As I said earlier, the affine type system is opt-out in Rust, so you can do whatever you need without it(including your GUI stuff) and still be able to benefit from it when writing your business logic, and being more productive thanks to it.