The waitgroup verison of the example is MUCH easier to reason about. I would hate to have to debug that function.

I think a lot of the potential harm that could be caused by this feature would be almost entirely mitigated with a strong standard library implementation of many/most of the most common use cases. I think this approach is fine, and generally needed when writing a lot of iterator-heavy code. This seems fairly reasonable. What I get scared of is every sophomore programmer thinking they need their own implementation of exotic iterators, writing their own package, and it just creating a bunch more headache that would've been prevented with a simpler or more explicit approach. Not everyone should get equal access to parallel iterators! That comes with some very real risks!😆

The syntax is not the most readable, but overall, I'm in favour of the proposal. It will be a very useful tool for the Go devs and for library devs like myself. Endusers don't have to deal with the inner complexity as much and can have a more homegeneous experience dealing with ranges. It's up to the library devs to write self-documenting and readable iterators.

This is really powerful. But it feels very un-Go-y……eg it’s too much magic. Obfuscation isn’t good for Go, I know verbosity gives it a bad repo, but I also think this forces better code

Nice feature to extend loops, but such an implementation feels difficult to handle and violates the value of simplification. So, whatever the Go Community prefers :)

Go is such a cool language, I just started learning it so this was very helpful. Thanks Dreams!

Just what I needed! TY TY TY

very interesting! great quality content as always. thanks

Elliott, pls, make a step by step guide on how to use pprof professionally.

Python and C++ (modern C++, anyway) make fairly heavy use of generators (in C++ up to 20 they were implemented with input iterators; C++23 has an explicit std::generator class). It's a very powerful pattern for parsing data streams, for example. Node has had something similar since basically forever.

Nice to see Go finally getting generators. I use this pattern a lot when working in PHP, so good to see it's going to be possible to do it in Go.

This will be very nice to work with when using remote data sources - just treating them as arrays, imstead of something like 'for val, err := source.Next(); err == nil { dostuff(val) }

5:40 that moment when I'm finally stupid enough for Go.

This video is great. The explanation and animation is great. One nit, the Parallel implementation is wrong. It works because it is unlikely that that race condition will be met once you've canceled the context, but another goroutine could be yielding in as you cancel. This is a classic case where you need a mutex. A potential solution could look like this: func Parallel[T any](list []T) func(func(int, T) bool) { return func(yield func(int, T) bool) { var ( wg sync.WaitGroup m sync.Mutex cancel = make(chan struct{}) isCanceled bool ) wg.Add(len(list)) for i, e := range list { go func() { defer wg.Done() select { case

Parallel processing can definitely get interesting when hidden somewhere down in code you don't know about there is a shared resource. Something like a memory allocator perhaps.

what do you use to animate the code in your videos?

The syntax of "functions returning functions accepting functions that you can pull values from" is too complicated and magic-y. It seems like they're trying to stretch the extra-simplistic syntax of Go1, when it might be better to learn from its shortcomings to come up with Go2 But that's my humble opinion

Please create a premium course on Go. I am all ready to subscribe to it. 🎉🎉🎉🎉🎉You are probably the best teacher who teaches golang perfectly.

This experimental feature challenges boilerplate oriented programming. Jokes aside. It's more convenient for sure. In my opinion it's bad for go's simplicity.

Maybe it's the specific example, but this implementation made the code far more complicated and less obvious than it was when using the async and go func directly. It can be bad when abused.

func func func func func func

So it seems like function integrators are, generally, a good feature. The concern seems to come if an iterator implements concurrency because the concurrent logic is obfuscated behind the function. I’d love to see some high level iterators implemented by the std lib but default (or only) be synchronous. Maybe there could be a pattern to “enable” or “opt in” to concurrency on the new iterators. That way it would be obvious that they’re concurrent without having to read how exactly that iterator you’re using works

this is huge

This is great, gonna make some things way easier to do

yaaa.... it think go should bench this one. it just seems like the plot has been lost in this feature. i know go wants to be this gc lang that has first class support for concurrency to make up for that but it also promises to stay simple like c. It feels like too big of a sacrifice of the former in favor for the latter....

One of the ways I've been identifying goroutine usages obfuscated by a function call is to require a context passed in as the first parameter.

Yes, this video made me appreciate Rust even more. Thanks!

Finally Go has gotten a feature that existed in other languages like Python or C# 20 years ago.

So long as the standard library gets a good set of iterators covering most use cases this could be quite good without introducing too much magic you need to lookup to the language. My favorite thing about go is it’s dead simple and you can at a glance see exactly what the code is doing.

need this shit.

Can you make a neovim for elixir tutorial? I keep getting stuck on it myself.

Every time I'm surprised by the fact that go hasn't all the things I take for granted now in Rust and Kotlin. I need to make my own stuff too much, it feels like left-pad all over again.

if go manages to polish typing system or move to traits (which is unlikely), it'll be hands down the best language

MANN I WAS JUS ABOUT TO COMMENT IF U COULD MAKE MORE GO ADVACNED CONTENT SOO GOOOD

it seems rust is becoming easier and clear than go. The only good thing i like about go is compile time.

1. Goroutine G starts iteration, fall into default section in select and runs yield function 2. Goroutine H starts iteration and fall into default section in select 3. Goroutine G receives false from yield function and cancels context 4. Goroutine H call yield function and must panic, because it is yield after break Parallel does not work :( To fix that, we need blocking yield implementation, and await on yield channel in select

3:24 what happens if we just call wg.Done() after calling process? Ie without defer?

I don't know much about Go, so forgive this potentially stupid question: are these basically generators as defined in Python?

the less boilerplate the better IMO. makes it easier to understand and to learn

How to configure vs code so it doesn't show syntax "error" when writing iterators for rangefuncs? For running I know it's just GOEXPERIMENT=rangefunc .

I need a slice keyword because i’m slow and confuse a lot of things 😂. This feature is great but i need something more declarative where im just calling a keyword & it just works! Yes im a bad developer but swiftui’s declarative nature has ruined me and made me lazy 😂. No more imperative button code. You just call button and it’s there. I need this in a package or more preferably in the language. Ok it started off minimal but when i first used rust is was basic, now you barely see lifetimes because they have slowly abstracted them into keywords where you can literally build your own state manager with miner lifetime usage to get it done. Pack the language with declarative stuff! rant over. 😂

I think this could be really powerful but it's kind of complicated, I would use it sparingly and wouldn't introduce custom iterators to a project if I didn't have to. Old-school for loops and indexing can be cumbersome at times but even a monkey understands what it's doing.

I highly prefer the boiler plate "heavy" way of doing this. No reason to abstract away easy patterns everyone knows

So it took them just 15 years to discover iterator infrastructure... Now we wait for local-scope level for defer (that is calling on end of the current scope, not the whole function), mutual module inclusion, configurable ciphersuites in TLS1.3, modern error handling and a few others.

Still waiting for arena in go

Looks a lot like what is done in C# / Dotnet. I like the comment you mention, it's hard to tell how the underlying code is run. I would say good naming could help with this. But for love of god, please don't do like dotnet, by making everything a Task and have async / await all the way up the stack.

ah yes, features that exist in other languages for years

Did they hire a JavaScript programmers in the core team?

that's a lot of steps to run a par...

Great but I'll stick to the first implementation.

I think Go is only fun when you learn about the syntax. When I use it, I don't get it, it's like a primitive thing. Most Go developers won't update Go to a new version because they don't need it.

As it stands, I'm not sure I like it. Go's power comes from the verbosity, and obfuscating that behind a convenience interface seems more like other languages for little benefit

Nice video, but I'm too stupid to understand it.

wow, Go has finally got yet another feature that exists in other languages for like forever

While I've always been a critic of Go for being anemic in features, this one feels out of touch with the rest of the language. It shies away from Go's main idea of simplicity.

Personally, I prefer generators in the style of python for something like this (e.g. the nicety of just using "yield" instead of this strange function stuff), but I guess this'll do. I think the best part that will come out of this is watching all the gophers complaining for years about how this too complex... "What's next???? Usable Enums?!?!? Preposterous I say"

oh... they finally discovered operations on iterators...?

I hope you start making Rust content

This is not the go way. One of the key distinguishing features of go is its relentless simplicity. We don't need new syntactic sugar. What we need is more speed and less memory consumption.

Go lang and programmers slowly realizing have some more features may actually be good 😆 Watch it basically doing what other languages do but worse because they didnt accept complexity from the start and think "simplicity" is cutting corners

i have a bad feeling about this

Govascript 😅

WE DON'T WANT TO CHANGE THE WAY TO WRITE LOOPS! THAT'S THE ENTIRE POINT OF GO!

this seems to be the worst implementation of c# iterators (or js generators) I’ve seen so far. by a lot. This must be the most convoluted and arcane syntax to solve the problem in any language. I would have expected the func to return an interface that for .. range can iterate over, and you’d yield a value in your func to the consumer. the compiler would build a hidden struct that implements the interface. (haven’t written go in a while, last time, they didn’t even have a standard interface for something that you can loop over) that way you can process a stream in your func and consume each item in a for loop the moment they’re read without any expensive extra threads or synchronization (when using go routines and channels) go is such a bizarre language…

Rust will be easier to use than this.

the syntax is terrible

uu can this change it so that we don't write fucking loops no more? :D

I dont like it

Congrats on making Go look just as shitty and unreadable as Scala. Generics was such a mistake, dear lord.

They could have simply added generator rather than this ugly shit. A simple yield statement is simpler and far more readable

There is no point in using Golang, when there is Rust. Go is just worse at everything

I hate golang, for very deep reasons. From the fact that it’s shitty by design, and the fact they cover it up with “simplicity” (see clojure for REAL simplicity, and not just easiness), all the way to the fact that this language forces programmers to be primitive code monkeys that cant do anything besides write lines of unexpressive gibberish. verbosity language has the repetitiveness and verboseness of assembly, but without the benefits that verbosity gives to other languages. It has the shortsighted sloppy design of C, but without the ability to do what C is capable of. I hope they keep piling features on top of Go so that all these new features will eventually reveal more and more of the fundamental problems with the language, just like once happened with C++. Trying to evolve C is a bad idea, it’s proven by all the garbage latguages we have today. The only ones that are designed relatively well are Erlang, Clojure and Common Lisp.