Go Iterators Are Bad

look at this why people are angry over

Go Go's 1.23 iterators by the way I was

very excited about uh Go's iterators I'm

very very excited about it and ginger

bill is Awesome by the way Ginger bill

is going to be on the stream here

shortly but I'm very very very excited

about iterators for those that don't

know what makes this great is that if

you're programming some uh some go which

you know you do from time to time um you

will be able to do something like this

if I were to go to uh main.go here we'll

just pick any of them I will be able to

have some custom struct and I'll be able

to go for you know my custom struct and

do like value or uh K value in range you

know my struct which is super cool like

that's a really nice feature we're

getting good features like go is

officially becoming a 2016's language

which is which is which is a good year

okay it's a good year so I'm very very

excited I looked at him yesterday it

looks great to me I'm not sure what the

problem is yeah I actually want to see

this problem so I'm actually very

excited about this by the way I did lose

my voice at open saw so forgive me hey

forgive me please it's hard to talk I

can't scream today we can't get into

things I want to get into things but I

can't cuz if I do I'm going to lose my

voice even more Oh I thought my sound

was low no no no no yeah Ginger bill is

very very smart no this is based on but

completely Rewritten from a Twitter post

right here okay so we'll open that up

and look at that tldr it makes go feel

too functional rather than being an

unabashed imperative language isn't go a

fairly functional language to begin with

you have first class functional support

or first class functions we'll see we'll

see I saw a PO let's see let's see I

recently saw a post on Twitter showing

the upcoming go iterator design for go

1.23 August 2024 from what I can gather

many people seem to dislike this design

I wanted to give my thoughts on it as a

language designer so bill by the way

Ginger bill is a language designer and a

good one the merge PR for the proposal

could be found here it has an in-depth

explanation of the design explaining why

certain approaches were chosen instead

so I do recommend reading it if you are

familiar with go okay here's the uh

here's the example from the original

tweet all right so backward H takes in

an N uh we have this as an array of

these NES functional it's a that returns

a function that returns a function that

takes in an INT and an e and returns a

bu then you return function yield Funk

bu 4 I this one and yield it out okay

this is where cleanup goes okay uh we

have this we have this and we can range

backwards on S there you go see we can

range backwards on S which is pretty

cool right like this is this is pretty

cool uh I I I like I immediately agree

that there's a lot of effing syntax

there to explain this why yeah curring

yeah we got some curring going on this

is a lot of effing syntax right here

just to say something still easier to

read than rust potentially potentially

uh this example is clear enough in what

it does but the entire design of it is a

bit crazy to me for the general majority

uh use case from what I understand it

appears that the code will be

transformed into something as the

following backward s function int L

string bull format this one return true

return false would be the equivalent of

an explicit break okay okay this means

that g iterators are much closer to what

some languages have for with the four

each method yeah dot for each in

JavaScript and passing a call back to it

and fun fact this approach is already

possible and go uh before 1.23 but it

does not have syntactic sugar to use

with the four range statement yeah I'll

try to summarize the rationale for go

1.23 iterators but it seems that they

are wanting to minimize a few factors

make the iterator look SL act like a

generator from other languages thus the

yield minimize the need for sharing too

many stack frames allow for cleanup with

defer reduce data being stored outside

the control flow I do like the allowing

for clean up with the fur I think this

was pretty nice I at least I like that

idea as Russ uh Cox uh explains the

original proposal not regarding push

versus pole iterator types the vast

majority of the time push iterators are

more convenient to implement and to use

because setup and tear down can be done

around yield calls rather than having to

implement those as separate operations

and expose them to the caller Direct use

including with Range Loop of a push

iterator requires giving up sto uh

storing any data in control flow so

individual clients May occasionally want

to pull or want a pull iterator instead

any such code can trivially call pull

and defer stop I generally prefer pull

over push like generally speaking I

think pull over push is the way to go

and why I think it's the way to go is

that you can create really beautiful

like lazy items which makes it really

really nice uh as opposed to like kind

of push it's like you kind of you have

to create like these buffer zones and

all that for it and then you kind of

have to do a lot of um you have to do

like often copies are involved when you

do that so like a JavaScript would be a

push when you do a DOT map it executes

the entire array across that dot map

whereas when you do a poll it grabs the

first value it goes through the map it

would then go through the iterator or

the filter and then come out say the for

each whereas with JavaScript it does the

map it does the filter and then it does

the for each which is kind of that's the

difference between push and pull so I

generally prefer pull over push I think

it just makes it nicer in general it it

makes it it just also makes it really

easy to understand all right uh Russ Cox

goes into more detail in the article

storing data in control flow and about

why he likes this approach to design

more complex example do not worry about

what it actually does I just want to

show you something of the cleanup needed

for something like defer okay an example

from the original PR shows a much more

complex approach requiring cleanup where

the values are pulled directly all right

let's see so we are doing a just a value

only iterator and the see it's a

sequence sequence V and we're going to

return a sequence of two v's uh pair

returns an iterator over successive

pairs of values from sequence all right

we're going to pull stop one two if not

one two yield this one there we go okay

I think I get this I know he said not to

worry but yeah you just take two you

just create pairs over it okay an

alternative audo code proposal State

machine I'm not suggesting go does this

whatsoever when designing Odin I wanted

the ability for a user to design their

own kind of iterators but have them be

very simple in fact just normal

procedures I didn't want to add a

special construct to the language just

for this this would complicate the

language too much which is what I wanted

to minimize with Odin one possible

pseudo proposal I could give for go

iterators would look something as the

following backward an any uh an any

array function in pool this one return

function on break in this one if on

break or I is greater than this one this

is where cleanup goes else we do this

one we return it out return it

oh I think I see what's happening here

we're just assigning these oh naked

return yes these are just naked returns

right do a little naked return on here

we get uh index uh Elum and okay and

then just return it I know I hate I I'm

not a naked return guy Ginger Bill Dirty

Man Dirty Dirty Man with that one this

pseudo proposal would operate like this

yeah okay generally like it uh this is

from what this this is similar what I do

in Odin but Odin does not support stack

frame scope capture closures only non-s

scope capturing procedure literals

because go is garbage collected I see

little need uh to no utilize or to not

utilize them like this the main

difference is that Odin does not try to

unify the idea into one construct I know

some people will think this approach is

a lot more complicated it is doing the

opposite of what Cox prefers with

storing data in control flow and stores

the data outside of it but this is

usually what I want from an iterator

rather than what go is going to do this

is the problem it removes the Elegance

of storing the data in the control flow

the push pole distinction that Cox

explains yeah so I assume what he's

trying to say is that notice that you

have to store the data here and you use

that as control flow as opposed to um

having it right here which is like you

don't you don't store it outside of the

function you actually store it right

here in the ah oh gosh you store right

here in in the actual this one and then

you iterate over it and so makes like a

just a small difference but I I mean

this is probably a bit closer to what

rust does rust you typically have a

struct that is your iterator that

implements iterator in which contains

these items and then every time you call

it it's able to operate over that an

iterator having a state tracking uh

where it's at doesn't sound bad yeah see

NE I I don't think it sounds bad it's

it's it for me it's very very simple to

implement that I I know I understand it

much easier that way at least it's very

easy to implement in my head uh I'm not

very let's see I am very much an

imperative programmer and I like how

things actually execute rather than

trying to make uh it elegant looking

code so the approach I wrote above is

fundamentally a about thinking with

regards to execution I don't know what

NB is NB the type uh class interface

route would not work and go because this

would not be or let's see because this

would not be an orthogonal design

concept and actually be more confusing

than necessary this is why I didn't

originally propose it different

languages have different requirements as

to what works with them Go's apparent

philosophy the approach in go 1.23 takes

uh or takes seems to go in the face of

the apparent philosophy of making go for

the general frankly mediocre programmer

okay you know like I like go bro can we

just take a second here hey can we just

take a second here yo I'm officially a

mediocre programmer Google let's

go let's go oh baby oh baby oh baby

let's

[Music]

go Karen get out the

Champa it is official I am mediocre I

mean that's a huge upgrade you should

did you see what Google originally said

not good it's not looking good but now

it's looking

great literally better than Ken Thompson

inventor of C can't commit to see me

boom middle of the pack putting down W's

left and right can I get a pay rise pay

rise I wish I could be mediocre I know

one day you're going to be mediocre Shan

of the dev not there yet you're not

there yet but one day you will be

mediocre is that an upgrade from key

sheater yes yes it is absolutely mid uh

we're definitely um I'm going to just

take that and we're going to Tweet this

this feels like a great things um Ginger

Bill I'm finally a mid programmer I love

it I love it oh I'm love I'm so I'm so

happy right now this is such a good

article uh it's not elitism by the way

for those that don't understand go is

designed so that anybody can be

successful like you don't have to be

smart to use go okay and what I mean by

that is try Zig for a moment and realize

that there's programming languages in

which you need to think about everything

and there's programming languages in

which you can be very productive in like

I'm getting good at Zig I'm actually

getting what I would consider to be

pretty pretty dang good at Zig but that

doesn't mean it's easy like I'm building

things I'm able to do stuff I feel

pretty fast at it now I know how to make

interfaces vtables all that kind of

stuff but I'm not fast like I am with go

right

go is just like you don't even have to

think you just don't you just build it

and when you don't like something it's

pretty easy to patch over what you've

goofed up and then add on top of it and

when you don't want to do that anymore

and you want to fix it it's pretty easy

to fix and refactor and move on grug

want mid yeah I'm a I'm a real mid I'm a

mid man I'm a midman go is the fluffer

language for mediocre DS yeah I like it

that's why I love Ruby is so fast and

easy to makes everyone so productive

yeah I mean I I never discount the

productivity argument generally speaking

I think that when people say that you

use a language in which is really prod

uh productive I agree but if you say

that about JavaScript I just disagree

with you as a person that's probably

better than you at JavaScript by a by a

country mile like by a long country mile

by a New York block it is a very hard

language to be good at and to write well

and I know people think that it's easy

that's what makes it so Insidious

anyways hello Prime well hey nice look

at all those little Yar Hearts anyways

the quote Rob Pike the key point here is

our programmers are are googlers not

necess they are not researchers they

typically fairly young fresh out of

school probably learned Java maybe some

C or C++ probably learned python they're

not capable of understanding a brilliant

language well okay well I Rob I I really

always hate these kind of things uh when

someone says they're not capable I'd say

the job that they're doing does not

require right big difference big big

difference thank you for all the booty

thank you for all the dumpy baby I know

it's very elitist a brilliant language

but we want them to let's see but we

want to use them to build good software

so the language that we give them has to

be easy to understand and easy to adopt

um yeah I mean go is very easy to

understand and very easy to adopt it's

in fact as somebody who only gave go a

real shot this year like a real shot

built a really hard program and go I was

shocked at how how nice the experience

was because the types are so simple I

thought I was going to hate it like I

did I genuinely thought I was going to

hate it but I'm fine eating kale

eating a mid language doing a mid

language because I'm like ah whatever

it's going to be you know I I want to

say I want to give it a shot you know

but now that I've done it I realized the

beauty in the grug nature of it all see

is easy to understand now try building

something complex with it yeah I know

many people are offended by this comment

but it's brilliant language design by

understanding who you are designing the

language for it is not insulting but

rather the matter OFA statement as go

was originally for people who worked at

Google and similar Industries and funny

part is that old Google Google 10 years

ago they like they did they were known

for hiring pretty smart people you might

be a better and more capable programmer

than the average googler but that

doesn't matter there's a reason people

love go it's simple opinionated and most

people can pick it up very quickly yes

uh however this iterator design seems

out of character to go especially for

someone like uh proposer Russ Cox

assuming that his let's see he was

actually the original proposer On The Go

Team it makes go a lot more complicated

and even more magical too I understand

how iter system works because I'm

literally a language design and compile

implementer it also has the possible

issue uh to it won't be a well

performing approach either because of

the need for closures and callbacks yeah

I'm very curious about the closure and

call back thing because that is not a

very typically not a very good um

performance I learned go before I

learned HTM X damn really is it called

go from Google probably I mean can we be

real here I know it's called goang but I

assume it's just Google Google Lang uh

maybe the argument for its design is

that the average go programmer is not

meant to implement iterators but just

use them and that the majority of

iterators that people will need will

already be available in go standard

library or by thirdparty package itself

so the onus uh is put on the package

writer and not the package user fair I

think that's pretty fair uh I mean I the

thing I do like about it it it's going

to unlock a lot of cool behavior and so

they already put in generics they

already have this like generic slice

package and Maps package which is super

nice and now they have this so I I I am

happy in the direction of go like I am

I'm very happy in the direction of go

and I hope they keep making really good

direction changes like this I think

they're just realizing that you H you

can't make a language so simple that

people need to rewrite everything every

time you need to make a language simple

enough that everything you need to write

should already be written and provided

in the standard library right I think

that's like a pretty good approach and

that's largely what they've done Lua

Lu's are very simple language but it's

actually a really powerful language it's

really easy to write well uh this is why

I think a lot of people seem to be angry

over the design it goes against

everything go was originally meant to be

in the eyes of a lot of people and it

seems like a really complicated mess I

understand the beauty that it looks like

a generator with the yield and the

inline code approach but I do not think

that is uh necessary in the vein of what

go is to a lot of people I actually wish

they would have gone much more the rust

route honestly have some sort of imp

like iterator uh function interface that

you could Implement and then you can

just range over it right if you provided

a next and is done or whatever you know

whatever way you want to do cuz they

have optionals I I mean personally I

think that that would have been

fantastic I mean I know it could have

collided with other things and maybe you

had your own iterators that had

something similar and maybe there that's

why they're kind of avoiding it is by

having this really complicated way you

can do a functional way to do it I just

I think doing an interface would have

been so much nicer just like string

right if you do formatting you can just

have string and if you implement string

it just works in the formatting which is

really really nice go does hide a lot of

how the magic Works under the scenes

especially when garbage collection go

routine select statements and many other

constructs however I think is a little

too magical in that it Expos the magic

to the user a little too much wilst

looking overly complex for the average

Co programmer I do think that this like

generally speaking the yield side of

things like I honestly don't even know

what it's doing I'd have to go read

about how this works because yield

usually is like a replacement for return

but it's like now a function but it's

you have yield Funk this must be the

name of the function called yield maybe

you can call it anything I not like I

assume I've never seen uh uh what's it

called named functions this way so

that's what I assume it is is this just

simply means hey it's time to be done

maybe I'm not really sure or you yield

out the value to the loop yeah that must

be what it is this yields out the value

out to the loop right the word yield

kind of tricks like tricks me here this

is yeah okay okay so this must be the

one that's doing it okay I see it I see

it I see it I see it it just feels

complicated right it yield is the loop

body basically yeah it just look it it

just feels complicated for me because my

brain had to like um at least the

examples my brain has to stop using

yield in the word that I or in the way

I'd normally use the word yield and use

it different yeah they should have

called it Yeet or Loop body or Loop

brain what's that I don't think I have

one of those you probably don't did you

ever see that uh this is why it's

confusing to me yeah that's why I got so

confused at first now now I understand

it this makes perfect sense right this

is literally just the function you're

just calling the function if that

function returns false you return false

which is kind of a generally interesting

thing I wonder how this works with

breaking out of you know what I mean

like can you do something like this uh

let's go back to the go I wonder if you

can do something like

uh do something with like

outer and break like a break outer

however that looks you know like just

sounds confusing right I assume that's

it it just all works but still it feels

confusing you know what I mean yeah it

has a go-to effectively yeah it has a

go-to cuz you have to break on the

inside and the outside so okay you can

okay isn't that a go-to that is oh boys

that's a go-to hell yeah go-to

considered amazing and you can screw off

uh all right here we go maybe the

argument is for the oh yeah we already

read

that uh the other aspect where people

find it confusing is that funk return uh

that returns Funk that takes a funk as

an argument and that the body of the

four range is transformed into a funk

and all let's see and all breakes and

other Escape control flows are converted

into return false it's just three levels

of procedural deep which again feels

like functional language Des rather than

imperative language design okay no I'm

not suggesting they replace the iterator

design uh what I am suggesting but

rather a generalized iterator approach

may not have been a good thing go in the

first place oh really for me at least go

is an unapologetically imperative

language with first class CSP like

constructs it's not trying to be a

functional like language iterators are

in the weird place where they do exist

in imperative languages but they are

very functionally but but are very

functionally as a concept iterators can

be elegant in functional languages but

in some many unabashed imperative

languages they always feel weird somehow

because they are being unified into a

separate construct rather than

separating out the parts of it I can buy

this initialize iterator destroy yeah

this is a very yes okay actually I I I

really do like this go relies heavily on

closures fine it does rely heavily on

closures but it's still it it is a very

imperative language typically if you're

using a lot of closures I would be a bit

surprised I and what I mean by that is

that means the only thing I can really

argue in my head for a lot of closures

that statement is that you must be doing

a lot of G Funk make a request that's

outside the loop and a weight group and

then or an airor group and then get all

your responses back and call it a day

that's at least how I cuz like the thing

I built with a bunch of bite processing

and compression and all that there's not

there's no closures right closures just

don't really happen in non highly

parallel SL uh whatever the other word

is I don't know why I'm blanking on it

uh concurrent

uh programming recently I heard about

Lambda calculus oh gosh oh gosh here it

goes here we go again here we go again

what's an imperative language I go a

then I go B then I go C then I go D then

I go e right yeah yeah yeah yeah yeah

yeah yeah yeah yeah let's see aside

Odin's approach as I alluded sorry my my

voice is still a little bit lost so

please forgive me then I go P then I go

a lot of p PE lot of p PE yeah uh no F

no effing no effing around here aside

Odin's approach as I alluded to to

previously in Odin an iterator uh is

just a procedural call where the last

value of the multiple return is just a

Boolean indicating whether to continue

or

not and because Odin does not support

closures the equivalent go backward

iterator in Odin is a little uh more

code to type note before people say that

looks even more complex can please

continue reading the article most Odin

iterators are not like this I would

never recommend writing such an iterate

iterator where a trivial for Loop is

preferred for both the reader and the

writer all right backward iterator see I

I like this approach already which is

this right here I liked the struct I

this is a very Russ does this too having

a struct for the iterator I like this

approach backward get the procedure you

get the backward iterator you give it a

slice it gives you backward iterator it

starts right here see the states stored

on the struct I see I prefer this by far

like absolutely there we go this makes

10 times more sense to me it just does

if this is greater than this we do this

else return yeah naked returns I hate it

I hate it there we go this is beautiful

to me this actually looks much simpler

than the go one I know like to me uh if

we go back up to the Top If I compare

these two things like I find this I'm

just going to go like that if we're

going to be real even though this one is

much more uh shall we say concise I find

it to be way simpler to

understand right like this is much more

concise you can see it in a small screen

but the the amount of function that

you're trying to Funk yourself with is

very right it's a it's a function that

returns a function that takes in a

function that returns booing right

whereas this one it's just like ah I

have my struct this is very

onedimensional I understand ah I can

make one by just simply doing that I can

iterate very easily by saying am I

greater than or equal to zero awesome do

that else you know return like this is

this is just extremely simple code

there's no no one has a question about

how it works despite me I have no idea

what any of this like I don't understand

this syntax at all but this is so simple

to follow I'm shocked that uh go did not

do it this way it just feels better to

me right it just feels it just feels

better you know uh let's see I'm a funk

uh playing a funk I'm a funk that's

pling a funk disguised as another Funk

oh my gosh oh my gosh oh my gosh dude

you just you literally just accidentally

made a great meme we're going for it

let's go uh what is it Tropic uh

Thunder uh memes uh generator let's see

what we got yeah generate that one save

the image go to Twitter go 1.23 uh uh

boom MIT license Bam Bam I'm a funk

playing a funk disguise is another Funk

dude that is so good that is so good

thank you thank you for your service

memes is speed yeah speed speed running

a meme quick speedrun of a meme pleasure

to be of a service TS clay you're a

beautiful man great movie too many funks

given D just so many so many anyways all

right let's go back to this I by the way

I'm shocked that Google didn't do this

or go didn't do this I I I still am

shocked I don't like I honestly in my

head this is actually also by the way

just to be fair this is also how async

iterators work in JavaScript because

it's the only sensible way to make async

iterators hey Ginger bill I was just

letting you know Hey look it's the

writer of the article Ginger I was just

defending you saying that like this is

the only sane way to make iterators I

think I I don't understand why you

wouldn't require a struct that

implements an interface and that's that

right cuz that it that feels very if

you think about it like go always offers

ways for you to implement if you want a

reader it's just a struct that

implements an interface you want a

writer it's just a struct that

implements an interface you want

something that can be stringified you

implement the string interface so it's

like it's shocking that it didn't just

follow all the other things now the

difference is the state Machine versus

story yeah I know and I I I hate this

argument because a struck State machine

is the only in my personal opinion is

the only sensible way to make an

iterator the this feels very confusing

to me right this feels this this feels

confusing just generally speaking

because I don't want to be a funk that's

disguised as a funk that is a funk any

that or I'm a funk that is a funk this

disguised is a funk it does not Shock me

why they uh didn't make it an iterator

because it doesn't actually work because

the iterator and go would have to be

extremely generic okay ah yeah okay okay

okay fair and factual I I can understand

I can understand that argument for it a

lot of funking going on yeah all right

anyways this does not appear to be more

complicated than the go approach because

or it this does appear to be a lot more

complicated I'd actually fully disagree

this appears to be extremely

one-dimensional and a baboon such as

myself a grug brain Dev this makes

perfect sense I get it this is what I

would say does not require 200 IQ this

is what I think requires 200 guy IQ

honestly I do think it's more

complicated uh than the go approach

because it requires you to r a a right a

lot more code however just use co-pilot

just use just use copilot boiler plate

mentioned boiler plate mentioned um

however it's actually a hell a lot

simpler to understand comprehend and

even faster to execute the iterator does

not call for Loops body rather the body

calls the iterator I know Cox loves the

ability to store data and control flow

and I do agree it is nice but does not

fit well with Odin uh especially with

the lack of closures because Odin is a

manually uh memory managed language an

iterator is just syntax sugar for the

following yeah that's Lally all it is

that's why that's why uh in Zig right

now when you look at Zig I created for

for the game I created an FPS iterator

right I can't just like call hey four

range on my iterator or on my FPS

iterator but it does actually work

really really nicely to be able to have

something that I can be like hey sleep

the appropriate amount give me the Delta

and then the next time it's called

depending on how long my game Loop took

it can then sleep for the appropriate

amount of time it's a very simple kind

of iterator is type pattern Odin catches

my eye lately Odin's a very interesting

language Odin's approach is just

removing the magic and making it

extremely clear what's going on

construction and destruction must be

handled manually with explicit

procedures and that iteration is just uh

a simple procedure which is called each

Loop all three constructs are handled

separately rather than managed into one

confusing thing like go yes yes I do

agree that uh I also the followup

agreeing uh is that the cleanup code

will make it much more confusing looking

cuz if you have any level of cleanup

code that's more than one line there's

just like a lot that goes on right here

all right Odin does not hide magic Wist

go approach is actually very magical

Odin makes you uh handle the closure

like values manually along with

construction and destruction of the

iterator itself Odin's approach also

trivially trivially allows you to have

as many multiple return values as you

wanted to a good example of Odin's core

encoding CSV package where the reader

can be treated like an iterator by the

way fun fact for those that are

wondering CSV does not have an official

standard there is a RFC but there is no

official encoding of a CSV how F how

effed is that how effed is that CSV is a

good aful standard yeah I know how like

screwed is that that there's like a

thing that people use all the time that

actually doesn't have a standard have

you ever used it

where we've had some csvs produced when

I was at Netflix dumping data from uh

our big dat data into records worked

with like half of the CSV parsers the

RFC for CSV had an extra comma in it so

it couldn't be read in

Excel isn't that just so good isn't it

just like isn't CSV just such a funny

funny thing that we deal with it's

actually the like literally the world's

worst format and yet there it is drink

some water PR no I lost my voice

Microsoft Excel csvs do this for

non- ancy characters damn dude that's so

it's just so effed up and coding

procedure reader string index error more

bu okay nice aside C++ iterators I will

try not to get into huge rant about C++

iterators in this article everything C++

did for iterators C++ is the only

language in which asks me would you like

me to install co-pilot and for me to say

yes C++ iterators are much more than a

mere iterators wilst at least Go's

approach is a mere iterator I completely

understand why C++ iterators do what

they do but 99% of the time I just want

a mere iterator not something that has

all the AL algebraic properties that I

that allow it to be utilized in more

General places dude everything with C++

iterators felt very hard they feel

extremely difficult lost your voice at a

redneck lawnmower trailer pull

competition I they like unironically a

redneck lawnmower trailer pull

competition is exactly something that

open sauce would have uh for people who

don't know C++ very well an iterator is

a custom struct class uh which

requirements is to have the overload

operators to make it act like pointers

historically a C++ iterator would look

like this ah isn't that just lovely

don't you love a good oldfashioned begin

not equal end begin Plus+ ah look at

that beauty ain't nothing like it you

got throwing a little const in there a

little const Auto

[Music]

reference dude I hate them uh and would

be wrapped in a macro before C++ uh 11

range Loops yeah the big classic thing

to do is you make apparently you make a

for each Macro and then you use that to

do your actual iteration before C++

arranged a four Loop syntax and auto

became a thing the biggest issue with

C++ iterators require you to Define five

different operations at a minimum the

following three operation overloads

equals does not equal Plus+ pointer uh

along with two Standalone uh procedures

or bound methods which return in

iterator value begin and end if I was to

design a C++ mere iterators it would

have to be as simple as a struct class

that calls an iterator next or something

and that's it yes it does mean that

other algebraic properties are lost but

I honestly do not need the ever for any

problem I am working on when I'm working

on those kind of problems or those kinds

of problems they always be either a

contiguous array or I implement the

algorithm manually because I want

guarantee the performance will be good

for the data structure however there is

a reason I made my own language Odin

because I completely disagree with the

entire C++ philosophy and I want to get

away from that Madness does anybody know

what language in uh inspired C++ anybody

we've had a couple people know it simula

simula uh what is that nigar right it's

it's nigar and gosh I can't remember

anyways simula called it very great

story by the way how simula was created

very cool story very very very very cool

story uh they just it's actually simula

both was born and died on the fact that

it was a simulation language trying to

be a general a general programming

language it's kind of s it's kind of sad

hey thank you very much Gucci algo 68

Supremacy yeah so they they compiled

down to algo but eventually had the quit

doing algo due to a stack one thing that

was really cool about simula is that

there was no such thing as this idea of

storing data on the stack and coming up

doll that's right doll yeah nigar

niggard and doll and coming up with this

idea of storing a bunch of stuff on the

stack was like extremely first off it

considered distasteful gross but second

off it just like wasn't really done and

they like came up with it pretty cool

it's super cool like a genuinely super

cool like story uh C++ iterators are a

hell of a lot more complicated than go

iterators but they're much more direct

with the local operation at least with

go you don't need to construct a type

with five different properties in

conclusion I feel like go iterators do

make sense with the design principles

but to them uh let's see applied to them

but seem antithetical to what most

people view go as being I know go has

had to get more complex over the years

especially with the introduction of

generics which I do think uh are

actually welld designed with only a few

syntax quibbles yeah I mean everybody's

still the problem is is every every body

wants one thing to really make iterate

uh uh generics awesome which is Method

receivers but it does appear that you

can you can get around some of that

because I know there's some generic

libraries in which I don't even

understand how they work but they they

do work uh but the introduction of

iterators of this feels uh of this ilk

feels wrong I think the short of it is

that it feels like it goes against the

apparent philosophy of go that many

people believe coupled with being very

functional way of doing things rather

than imperative and because of those

reasons I think that is why people don't

like the iterator stuff even if I

completely understand the design choices

made it doesn't feel like what go

originally was to many people maybe the

concerns of mind and others are

overblown and most people will never

actually Implement them and just use

them and that them being this over

complicated to implement second to last

controversial take maybe go needed to

gatekeep even more than just tell the

functional Bros to go away and stop

asking for such features which make go a

much more complicated and complex

language last controversial thing by the

way I do like this you should this is I

mean I'm sure Bill I'm sure Ginger bill

will 100% say this that his language

likely has uh likely has uh a bunch of

people asking for things that he has to

say no to constantly and that there's an

entire collection of people that want

Odin to probably look like rust or look

like go or look like zigg or look like

Fillin the blank and he has to say no a

lot I dislike go iterators there I said

it I I mean I want to dislike him but I

also want to use them I mean that's

where my big problem really comes down

too because I find myself doing dumb

things now you say no a lot not not

surprising grug's favorite uh word is no

yeah what language is fill in the blank

it's a new language you wouldn't

understand here's an example of what I

what I really want uh if you look up

let's see um there you go I have this

idea of a virtual box which is just a

quad tree that you can replace and uh

replace the underlying buffers for and

what I had to do is I had to do a um I

created this whole next idea and I had

to create like my own iterators so it's

like it has these bite Ator results

which has this and then like I had to do

all these things and when I want to use

this I have to do things like this I

have to like range over certain things

in a very annoying way that I really

hate because I can't just simply do it

well right like look at this at the four

forever get this then I have to do that

so it's like I want I want that because

when I get the result and the result is

done I have to like manually break I

just want something that I can make a

struct that I can walk with you know

what I mean I like that I like the next

I like done make it easy anyways I don't

know go iterators feel really clever

which I think people feel is anti-g

goang which is another way of saying

What ginger bill was saying that's

probably Fair that's probably really

fair yeah but simultaneously I read

someone else's code and say I hate this

yeah I think reading someone else's

iterator code is going to be in

intensely more difficult right intensely

more difficult I I actually really agree

with that reading you pick careful now

hey Prime Thor told me uh your deep Dart

Secret your stash is green screen CGI on

your face and not real the name is the

stash is actually real buddy don't don't

try that don't you Thor's just angry

because we got a thousand people to sing

him happy birthday a jet