I have also moved towards "dumb data objects", immutable if possible, and a library of functions that operate on them. Exactly what this looks like will obviously depend on the language, though.

In Java, I might have a Foo object and a FooController.

In Kotlin, I'd probably have a Foo object and a FooController file, but that file would contain functions, not a controller object. Of course, in the bytecode this would map to a FooControllerKt object.

Kotlin also offers extension functions, which are similar to how Go declares object methods. I use these for utility functions, as opposed to business logic. If I wanted a function to camel-case a string, for example, I'd use an extension function. If I wanted a function to determine if a string is a valid zip code, I'd use a method that takes in a string.