[wtetzner]

> My problem, though, was to explain all the nuances given that they usually have nothing to do with the "business" part of the problem somebody was solving.

Yeah, I completely agree. A GC provides a lot of benefits in terms of clarifying the intention of business logic.

Unless, of course, performance/memory usage is an important part of your business logic, in which case Rust is exactly what you want.

[pkolaczk]

Maybe I'm weird, but I find the explicit ownership, mutability and lifetime information encoded in Rust definitions very helpful at understanding a new code-base. Something that otherwise needs to be documented in comments / external documentation in Java, but most often it is missing, and then recovering such information from the code is similarly hard to recovering the types in a dynamic language.

Lack of GC in makes it harder to write but easier to read.

[wtetzner]

It gives you a lot more information, but a lot of that information is more about lower-level mechanics than "business logic". I think it really depends on what you're writing and what's important to it.

[pkolaczk]

It can be actually tied pretty well to business logic. You can explicitly model some business rules, e.g. a subscription cannot exceed the lifetime of the user account, etc. Similar to how you can use static type system to prohibit invalid states. Here Rust gives more tools of this kind, than other languages.

Another one I really love is ability to destroy objects on final operation. E.g you close something and it can't be used any more. Most other languages can protect using such closed object only with runtime exceptions.

Some languages like Java don't even make a distinction between "object A is composed of B and C" vs "uses B and C" (in both cases they'd be references)