3 ms·

No, 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 simpl

No, 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 ago
Implementing 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 ago
  Yes, 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 ago
    This 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 ago
      How 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.
      - duped 5y ago
        They're implemented with closures, not passing things through FIFOs. It's not magic. You barely need a compiler pass to implement the sugar for `for` loops: it's a trivial transformation to a `while`.
        rad_gruchalski 5y ago
        Okay, but what’s the benefit for go. I can iterate over slices, maps and channels (for ... range). Slices must have a capacity defined. What’s the benefit of lazy iterator? for over a channel is in essence lazy. Channel stores the data as a linked list. So what’s the benefit.
        duped 5y ago
        The benefit of generic iterators or implementing iterators lazily? The benefit of generic iterators is that they make SOLID programs easy to write, especially when converting data. It makes any kind of data ingest or hand rolled parsing/semantic analysis easy to write, read, and hard to screw up - which is 90% of business logic. Lazy evaluation is the only reasonable way to implement iterators so you don't have to pay the costs of intermediate data structures or sending data over channels. Insertion into a data structure isn't free. Function composition is.

duped 5y ago

Implementing 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 ago
Yes, 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 ago
  This 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 ago
    How 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.
    - duped 5y ago
      They're implemented with closures, not passing things through FIFOs. It's not magic. You barely need a compiler pass to implement the sugar for `for` loops: it's a trivial transformation to a `while`.
      - rad_gruchalski 5y ago
        Okay, but what’s the benefit for go. I can iterate over slices, maps and channels (for ... range). Slices must have a capacity defined. What’s the benefit of lazy iterator? for over a channel is in essence lazy. Channel stores the data as a linked list. So what’s the benefit.
        duped 5y ago
        The benefit of generic iterators or implementing iterators lazily? The benefit of generic iterators is that they make SOLID programs easy to write, especially when converting data. It makes any kind of data ingest or hand rolled parsing/semantic analysis easy to write, read, and hard to screw up - which is 90% of business logic. Lazy evaluation is the only reasonable way to implement iterators so you don't have to pay the costs of intermediate data structures or sending data over channels. Insertion into a data structure isn't free. Function composition is.