Gothon Library to simulate useful Python methods

[Andres Fernando Baron]

Hi !
A few days ago I wrote about a library that will use the power of generics in go ˆ1.18 to emulate the most common and practical Python methods, such as handling lists, dictionaries, heaps, etc. I put forward a bit of code for the slices and recreate in a generic way the handling of lists that we have with python. 
Some next steps are to recreate the Heapify library https://docs.python.org/3/library/heapq.html , dictionary methods and support set operations (w3schools.com/python/python_sets.asp).
If anyone would be interested in joining with code or feedback, you all are more than welcome.
Link to repo is : https://github.com/abaron10/Gothon
Thanks!

[jason white]

Hi Andres, 

If I can provide some feedback here, I see what you're going for, but at the same time using a library like this would defeat the point of using Go in the first place. Not only is it not idiomatic Go, but it adds an unnecessary level of complexity and abstraction to any codebase that consumes it. Applying an automatic decrease in efficiency and performance as well, right off the bat. Not good.

I would recommend to just use what's available in Go already, if you want to use Python, use Python, but if you want to use Go, use Go the way Go is intended to be used. Don't overthink it, the more you try to make Go like other languages you may have experience with is only holding you back from learning how to use Go. This ultimately applies to any new language you learn as well. 

As an FYI, here's a great set of examples from the GO WIKI on GIT on how to use slices efficiently:

https://github.com/golang/go/wiki/SliceTricks

I'd imagine you learned something whilst writing this library, which is always great, but I would encourage you to rethink why you think you need it in the first place.

Have a great one!

-Jason

[TheDiveO]

small note here about the package naming -- to be taken with a larger grain of salt, as usual: you repeat and thus "stutter" on "Gothon/gothonSlice". I've looked into some existing slice generics examples that now pop up like mushrooms after a warm shower. They tend to simply stick with "slice" or "slices", even if this is deemed a *cough* generic name (pun might be intended).

Otherwise, as Jason White already said: don't expect too much interest in your work, but see it as an experiment. Of course, we might be proven wrong and then you'll see interest in those kind of helpers. However, be aware that you can easily considerable performance and then the main benefit would be to be more welcoming to Pythonistas at first, before having to refactor code to become more "native" to Go.

When I was coming from Python some years ago (and I still like Python!) I came with the explicit idea of "don't look back", dive into the Go ecosystem and learn their patterns first. Only with good experience, start to bring in things where Go might benefit from Python, but don't try to emulate P on G (or any other X on Y), unless you somehow need to lift-and-shift old code. Which rarely is a good idea, unless you have significant monetary investment and gain in doing so.

[Brian Candler]

On Monday, 5 September 2022 at 09:12:53 UTC+1 harald....@gmx.net wrote:

small note here about the package naming -- to be taken with a larger grain of salt, as usual: you repeat and thus "stutter" on "Gothon/gothonSlice". I've looked into some existing slice generics examples that now pop up like mushrooms after a warm shower. They tend to simply stick with "slice" or "slices", even if this is deemed a *cough* generic name (pun might be intended).

You probably also want to look at these:

https://github.com/golang/go/wiki/SliceTricks

https://ueokande.github.io/go-slice-tricks/

The idiomatic way to do 'extend' is a = append(a, b...)

For Index, there are other libraries available, including https://pkg.go.dev/golang.org/x/exp/slices#Index - the code is trivial though.

For sets, unless you have special performance or space requirements, the go-to approach is to use a map with empty values.  It doesn't have to use generics, but it can:

https://go.dev/play/p/Cvy4fWdbYJj