5 ms·

> Then, you can define your categories normally: > var ( > Adventure = genre.New(1, "Adventure") > Comic = genre.New(2, "Comic") >

> Then, you can define your categories normally: > var ( > Adventure = genre.New(1, "Adventure") > Comic = genre.New(2, "Comic") > // etc > ) Yet there is nothing preventing anyone from reassigning Adventure to genre.New(2, "Comic") or some other arbitrary value. The fact that golang doesn't have the equivalent of Java's `final` is just poor design.

lhorie 6y ago
There's nothing preventing someone from editing the source code to `const Comic = Adventure` either. Either you have access to edit String() AND have access to mess with the definitions in source code, or you don't have access to either. The idea that `final` can protect you against yourself is kinda silly IMHO.
- gher-shyu3i 6y ago
  Think about the use case of a library import. In golang, the user has the ability to change library "constants", wreaking havoc in the process. Secondly, `final` serves as strong and clear documentation. We know just from looking at the definition that this is variable is not going to be re-bound. On a side note, this compiles in golang: func main() { true := false if !true { fmt.Println("wat") } }
  - lhorie 6y ago
    I mean, at some point, garbage in garbage out, no? For example, in javascript, you can do `Array.prototype.map = null`, in C you can do `#define if while`, etc. It's highly unidiomatic to mutate bindings from libraries in any language, even ones that technically allow you to, so the observation that go is one of those languages feels like nitpicking at obscurities. My Java is rusty, but I recall that several years ago I ran into some stuff in the Java core API that was needlessly marked final requiring some nasty wrapping around a huge class to get around. Trade-offs, trade-offs.
    - gher-shyu3i 6y ago
      > I mean, at some point, garbage in garbage out, no? For example, in javascript, you can do `Array.prototype.map = null`, in C you can do `#define if while`, etc. Yes, but a good language is supposed to minimize chances of error, especially one that was designed after C, C++, and Java. The industry progressed, and we have a better understanding of what some good ideas are, and which to avoid. The fact that golang allows null pointers is inexcusable IMO. C# was able to retrofit a nullable handling mechanism into the language, and practically any useful language that was designed after that had some sort of nullable type handling (Scala, Kotlin, Rust, and I believe Zig and Nim as well, etc.).
morelisp 6y ago
> The fact that golang doesn't have the equivalent of Java's `final` is just poor design. That Java dropped C++-style `const` is also poor design. We're just all really bad at this.
- gher-shyu3i 6y ago
  C++'s const has some issues, so I can see why. Plus, it's possible to design around it by means of immutable data structures (e.g. see Scala). I think that Rust's approach is superior to C++'s here, but even that has some issues so they have to retort to interior mutability via RefCell.

lhorie 6y ago

There's nothing preventing someone from editing the source code to `const Comic = Adventure` either. Either you have access to edit String() AND have access to mess with the definitions in source code, or you don't have access to either. The idea that `final` can protect you against yourself is kinda silly IMHO.

gher-shyu3i 6y ago
Think about the use case of a library import. In golang, the user has the ability to change library "constants", wreaking havoc in the process. Secondly, `final` serves as strong and clear documentation. We know just from looking at the definition that this is variable is not going to be re-bound. On a side note, this compiles in golang: func main() { true := false if !true { fmt.Println("wat") } }
- lhorie 6y ago
  I mean, at some point, garbage in garbage out, no? For example, in javascript, you can do `Array.prototype.map = null`, in C you can do `#define if while`, etc. It's highly unidiomatic to mutate bindings from libraries in any language, even ones that technically allow you to, so the observation that go is one of those languages feels like nitpicking at obscurities. My Java is rusty, but I recall that several years ago I ran into some stuff in the Java core API that was needlessly marked final requiring some nasty wrapping around a huge class to get around. Trade-offs, trade-offs.
  - gher-shyu3i 6y ago
    > I mean, at some point, garbage in garbage out, no? For example, in javascript, you can do `Array.prototype.map = null`, in C you can do `#define if while`, etc. Yes, but a good language is supposed to minimize chances of error, especially one that was designed after C, C++, and Java. The industry progressed, and we have a better understanding of what some good ideas are, and which to avoid. The fact that golang allows null pointers is inexcusable IMO. C# was able to retrofit a nullable handling mechanism into the language, and practically any useful language that was designed after that had some sort of nullable type handling (Scala, Kotlin, Rust, and I believe Zig and Nim as well, etc.).

morelisp 6y ago

> The fact that golang doesn't have the equivalent of Java's `final` is just poor design. That Java dropped C++-style `const` is also poor design. We're just all really bad at this.

gher-shyu3i 6y ago
C++'s const has some issues, so I can see why. Plus, it's possible to design around it by means of immutable data structures (e.g. see Scala). I think that Rust's approach is superior to C++'s here, but even that has some issues so they have to retort to interior mutability via RefCell.