[kelnos]

The first comment below your link to the message about Rob Pike's feeling on types was a more succinct form of my reaction:

> Sounds like Rob Pike doesn't understand type theory.

I'd be a bit more charitable; Pike is a smart dude, I'm sure he does understand type theory, but has decided he'd prefer to write imperative code. And he's actually good at writing imperative code correctly, so for him, that works. But most people are not very good at writing imperative code correctly, at least not the first time, and not without writing a large volume of tests (usually several times as much test code as program code) to verify that imperative code.

Or perhaps Pike was just assuming the person he was talking to was only talking about types in the OOP sense. If that's the case, I agree with him: taxonomies are boring, and inheritance often leads to leaky abstractions.

But types let you do so much more than that. I much prefer being able to encode behavior and constraints into the types I define over writing a bunch of tests to verify that the constraints I've expressed in code are correct. Why do the work that a compiler can do for you, and do it much better and more reliably than you?

[swertyb]

> But most people are not very good at writing imperative > code correctly, at least not the first time, and not > without writing a large volume of tests (usually several > times as much test code as program code) to verify that > imperative code.

How are languages other than Go (like Rust, Swift etc.,) not imperative? They are nearly as much imperative as Go but have FP features like ADTs and pattern matching, but those don't make them "functional". This point might be valid if you are talking about Haskell, MLs and the likes.

> I much prefer being able to encode behavior and constraints > into the types I define over writing a bunch of tests to verify that the constraints > I've expressed in code are correct. Why do the work that a compiler can > do for you, and do it much better and more reliably than you?

IMO, this "types replacing tests" might be true when comparing dynamic vs static typing, but for already static typed languages, extra typing cannot be a substantial gain. Personally, I find type-level programming beyond a certain extent to be counter productive and it doesn't seem to have much impact on correctness (unless we bring in dependent types).

[kelnos]

You're acting like a language is either 100% imperative or 100% functional, but there's a lot of middle ground.

I just fundamentally disagree that "extra typing" (as you put it) doesn't give you much of a gain in correctness confidence.

[vlads_]

I'm going to be a smartass about this and say I think neither of you are wrong. The "extra typing" gives you a large boost in your confidence that you've written something correct, without necessarily boosting the correctness of what you have written.

The best example of this which I have seen is Amos' https://fasterthanli.me/blog/2020/i-want-off-mr-golangs-wild... in which he chastises Go for allowing him to print filenames which contain non-UTF-8 data to the terminal which does not display correctly, instead of forcing them be escaped. Rust does that, so he is confident that the program he writes in Rust handles filenames properly: if they are UTF-8 they are printed normally, if they are not they are escaped. Since the Rust type system allows him to do this, it must be correct, right? Of course not. Filenames which contain vt100 escape codes would do a lot more damage and they are not handled at all.

At the end of the day you still have to think of all the possible cases. Types help to constrain the number of possible cases, but the more time you're spending making type constraints as narrow as possible, the less time you're spending handling the cases which can never be caught by the type system.

[azernik]

Parent comment isn't implying that functional vs imperative is a binary; they're pointing out that the power of a type system is orthogonal to the imperative/functional spectrum.

[stickfigure]

How about just having the bread-and-butter tools of FP available? You can't have a typesafe map operation without generics, so that alone is a major impediment to FP in Go.

[swertyb]

You are conflating FP with statically typed FP. There are dynamic typed FPLs too (Scheme, Elixir etc.,). Yes, I agree that Go could've been better if it had simple generics and discriminated unions.

By the way, generics are not at all exclusive to FP. Both C++ and D proved advanced generic/meta-programming facilities like template template parameters(HKTs) and constant generics which Rust currently lacks. But I'd certainly not use these if there is no absolute need.

What I objected to was abstracting and generalizing too much to the point of over-engineering. Some type systems, like those of Rust and Haskell, provide more room for such abuse and it takes some discipline to keep it simple. In contrast, OCaml is a very good sweet spot. ML modules are as powerful as type classes and lead to much cleaner and simpler APIs. OCaml compiles even faster than Go!