3 ms·
It's less about getters and setters specifically and more about how much Java's ecosystem relies on code generation through libraries like Lombok instead of jus
by CrimsonVoid 4y ago
It's less about getters and setters specifically and more about how much Java's ecosystem relies on code generation through libraries like Lombok instead of just trying to fix the language. Likewise, Rust's answer to everything seems to be "just make a (proc) macro" instead of trying to extend the language. Proc macros do have their place, serde being a great example, but then there are crates like thiserror and bitflags which exist because Rust provides nothing in the language grammar to actually talk about errors and error handling patterns, or bitmasks (which is an incredibly common thing for a systems programming language). Sure you could write out the From<Error> impls instead of using thiserror, but most people aren't going to because Rust makes something that should be mundane incredibly annoying to write by hand.
Side note, Rust best practice seems to be in favor of getters and setters like Java and several popular libraries I've seen don't expose struct fields directly instead opting for set_x() and x() methods. Give it a few years and I'm sure Rust will have its own Lombok crate generating getters, setters, and constructors too.