4 ms·

Oh yeah, and generic lists and maps And built-in testing infrastructure, performance testing, code distribution, linting, code formatting, parsing and AST libra

• papaf 12y ago
  And a built in dependency manager, build tool, documentation generator...
  • dkarapetyan 12y ago
    But generics crosses the line because compile-time code generation is so much clearer and simpler and doesn't add any overhead to compilation times because code substitution is not compilation.
• pjmlp 12y ago
  pre-Java 1.5 already had all of that.
  • burntsushi 12y ago
    Where was pre-Java 1.5's generic HashMap? Or closures?
    • pjmlp 12y ago
      > Where was pre-Java 1.5's generic HashMap? In java.util.Hashtable as implementation of the java.util.Dictionary interface, since version 1.1 back in 1997. Implemented using s/interface{}/Object/g with ability to use any type as key, as long as, hashCode() and equals () are overriden. Also allows for fine tuning of the capacity and load factor. > Or closures? In anonymous inner classes. A pain to use when compared with real closures, but doable nonetheless.
      • masklinn 12y ago
        In the discussion's context, "generic" is about parameterized types (type-safe collections), not about working on any object.
        • pjmlp 12y ago
          Which Go lacks and the OP was stating it has.
          • masklinn 12y ago
            * Go has a generic hashmap, the builtin map type is one of the magical special-status generic collections (with arrays, slices and channels). * pre-1.5 Java did not have one, its only parametric type was the low-level array
            • pjmlp 12y ago
              Ah, ok. That is correct.
      • burntsushi 12y ago
        That is not a generic HashMap. See masklinn's response. The fact is, the comparison between Go and "pre generics Java" is a bad one. There are many substantial differences, and blessed parameterized types in Go is absolutely one of them.