Hacker News Reader

What's quite sucky is that they will remain as standalone functions and not member functions, so you can't chain them (e.g. slice.Sort(...).Filter(...).Reduce(...))`. Not sure why golang is resistant to adding member functions to types.

View on HN

Why not just get a “pipe” operator added to the language instead? Many functional programming languages already have one.

https://docs.microsoft.com/en-us/dotnet/fsharp/language-refe...

No need to alter the type system of the language, while it’s clearly a syntactical improvement you’re looking for.

I (sadly) can't imagine that getting through the language modification process, somehow, though it certainly would solve this particular problem! If we're looking for things that Go could usefully take from functional languages I'd personally start with the much lower-hanging fruit of some guarantees about mutability of structures, though.

(ps: Hi, Ed!)

My guess is that compilation time could be increased, which would let Go in the same boat as Rust or C++. I suspect every nice or must-have feature you add to a language, you must take the choice between deal with it in runtime or compilation time. Not adding features, no choice to take.

It shouldn't affect compile times though. golang compile times arealready in a similar ballpark to Java (if not slower) for large codebases.

Reply on news.ycombinator.com