Don’t bother… Python is an abomination. Perfect for one-off scripts - anything beyond that steer clear.
> On Feb 27, 2021, at 12:59 PM, Amnon <amno...@gmail.com> wrote: > > I liked Python too. > But I never really understood why anyone though that dynamic typing was a > good idea. > Or why performance was so pathologically bad, > or why they decided to make invisible characters semantically significant, > or why python applications were so fiendishly complicated to deploy, > or why there was a Global Interpreter Lock, > or whether one should use pip, pipenv, poetry or Conda... > or why over a decade after python 3 came out, a quarter of users are still > using python 2.7 > > I suppose one of the things I like about Go is that it is a simple language, > and that the > the design decisions do make sense to a mere mortal like myself. > But one day I will go back to python and try to get my head round some of the > intractable > paradoxes which have always baffled me. > > On Saturday, 27 February 2021 at 17:52:41 UTC bobj...@gmail.com wrote: > Thanks, Amnon, for that well known quote from the Python world. Python has > been one of my favorite languages for around 20 years. Even had the honor of > meeting Guido while we were both working at Google a while back. > > Please, Python, do not integrate a dependency management system into your > language and force all Pythonistas to use it! > > (Actually, my recollection is that quote was a swipe at the competing Perl > language, whose motto is "there is more that one way to do it" :) > > On Thursday, February 25, 2021 at 11:38:39 PM UTC-8 Amnon wrote: > There should be one-- and preferably only one --obvious way to do it. > > From the Zen of Python. > But also good advice for Gophers. > > On Friday, 26 February 2021 at 01:03:00 UTC skinne...@gmail.com <> wrote: > I have a wonderful video of a GO program I wrote over 5 years ago which will > not compile today due to my failure to vendor one lost module. I too had > multiple paths in my GOPATH and it varied upon the client. I consider the new > modules an improvement but the adaptation has not been without pain. > > For students who are experimenting and testing and trying things, and only > running and compiling locally, a single experimental repository with a doc.go > file and v0.0.0 module for an experimental pkg and cmd works very very well > and if they do create a useful abstraction then they can refactor and publish > the result with ease at the end of the semester after they have a mastery of > the language. > > I have a student using vscode and my vscode is complaining that my Go1.16 > installation does not have a GOPATH. > > On Thursday, February 25, 2021 at 6:36:36 PM UTC-6 mar...@gmail.com <> wrote: > Given the writing on the wall that GOPATH is going away, what I have done is > created a single module where I keep all my own code, each different > experiment in its own subdirectory. I named it "github.com/.. > <http://github.com/>.", but never submitted it to github, so in the future I > can do that without too much fuss if I wanted to. > > Having been writing Go heavily since 1.2, I find the all-code-in-one-module > approach to be the easiest so far. > > -- Marcin > > > On Thu, Feb 25, 2021 at 4:21 PM Bob Alexander <bobj...@gmail.com <>> wrote: > Agreed -- module mode is great for "delivered code". But in a personal single > machine single developer environment, all the extra complexity and manual > overhead might not worth it. I'd guess that most students and hobbyists don't > even use SCMs. My point was that GOPATH mode is good for them. > > On Thu, Feb 25, 2021 at 1:38 PM Robert Engels <ren...@ix.netcom.com <>> wrote: > That is 100% true but a important point is that using GOPATH requires manual > dependency management via ‘vendoring’. This can be very labor intensive and > error prone - leading to security issues in your delivered code. > >> On Feb 25, 2021, at 3:08 PM, Bob Alexander <bobj...@gmail.com <>> wrote: >> >> >> GOPATH mode does not limit your Go code to a single directory. I've seen >> this misunderstanding stated in probably hundreds of various posts. >> >> $GOPATH allows specification of multiple directories. I've used that >> capability for several years to distribute my Go code to my personal general >> library and to various application-specific libraries. Each of the multiple >> GOPATH directories refers to a Go "workspace", so the result is my general >> library workspace plus mini-workspaces in various application directories -- >> each with src, pkg, and bin subdirectories. A single go install installs all >> workspaces specified in your GOPATH at once, or you can selectively build by >> temporarily changing the GOPATH. >> >> This is a pretty good setup for me, a decades-experienced software engineer >> working in "programmer" mode for my personal development. >> >> Go's goal of ending GOPATH mode sounds like a choice to serve the >> professional software engineer, and not the personal programmer. Module mode >> is a good thing if you are publishing your code, but is a lot of additional >> labor and cognitive load for us "programmers". >> >> I wonder if this might discourage adoption of Go by certain categories such >> as college and high school students, non-software-engineer professionals who >> write internal programs for their business, and curious folks who want to >> introduce themselves to Go. It is soooo much easier to set up my environment >> with GOPATH mode. In attempting conversion to MODULE mode, I've spent lots >> of frustrating hours and it's still not working perfectly! >> >> So, I am +1 for retention of GOPATH mode (as well as MODULE mode), allowing >> Go users to make the choice of MODULE vs. GOPATH based on their needs. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts...@googlegroups.com <>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/CAKyHfRPYgop6YPgk3AcJ4Q43NgV%3D9KP%3DzgYja8Z6FJuc0UuPig%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/golang-nuts/CAKyHfRPYgop6YPgk3AcJ4Q43NgV%3D9KP%3DzgYja8Z6FJuc0UuPig%40mail.gmail.com?utm_medium=email&utm_source=footer>. > > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts...@googlegroups.com <>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAKyHfRPw125S_800nhBxV9UrqHCaet-8WAO2q%2B1Xah3dhNiS5w%40mail.gmail.com > > <https://groups.google.com/d/msgid/golang-nuts/CAKyHfRPw125S_800nhBxV9UrqHCaet-8WAO2q%2B1Xah3dhNiS5w%40mail.gmail.com?utm_medium=email&utm_source=footer>. > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/dd414b53-aadd-430c-b328-1ed8d544f33an%40googlegroups.com > > <https://groups.google.com/d/msgid/golang-nuts/dd414b53-aadd-430c-b328-1ed8d544f33an%40googlegroups.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/7BE2B4F1-0346-456C-BFC5-11138356A67C%40ix.netcom.com.
