Take a look at the `time.Time` struct. It has a couple fields. What are the trade offs of making those fields public? (I contend that encapsulation is supremely useful, and the time package is a good exemplar.)

Note that Go's compiler does do function inlining, so it might be possible to encapsulate your data without runtime costs. With that said, you certainly don't have the flexibility that you have in C/C++/Rust.

Of course I agree that blindly adding getters/setters everywhere is bad juju. But to say encapsulation isn't useful is a step too far. Instead of thinking in terms of getters/setters, I'd rather think in terms of invariants on your data. If you have invariants you want to protect, then encapsulation is one possible tool you can use to protect them.

He didn't say encapsulation is not useful. He said it's not that useful. In other words, blindly encapsulating everything because that's supposed to be the right way is overkill.

Unless you're building an API.

> He didn't say encapsulation is not useful. He said it's not that useful.

So look at my comment as a refinement on that idea?

This is because most FP languages embrace immutability, so setters are absent by design, and getters are not needed. Any computation goes to proper functions, not "getters". Absence of virtual methods also helps: there is no point in having a getter (or a setter) if nobody would override it.