3 ms·

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(.

• EdSchouten 5y ago
  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-reference/functions/#pipelines 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.
  • jen20 5y ago
    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!)
• erdeibit 5y ago
  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.
  • azth 5y ago
    It shouldn't affect compile times though. golang compile times arealready in a similar ballpark to Java (if not slower) for large codebases.