4 ms·
Piling on here - My impression of your snippet here is that GroupBy() and Values() both construct (potentially very large) temporary arrays on the stack. Maybe
by mappu 5y ago
Piling on here - My impression of your snippet here is that GroupBy() and Values() both construct (potentially very large) temporary arrays on the stack.
Maybe Haskell and F# can elide this kind of thing, but it's not something the Go compiler is going to do.
- Yoric 5y agoRust and OCaml (the latter if you use the right libraries) can definitely avoid it. Why couldn't Go?
- wrnr 5y agoI've been waiting to do things like that in Go for a long time. It can be done efficiently just like the Java Stream interface.
- mappu 5y agoAn alternate-universe Go with a lot more (& slower) compiler passes could do it, but I don't believe there are any plans to build such a thing. As it stands, this kind of code (where all intermediates have type []T) will run much more poorly than you could do with imperative loops. The final generics design is probably not expressive enough to do it ergonomically in user code neither (building something where the intermediates are a library type with a last `.something()` call to collect a final []T).
- pjmlp 5y agoOCaml compiles as fast Go. No secret sauce, just having the pleasure of chosing multiple backends, including an interpreter. Bytecode runtime during workflow, optimized native AOT for release and final production tests.
- duped 5y agoThat's just bad design - iterators and sequences need to be lazy. The intermediary type should not eagerly create large arrays on the stack, it should only ever do real work once the iterator has been driven.
- rad_gruchalski 5y agoNo, they don’t need to be. They can be. Go wasn’t designed as a functional language but to be fast to compile, fast to execute, zero dependency binary and simple syntax. It achieved that by a mile.
- duped 5y agoImplementing iterator combinators by eagerly evaluating them into temporaries is a bad, naïve design that results in the issue illustrated above. A much better design is to do it lazily which is possible if you can store closures as fields of a data structure. Not sure what fast compilation and execution or dependencies has to do with this. Implementing iterators that way is the worst possible solution that results in slow execution that can blow up the stack and crash a program. It would be better not to have iterators at all than to require them to be eagerly evaluated. You can support functional features without being a Haskell...
- rad_gruchalski 5y agoYes, lots of science. Go has slices which require specifying a size and you iterate over them using a for statement. You want lazy, pop in a channel and do it lazy.
- duped 5y agoThis isn't "lots of science" it's rudimentary software engineering... Sending data through channels just to implement an iterator seems insane. It's not strictly lazy either... Why do go developers reject simple patterns that make faster code?
- rad_gruchalski 5y agoHow are those magical lazy operations implemented in other languages? Someone had to take that insane step. It’s just not by default in go. Look, I’ve written lots of scala and erlang so I get your argument. It just does not exist in go. And that’s okay. Never got caught thinking “gee, need a lazy collection”. Maybe a stream when reading stuff from the ether. In go, channel was enough. 5 minute job. Nothing insane.
- skjfdoslifjeifj 5y agoThe standard Ocaml compiler doesn't elide it and as far as I'm aware neither do any of the publicly available libraries. All of the lazy stream implementations in Ocaml have a performance cost similar to Java streams. Haskell and Rust are relatively unique in that they can completely eliminate the performance cost in the typical cases.
- deleted 5y ago[deleted]
- Serow225 5y agoFWIW C# would as well (LINQ)