Replying to Avatar Tristan Brice Velloza Kildaire

The Go designers, the original ones are indeed balls deep in that 40 year + language design experience indeed.
Avatar
ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

yeah, the longer i use #golang the more i get it too...

the only thing i warn people about go is that maps and slices are funny with concurrency and be really careful about where you put channel operations and goroutines

there can be a tendency to go nuts on those two things, i think every go programmer goes through a phase of it

oh yeah, sometimes some people go nuts with interfaces - don't make them unless you already have a concrete type, or a plan to make multiple types, more often you don't need them and they create an unhelpful layer of indirection

Reply to this note

Please Login to reply.

Discussion

Avatar
ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

the usual trigger for making interfaces fro me these days is noticing that i just made three sets of methods for types that were the same, then i am facepalm

Avatar
Tristan Brice Velloza Kildaire 1y ago

Yep! Same

Avatar
Tristan Brice Velloza Kildaire 1y ago

Slices have to be handled carefully in D to, or well by carefully I mean one must think when using them.

Avatar
ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

yeah, i remember when i first used a language with dynamic arrays

i kinda prefer static arrays to be honest, i always look at the code and think to myself "is this probably going to need a reallocation?" and try to avoid that

Avatar
Tristan Brice Velloza Kildaire 1y ago

Defs agree!

The only times I have interfaces is when I know there are a few classes with behavior I need via an interface.

Well, other way round. Describe a behavior and implement it in many place.

Avatar
ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

yeah, there is definitely use for it... i just implemented a binary codec recently for database index keys, it is way cleaner than the previous offset laden code full of wordy and error prone constants (literals even) read and write are two examples that often come up... interface methods also tend to come in pairs, in general, not always... and yes, interfaces need to be small... there is an interface in my current project that i think could do without one idiotic method that doesn't do anything actually - an init function... another principle of #golang is to design structs so the zeros are reasonable defaults if they aren't, you can also handle that as a function called from methods that need a value other than zero to set the value to a reasonable default, then the interface is cleaner and the programmer can just throw these things in