4 ms·

You absolutely can implement those functions in Go, if you're willing to sacrifice both type safety and performance. e.g., https://godoc.org/github.com/BurntSus

You absolutely can implement those functions in Go, if you're willing to sacrifice both type safety and performance. e.g., https://godoc.org/github.com/BurntSushi/ty/fun https://godoc.org/github.com/BurntSushi/ty/fun Javascript is unityped, and you can certainly pretend Go is unityped too, by using `interface{}` everywhere. If you linked to a similar set of functions defined in, say, C++, then I'd agree that Go has no real way to achieve something similar. > (errors can be modelled with a generic Result<T> which forces you to check for error and allows chaining, generics would enable immutable data structures which are much safer for concurrent programming...) Generics isn't sufficient for that though. You also need sum types, which Go doesn't have. Lack of generics isn't objectively a flaw. It's a trade off. You may disagree with that trade off though!

spion 11y ago
You don't need sum types, Result / Optional etc can be implemented in a language without them. I can implement those in TypeScript too. Its a fast compiler, has a type system, and it supports generics.
- burntsushi 11y ago
  Sum types are how Result/Option/Maybe/Either are typically implemented. The type system guarantees that inhabitants of the type contain exactly one success value xor one error value, and that accessing the value requires handling both cases, which is checked at compile time.
  - spion 11y ago
    Sure, but you don't necessarily need sum types for Either. Its more tedious, but totally doable without them, e.g. just with higher order functions: let left = a => (l, r) => l(a) let right = b => (l, r) => r(b) its now impossible to consume result without passing functions to handle both the left and the right value. let mapRight = f => val => val(identity, right => right(f(val)))
    - burntsushi 11y ago
      Indeed, but now you're just being academic. Such an approach is quite bothersome. I maintain my initial criticism of your suggestion. It's easy to be an armchair designer of programming languages. It's quite a bit more difficult to be in the driver's seat, because you have to answer the hard questions; you can't just throw feature sets against an HN comment wall and see what sticks.

spion 11y ago

You don't need sum types, Result / Optional etc can be implemented in a language without them. I can implement those in TypeScript too. Its a fast compiler, has a type system, and it supports generics.

burntsushi 11y ago
Sum types are how Result/Option/Maybe/Either are typically implemented. The type system guarantees that inhabitants of the type contain exactly one success value xor one error value, and that accessing the value requires handling both cases, which is checked at compile time.
- spion 11y ago
  Sure, but you don't necessarily need sum types for Either. Its more tedious, but totally doable without them, e.g. just with higher order functions: let left = a => (l, r) => l(a) let right = b => (l, r) => r(b) its now impossible to consume result without passing functions to handle both the left and the right value. let mapRight = f => val => val(identity, right => right(f(val)))
  - burntsushi 11y ago
    Indeed, but now you're just being academic. Such an approach is quite bothersome. I maintain my initial criticism of your suggestion. It's easy to be an armchair designer of programming languages. It's quite a bit more difficult to be in the driver's seat, because you have to answer the hard questions; you can't just throw feature sets against an HN comment wall and see what sticks.