Hacker News Reader

Comment by akshayshah | Hacker News Reader

I'm particularly excited to have all the patterns from the slice tricks wiki page[0] shipped as a standalone package. (I'm not sure why the slices package doesn't include any of the good stuff...) Understanding those patterns requires internalizing the relationship between slices and arrays, which is important but too high of a bar for a simple, safe in-place filter.

[0]: https://github.com/golang/go/wiki/SliceTricks#additional-tri...

View on HN

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.

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