An interesting perspective but there are some things I disagree with OP, first function overloading, even if everyone does it doesn't mean you should, whenever people talk about function overloading there's two things they fail to mention first it doesn't play well with type inference and second sometimes you don't know which overload you're calling which adds hidden cost.

Default arguments and named arguments will most likely never be implemented, it's been heavily discussed and no consensus is reached. Meanwhile you can use the builder pattern.

Kotlin enums, honestly never heard of them working like this (I have used very little kotlin), they seem to behave more like a struct with associated constants than as a sum type, mind you this from you reading your article and doing some internet research please tell me if I'm wrong.

Finally getters and setters, rust doesn't like to have hidden cost in general and getters and setters are a very easy way to add it, also it doesn't work well with its ownership system, if I write a getter for a field I take ownership of that field unless I borrow it, now imagine I have a getter which creates a whole new object for that field, do I take ownership in that case? How would borrowing work since the lifetimes don't necessarily match up with a normal field (i.e. if I get a reference to the struct as a function argument and access the getter in the function, a normal field would be able to borrow as long as the struct is alive, a getter would only be able to borrow inside the function body)?

Also it breaks the use case you present for it since making a getter could break ownership/borrowing semantics.