3 ms·
Yeah if you're writing "Compose3" you've already lost. The extra type annotations only make it worse. x := foo() y := bar(x) z := baz(y) Wow.
by platinumrad 5y ago
Yeah if you're writing "Compose3" you've already lost. The extra type annotations only make it worse.
x := foo()
y := bar(x)
z := baz(y)
Wow.
- pharmakom 5y agoOk, now what if foo, bar and bar are async? Nullable? Result types?
- platinumrad 5y agoWell it's not like Go has do notation so I don't know what you're expecting here.
- pharmakom 5y agoI’m pointing out that functional programming goes beyond trivial things like compose3 and list operations (useful though they can be).
- platinumrad 5y agoSure, but e.g. monadic futures aren't going to be very usable in a language without do notation, custom operators, or non-verbose lambdas. Might as well just use channels. As for nullability and error handling, writing "if" over and over again might be bad, but in Go I don't think functional approaches are going to be any better. Maybe liftA2, etc. on pointers would be usable, but not much else.