I love the Rust community but this can't seriously be part of an example as in expected usercode for Yew.

By the way, I didn't get this about React either; they define their own InputEvent to be able to make cross-platform statements, and they explicitly don't guarantee that an event object emitted by React is a web Event. They are by all metrics in the best possible position to attach the value to input events directly.

In fact, if I had to define a React-like event API, I'd special case input such that the handler signature becomes

(value, event) => void

I retract my outrage, the example was outdated. This is an updated HOF that is nicer to use. I'm still grumpy that this isn't a method on InputEvent though.

@lorentz that function signature is crazy

@AlgoRythm the more I see the less I want to know.

I bet I have code in C++ that would freak people out too.

@AlgoRythm It's neither complicated nor counterintuitive. Its purpose is to simplify moderately complex use cases where the callback can be a single expression but for some reason the string appears twice.

If it didn't have an explicit lifetime annotation it would be counterintuitive or at least suspicious because existentials default to 'static in some cases where a reference wouldn't.

Rust developers rely on the explicitness of the language to avoid understanding every detail upfront, so a big declaration isn't generally complicated or difficult.

React in Rust? For blogs where the only reason why they don't fail at basic stuff like clicking on links and actually loading a page is that the project doesn't get finished at all? ^^

@Fast-Nop Not finishing the project is a motivation issue which can be addressed with Rust's DX. But no, this is a bookmark manager / custom start page.

and its main purpose is explicitly to learn the Yew-Actix-Diesel full Rust stack. Getting a fancy bookmark manager is secondary

@lorentz If you call a puzzle language, such as Rust, "DX". I don't.

@lorentz And also, it's not a motivation issue. It's a penchant for overly complicated solutions, then losing motivation after the resulting mess got too entangled to actually fix it.

@Fast-Nop Programming is a puzzle, some languages have visibly different connections, others look like they'd fit until you look at the whole thing together.

@lorentz I see programming as puzzle how to solve a problem. By contrast, a puzzle language puts riddles by its own, unrelated to the problem.

For example, when implementing a simple data structure like a double linked list requires advanced language skills, then the language qualifies as puzzle language because it gets in the way.

@Fast-Nop A doubly linked list doesn't require special language skills in Rust, it just requires regular language skills, and knowing how long your objects actually live, just as it does in C++, C, Zig and every non-garbage-collected language. The most straightforward way to implement it is with Rc-s or Arc-s in one direction and Weak-s in the other. It may be wise to implement Drop manually for the list node and drop the tail in a loop because - again, just like in C++ - by default destructors are called recursively and might overflow the stack.

@Fast-Nop If you want custom lifetime behaviour, you can also implement it with pointers and unsafe, using basically the same toolset as C++. Safe rust is recommended because it's even easier than that, not because manual lifetime management is somehow harder than in other languages.

@lorentz you can't have it as a method and keep it working the same, a trait tho, a trait would be reasonable

> I love the Rust community

They're the worst, obnoxious and denying language design faults with bs excuses all the time

Have fun changing 50 files because a lifetime/async gets added and waiting 2 hours to compile 🤡
Not even getting noticeable performance improvements for the frontend but it's unmaintainable

@devRancid In what circumstances did you encounter a need to change things where you wouldn't expect the change to affect the types in question?

@devRancid I found that existentials help a lot by the way. When I needed to add and remove generics a lot from a context struct in Orchid, I eventually defined a ParseContext trait and passed around a `ctx: &impl ParseContext` which hid the changes to the concrete type. In older versions where existentials weren't supported, this would've been

`<C: ParseContext>(ctx: &C, ...`

which feels a bit heavy when most functions that forward this parameter are 7 lines long, but I think I could've gotten used to that too.

I don't know if this is relevant to your use case, I just remembered it from the wording of your complaint.

@devRancid I agree that they're very defensive though, just today I read that Rust only suports cheap implicit calls like Deref and Drop and doesn't have an implicit Clone because it's potentially expensive.

All probable Drop implementations are exactly as expensive as the corresponding Clone.