[sophacles]

It's a pain to write all that boilerplate, I agree. I don't think it's bloat though - I've been doing rust for a few years now, and when I revisit old mostly forgoten code, I love that boilerplate. I rarely have to do any puzzling about how to infer what from the current file, it's just all right there for me.

I feel this way about all the verbosity in rust - some of it could likely be inferred, but but having it all written down right where it is relevant is great for readability.

[worik]

Having done a bit of C lately (lots in the past) and quite a bit of Rust, Rust is not verbose!

The functional syntax the author of this (good) article complains about is what this (long experience in procedural C like languages) old programmer has come to love.

[Klonoar]

>when I revisit old mostly forgoten code, I love that boilerplate. I rarely have to do any puzzling about how to infer what from the current file, it's just all right there for me.

This is going to sound absurd, but the only other language I had this experience with was Objective-C.

Verbosity is super underrated in programming. When I need to come back to something long after the fact, yes, please give me every bit of information necessary to understand it.

[hermitdev]

Useful verbosity is fine to me. However, I never wish to see another line of COBOL, thank you very much.

[eropple]

This is a really good point, IMO. I've never written extensive amounts of Objective-C, but in my adventures I've had to bolt together GUIs with Objective-C++ and I learned to love the "verbose" nature of Obj-C calls whenever I had to dive back into the editor for a game engine or whatever because it meant I didn't have to rebuild so much state in my head.

[zarzavat]

What you want is for the complex things to be verbose and the simple things to be concise.

Objective-C makes everything verbose. It’s too far in the other direction. Memories of stringByAppendingString

[Klonoar]

Eh, sure, I'm willing to buy Objective-C went too far in some places. It still works for coming back to, though. :)

[carlmr]

That's true, I found this writing F# with an IDE vs reading F# in a PR without IDE it really becomes easier to read if you at least have the types on the function boundary.

F# can infer almost everything. It's easier to read when you do document some of the types though.

[eropple]

> F# can infer almost everything. It's easier to read when you do document some of the types though.

F# is also easier to avoid breaking in materially useful ways if (like TypeScript) you annotate return types even if they can be inferred. You'll get a more useful error message saying "hey stupid, you broke this here" instead of a type error on consumption.