Re: [go-nuts] Contrary to popular opinion...

[Robert Engels]

I wasn’t referring to the mixed tab/space issue. I mean you copy a few live 
that are at one indentation to another location with a different indentation - 
everything is mucked up usually. You don’t have these issues with brackets - 
the code is easily formatted correctly or a bracket added then formatted. 

To me though the white space is the least of the problems. The dynamic nature 
make long term maintenance of large systems impossible - especially for larger 
teams. 

I recommend reading “Dreaming in Code” for great lessons in why not to use 
Python. 

> On Feb 28, 2021, at 7:48 PM, Justin Israel  wrote:
> 
> 
> 
>> On Monday, March 1, 2021 at 9:36:57 AM UTC+13 ren...@ix.netcom.com wrote:
>> I think the only time the indentation is a problem is when refactoring code 
>> - copying pasting code blocks seems to be a guessing game with my IDEs and 
>> often require manual fixes - the issue seems far less common (and more 
>> easily corrected) when using brackets.  
>> 
 On Feb 28, 2021, at 12:12 PM, Bob Alexander  wrote:
 
>>> 
>> 
>>> I never have understood the *serious* hatred of Python's "indentation as 
>>> syntax" approach. I've used lots of bracketed and begin/end languages 
>>> (C/C++, Algol & relatives, Ruby, and most other programming languages), and 
>>> when I write code in those languages I usually indent as I write. 
>>> Obviously, indenting makes it much easier for a human to understand the 
>>> program structure. It never occurred to me to code C, for example, without 
>>> indenting. Of course, the compiler doesn't mind -- for the computer the 
>>> brackets are easier to understand, but not for humans.
>>> 
>>> When I pseudo-code with pencil and paper or text editor, my natural 
>>> tendency is to use indentation for structure, not brackets. I'd imagine 
>>> this is true for almost everyone. When Python came along the Python team 
>>> adopted the motto "programmable pseudo-code" (or something like that) and, 
>>> for me, it was true. I personally think Python is very readable. Another 
>>> minor benefit of the indentation-only approach is the reduced vertical size 
>>> of a program -- all those trailing brackets on a line of their own add up :)
>>> 
>>> So it never occurred to me to object to Python's indentation approach. I 
>>> always did it anyway. And, even without code formatters, if a program could 
>>> compile and run, I could rely on the indentation to be representative of 
>>> the program's actual structure.
>>> 
>>> Aside from indentation Python's keyword function arguments and optional 
>>> arguments often make for more readable code. Go could really benefit from 
>>> those features, and since they are already available in struct literals, it 
>>> might not be too hard to fit into the Go language...
>>> 
 On Sun, Feb 28, 2021 at 12:35 AM 'Dan Kortschak' via golang-nuts 
  wrote:
 On Sun, 2021-02-28 at 09:23 +0100, Jan Mercl wrote:
 > I meant, for example, in regexp notation, ` *` vs `\n *` between a
 > function signature and the opening brace of the function body.
 
 Ah, yes.
 
 > This assumes newline is a whitespace. Most programming languages
 > agree, but humans may not.
 
 With semicolon insertion, they're not. While they are white, they're
 qualitatively difference to horizontal white.
 
 Dan
 
 
 -- 
 You received this message because you are subscribed to a topic in the 
 Google Groups "golang-nuts" group.
 To unsubscribe from this topic, visit 
 https://groups.google.com/d/topic/golang-nuts/uy17JJe8KB4/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 golang-nuts...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/golang-nuts/070aa073f9c5c9d78a7d68bf9534fa37d701d384.camel%40kortschak.io.
>>> 
>>> -- 
>> 
>>> 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/CAKyHfRMkgqZ0MyQFcyszX3m1DLcrK%3D1Zfiw2ugFx3VsX2QSeAQ%40mail.gmail.com.
> I have been a Python developer for 14 years, and whitespace has never really 
> presented itself as any significant issue. The occasional copy-paste 
> resulting in mixed spaces vs tabs gets flagged by modern code editors. 
> 
> -- 
> 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/713d2178-87a2-480a-9ba1-d113175bdd72n%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"go

Re: [go-nuts] Contrary to popular opinion...

[Justin Israel]

On Monday, March 1, 2021 at 9:36:57 AM UTC+13 ren...@ix.netcom.com wrote:

> I think the only time the indentation is a problem is when refactoring 
> code - copying pasting code blocks seems to be a guessing game with my IDEs 
> and often require manual fixes - the issue seems far less common (and more 
> easily corrected) when using brackets.  
>
> On Feb 28, 2021, at 12:12 PM, Bob Alexander  wrote:
>
> 
>
> I never have understood the *serious* hatred of Python's "indentation as 
> syntax" approach. I've used lots of bracketed and begin/end languages 
> (C/C++, Algol & relatives, Ruby, and most other programming languages), and 
> when I write code in those languages I usually indent as I write. 
> Obviously, indenting makes it much easier for a human to understand the 
> program structure. It never occurred to me to code C, for example, without 
> indenting. Of course, the compiler doesn't mind -- for the computer the 
> brackets are easier to understand, but not for humans.
>
> When I pseudo-code with pencil and paper or text editor, my natural 
> tendency is to use indentation for structure, not brackets. I'd imagine 
> this is true for almost everyone. When Python came along the Python team 
> adopted the motto "programmable pseudo-code" (or something like that) and, 
> for me, it was true. I personally think Python is very readable. 
> Another minor benefit of the indentation-only approach is the reduced 
> vertical size of a program -- all those trailing brackets on a line of 
> their own add up :)
>
> So it never occurred to me to object to Python's indentation approach. I 
> always did it anyway. And, even without code formatters, if a program could 
> compile and run, I could rely on the indentation to be representative of 
> the program's actual structure.
>
> Aside from indentation Python's keyword function arguments and optional 
> arguments often make for more readable code. Go could really benefit from 
> those features, and since they are already available in struct literals, it 
> might not be too hard to fit into the Go language...
>
> On Sun, Feb 28, 2021 at 12:35 AM 'Dan Kortschak' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
>> On Sun, 2021-02-28 at 09:23 +0100, Jan Mercl wrote:
>> > I meant, for example, in regexp notation, ` *` vs `\n *` between a
>> > function signature and the opening brace of the function body.
>>
>> Ah, yes.
>>
>> > This assumes newline is a whitespace. Most programming languages
>> > agree, but humans may not.
>>
>> With semicolon insertion, they're not. While they are white, they're
>> qualitatively difference to horizontal white.
>>
>> Dan
>>
>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/golang-nuts/uy17JJe8KB4/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> golang-nuts...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/070aa073f9c5c9d78a7d68bf9534fa37d701d384.camel%40kortschak.io
>> .
>>
> -- 
>
> 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/CAKyHfRMkgqZ0MyQFcyszX3m1DLcrK%3D1Zfiw2ugFx3VsX2QSeAQ%40mail.gmail.com
>  
> 
> .
>
> I have been a Python developer for 14 years, and whitespace has never 
really presented itself as any significant issue. The occasional copy-paste 
resulting in mixed spaces vs tabs gets flagged by modern code editors. 

-- 
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/713d2178-87a2-480a-9ba1-d113175bdd72n%40googlegroups.com.

Re: [go-nuts] Contrary to popular opinion...

['Dan Kortschak' via golang-nuts]

On Sun, 2021-02-28 at 10:11 -0800, Bob Alexander wrote:
> I never have understood the *serious* hatred of Python's "indentation
> as syntax" approach. I've used lots of bracketed and begin/end
> languages (C/C++, Algol & relatives, Ruby, and most other programming
> languages), and when I write code in those languages I usually indent
> as I write. Obviously, indenting makes it much easier for a human to
> understand the program structure. It never occurred to me to code C,
> for example, without indenting. Of course, the compiler doesn't mind
> -- for the computer the brackets are easier to understand, but not
> for humans.

Indenting is better for humans and paired stack operations are better
for machines. Having both is helpful.


-- 
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/4daf048d4292ac80a23ebd39ee13fdd16df0ff80.camel%40kortschak.io.

Re: [go-nuts] Contrary to popular opinion...

[Robert Engels]

I think the only time the indentation is a problem is when refactoring code - 
copying pasting code blocks seems to be a guessing game with my IDEs and often 
require manual fixes - the issue seems far less common (and more easily 
corrected) when using brackets.  

> On Feb 28, 2021, at 12:12 PM, Bob Alexander  wrote:
> 
> 
> I never have understood the *serious* hatred of Python's "indentation as 
> syntax" approach. I've used lots of bracketed and begin/end languages (C/C++, 
> Algol & relatives, Ruby, and most other programming languages), and when I 
> write code in those languages I usually indent as I write. Obviously, 
> indenting makes it much easier for a human to understand the program 
> structure. It never occurred to me to code C, for example, without indenting. 
> Of course, the compiler doesn't mind -- for the computer the brackets are 
> easier to understand, but not for humans.
> 
> When I pseudo-code with pencil and paper or text editor, my natural tendency 
> is to use indentation for structure, not brackets. I'd imagine this is true 
> for almost everyone. When Python came along the Python team adopted the motto 
> "programmable pseudo-code" (or something like that) and, for me, it was true. 
> I personally think Python is very readable. Another minor benefit of the 
> indentation-only approach is the reduced vertical size of a program -- all 
> those trailing brackets on a line of their own add up :)
> 
> So it never occurred to me to object to Python's indentation approach. I 
> always did it anyway. And, even without code formatters, if a program could 
> compile and run, I could rely on the indentation to be representative of the 
> program's actual structure.
> 
> Aside from indentation Python's keyword function arguments and optional 
> arguments often make for more readable code. Go could really benefit from 
> those features, and since they are already available in struct literals, it 
> might not be too hard to fit into the Go language...
> 
>> On Sun, Feb 28, 2021 at 12:35 AM 'Dan Kortschak' via golang-nuts 
>>  wrote:
>> On Sun, 2021-02-28 at 09:23 +0100, Jan Mercl wrote:
>> > I meant, for example, in regexp notation, ` *` vs `\n *` between a
>> > function signature and the opening brace of the function body.
>> 
>> Ah, yes.
>> 
>> > This assumes newline is a whitespace. Most programming languages
>> > agree, but humans may not.
>> 
>> With semicolon insertion, they're not. While they are white, they're
>> qualitatively difference to horizontal white.
>> 
>> Dan
>> 
>> 
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/golang-nuts/uy17JJe8KB4/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/070aa073f9c5c9d78a7d68bf9534fa37d701d384.camel%40kortschak.io.
> 
> -- 
> 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/CAKyHfRMkgqZ0MyQFcyszX3m1DLcrK%3D1Zfiw2ugFx3VsX2QSeAQ%40mail.gmail.com.

-- 
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/52160140-98CA-47AC-AA22-3D7ABB9B2FA9%40ix.netcom.com.

Re: [go-nuts] Contrary to popular opinion...

[Bob Alexander]

I never have understood the *serious* hatred of Python's "indentation as
syntax" approach. I've used lots of bracketed and begin/end languages
(C/C++, Algol & relatives, Ruby, and most other programming languages), and
when I write code in those languages I usually indent as I write.
Obviously, indenting makes it much easier for a human to understand the
program structure. It never occurred to me to code C, for example, without
indenting. Of course, the compiler doesn't mind -- for the computer the
brackets are easier to understand, but not for humans.

When I pseudo-code with pencil and paper or text editor, my natural
tendency is to use indentation for structure, not brackets. I'd imagine
this is true for almost everyone. When Python came along the Python team
adopted the motto "programmable pseudo-code" (or something like that) and,
for me, it was true. I personally think Python is very readable.
Another minor benefit of the indentation-only approach is the reduced
vertical size of a program -- all those trailing brackets on a line of
their own add up :)

So it never occurred to me to object to Python's indentation approach. I
always did it anyway. And, even without code formatters, if a program could
compile and run, I could rely on the indentation to be representative of
the program's actual structure.

Aside from indentation Python's keyword function arguments and optional
arguments often make for more readable code. Go could really benefit from
those features, and since they are already available in struct literals, it
might not be too hard to fit into the Go language...

On Sun, Feb 28, 2021 at 12:35 AM 'Dan Kortschak' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> On Sun, 2021-02-28 at 09:23 +0100, Jan Mercl wrote:
> > I meant, for example, in regexp notation, ` *` vs `\n *` between a
> > function signature and the opening brace of the function body.
>
> Ah, yes.
>
> > This assumes newline is a whitespace. Most programming languages
> > agree, but humans may not.
>
> With semicolon insertion, they're not. While they are white, they're
> qualitatively difference to horizontal white.
>
> Dan
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/uy17JJe8KB4/unsubscribe.
> To unsubscribe from this group and all its topics, 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/070aa073f9c5c9d78a7d68bf9534fa37d701d384.camel%40kortschak.io
> .
>

-- 
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/CAKyHfRMkgqZ0MyQFcyszX3m1DLcrK%3D1Zfiw2ugFx3VsX2QSeAQ%40mail.gmail.com.

Re: [go-nuts] Contrary to popular opinion...

[Robert Engels]

Popularity has nothing to do with good - thus Twitter and the Kardashians. . 

> On Feb 28, 2021, at 2:35 AM, 'Dan Kortschak' via golang-nuts 
>  wrote:
> 
> On Sun, 2021-02-28 at 09:23 +0100, Jan Mercl wrote:
>> I meant, for example, in regexp notation, ` *` vs `\n *` between a
>> function signature and the opening brace of the function body.
> 
> Ah, yes.
> 
>> This assumes newline is a whitespace. Most programming languages
>> agree, but humans may not.
> 
> With semicolon insertion, they're not. While they are white, they're
> qualitatively difference to horizontal white.
> 
> Dan
> 
> 
> -- 
> 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/070aa073f9c5c9d78a7d68bf9534fa37d701d384.camel%40kortschak.io.

-- 
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/DAE6A67B-9DF7-4451-920C-3D4E0D286D91%40ix.netcom.com.

Re: [go-nuts] Contrary to popular opinion...

['Dan Kortschak' via golang-nuts]

On Sun, 2021-02-28 at 09:23 +0100, Jan Mercl wrote:
> I meant, for example, in regexp notation, ` *` vs `\n *` between a
> function signature and the opening brace of the function body.

Ah, yes.

> This assumes newline is a whitespace. Most programming languages
> agree, but humans may not.

With semicolon insertion, they're not. While they are white, they're
qualitatively difference to horizontal white.

Dan


-- 
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/070aa073f9c5c9d78a7d68bf9534fa37d701d384.camel%40kortschak.io.

Re: [go-nuts] Contrary to popular opinion...

[Jan Mercl]

On Sun, Feb 28, 2021 at 9:05 AM 'Dan Kortschak' via golang-nuts
 wrote:

> I'm curious where the meaningful whitespace is in Go (for amounts
> differences in number greater than 1).

I meant, for example, in regexp notation, ` *` vs `\n *` between a
function signature and the opening brace of the function body.

This assumes newline is a whitespace. Most programming languages
agree, but humans may not.

-- 
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/CAA40n-XT1jk_VsjAYShjpcMvUgrH%3D_DS0sU-jv-Xc%2BUR_WGXSQ%40mail.gmail.com.

Re: [go-nuts] Contrary to popular opinion...

[Arnaud Delobelle]

E.g. compare

a = 1
b = 2

And

a = 1 b = 2


They do no mean the same in Go.

Arnaud
On Sun, 28 Feb 2021, 08:05 'Dan Kortschak' via golang-nuts, <
golang-nuts@googlegroups.com> wrote:

> On Sun, 2021-02-28 at 08:40 +0100, Jan Mercl wrote:
> > Actually Go has that problem as well, just a thousand times smaller.
>
> I'm curious where the meaningful whitespace is in Go (for amounts
> differences in number greater than 1).
>
> > FTR, I also think Python's approach to white space is a failure. But
> > its popularity seems to prove people think otherwise.
>
> The problem with python's approach is that it operated on the basis
> that error correcting redundancy in source code is not valuable. It is.
>
> Dan
>
>
> --
> 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/baa6db5212f6c2d71e6d011faec073a558b02adb.camel%40kortschak.io
> .
>

-- 
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/CAJ6cK1YWwGX0SZcJJMmoHWwLCWufhxmQiB%2B%3D%3D2LcuB9J%2BtOJ4g%40mail.gmail.com.

Re: [go-nuts] Contrary to popular opinion...

['Dan Kortschak' via golang-nuts]

On Sun, 2021-02-28 at 08:40 +0100, Jan Mercl wrote:
> Actually Go has that problem as well, just a thousand times smaller.

I'm curious where the meaningful whitespace is in Go (for amounts
differences in number greater than 1).

> FTR, I also think Python's approach to white space is a failure. But
> its popularity seems to prove people think otherwise.

The problem with python's approach is that it operated on the basis
that error correcting redundancy in source code is not valuable. It is.

Dan


-- 
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/baa6db5212f6c2d71e6d011faec073a558b02adb.camel%40kortschak.io.

Re: [go-nuts] Contrary to popular opinion...

[Jan Mercl]

On Sat, Feb 27, 2021 at 10:37 PM Bob Alexander  wrote:

> Try removing all the space from your post and see how understandable it is, 
> or remove all indentation from a Go program, etc. (Hmm, that would make 
> formatters a lot easier to write... )

Removing all spaces makes most languages ambiguous. But the point Bob
made was that in most languages it does not matter how much white
space separates tokens if the amount is not zero.

Actually Go has that problem as well, just a thousand times smaller.
FTR, I also think Python's approach to white space is a failure. But
its popularity seems to prove people think otherwise.

-- 
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/CAA40n-Vut-6NU%2BOwtjjV9kats8h1Ho_7xDuFhWeRN6YLG2CdOw%40mail.gmail.com.

Re: [go-nuts] Contrary to popular opinion...

[Bob Alexander]

Well, it seems that you don't like Python any more :) But I do like it --
and I like Go too. I'd guess that lots of other folks have figured out
positive answers to your Python issues, 'cause Python ranks high on the
popularity lists. E.g on the issue of invisible characters having semantic
importance -- they have importance to most (maybe all) human written
languages too, so they can't be all bad. Try removing all the space from
your post and see how understandable it is, or remove all indentation from
a Go program, etc. (Hmm, that would make formatters a lot easier to
write... )

Your issue about whitespace is one I've heard often, but then I wonder why
they would want a compiler to accept misleading indentation.

O

On Sat, Feb 27, 2021 at 10:59 AM Amnon  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/...", 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 
> 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 
>> 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 
>>> 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 m

Re: [go-nuts] Contrary to popular opinion...

[robert engels]

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  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/.. 
> .", 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 > 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 > 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 > 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

Re: [go-nuts] Contrary to popular opinion...

[Amnon]

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/...", 
 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  
 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  
> 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  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

Re: [go-nuts] Contrary to popular opinion...

[bobj...@gmail.com]

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/...", 
>>> 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  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  
 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  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 s 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 
> Gr

Re: [go-nuts] Contrary to popular opinion...

[Amnon]

*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/...", 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  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  
>>> 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  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 s 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
  
 
 .

 -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop rece

Re: [go-nuts] Contrary to popular opinion...

[David Skinner]

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/...", 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  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  
>> 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  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 s 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
>>>  
>>> 
>>> .
>>>
>>> -- 
>> 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
>>  
>> 

Re: [go-nuts] Contrary to popular opinion...

[Marcin Romaszewicz]

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/...", 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  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 
> 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  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 s 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+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/CAKyHfRPYgop6YPgk3AcJ4Q43NgV%3D9KP%3DzgYja8Z6FJuc0UuPig%40mail.gmail.com
>> 
>> .
>>
>> --
> 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/CAKyHfRPw125S_800nhBxV9UrqHCaet-8WAO2q%2B1Xah3dhNiS5w%40mail.gmail.com
> 
> .
>

-- 
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/CA%2Bv29Ltre_wThDS9d8YXHSqkLFY9tT8aOS0fYcg3KmWAPvETJA%40mail.gmail.com.

Re: [go-nuts] Contrary to popular opinion...

[Bob Alexander]

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  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  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 s 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAKyHfRPYgop6YPgk3AcJ4Q43NgV%3D9KP%3DzgYja8Z6FJuc0UuPig%40mail.gmail.com
> 
> .
>
>

-- 
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/CAKyHfRPw125S_800nhBxV9UrqHCaet-8WAO2q%2B1Xah3dhNiS5w%40mail.gmail.com.

Re: [go-nuts] Contrary to popular opinion...

[Robert Engels]

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  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 s 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAKyHfRPYgop6YPgk3AcJ4Q43NgV%3D9KP%3DzgYja8Z6FJuc0UuPig%40mail.gmail.com.

-- 
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/90A75740-F716-46C7-8F37-28307E5BAB75%40ix.netcom.com.