> anyone writing Python (sans mypy) doesn't get to chastise Go for lacking generics! :)

Why do you say this point in particular? Python's duck typing makes generics very easy, no? i.e., you can write an algorithm in python that just assumes a particular method is callable and you don't have to code gen individual implementations for different types. plus the dunder (e.g., `__iadd__`) methods give a lot of useful basic functionality

>The other definition of generics that _is_ satisfiable by (untyped) Python--the definition you presumably had in mind--is equally satisfiable by Go via its `interface{}` type. So regardless of which definition you adhere to, "Go lacks generics" is no more valid a criticism for Go than for Python.

Well, that's not exactly the case. Interface{} might have the same tradeoffs with Python's dynamic types (plus more ceremony), but that's not the real issue.

Python is inherently a dynamic typed language, so not having types and generics is expected and idiomatic.

For Go, you have a type system and static type checking, but you can't properly use it when you resort to interface{} to make generic algorithms.

So while for Python not having types/generics is business as usual (and that's part of the very promise of the language), for Go not having generics means losing two of it's main promises, static type checking and speed.

For whatever it's worth, I'm a proponent of generics in Go.

"Static type checking" does not mean "every conceivable program is safely expressable by the type system". Haskell doesn't make this promise and neither does Go.

Anyway, Go is as slow and as unsafe as Python in the ~1-5% of code that is generic. It's still a pretty good deal even if you were mistakenly expecting 0%.

>"Static type checking" does not mean "every conceivable program is safely expressable by the type system". Haskell doesn't make this promise and neither does Go.

No, and I didn't make this claim or demand this either.

But it should mean: "any algorithm variation where just the type changes should be expressable by the type system without me having to rewrite e.g. a sort list for int64 lists, int32 lists, float lists, etc, it's 2019 already".

That's not what static typing means. If you want it to mean that, go right ahead. I agree that Go should support that feature, but it has no bearing on the definition of static typing nor on Go's position relative to Python with respect to speed or safety.

I assumed the poster meant the git concept of pre-commit hooks, which is just a shell script - https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks

Your parent is correct. Here's our pre-commit config too FWIW:

  more .pre-commit-config.yaml
    repos:
      - repo: https://github.com/pre-commit/pre-commit-hooks
        rev: v2.1.0
        hooks:
          - id: end-of-file-fixer
          - id: check-json
          - id: check-yaml
  - repo: https://github.com/asottile/reorder_python_imports
    rev: v1.3.4
    hooks:
      - id: reorder-python-imports
        args: [--application-directories=gaia]
        language_version: python3
  - repo: https://github.com/ambv/black
    rev: stable
    hooks:
      - id: black
        language_version: python3
  - repo: local
    hooks:
      - id: eslint
        name: eslint
        entry: ./frontend/node_modules/.bin/eslint --fix
        language: node
        language_version: system
        files: \.(js|jsx|ts|tsx)$
  - repo: https://github.com/prettier/prettier
    rev: "1.15.3"
    hooks:
      - id: prettier
        files: \.(yml|yaml|md|json)$
        language_version: system

Elasticache is a totally closed source implementation that does not contribute back to the community. How did this situation change your decision?

what would they contribute back? elasticache is just vanilla redis. aws is selling you compute time and ram.

> elasticache is just vanilla redis

Only at the interface level. Elasticache is a heavily forked Redis. There's a reason it's several versions behind.

that makes sense. i guess i had just assumed it was laziness. :-)

out of curiosity, do you have any idea what their mods might be?

I never bothered to really look into it -- I suspect it's semi-public information. If I had to guess, lots of internal changes to make Redis behave better in AWS's architecture to do with containerization, EC2, S3/EBS, maintenance automation related stuff, instrumentation, etc.

Oh actually definitely some stuff related to their redis clustering system.

They also support encryption in transit. That part was open sourced recently, but hasn't made it into upstream yet (though it most likely will from sounds of it).

They're complementary (I'd say) :)