Hacker News Reader

I have experience that I think most don't. My experience says you are very, very incorrect.

In the past couple of decades I have been through a couple IPOs, a couple of acquisitions, and have been in engineering leadership roles and slinging code in half a dozen different shaped eng/dev cultures.

In every case, static typing makes teams faster and gradual typing was a pain with potential payoffs that were muddy. Gradual typing is a shitty bandaid and so are type annotations.

I have migrated no less than 30 systems from various languages to Go across different companies, divisions, and teams. Mostly PHP, ruby, perl, python. Didn't migrate the elixir but I would have if given the opportunity.

In every single case, the team started delivering software faster. Prototypes became faster with the sole exception of prototype admin crud panels which we have needed like twice out of the nearly three dozen services I have worked on migrating. And super dynamic json can be a pain (which I blame not on problem spaces but on less thought out dynamic typed solutions offloading their lack of design onto customers via randomish response bodies).

When programs/applications get larger, the complexity tries to combinatorially expand. It can quickly outgrow what newer team members can juggle in their head. Type systems take some of that away. They also take away tests that are there due to lacking types. "What if this is a string, or list, or number" isn't a question you ask, nor is it a test you write and maintain.

When everything fits in your head, dynamics types are freeing. When it doesn't fit in your head, tooling helps.

Even smaller programs benefit. The dozens of teams I have personally witnessed don't find adding a type as a slowdown - they see whole test cases they can ignore as impossible to compile.

This is junk. Writing a type annotation takes basically zero time, then saves you time by preventing the runtime error because you forgot which variable was which, then saves you more time by autocompleting the correct list of valid methods when you hit dot.

Acting like Go is comparable to JS is ridiculous; Go's type system is the only kind of type system needed in Ruby. Rust is a staggering outlier in complexity. And the Turborepo port took a long time specifically because they tried to port one module at a time with C interop between the old and new codebases, which massively slows down development in any language, especially Go. This is just about the most dishonest 'example' you could have picked.

Either that or you are saying 'weakly typed' to mean type inference in `var := value`, in which case (a) Rust has that too and (b) that's not what the debate is about, nobody is against that

Making the type annotations pass restricts you to writing more bloated and verbose programs in general.

Stating that A is an integer isn't much of a issue but once you get a reasonably complex program and A now has a compound type made of 5 parts, it really does slow you down and it really does make you write considerably worse programs for the sake of passing a type checker.

Any commercial code will need to be unit tested so there is no time saving from finding runtime errors earlier and an any good IDE will detect the same errors and provide you with the same auto complete automatically for free without any type annotations at all. These are problems which exist solely in your head.

1 developer vs a whole team of developers. I think you need to face the facts.

There are studies comparing old dynamically types languages against statically type languages. They always show approximately 1/3 of the lines of code being used with 3x faster development times in the dynamically types languages. This isn't some new discovery.

Well even Python is strongly typed but for the sake of this we are discussing type complexity.

It seems like your main gripe is that writing the type annotations slows you down, so I'd be interested to know what you think of languages like OCaml, Elm, Gleam or Roc. These are languages which never (or almost never) require any type annotations because the compiler can always infer all the types. Most people using these languages tend to add type annotations to top-level functions anyway though.

It seems to me that this is equivalent to a language without a type checker that automatically generates a unit test for every line of your program that tests its type.

The default type is always any (or dynamic, as some call it). No need to type everything. Usually you type just some args. Not even locals.

And some types can be inferred by the compiler, as e.g. for new instantiators. Or array, int, str convertors.

You are comparing apples to oranges, and go is pretty strong typed

I'm comparing a program with itself.

Go only has basic types and interfaces to emulate duck typing (structural typing). The type complexity in Go is rather on the low side of things.