@@kenarnarayaka It's a sea of sigils. It sucks to write and read it when you're at the complexity ceiling passing database connections with user request data, combining it with data from a file you just read, etc. etc.
To me the main advantage of the design is that it is easy to refactor between a function that pushes into a channel and an iterator. You can pass func yield(x) { ch
I'm not overly enthusiastic but I'm definitely going to use them. This isn't the first feature in Go that needs some thought when using -- channels and goroutines are about as convoluted in typical use. Maybe they should have added a more channel-like syntax but on the other hand this doesn't require changes in the parser.
agree. Channels, the idea of interfaces, gorouties felt like they took a lot of thinking than writing to understand. I just learnt the bloody language and started building shit and they throw one more confusing thing at our faces. And everyone gonna use more of it and make it more confusing
What even is the "right" complexity level of Go? It is a completely arbitrary line what to include and what not. Personally I always found it annoying that slices, unsorted maps and channels where the only data structures that feel integrated into the language and if you want something like a sorted map you have to go and copy & paste it for every type you need and it always looks out of place. Generics and now function iterators change that. I would expect it to be used for a limited set of use cases (mainly data structures) and the wast majority of Go programmers only using it as library. Not the type of code you would have to change regularly.
Initially there was pretty much one way to solve a problem in GO. That was the beauty of it. The language had so little features you often trended towards the same ways of writing code. Meant less spaghetti. This is just junior engineering fuel.
My polemic opinion is that I like this implementation of range-over-functions haha, I don't feel it breaks the “Go style” and reading the discussion you can understand why they decided not to use an iterator as interface, so welcome to it
I think I get the concept of why, they want to implement somethign where you can process large dataset with a memory optimized way. It is similar to the concept of Generators in PHP, though no need for this to achieve this. There are already multiple ways of doing it, using channels or without channels as well. Here is a trivial example with channels. The point would be of course not to process a slice like in this example, but for example pass an *sql.DB, or a select SQL statement or a csv file, and read them line by line, fetch data via cursor or buffered query and this way you can process large amount of data efficiently: The trivial example: `package main import "fmt" func main() { elements := []string{ "element1", "element2", "element3", } for el := range iterator(elements) { fmt.Println(el) } } func iterator(items []string) = len(items) { break } ch
Yeah, I think the idea is just to standardize the iterator pattern in go wholesale. To your point, nothing is stopping you from doing this now: ``` package main import "fmt" func iter[T any](items []T) func() (T, bool) { var i int return func() (T, bool) { if i < len(items) { item := items[i] i++ return item, true } var t T return t, false } } func main() { s := []string{"a", "b", "c"} fn := iter(s) for item, ok := fn(); ok; item, ok = fn() { fmt.Println(item) } } ```
Compare this with simplicity of Python’s iterator protocol and generator functions. But that’s what you get if you are staunch opponent of concepts from other languages. But at least it gives me a possibility to iterate over anything I want, making builtin types less special, so I’ll take it anyway.
Easy peasy! New working agreement at team "There isn't any excuse to use the iter package or those weirdo functions around that feature, simplicity and readability over all mate 🙏" and that's it 👍
Coming from the world of Python: this is a reasonable addition. You don't have to use them, but you can now iterate through anything without messing with indexing.
I thought channels are used to emulate iterators in go, like just push object into the channel one by one and make some custom logic by receiving them from the channel
I love iterators sometimes I wish I had them but I'd go with a for range with function call anytime compared to this. Why didn't they just pick an easier syntax? maybe give iterators some special keyword instead of mambojambo with func? iter Backwards(arg:string):bool { normal for loop going backwards }
Ima need to wait until Chat Gippety catches up to this feature so I can wrap my head around it. Every explanation in videos or docs has not clicked for me yet.
just try to call the iterator without the for range loop. It's a syntax sugar for calling a function that iterates over stuff and applies another "yeald" function
I'm not keen on the new iterators. I'd have liked it if they did it more in the shape of an interface. PHPs Iterator Interface, for example. That is way easier to understand, than this this Mess of functions within functions and some Yields thrown in, makes things confusing. All in all, I'm not going to write my own iterators in this way, but I appreciate the option. Back when Generics were introduced, I too though, that I'd never use them, but there were situations, where they came in handy.
It's expanding the usage of range without breaking existing code. before: range accepts built-in slice and map now: any iterators you create with or without the iter stdlib. Maybe the implementation is ugly but I read the source, I can't figure out a better way.
Yes I definitely think this was the wrong direction. I personally don't see any benefits of including them in the language right now as they currently stand.
I think it's okay for this to exist in the standard library. However, I really, really hope the use of iterators is mainly confined to niche utility libraries and stuff like that. The use of iterators in Go should be treated as a code smell and viewed with skepticism until an adequate rationale for its existence is demonstrated. If you're using iterators to cook up a solution to a problem that could have been done otherwise with less code and more readability, the iterators need to go.
Seq vs Seq2 and all the duplicated methods show that iterators need a bit more time in the oven. I definitely like the idea though, the current iterators like bufio.Scanner or sql.Rows are a bit more painful than they have to be.
When I first use it in 1.22, I thought it was nice After using it extensively, I don't think they are worth it anymore, at all I hope they do not release them
You didn't mention the upside, which is that this kind of implementation is most performant. Also, you'll probably never write iterators yourself, but use libraries.
IMHO they could just add the “iter” pkg as some kind of generic helper that gets a callback generic function to process each iteration… Not really liking the concept of messing with internal components of the language such as the range keyword. BTW does that mean it’s kinda breaking the code and public repos would need to add the go version build tag for supporting not using this?
code built before 1.23 would continue working as expected. it'd only be breaking if a library which implemented iterators in a different way (because there was no previous standard) adopted this standard, however, that's with many features, and most of those libraries should release a v2 version of the package if it's a breaking change anyway.
I think they have made a mess here. The func of a func being hiddeded is crazy. It doesn't make the code easy. Imagine throwing in a few channels into that pipe of horse poo... Dotnet has a very clean `yield` keyoword that can return a tuple. Why a func of a func, who in their right mind is going to remember how to do this. It feels worse than Javascript's poly promise pre 2013!
That's what happens when people want to write in Go like in Python, C++ or java. To write good Go code, you should think on Go, not haskel, rust or java. Like java-features? Go develop on java. Please don't breake Go
All this to avoid the "language complexity" of the "yield" keyword. This is wear I very much diverge with the language developers and their crusade to keep the language as minimal as possible. They can't see the forest for the trees, and in practical terms, make it more complex with strange design patterns like this.
I think it’s pretty novel actually. Russ was able to propose iterators without the need for a new keyword. I think thats great! Yield is a whole can of worms and could be implemented in a plethora of ways. Go has a concept of yield, but you never know about it because the language design is so thoughtful (see how channels, mutex, or any “blocking” thing works in the runtime). This type of iterator pattern is also incredibly efficient. Its pretty much syntactic sugar, whereas yield is not.
I am new to Go, Python is my main lang. Iterators are great in Python (my opinion). I agree these new Go iterators look very unreadable. Something like map/filter( func, iterable) goes so much more easy on the eye, if simplicity and readability is Go's mantra.
@@JamesRouzier Yes, I tried it in 1.22 with some examples. You can even use them to return errors or read from a socket, it's really powerful but it's anything but simple to implement and easy to read and write. Powerful and horrible.
@@JamesRouzier There is a level of "magic" (hidden control flow or syntactic sugar) going on with the yield function (that you call whatever you want, really, it's just a func) that's not obvious at all... That's my main issue with this implementation. But it looks like the ship has sailed and we're getting this for better or for worst.
You will not need this 95% of the time. That's why it looks like that even. It's discouraged to make lots of these for no reason. It's good for cases when you do need them, and even then it's about performance and it's the library provider problem to handle this.
I think they chose a really poor example to showcase. Implementing this as a method on a struct is pretty trivial. The outermost wrapper function is IMO what leads to a double take or head scratch. Maybe it is too complicated and Im in the minority opinion here. I don’t know how I feel about the xiter proposal. That would seem to mainstream functional iteration patterns in go and make it easy to do things in multiple ways.
I kind of agree, but as much as I love go, the annoying thing that I have to put up with is the lack of some of the smaller less complex features eg proper enums and missing ternary operator.
I'm cool with it because generics and iterators are meant for library makers. Not weak minded people like me. Unless the language becomes a literal drag in Air on file save then I'm unburdened by Google's decisions. Every language has issues and this one isn't it.
As C# programmer that never had any experience with GO I can see that: 1) GO is unreadable. 2) They trying to introduce something that in C# is considered legacy since 2007.
C# is a higher-level language that already has for, foreach, yield, and abstractions/interfaces for iteration. I don't personally like this style of iterating, but is rather meaningless comparing a higher-level language with every feature including the kitchen sink to a language whose primary design-goal is to be minimal. Ruby makes it even easier and legible than C#, does that make C# "legacy" to Ruby?
@@ForeverZer0 1) By legacy I mean delegates such as Predicate, Comparison, Converter that has been replaced by generic Func and Action and those previous are used only in legacy methods. Those helpers in 6:00 looks like similar mistake like this. 2) Being a lower-level language doesn't mean you have to have complex syntax. 3) If you have the func keyword in one function 5 times, your language is not minimalist.
“We’ve added ‘Function Coloring’ - without needing async!” Hmm yeah look, if we’ve learnt anything about the countless languages and function coloring issues it’s that this never works out all that clean, why adding this issue to iterators, I’ll never know 🤣🤣🤣
When you add a language feature, even if you avoid it, it doesn’t guarantee your team members will avoid it meaning you’ll have to work on code that uses the feature regardless meaning you’ll have to learn it and get comfortable with it.
Lmao I love how the Go team builds a half baked feature that is way worse than what other languages have (I'm not a C# fan, but compare this to IEnumerable for example), probably because it was simpler to implement and users complain about what? Skill issues.
The iterator implementation is so bad, because go generics are bad. People are not using generics because they are so limited. You can see that clearly in the xiter func spam. If go had actual generics we would have an actual tuple type that would take an arbitrary number of elements, which would remove the need for all the *2 funcs and types.
It looks like python now. Which is a real bummer. Just because language concepts exist and are useful in other languages doesn't mean they need adopted by all languages
The problem is that libraries that needed iterators implemented them in their own way, looking completely different package to package. It's not like Go 1.23 iterators were implemented to solve a problem that didn't exist -- it is definitely nice to have a standard (not necessarily saying the way they implemented is good or bad).
This has to have been a long time coming. I abuse the heck out of generics, if you use lots of external libraries they are a must(Any interface{} fans here?), why not have iterators too? But dude why can't we just have a generic parameter count... Seq, Seq2? Why not Seq3? Also, why is it called Seq? Could just be a Sequence and a Mapping. I thought we like descriptive names in go... One more thing, wtf is that yield() call, that's wild. This is recursive?
@@nexovec May be. But abusing interface{} tells me that go is not the language you need to use, I don't know what warrants the use of it that much, would love to hear it though.
This is wild to me that people are complaining about iterators. I was pissed off when i found out go did not have iterators. I don't understand how iterators add complexity if you don't like them dont use them its simple as that.
I hope you all enjoyed this video :) dont forget to subscribe!
ocaml lookin pretty good now, huh?
don't disrespect dennis ritchie like that
😅
Not on Windows smh
@@TehKarmalizereasy fix
@@TehKarmalizerthat's a net positive in my book
Honestly, the xiter package feels like it was made as a satire to the seq and seq2
it's not a yield keyword, it's just a func name, I think.
I have no idea what I just watched. To me that func^4 thing is looking worse than rust.
Rust isn’t bad.
Plot twist: he's a Rust fan and sees everything worse than Rust secretly :)
Func func func yield func
@@parthokri love rust, but rust syntax IS bad
@@kenarnarayaka It's a sea of sigils. It sucks to write and read it when you're at the complexity ceiling passing database connections with user request data, combining it with data from a file you just read, etc. etc.
To me the main advantage of the design is that it is easy to refactor between a function that pushes into a channel and an iterator. You can pass func yield(x) { ch
I'm not overly enthusiastic but I'm definitely going to use them. This isn't the first feature in Go that needs some thought when using -- channels and goroutines are about as convoluted in typical use. Maybe they should have added a more channel-like syntax but on the other hand this doesn't require changes in the parser.
agree. Channels, the idea of interfaces, gorouties felt like they took a lot of thinking than writing to understand. I just learnt the bloody language and started building shit and they throw one more confusing thing at our faces. And everyone gonna use more of it and make it more confusing
I'm not going to pretend I know enough about GO to get upset about this, but this is pretty wild
us bro, us
Are the inventors of this new feature the same people who invented Go itself? Or is it some different team making these language updates?
What even is the "right" complexity level of Go? It is a completely arbitrary line what to include and what not. Personally I always found it annoying that slices, unsorted maps and channels where the only data structures that feel integrated into the language and if you want something like a sorted map you have to go and copy & paste it for every type you need and it always looks out of place. Generics and now function iterators change that. I would expect it to be used for a limited set of use cases (mainly data structures) and the wast majority of Go programmers only using it as library. Not the type of code you would have to change regularly.
Initially there was pretty much one way to solve a problem in GO. That was the beauty of it. The language had so little features you often trended towards the same ways of writing code. Meant less spaghetti. This is just junior engineering fuel.
My polemic opinion is that I like this implementation of range-over-functions haha, I don't feel it breaks the “Go style” and reading the discussion you can understand why they decided not to use an iterator as interface, so welcome to it
I think I get the concept of why, they want to implement somethign where you can process large dataset with a memory optimized way. It is similar to the concept of Generators in PHP, though no need for this to achieve this. There are already multiple ways of doing it, using channels or without channels as well.
Here is a trivial example with channels. The point would be of course not to process a slice like in this example, but for example pass an *sql.DB, or a select SQL statement or a csv file, and read them line by line, fetch data via cursor or buffered query and this way you can process large amount of data efficiently:
The trivial example:
`package main
import "fmt"
func main() {
elements := []string{
"element1",
"element2",
"element3",
}
for el := range iterator(elements) {
fmt.Println(el)
}
}
func iterator(items []string) = len(items) {
break
}
ch
Yeah, I think the idea is just to standardize the iterator pattern in go wholesale. To your point, nothing is stopping you from doing this now:
```
package main
import "fmt"
func iter[T any](items []T) func() (T, bool) {
var i int
return func() (T, bool) {
if i < len(items) {
item := items[i]
i++
return item, true
}
var t T
return t, false
}
}
func main() {
s := []string{"a", "b", "c"}
fn := iter(s)
for item, ok := fn(); ok; item, ok = fn() {
fmt.Println(item)
}
}
```
Why would you tag neovim if you're using vscode?
I really hope developers of go will listen to the community and at least consider their opinion when making a right direction for Golang to go.
Compare this with simplicity of Python’s iterator protocol and generator functions.
But that’s what you get if you are staunch opponent of concepts from other languages.
But at least it gives me a possibility to iterate over anything I want, making builtin types less special, so I’ll take it anyway.
Easy peasy! New working agreement at team "There isn't any excuse to use the iter package or those weirdo functions around that feature, simplicity and readability over all mate 🙏" and that's it 👍
Coming from the world of Python: this is a reasonable addition. You don't have to use them, but you can now iterate through anything without messing with indexing.
why this tags on video?
#coding #neovim #typescript
I thought channels are used to emulate iterators in go, like just push object into the channel one by one and make some custom logic by receiving them from the channel
I love iterators sometimes I wish I had them but I'd go with a for range with function call anytime compared to this.
Why didn't they just pick an easier syntax? maybe give iterators some special keyword instead of mambojambo with func?
iter Backwards(arg:string):bool {
normal for loop going backwards
}
because you don't want people to use them too much :))
Where can I find the blue gopher wallpaper for my desktop?
Ima need to wait until Chat Gippety catches up to this feature so I can wrap my head around it. Every explanation in videos or docs has not clicked for me yet.
just try to call the iterator without the for range loop. It's a syntax sugar for calling a function that iterates over stuff and applies another "yeald" function
Go developers is the only developers who wants to reinvent the wheel every day.
For real
exactly brother. I don't know how it kicked in like jokes to dads after they become dad, but I'm doing neural networks from scratch in Go 😭
I'm not keen on the new iterators.
I'd have liked it if they did it more in the shape of an interface.
PHPs Iterator Interface, for example. That is way easier to understand, than this this Mess of functions within functions and some Yields thrown in, makes things confusing.
All in all, I'm not going to write my own iterators in this way, but I appreciate the option.
Back when Generics were introduced, I too though, that I'd never use them, but there were situations, where they came in handy.
Is yeild a keyword? Cause i don't see anything using returned yeild func??
yes, yeild is a keyward.
It's expanding the usage of range without breaking existing code.
before: range accepts built-in slice and map
now: any iterators you create with or without the iter stdlib.
Maybe the implementation is ugly but I read the source, I can't figure out a better way.
Yes I definitely think this was the wrong direction. I personally don't see any benefits of including them in the language right now as they currently stand.
I think it's okay for this to exist in the standard library. However, I really, really hope the use of iterators is mainly confined to niche utility libraries and stuff like that. The use of iterators in Go should be treated as a code smell and viewed with skepticism until an adequate rationale for its existence is demonstrated. If you're using iterators to cook up a solution to a problem that could have been done otherwise with less code and more readability, the iterators need to go.
I think a reason why the definition of iterators looks like that is to discourage people from using them for no reason :))
I love map, filter, reduce, etcetera. But wtf is this syntax?
Seq vs Seq2 and all the duplicated methods show that iterators need a bit more time in the oven. I definitely like the idea though, the current iterators like bufio.Scanner or sql.Rows are a bit more painful than they have to be.
Can we just like not use them?
When I first use it in 1.22, I thought it was nice
After using it extensively, I don't think they are worth it anymore, at all
I hope they do not release them
Dunno, my biggest issue would be with chaining iterators and how ugly would that look.
That's actually straightforward, and way easier than next() based iterators.
func chain(itr1, itr2 Seq[T]) Seq[T] {
return func(yield ...) ... {
itr1(yield)
itr2(yield)
}
}
Or maybe because Go generics are limited not fully supported, and it's a good idea to avoid building projects on top of incomplete features.
Iterators are not even that bad tho
a yield keyword like python could have been way more neat and useful.
You didn't mention the upside, which is that this kind of implementation is most performant. Also, you'll probably never write iterators yourself, but use libraries.
IMHO they could just add the “iter” pkg as some kind of generic helper that gets a callback generic function to process each iteration…
Not really liking the concept of messing with internal components of the language such as the range keyword.
BTW does that mean it’s kinda breaking the code and public repos would need to add the go version build tag for supporting not using this?
code built before 1.23 would continue working as expected. it'd only be breaking if a library which implemented iterators in a different way (because there was no previous standard) adopted this standard, however, that's with many features, and most of those libraries should release a v2 version of the package if it's a breaking change anyway.
I'm not sure about defining types (like map, map2, etc.) in std lib, but iterators don't seem bad.
Well, I think people overreact on the internet. Is it the most beautiful syntax I've seen? Not at all. But it's not that bad. Kinda weird, but ok
If I see this in your commit you are fired, immediately .
I think they have made a mess here. The func of a func being hiddeded is crazy. It doesn't make the code easy. Imagine throwing in a few channels into that pipe of horse poo...
Dotnet has a very clean `yield` keyoword that can return a tuple.
Why a func of a func, who in their right mind is going to remember how to do this. It feels worse than Javascript's poly promise pre 2013!
That's what happens when people want to write in Go like in Python, C++ or java. To write good Go code, you should think on Go, not haskel, rust or java. Like java-features? Go develop on java.
Please don't breake Go
This is definitely not like C++. Iterators there are also gross in different ways.
I don't get why they didn't just made it as other languages (python, javascript fot example)
All this to avoid the "language complexity" of the "yield" keyword. This is wear I very much diverge with the language developers and their crusade to keep the language as minimal as possible. They can't see the forest for the trees, and in practical terms, make it more complex with strange design patterns like this.
I think it’s pretty novel actually. Russ was able to propose iterators without the need for a new keyword. I think thats great!
Yield is a whole can of worms and could be implemented in a plethora of ways. Go has a concept of yield, but you never know about it because the language design is so thoughtful (see how channels, mutex, or any “blocking” thing works in the runtime). This type of iterator pattern is also incredibly efficient. Its pretty much syntactic sugar, whereas yield is not.
I am new to Go, Python is my main lang. Iterators are great in Python (my opinion). I agree these new Go iterators look very unreadable. Something like map/filter( func, iterable) goes so much more easy on the eye, if simplicity and readability is Go's mantra.
It is not that bad
It's horrible.
@@iatheman have you written any?
@@JamesRouzier Yes, I tried it in 1.22 with some examples. You can even use them to return errors or read from a socket, it's really powerful but it's anything but simple to implement and easy to read and write.
Powerful and horrible.
@iatheman I wrote some I found it not that bad. However, I did not do anything too complicated yet.
@@JamesRouzier There is a level of "magic" (hidden control flow or syntactic sugar) going on with the yield function (that you call whatever you want, really, it's just a func) that's not obvious at all... That's my main issue with this implementation. But it looks like the ship has sailed and we're getting this for better or for worst.
I don't even understand why you would ever need this and why this is better than just squaring the number inside of your loop.
You will not need this 95% of the time. That's why it looks like that even. It's discouraged to make lots of these for no reason. It's good for cases when you do need them, and even then it's about performance and it's the library provider problem to handle this.
@@TheMelopeus so i still cant think of a good use case tho
I think they chose a really poor example to showcase. Implementing this as a method on a struct is pretty trivial. The outermost wrapper function is IMO what leads to a double take or head scratch. Maybe it is too complicated and Im in the minority opinion here. I don’t know how I feel about the xiter proposal. That would seem to mainstream functional iteration patterns in go and make it easy to do things in multiple ways.
Damn, don't break it, i just started learning Go 😭
Same dude
Break? Nothing is broken, this is just additional features. Everything you learn will be useful. Regardless if this is added or not :)
The problem will start, if some developers add some of this things, and you have to maintain that.
Stop choosing languages by hype. Even if there are downsides or new shiny things
Still takes like two weeks to learn the language so don't worry.
Honestly, I'd like to see Go but with optional more complex features
I kind of agree, but as much as I love go, the annoying thing that I have to put up with is the lack of some of the smaller less complex features eg proper enums and missing ternary operator.
I just want them to look simple, because we are stupid.
imo JS generators ( function* ) did a better job at making them readable.
You actually mean Python generators, which JS just stole wholesale.
@@YaroslavFedevych idk maybe, I never touched python
I'm cool with it because generics and iterators are meant for library makers. Not weak minded people like me. Unless the language becomes a literal drag in Air on file save then I'm unburdened by Google's decisions. Every language has issues and this one isn't it.
As C# programmer that never had any experience with GO I can see that:
1) GO is unreadable.
2) They trying to introduce something that in C# is considered legacy since 2007.
C# is a higher-level language that already has for, foreach, yield, and abstractions/interfaces for iteration.
I don't personally like this style of iterating, but is rather meaningless comparing a higher-level language with every feature including the kitchen sink to a language whose primary design-goal is to be minimal. Ruby makes it even easier and legible than C#, does that make C# "legacy" to Ruby?
@@ForeverZer0
1) By legacy I mean delegates such as Predicate, Comparison, Converter that has been replaced by generic Func and Action and those previous are used only in legacy methods. Those helpers in 6:00 looks like similar mistake like this.
2) Being a lower-level language doesn't mean you have to have complex syntax.
3) If you have the func keyword in one function 5 times, your language is not minimalist.
You know melkey is mad when he gives heart to his own comment.
“We’ve added ‘Function Coloring’ - without needing async!”
Hmm yeah look, if we’ve learnt anything about the countless languages and function coloring issues it’s that this never works out all that clean, why adding this issue to iterators, I’ll never know 🤣🤣🤣
Range was already magic woo woo shit, but like C++ - ignore it and write C.
Iterators will be the new least used feature in go
mama i want rust iterators
People that are complaining about this feature are gonna use it anyway.
just dont use it, like generics... avoid and be happy
or do i not see the real problem here?
When you add a language feature, even if you avoid it, it doesn’t guarantee your team members will avoid it meaning you’ll have to work on code that uses the feature regardless meaning you’ll have to learn it and get comfortable with it.
@@Slax305 That's true. I try to avoid team mates because they write shitty code... just kidding
Lmao I love how the Go team builds a half baked feature that is way worse than what other languages have (I'm not a C# fan, but compare this to IEnumerable for example), probably because it was simpler to implement and users complain about what? Skill issues.
generics implementation in Go is half ass, that's why i dont use it.
Syntactically not pretty, but functionality wise very welcome. The majority of time you will be combining the standard library ones.
The iterator implementation is so bad, because go generics are bad. People are not using generics because they are so limited. You can see that clearly in the xiter func spam. If go had actual generics we would have an actual tuple type that would take an arbitrary number of elements, which would remove the need for all the *2 funcs and types.
I prefer the rust iterator 😂
If you don't understand iterators I simply would not allow you to write production code. Find another job!
It looks like python now. Which is a real bummer.
Just because language concepts exist and are useful in other languages doesn't mean they need adopted by all languages
The problem is that libraries that needed iterators implemented them in their own way, looking completely different package to package. It's not like Go 1.23 iterators were implemented to solve a problem that didn't exist -- it is definitely nice to have a standard (not necessarily saying the way they implemented is good or bad).
I wholeheartedly agree
Glad I picked rust
This package has strong python wannabe vibes.
I secretly think this it's going to be great, sorry!
Iterators are a waste of time.
This has to have been a long time coming. I abuse the heck out of generics, if you use lots of external libraries they are a must(Any interface{} fans here?), why not have iterators too?
But dude why can't we just have a generic parameter count... Seq, Seq2? Why not Seq3? Also, why is it called Seq? Could just be a Sequence and a Mapping. I thought we like descriptive names in go... One more thing, wtf is that yield() call, that's wild. This is recursive?
It serves two purposes.
To let you know when to break out of the loop.
Also, to run the code in the loop.
I think go is not the language for you brother
@@1234Meiam I'm pretty sure you've got no idea about that.
@@JamesRouzier I understand what it does, but I have no idea how it actually works.
@@nexovec May be. But abusing interface{} tells me that go is not the language you need to use, I don't know what warrants the use of it that much, would love to hear it though.
This is wild to me that people are complaining about iterators. I was pissed off when i found out go did not have iterators. I don't understand how iterators add complexity if you don't like them dont use them its simple as that.
You wish it were that simple. Working on a team adds all sorts of complexity and this is going to be one of them.
Like
Like2
I think I will see the same OOP in Golang as in Java)))
Any language that lives long enough will become Rust
Rust changes so much, even Rust will become Rust as time goes on.
It’s so hard to read. Better to just not have them, imo.
Go++
Hate it