Re: [go-nuts] What is a ordinary and exceptional error?

[Kamil Ziemian]

Axel Wagner, you opinin is highly appriciated.

niedziela, 1 października 2023 o 15:00:35 UTC+2 Axel Wagner napisał(a):

> On Sun, Oct 1, 2023 at 2:37 PM Jerry Londergaard  
> wrote:
>
>> I've been thinking about this point as well lately. I think I understand 
>> (at least some of) the conditions under which
>> you would call a panic(), but I still don't quite grok why it's better 
>> than returning an error if that error is properly 
>> handled.  If I panic(), then no defer() statements will be called, and I 
>> don't give any chance to the calling code to cleanup etc. 
>>
>
> `panic` does call defered functions.
>
> The reason why not to return an error is who is responsible for fixing the 
> failure condition.
>
> An error is usually returned to the user/operator and it is expected that 
> they remedy it. For example, if a connection fails because a name can not 
> be resolved, the program should just print "can't resolve example.com", 
> signalling that the user has to fix their inputs or network setup.
>
> On the other hand, a panic is expected to be reported to the developer for 
> fixing. If a program has a bug, there really is nothing the user can do. No 
> amount of changed inputs or re-running will make the bug go away - the code 
> needs to be fixed.
>
> Hence, a panic contains a stack trace (the developer needs that stack 
> trace to effectively find and fix the bug), while an error does not (the 
> user does not know your code so the stack trace doesn't help them).
>
> To be clear, not everyone follows this philosophy and not every program 
> follows this dichotomy (in a service, the role of operator and developer 
> often overlap - hence "devops"). But it's a pretty self-consistent view 
> that can answer a lot of questions about good error handling and messages.
>  
>
>>
>> I struggle to think of a scenario where it would be better to *not* allow 
>> the code to cleanup and exit gracefully. Is it because we
>> don't want to give the code the possiiblity of ignoring the error?
>>
>> On Saturday, 30 September 2023 at 9:10:09 pm UTC+10 Kamil Ziemian wrote:
>>
>>> Thank you mister Rader, this was what I needed. I think I now have 
>>> intuition what this text want to say.
>>>
>>> Best regards
>>> Kamil
>>>
>>> piątek, 29 września 2023 o 23:58:39 UTC+2 Kurtis Rader napisał(a):
>>>
>>>> An ordinary error is one that can be expected to occur. For example, 
>>>> opening a file may fail because the file does not exist or the process 
>>>> doesn't have permission to open it. An exceptional error is one that is 
>>>> not 
>>>> expected to occur and often indicates the state of the program is invalid. 
>>>> For example, a data structure that contains pointers that should never be 
>>>> nil. If a nil pointer is found that means the structure is corrupted. 
>>>> Probably due to a programming bug. Exceptional errors are those which may 
>>>> make it unsafe to continue execution. In which case calling panic() may be 
>>>> the only sensible course of action.
>>>>
>>>> On Fri, Sep 29, 2023 at 2:38 PM Kamil Ziemian  
>>>> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> In Go FAQ we read "We believe that coupling exceptions to a control 
>>>>> structure, as in the try-catch-finally idiom, results in convoluted 
>>>>> code. It also tends to encourage programmers to label too many ordinary 
>>>>> errors, such as failing to open a file, as exceptional.", " Go also has a 
>>>>> couple of built-in functions to signal and recover from truly exceptional 
>>>>> conditions.".
>>>>>
>>>>> Can you explain to me in general terms what is a ordinary and 
>>>>> exceptional error? I'm just a hobbist programer and I never think about 
>>>>> errors in that way.
>>>>>
>>>>> Best regards,
>>>>> Kamil
>>>>>
>>>>> -- 
>>>>> 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/e9fdeb9d-e3b6-49ea-b7e3-5ab7ddafea7bn%40googlegroup

[go-nuts] Re: Go FAQ needs updates or not?

[Kamil Ziemian]

If I can, I want to make another comment about Go FAQ.

In section "Why can't the compiler infer the type argument in my program?" 
we read
"There are many cases where a programmer can easily see what the type 
argument for a generic type or function must be, but the language does not 
permit the compiler to infer it. Type inference is intentionally limited to 
ensure that there is never any confusion as to which type is inferred. 
Experience with other languages suggests that unexpected type inference can 
lead to considerable confusion when reading and debugging a program."
>From what I understand this if comment on the situation when we have 
function `f[T constraint](x, y T)` and we call it like `f(int(1), int(2))` 
can't infere that T should be a int (maybe it is stupid example, but I only 
use generics in such obvious cases). If I didn't know generics more I would 
understand text belowe as saying that code `f(int(1), int(2))` is always 
invalid and must be replaced by `f[int](1, 2)`. I would suggest to tweek it 
a bit, to make clear that Go has type inference, only more limited that in 
other languages.

Of course it is only my opinion.

Best regards,
Kamil

piątek, 29 września 2023 o 23:31:59 UTC+2 Kamil Ziemian napisał(a):

> Ok, there is one thing connected to Go FAQ that I don't like. 
>
> In section "When did Go get generic types?" we read "See the language spec 
> <https://go.dev/ref/spec> and the proposal 
> <https://go.dev/design/43651-type-parameters> for details.", where 
> proposal in question is "Type Parameters Proposal" (
> https://go.googlesource.com/proposal/+/master/design/43651-type-parameters.md).
>  
> "Type Parameters Proposal" is very good written document, I read it even 
> before Go 1.18 came out, but as Ian Lance Taylor said here when Go 1.18 was 
> released, this proposal is not 100% copatible with Go today. Few changes 
> was done when implementing generics and Taylor said that Go Spec is the 
> document that state how generics must work in Go. I find example of code 
> that is valid in the light of the proposal, but not in the light of Go 
> Spec, but I don't remember it. I propose that disclaimer should be added, 
> for example at the top o the proposal saying something like "This proposal 
> is not 100% compatibile with what was finally accepted in Go. Look to Go 
> Spec for acctual information.".
>
> As a side note, I like Go Spec, but it is not good document if you just 
> want to learn generics. Since they influance dozens of things (functions, 
> methods, iterfaces, you name it), description of them is scattered through 
> all document and I hear from true Go programmers, not hobbist like me, that 
> they have doubts if they understand generics description in Go Spec. I 
> would propose to add some quationary note about that to Go FAQ, but this is 
> only my humble opinion.
>
> Best regards
> Kamil
>
> piątek, 29 września 2023 o 22:21:35 UTC+2 Kamil Ziemian napisał(a):
>
>> Hello,
>>
>> I read Go FAQ again and I'm start to think that few minor things may 
>> needs some update. It is only my humble opinion and I'm not even true 
>> programmer, only hobbist, so if you disagree, you are probably right.
>>
>> "What is the purpose of the project?"
>> This section starts "At the time of Go's inception, only a decade ago, 
>> the programming world was different from today." Since first idea of Go is 
>> 2007 I guess that was written in 2017. If so it was six years ago and 
>> things change during that time, so maybe someone with more knowledge can 
>> review this part and say if is "up to date".
>>
>> "Is Google using Go internally?"
>> We read here "One easy example is the server behind golang.org.". From 
>> what I understand this should be updated to "server behind go.dev".
>>
>> Best regards,
>> Kamil
>>
>

-- 
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/7c120d98-6767-4598-953f-e49c3986f584n%40googlegroups.com.

Re: [go-nuts] What is a ordinary and exceptional error?

[Kamil Ziemian]

Thank you mister Rader, this was what I needed. I think I now have 
intuition what this text want to say.

Best regards
Kamil

piątek, 29 września 2023 o 23:58:39 UTC+2 Kurtis Rader napisał(a):

> An ordinary error is one that can be expected to occur. For example, 
> opening a file may fail because the file does not exist or the process 
> doesn't have permission to open it. An exceptional error is one that is not 
> expected to occur and often indicates the state of the program is invalid. 
> For example, a data structure that contains pointers that should never be 
> nil. If a nil pointer is found that means the structure is corrupted. 
> Probably due to a programming bug. Exceptional errors are those which may 
> make it unsafe to continue execution. In which case calling panic() may be 
> the only sensible course of action.
>
> On Fri, Sep 29, 2023 at 2:38 PM Kamil Ziemian  wrote:
>
>> Hello,
>>
>> In Go FAQ we read "We believe that coupling exceptions to a control 
>> structure, as in the try-catch-finally idiom, results in convoluted 
>> code. It also tends to encourage programmers to label too many ordinary 
>> errors, such as failing to open a file, as exceptional.", " Go also has a 
>> couple of built-in functions to signal and recover from truly exceptional 
>> conditions.".
>>
>> Can you explain to me in general terms what is a ordinary and exceptional 
>> error? I'm just a hobbist programer and I never think about errors in that 
>> way.
>>
>> Best regards,
>> Kamil
>>
>> -- 
>> 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/e9fdeb9d-e3b6-49ea-b7e3-5ab7ddafea7bn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/e9fdeb9d-e3b6-49ea-b7e3-5ab7ddafea7bn%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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/870426b7-c3aa-4f64-8594-32b1bbc9525fn%40googlegroups.com.

[go-nuts] What is a ordinary and exceptional error?

[Kamil Ziemian]

Hello,

In Go FAQ we read "We believe that coupling exceptions to a control 
structure, as in the try-catch-finally idiom, results in convoluted code. 
It also tends to encourage programmers to label too many ordinary errors, 
such as failing to open a file, as exceptional.", " Go also has a couple of 
built-in functions to signal and recover from truly exceptional 
conditions.".

Can you explain to me in general terms what is a ordinary and exceptional 
error? I'm just a hobbist programer and I never think about errors in that 
way.

Best regards,
Kamil

-- 
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/e9fdeb9d-e3b6-49ea-b7e3-5ab7ddafea7bn%40googlegroups.com.

[go-nuts] Re: Go FAQ needs updates or not?

[Kamil Ziemian]

Ok, there is one thing connected to Go FAQ that I don't like. 

In section "When did Go get generic types?" we read "See the language spec 
<https://go.dev/ref/spec> and the proposal 
<https://go.dev/design/43651-type-parameters> for details.", where proposal 
in question is "Type Parameters Proposal" 
(https://go.googlesource.com/proposal/+/master/design/43651-type-parameters.md).
 
"Type Parameters Proposal" is very good written document, I read it even 
before Go 1.18 came out, but as Ian Lance Taylor said here when Go 1.18 was 
released, this proposal is not 100% copatible with Go today. Few changes 
was done when implementing generics and Taylor said that Go Spec is the 
document that state how generics must work in Go. I find example of code 
that is valid in the light of the proposal, but not in the light of Go 
Spec, but I don't remember it. I propose that disclaimer should be added, 
for example at the top o the proposal saying something like "This proposal 
is not 100% compatibile with what was finally accepted in Go. Look to Go 
Spec for acctual information.".

As a side note, I like Go Spec, but it is not good document if you just 
want to learn generics. Since they influance dozens of things (functions, 
methods, iterfaces, you name it), description of them is scattered through 
all document and I hear from true Go programmers, not hobbist like me, that 
they have doubts if they understand generics description in Go Spec. I 
would propose to add some quationary note about that to Go FAQ, but this is 
only my humble opinion.

Best regards
Kamil

piątek, 29 września 2023 o 22:21:35 UTC+2 Kamil Ziemian napisał(a):

> Hello,
>
> I read Go FAQ again and I'm start to think that few minor things may needs 
> some update. It is only my humble opinion and I'm not even true programmer, 
> only hobbist, so if you disagree, you are probably right.
>
> "What is the purpose of the project?"
> This section starts "At the time of Go's inception, only a decade ago, 
> the programming world was different from today." Since first idea of Go is 
> 2007 I guess that was written in 2017. If so it was six years ago and 
> things change during that time, so maybe someone with more knowledge can 
> review this part and say if is "up to date".
>
> "Is Google using Go internally?"
> We read here "One easy example is the server behind golang.org.". From 
> what I understand this should be updated to "server behind go.dev".
>
> Best regards,
> Kamil
>

-- 
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/008eef74-656c-4dce-b665-eac614df68f3n%40googlegroups.com.

[go-nuts] Go FAQ needs updates or not?

[Kamil Ziemian]

Hello,

I read Go FAQ again and I'm start to think that few minor things may needs 
some update. It is only my humble opinion and I'm not even true programmer, 
only hobbist, so if you disagree, you are probably right.

"What is the purpose of the project?"
This section starts "At the time of Go's inception, only a decade ago, the 
programming world was different from today." Since first idea of Go is 2007 
I guess that was written in 2017. If so it was six years ago and things 
change during that time, so maybe someone with more knowledge can review 
this part and say if is "up to date".

"Is Google using Go internally?"
We read here "One easy example is the server behind golang.org.". From what 
I understand this should be updated to "server behind go.dev".

Best regards,
Kamil

-- 
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/646da6d3-6cad-49fc-b699-8c975ebe40d0n%40googlegroups.com.

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[Kamil Ziemian]

Hello,

First, as I probably end my first reading of Go Spec in coming days, I want 
to thank you all for helping me in that. Thank you. :)

Second, I have question about example shown in section "Appending to and 
copying slices".

s0 := []int{0, 0}
s1 := append(s0, 2)// append a single element s1 == 
[]int{0, 0, 2}
s2 := append(s1, 3, 5, 7)  // append multiple elementss2 == 
[]int{0, 0, 2, 3, 5, 7}
s3 := append(s2, s0...)// append a slice  s3 == 
[]int{0, 0, 2, 3, 5, 7, 0, 0}
s4 := append(s3[3:6], s3[2:]...)   // append overlapping slices4 == 
[]int{3, 5, 7, 2, 3, 5, 7, 0, 0}

I didn't understand why s4 looks that after append. I would guess that if I 
call append(s3[3:6], s3[:2]...) (s3[2:] replaced by s3[:2]) it should 
produce result above. But I don't think clearly recently, to much on my 
head.

Best regards,
Kamil

sobota, 29 lipca 2023 o 19:50:51 UTC+2 Kamil Ziemian napisał(a):

> "The confusion may come from the fact that a list of forbidden built-in 
> operations is immediately followed by a list of (mostly) allowed operations 
> that illustrate the original rule?"
> You hit the nail on the head.
>
> I don't have much faith in me as programmer, so I ask about any such issue 
> that is bothering me.
>
> Best regards,
> Kamil
>
> pt., 28 lip 2023 o 17:32 Brian Candler  napisał(a):
>
>> If you wanted to be absolutely clear, you could insert "The following are 
>> examples of expression statements" - although it didn't really trouble me 
>> as-is.
>>
>> On Friday, 28 July 2023 at 16:12:11 UTC+1 Jason Phillips wrote:
>>
>>> The confusion may come from the fact that a list of forbidden built-in 
>>> operations is immediately followed by a list of (mostly) allowed operations 
>>> that illustrate the original rule? With the exception of "len", it may be 
>>> more clear for it to be structure like:
>>> ExpressionStmt = Expression .
>>>
>>> h(x+y)
>>> f.Close()
>>> <-ch
>>> (<-ch)
>>> len("foo") // illegal if len is the built-in function
>>>
>>> The following built-in functions are not permitted in statement 
>>> context:
>>> append cap complex imag len make new real
>>> unsafe.Add unsafe.Alignof unsafe.Offsetof unsafe.Sizeof 
>>> unsafe.Slice
>>>
>>> But, that leaves the "len" example with zero context upfront.
>>>
>>> On Friday, July 28, 2023 at 10:51:20 AM UTC-4 Axel Wagner wrote:
>>>
>>>> Note also, that you didn't paste the entire section:
>>>>
>>>> With the exception of specific built-in functions, function and method 
>>>> calls and receive operations can appear in statement context. Such 
>>>> statements may be parenthesized. […] The following built-in functions are 
>>>> not permitted in statement context:
>>>>
>>>> This is IMO very clear about those other examples being allowed.
>>>>
>>>> On Fri, Jul 28, 2023 at 4:42 PM Axel Wagner  
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, Jul 28, 2023 at 4:04 PM Kamil Ziemian  
>>>>> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> After a long break, I go back to reading Go Spec.
>>>>>>
>>>>>> In the section "Expression statements" we read that "The following 
>>>>>> built-in functions are not permitted in statement context:
>>>>>>
>>>>>> append cap complex imag len make new real
>>>>>> unsafe.Add unsafe.Alignof unsafe.Offsetof unsafe.Sizeof unsafe.Slice
>>>>>>
>>>>>> h(x+y)
>>>>>> f.Close()
>>>>>> <-ch
>>>>>> (<-ch)
>>>>>> len("foo")  // illegal if len is the built-in function"
>>>>>>
>>>>>> Are things following "h(x+y)" also forbidden in the statement 
>>>>>> context? This part of spec isn't specially clear in my opinion.
>>>>>>
>>>>>
>>>>> No, they are not. Otherwise, they'd have a comment following them 
>>>>> saying "illegal for $reason".
>>>>>  
>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>> Kamil
>>>>>> poniedziałe

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[Kamil Ziemian]

"The confusion may come from the fact that a list of forbidden built-in
operations is immediately followed by a list of (mostly) allowed operations
that illustrate the original rule?"
You hit the nail on the head.

I don't have much faith in me as programmer, so I ask about any such issue
that is bothering me.

Best regards,
Kamil

pt., 28 lip 2023 o 17:32 Brian Candler  napisał(a):

> If you wanted to be absolutely clear, you could insert "The following are
> examples of expression statements" - although it didn't really trouble me
> as-is.
>
> On Friday, 28 July 2023 at 16:12:11 UTC+1 Jason Phillips wrote:
>
>> The confusion may come from the fact that a list of forbidden built-in
>> operations is immediately followed by a list of (mostly) allowed operations
>> that illustrate the original rule? With the exception of "len", it may be
>> more clear for it to be structure like:
>> ExpressionStmt = Expression .
>>
>> h(x+y)
>> f.Close()
>> <-ch
>> (<-ch)
>> len("foo") // illegal if len is the built-in function
>>
>> The following built-in functions are not permitted in statement
>> context:
>> append cap complex imag len make new real
>> unsafe.Add unsafe.Alignof unsafe.Offsetof unsafe.Sizeof
>> unsafe.Slice
>>
>> But, that leaves the "len" example with zero context upfront.
>>
>> On Friday, July 28, 2023 at 10:51:20 AM UTC-4 Axel Wagner wrote:
>>
>>> Note also, that you didn't paste the entire section:
>>>
>>> With the exception of specific built-in functions, function and method
>>> calls and receive operations can appear in statement context. Such
>>> statements may be parenthesized. […] The following built-in functions are
>>> not permitted in statement context:
>>>
>>> This is IMO very clear about those other examples being allowed.
>>>
>>> On Fri, Jul 28, 2023 at 4:42 PM Axel Wagner 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Jul 28, 2023 at 4:04 PM Kamil Ziemian 
>>>> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> After a long break, I go back to reading Go Spec.
>>>>>
>>>>> In the section "Expression statements" we read that "The following
>>>>> built-in functions are not permitted in statement context:
>>>>>
>>>>> append cap complex imag len make new real
>>>>> unsafe.Add unsafe.Alignof unsafe.Offsetof unsafe.Sizeof unsafe.Slice
>>>>>
>>>>> h(x+y)
>>>>> f.Close()
>>>>> <-ch
>>>>> (<-ch)
>>>>> len("foo")  // illegal if len is the built-in function"
>>>>>
>>>>> Are things following "h(x+y)" also forbidden in the statement context?
>>>>> This part of spec isn't specially clear in my opinion.
>>>>>
>>>>
>>>> No, they are not. Otherwise, they'd have a comment following them
>>>> saying "illegal for $reason".
>>>>
>>>>
>>>>>
>>>>> Best regards,
>>>>> Kamil
>>>>> poniedziałek, 12 czerwca 2023 o 02:02:27 UTC+2 Rob Pike napisał(a):
>>>>>
>>>>>> Although the sentence is OK as it stands, the section should be
>>>>>> tweaked a bit. One of the examples there (myString(0x65e5)) is valid Go 
>>>>>> but
>>>>>> vet rejects it, as part of the move towards disallowing this conversion,
>>>>>> which was there mostly for bootstrapping the libraries.
>>>>>>
>>>>>> -rob
>>>>>>
>>>>>>
>>>>>> On Mon, Jun 12, 2023 at 3:10 AM 'Axel Wagner' via golang-nuts <
>>>>>> golan...@googlegroups.com> wrote:
>>>>>>
>>>>>>> Ah, the spec does actually say:
>>>>>>>>
>>>>>>>> Converting a signed or unsigned integer value to a string type
>>>>>>>> yields a string containing the UTF-8 representation of the integer. 
>>>>>>>> Values
>>>>>>>> outside the range of valid Unicode code points are converted to 
>>>>>>>> "\uFFFD".
>>>>>>>
>>>>>>>
>>>>>>> P

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[Kamil Ziemian]

Hello,

After a long break, I go back to reading Go Spec.

In the section "Expression statements" we read that "The following built-in 
functions are not permitted in statement context:

append cap complex imag len make new real
unsafe.Add unsafe.Alignof unsafe.Offsetof unsafe.Sizeof unsafe.Slice

h(x+y)
f.Close()
<-ch
(<-ch)
len("foo")  // illegal if len is the built-in function"

Are things following "h(x+y)" also forbidden in the statement context? This 
part of spec isn't specially clear in my opinion.

Best regards,
Kamil
poniedziałek, 12 czerwca 2023 o 02:02:27 UTC+2 Rob Pike napisał(a):

> Although the sentence is OK as it stands, the section should be tweaked a 
> bit. One of the examples there (myString(0x65e5)) is valid Go but vet 
> rejects it, as part of the move towards disallowing this conversion, which 
> was there mostly for bootstrapping the libraries.
>
> -rob
>
>
> On Mon, Jun 12, 2023 at 3:10 AM 'Axel Wagner' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
>> Ah, the spec does actually say:
>>>
>>> Converting a signed or unsigned integer value to a string type yields a 
>>> string containing the UTF-8 representation of the integer. Values outside 
>>> the range of valid Unicode code points are converted to "\uFFFD".
>>
>>
>> Personally, I think this is fine as is. I think people understand what 
>> happens from these two sentences. 
>>
>> On Sun, Jun 11, 2023 at 7:02 PM Axel Wagner  
>> wrote:
>>
>>> I'm not entirely sure. I don't think your phrasing is correct, as it 
>>> doesn't represent what happens if the integer value exceeds the range of 
>>> valid codepoints (i.e. if it needs more than 32 bits to represent). That 
>>> being said, the sentence as is also isn't really precise about it. From 
>>> what I can tell, the result is not valid UTF-8 in any case.
>>>
>>> I think it might make sense to file an issue about this, though in 
>>> general that conversion is deprecated anyway and gets flagged by `go vet` 
>>> (and `go test`) because it is not what's usually expected. So I'm not sure 
>>> how important it is to get this exactly right and understandable.
>>>
>>>
>>> On Sun, Jun 11, 2023 at 5:17 PM Kamil Ziemian  
>>> wrote:
>>>
>>>> I have some hair splitting question. In the "Conversions to and from a 
>>>> string type" we read:
>>>> "Converting a signed or unsigned integer value to a string type yields 
>>>> a string containing the UTF-8 representation of the integer."
>>>>
>>>> Would it be more corrected to say, that conversion from integer to 
>>>> string gives you UTF-8 representation of code point described by value of 
>>>> the integer? Or maybe it is indeed representation of integer described by 
>>>> UTF-8 specification?
>>>>
>>>> Best regards,
>>>> Kamil
>>>> czwartek, 28 października 2021 o 19:33:27 UTC+2 Kamil Ziemian 
>>>> napisał(a):
>>>>
>>>>> Hello,
>>>>>
>>>>> From what I understand proper Gopher read at least one time "The Go 
>>>>> Programming Language Specification" (https://golang.org/ref/spec) and 
>>>>> now I need to read it too.
>>>>>
>>>>> I learn something of Extended Backus-Naur Form to understand it, so if 
>>>>> I say something stupid beyond belief, I hope you will forgive me. In the 
>>>>> first part "Notation" (https://golang.org/ref/spec#Notation) I 
>>>>> believe that I understand meaning of all concepts except of 
>>>>> "production_name". On one hand "production_name" means that it is name of 
>>>>> the production, not rocket science here. On the other, after reading 
>>>>> about 
>>>>> EBNF I feel that I should have more information about it. Can you explain 
>>>>> it to me?
>>>>>
>>>>> Again I'm new to EBNF, so maybe this is stupid question.
>>>>>
>>>>> Best
>>>>> Kamil
>>>>>
>>>>> -- 
>>>> 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 discuss

[go-nuts] Re: Amateur's questions about "Go lang spec"

[Kamil Ziemian]

I have some hair splitting question. In the "Conversions to and from a 
string type" we read:
"Converting a signed or unsigned integer value to a string type yields a 
string containing the UTF-8 representation of the integer."

Would it be more corrected to say, that conversion from integer to string 
gives you UTF-8 representation of code point described by value of the 
integer? Or maybe it is indeed representation of integer described by UTF-8 
specification?

Best regards,
Kamil
czwartek, 28 października 2021 o 19:33:27 UTC+2 Kamil Ziemian napisał(a):

> Hello,
>
> From what I understand proper Gopher read at least one time "The Go 
> Programming Language Specification" (https://golang.org/ref/spec) and now 
> I need to read it too.
>
> I learn something of Extended Backus-Naur Form to understand it, so if I 
> say something stupid beyond belief, I hope you will forgive me. In the 
> first part "Notation" (https://golang.org/ref/spec#Notation) I believe 
> that I understand meaning of all concepts except of "production_name". On 
> one hand "production_name" means that it is name of the production, not 
> rocket science here. On the other, after reading about EBNF I feel that I 
> should have more information about it. Can you explain it to me?
>
> Again I'm new to EBNF, so maybe this is stupid question.
>
> Best
> Kamil
>
>

-- 
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/06347585-fd2c-4bfa-9527-3439389c6414n%40googlegroups.com.

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[Kamil Ziemian]

Thank you for encouraging words about generic in spec. Knowing that much 
more skilled people than I also have problem with understanding this part 
of spec, give my self assessment a boost.

sobota, 10 czerwca 2023 o 21:44:22 UTC+2 Axel Wagner napisał(a):

> If it helps, I don't think I really understand the generics parts of the 
> spec myself.
>
> On Sat, Jun 10, 2023 at 7:13 PM Kamil Ziemian  wrote:
>
>> This is not a complaint, but a reflection. I have read, as careful as I 
>> can, the half of the Go Spec and if I didn't learn how parametric 
>> polymorphism (generics; did I spell it right) should work from proposals 
>> and talks on YouTube, I would probably understand 30% less from it. I know 
>> that how parametric polymorphis works in Go and how is described in Spec is 
>> not in 100% identical with proposals, but it is good enough. Due to them I 
>> have overall picture of what type parameters and related concepts are, so I 
>> can guess what is the intention behind part of the Spec that mention type 
>> them.
>>
>> I think I just wouldn't be able learn parametric polymorphism from 
>> reading Spec. Things related to it are scattered across the text (this is 
>> not a complaint, I just notice a fact) and gathering them together is not a 
>> easy task.
>>
>> I should note, that I want to use parametric polymorphism as really as 
>> possible. For me this is a feature of the last resort, but one that you 
>> should know that exists.
>>
>> Needless to say, I will need to read Spec one more time in the future, at 
>> least.
>>
>> Best regards,
>> Kamil
>>
>> sobota, 3 czerwca 2023 o 23:48:52 UTC+2 Sean Liao napisał(a):
>>
>>> It is not a typo
>>>
>>> https://go.dev/issue/24451
>>>
>>> - sean
>>>
>>>
>>> On Sat, Jun 3, 2023 at 10:05 PM peterGo  wrote:
>>>
>>>> It's a simple typo. Send in a fix.
>>>>
>>>> peter
>>>>
>>>> On Saturday, June 3, 2023 at 4:07:15 PM UTC-4 Kamil Ziemian wrote:
>>>>
>>>>> As burak serdar said, 9 = 3 * 3 is not a prime number, all other 
>>>>> elements in the slice are prime numbers. It looks like authors of Go Spec 
>>>>> want to make a joke or check how well people read examples in it.
>>>>>
>>>>> Best regards,
>>>>> Kamil
>>>>> sobota, 3 czerwca 2023 o 21:52:37 UTC+2 burak serdar napisał(a):
>>>>>
>>>>>> On Sat, Jun 3, 2023 at 1:40 PM peterGo  wrote:
>>>>>>
>>>>>>>
>>>>>>> Kamil Ziemian,
>>>>>>>
>>>>>>> // list of prime numbers 
>>>>>>> primes := []int{2, 3, 5, 7, 9, 2147483647 <(214)%20748-3647>}
>>>>>>>
>>>>>>> The variable prime is a list of some prime numbers starting with the 
>>>>>>> lowest and ending with the highest prime numbers that can safely be 
>>>>>>> represented an int. An int may either 32 or 64 bits.
>>>>>>>
>>>>>>> Please explain the joke.
>>>>>>>
>>>>>>
>>>>>> Could it be that 9 is not prime?
>>>>>>  
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Note: “Explaining a joke is like dissecting a frog. You understand 
>>>>>>> it better but the frog dies in the process.”
>>>>>>> ― E.B. White
>>>>>>>
>>>>>>> peter
>>>>>>> On Saturday, June 3, 2023 at 3:13:28 PM UTC-4 Kamil Ziemian wrote:
>>>>>>>
>>>>>>>> Is this example found in the "Composite literals" section of Go 
>>>>>>>> Spec a joke?
>>>>>>>> // list of prime numbers 
>>>>>>>> primes := []int{2, 3, 5, 7, 9, 2147483647 <(214)%20748-3647>}
>>>>>>>>
>>>>>>>> I checked on the internet and 2147483647 <(214)%20748-3647> is a 
>>>>>>>> prime number (https://en.wikipedia.org/wiki/2,147,483,647), so 
>>>>>>>> this element is fine.
>>>>>>>>
>>>>>>>> Best regards
>>>>>>>> Kamil
>>>>>>>>
>>>>>>>> czwartek, 4 maja 2023 o 16:38:50 UTC+2 Kamil Ziemian napisał(a):
>>>>>>>>
>>

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[Kamil Ziemian]

This is not a complaint, but a reflection. I have read, as careful as I 
can, the half of the Go Spec and if I didn't learn how parametric 
polymorphism (generics; did I spell it right) should work from proposals 
and talks on YouTube, I would probably understand 30% less from it. I know 
that how parametric polymorphis works in Go and how is described in Spec is 
not in 100% identical with proposals, but it is good enough. Due to them I 
have overall picture of what type parameters and related concepts are, so I 
can guess what is the intention behind part of the Spec that mention type 
them.

I think I just wouldn't be able learn parametric polymorphism from reading 
Spec. Things related to it are scattered across the text (this is not a 
complaint, I just notice a fact) and gathering them together is not a easy 
task.

I should note, that I want to use parametric polymorphism as really as 
possible. For me this is a feature of the last resort, but one that you 
should know that exists.

Needless to say, I will need to read Spec one more time in the future, at 
least.

Best regards,
Kamil

sobota, 3 czerwca 2023 o 23:48:52 UTC+2 Sean Liao napisał(a):

> It is not a typo
>
> https://go.dev/issue/24451
>
> - sean
>
>
> On Sat, Jun 3, 2023 at 10:05 PM peterGo  wrote:
>
>> It's a simple typo. Send in a fix.
>>
>> peter
>>
>> On Saturday, June 3, 2023 at 4:07:15 PM UTC-4 Kamil Ziemian wrote:
>>
>>> As burak serdar said, 9 = 3 * 3 is not a prime number, all other 
>>> elements in the slice are prime numbers. It looks like authors of Go Spec 
>>> want to make a joke or check how well people read examples in it.
>>>
>>> Best regards,
>>> Kamil
>>> sobota, 3 czerwca 2023 o 21:52:37 UTC+2 burak serdar napisał(a):
>>>
>>>> On Sat, Jun 3, 2023 at 1:40 PM peterGo  wrote:
>>>>
>>>>>
>>>>> Kamil Ziemian,
>>>>>
>>>>> // list of prime numbers 
>>>>> primes := []int{2, 3, 5, 7, 9, 2147483647 <(214)%20748-3647>}
>>>>>
>>>>> The variable prime is a list of some prime numbers starting with the 
>>>>> lowest and ending with the highest prime numbers that can safely be 
>>>>> represented an int. An int may either 32 or 64 bits.
>>>>>
>>>>> Please explain the joke.
>>>>>
>>>>
>>>> Could it be that 9 is not prime?
>>>>  
>>>>
>>>>>
>>>>>
>>>>> Note: “Explaining a joke is like dissecting a frog. You understand it 
>>>>> better but the frog dies in the process.”
>>>>> ― E.B. White
>>>>>
>>>>> peter
>>>>> On Saturday, June 3, 2023 at 3:13:28 PM UTC-4 Kamil Ziemian wrote:
>>>>>
>>>>>> Is this example found in the "Composite literals" section of Go Spec 
>>>>>> a joke?
>>>>>> // list of prime numbers 
>>>>>> primes := []int{2, 3, 5, 7, 9, 2147483647 <(214)%20748-3647>}
>>>>>>
>>>>>> I checked on the internet and 2147483647 <(214)%20748-3647> is a 
>>>>>> prime number (https://en.wikipedia.org/wiki/2,147,483,647), so this 
>>>>>> element is fine.
>>>>>>
>>>>>> Best regards
>>>>>> Kamil
>>>>>>
>>>>>> czwartek, 4 maja 2023 o 16:38:50 UTC+2 Kamil Ziemian napisał(a):
>>>>>>
>>>>>>> You convince me to your point Axel Wagner. At the same time if we 
>>>>>>> look at examples in Go Spec, I think their can be improved.
>>>>>>> "A0, A1, and []string 
>>>>>>> A2 and struct{ a, b int } 
>>>>>>> A3 and int A4, func(int, float64) *[]string, and A5 
>>>>>>>
>>>>>>> B0 and C0 
>>>>>>> D0[int, string] and E0 
>>>>>>> []int and []int 
>>>>>>> struct{ a, b *B5 } and struct{ a, b *B5 } 
>>>>>>> func(x int, y float64) *[]string, func(int, float64) (result 
>>>>>>> *[]string), and A5"
>>>>>>> I mean, first we need to check that A0, A1 and []string are the same 
>>>>>>> type and after few examples like D0[int, string] is the same as E0, we 
>>>>>>> have 
>>>>>>> stated []int and []int are the same type. If you convince yourself that 
>>>>>>> A0 
>>>>>>> is the same as A1 

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[Kamil Ziemian]

As burak serdar said, 9 = 3 * 3 is not a prime number, all other elements 
in the slice are prime numbers. It looks like authors of Go Spec want to 
make a joke or check how well people read examples in it.

Best regards,
Kamil
sobota, 3 czerwca 2023 o 21:52:37 UTC+2 burak serdar napisał(a):

> On Sat, Jun 3, 2023 at 1:40 PM peterGo  wrote:
>
>>
>> Kamil Ziemian,
>>
>> // list of prime numbers 
>> primes := []int{2, 3, 5, 7, 9, 2147483647 <(214)%20748-3647>}
>>
>> The variable prime is a list of some prime numbers starting with the 
>> lowest and ending with the highest prime numbers that can safely be 
>> represented an int. An int may either 32 or 64 bits.
>>
>> Please explain the joke.
>>
>
> Could it be that 9 is not prime?
>  
>
>>
>>
>> Note: “Explaining a joke is like dissecting a frog. You understand it 
>> better but the frog dies in the process.”
>> ― E.B. White
>>
>> peter
>> On Saturday, June 3, 2023 at 3:13:28 PM UTC-4 Kamil Ziemian wrote:
>>
>>> Is this example found in the "Composite literals" section of Go Spec a 
>>> joke?
>>> // list of prime numbers 
>>> primes := []int{2, 3, 5, 7, 9, 2147483647 <(214)%20748-3647>}
>>>
>>> I checked on the internet and 2147483647 <(214)%20748-3647> is a prime 
>>> number (https://en.wikipedia.org/wiki/2,147,483,647), so this element 
>>> is fine.
>>>
>>> Best regards
>>> Kamil
>>>
>>> czwartek, 4 maja 2023 o 16:38:50 UTC+2 Kamil Ziemian napisał(a):
>>>
>>>> You convince me to your point Axel Wagner. At the same time if we look 
>>>> at examples in Go Spec, I think their can be improved.
>>>> "A0, A1, and []string 
>>>> A2 and struct{ a, b int } 
>>>> A3 and int A4, func(int, float64) *[]string, and A5 
>>>>
>>>> B0 and C0 
>>>> D0[int, string] and E0 
>>>> []int and []int 
>>>> struct{ a, b *B5 } and struct{ a, b *B5 } 
>>>> func(x int, y float64) *[]string, func(int, float64) (result 
>>>> *[]string), and A5"
>>>> I mean, first we need to check that A0, A1 and []string are the same 
>>>> type and after few examples like D0[int, string] is the same as E0, we 
>>>> have 
>>>> stated []int and []int are the same type. If you convince yourself that A0 
>>>> is the same as A1 and both are the same as []string, checking that []int 
>>>> has the same type as []int is quite trivial. I would prefer that examples 
>>>> would start from basic cases like []int is []int and []A3 is []int (if 
>>>> this 
>>>> one is true) and progress to more convoluted like D0[int, string] is E0.
>>>>
>>>> Best regards,
>>>> Kamil
>>>>
>>>> czwartek, 4 maja 2023 o 14:12:25 UTC+2 Axel Wagner napisał(a):
>>>>
>>>>> Personally, I'd rather add more examples of "self-evidently equal 
>>>>> types". In my opinion, all the type aliases in that block confuse matters 
>>>>> quite a bit.
>>>>>
>>>>> "[]int and []int are identical" is not actually self-evident at all. 
>>>>> It is self-evident that any sensible definition of type identity *should* 
>>>>> make them identical. But it's not self-evident that the given definition 
>>>>> *does*. Spelling that out in the example, means you are nudged to look at 
>>>>> the definition and see how their identity follows (by finding "Two slice 
>>>>> types are identical if they have identical element types").
>>>>>
>>>>> In fact, whenever you define an equivalence relation, proving that it 
>>>>> is reflexive is the very first step. And it's not always trivial. For 
>>>>> example, `==` on `float64` is *not* reflexive. It seems obvious that NaN 
>>>>> == 
>>>>> NaN *should* hold from how it's spelled - but it doesn't.
>>>>>
>>>>> So, I disagree that the examples should limit themselves to cases 
>>>>> where it's non-obvious that the two types should be identical.
>>>>>
>>>>> On Thu, May 4, 2023 at 12:35 PM Kamil Ziemian  
>>>>> wrote:
>>>>>
>>>>>> There is a second such example just below "[]int and []int", but to 
>>>>>> understand it we need some more type declarations, I listed the

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[Kamil Ziemian]

Is this example found in the "Composite literals" section of Go Spec a joke?
// list of prime numbers 
primes := []int{2, 3, 5, 7, 9, 2147483647}

I checked on the internet and 2147483647 is a prime number 
(https://en.wikipedia.org/wiki/2,147,483,647), so this element is fine.

Best regards
Kamil

czwartek, 4 maja 2023 o 16:38:50 UTC+2 Kamil Ziemian napisał(a):

> You convince me to your point Axel Wagner. At the same time if we look at 
> examples in Go Spec, I think their can be improved.
> "A0, A1, and []string 
> A2 and struct{ a, b int } 
> A3 and int A4, func(int, float64) *[]string, and A5 
>
> B0 and C0 
> D0[int, string] and E0 
> []int and []int 
> struct{ a, b *B5 } and struct{ a, b *B5 } 
> func(x int, y float64) *[]string, func(int, float64) (result *[]string), 
> and A5"
> I mean, first we need to check that A0, A1 and []string are the same type 
> and after few examples like D0[int, string] is the same as E0, we have 
> stated []int and []int are the same type. If you convince yourself that A0 
> is the same as A1 and both are the same as []string, checking that []int 
> has the same type as []int is quite trivial. I would prefer that examples 
> would start from basic cases like []int is []int and []A3 is []int (if this 
> one is true) and progress to more convoluted like D0[int, string] is E0.
>
> Best regards,
> Kamil
>
> czwartek, 4 maja 2023 o 14:12:25 UTC+2 Axel Wagner napisał(a):
>
>> Personally, I'd rather add more examples of "self-evidently equal types". 
>> In my opinion, all the type aliases in that block confuse matters quite a 
>> bit.
>>
>> "[]int and []int are identical" is not actually self-evident at all. It 
>> is self-evident that any sensible definition of type identity *should* make 
>> them identical. But it's not self-evident that the given definition *does*. 
>> Spelling that out in the example, means you are nudged to look at the 
>> definition and see how their identity follows (by finding "Two slice types 
>> are identical if they have identical element types").
>>
>> In fact, whenever you define an equivalence relation, proving that it is 
>> reflexive is the very first step. And it's not always trivial. For example, 
>> `==` on `float64` is *not* reflexive. It seems obvious that NaN == NaN 
>> *should* hold from how it's spelled - but it doesn't.
>>
>> So, I disagree that the examples should limit themselves to cases where 
>> it's non-obvious that the two types should be identical.
>>
>> On Thu, May 4, 2023 at 12:35 PM Kamil Ziemian  wrote:
>>
>>> There is a second such example just below "[]int and []int", but to 
>>> understand it we need some more type declarations, I listed them below.
>>> `type (
>>> A0 = []string
>>> A1 = A0
>>> A2 = struct{ a, b int }
>>> A3 = int
>>> A4 = func(A3, float64) *A0
>>> A5 = func(x int, _ float64) *[]string
>>>
>>> B0 A0
>>> B1 []string
>>> B2 struct{ a, b int }
>>> B3 struct{ a, c int }
>>> B4 func(int, float64) *B0
>>> B5 func(x int, y float64) *A1
>>>
>>> // Unimportant part.
>>> )`
>>> The line in question is
>>> "struct{ a, b *B5 } and struct{ a, b *B5 }"
>>> which is true, but again feel out of place. I only start grasping rules 
>>> of types identity, but I make guess that it should be something like
>>> "struct{ a, b *A5 } and struct{ a, b *B5 }"
>>>
>>> Of course it my just be that I'm just stupid. Feel free to inform me 
>>> that indeed I have no idea what is going on in the Go Spec.
>>>
>>> Best regards,
>>> Kamil
>>> czwartek, 4 maja 2023 o 12:20:35 UTC+2 Kamil Ziemian napisał(a):
>>>
>>>> Hello,
>>>>
>>>> In the section "Type identity" of Go Spec we read a list of type 
>>>> declarations
>>>> `type (
>>>> A0 = []string
>>>> A1 = A0
>>>> A2 = struct{ a, b int }
>>>> A3 = int
>>>> A4 = func(A3, float64) *A0
>>>> A5 = func(x int, _ float64) *[]string
>>>>
>>>> // Part unimportant for my point.
>>>> )`
>>>> and then we have list of types that are identical. Among them we can 
>>>> find text
>>>> "[]int and []int"
>>>> It is obviously true, but feel out of place. I make a humble guess that 
>>>> authors intended something along the lines
>>>> "[]A3 and []int&

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[Kamil Ziemian]

You convince me to your point Axel Wagner. At the same time if we look at 
examples in Go Spec, I think their can be improved.
"A0, A1, and []string 
A2 and struct{ a, b int } 
A3 and int A4, func(int, float64) *[]string, and A5 

B0 and C0 
D0[int, string] and E0 
[]int and []int 
struct{ a, b *B5 } and struct{ a, b *B5 } 
func(x int, y float64) *[]string, func(int, float64) (result *[]string), 
and A5"
I mean, first we need to check that A0, A1 and []string are the same type 
and after few examples like D0[int, string] is the same as E0, we have 
stated []int and []int are the same type. If you convince yourself that A0 
is the same as A1 and both are the same as []string, checking that []int 
has the same type as []int is quite trivial. I would prefer that examples 
would start from basic cases like []int is []int and []A3 is []int (if this 
one is true) and progress to more convoluted like D0[int, string] is E0.

Best regards,
Kamil

czwartek, 4 maja 2023 o 14:12:25 UTC+2 Axel Wagner napisał(a):

> Personally, I'd rather add more examples of "self-evidently equal types". 
> In my opinion, all the type aliases in that block confuse matters quite a 
> bit.
>
> "[]int and []int are identical" is not actually self-evident at all. It is 
> self-evident that any sensible definition of type identity *should* make 
> them identical. But it's not self-evident that the given definition *does*. 
> Spelling that out in the example, means you are nudged to look at the 
> definition and see how their identity follows (by finding "Two slice types 
> are identical if they have identical element types").
>
> In fact, whenever you define an equivalence relation, proving that it is 
> reflexive is the very first step. And it's not always trivial. For example, 
> `==` on `float64` is *not* reflexive. It seems obvious that NaN == NaN 
> *should* hold from how it's spelled - but it doesn't.
>
> So, I disagree that the examples should limit themselves to cases where 
> it's non-obvious that the two types should be identical.
>
> On Thu, May 4, 2023 at 12:35 PM Kamil Ziemian  wrote:
>
>> There is a second such example just below "[]int and []int", but to 
>> understand it we need some more type declarations, I listed them below.
>> `type (
>> A0 = []string
>> A1 = A0
>> A2 = struct{ a, b int }
>> A3 = int
>> A4 = func(A3, float64) *A0
>> A5 = func(x int, _ float64) *[]string
>>
>> B0 A0
>> B1 []string
>> B2 struct{ a, b int }
>> B3 struct{ a, c int }
>> B4 func(int, float64) *B0
>> B5 func(x int, y float64) *A1
>>
>> // Unimportant part.
>> )`
>> The line in question is
>> "struct{ a, b *B5 } and struct{ a, b *B5 }"
>> which is true, but again feel out of place. I only start grasping rules 
>> of types identity, but I make guess that it should be something like
>> "struct{ a, b *A5 } and struct{ a, b *B5 }"
>>
>> Of course it my just be that I'm just stupid. Feel free to inform me that 
>> indeed I have no idea what is going on in the Go Spec.
>>
>> Best regards,
>> Kamil
>> czwartek, 4 maja 2023 o 12:20:35 UTC+2 Kamil Ziemian napisał(a):
>>
>>> Hello,
>>>
>>> In the section "Type identity" of Go Spec we read a list of type 
>>> declarations
>>> `type (
>>> A0 = []string
>>> A1 = A0
>>> A2 = struct{ a, b int }
>>> A3 = int
>>> A4 = func(A3, float64) *A0
>>> A5 = func(x int, _ float64) *[]string
>>>
>>> // Part unimportant for my point.
>>> )`
>>> and then we have list of types that are identical. Among them we can 
>>> find text
>>> "[]int and []int"
>>> It is obviously true, but feel out of place. I make a humble guess that 
>>> authors intended something along the lines
>>> "[]A3 and []int"
>>> Can someone look at this part of Go Spec? I feel that someone make a 
>>> mistake, but at the same time humble me saying that there is any mistake in 
>>> the Go Spec is something that I shouldn't do.
>>>
>>> Best regards,
>>> Kamil
>>> poniedziałek, 8 listopada 2021 o 10:59:23 UTC+1 Kamil Ziemian napisał(a):
>>>
>>>> Thank you Jan Mercl, now I start to understand this rule.
>>>>
>>>> Best
>>>> Kamil
>>>>
>>>> niedziela, 7 listopada 2021 o 19:34:41 UTC+1 Jan Mercl napisał(a):
>>>>
>>>>> On Sun, Nov 7, 2021 at 7:23 PM Kamil Ziemian  
>>>>> wrote: 
>>>>>
>>>>>

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[Kamil Ziemian]

There is a second such example just below "[]int and []int", but to 
understand it we need some more type declarations, I listed them below.
`type (
A0 = []string
A1 = A0
A2 = struct{ a, b int }
A3 = int
A4 = func(A3, float64) *A0
A5 = func(x int, _ float64) *[]string

B0 A0
B1 []string
B2 struct{ a, b int }
B3 struct{ a, c int }
B4 func(int, float64) *B0
B5 func(x int, y float64) *A1

// Unimportant part.
)`
The line in question is
"struct{ a, b *B5 } and struct{ a, b *B5 }"
which is true, but again feel out of place. I only start grasping rules of 
types identity, but I make guess that it should be something like
"struct{ a, b *A5 } and struct{ a, b *B5 }"

Of course it my just be that I'm just stupid. Feel free to inform me that 
indeed I have no idea what is going on in the Go Spec.

Best regards,
Kamil
czwartek, 4 maja 2023 o 12:20:35 UTC+2 Kamil Ziemian napisał(a):

> Hello,
>
> In the section "Type identity" of Go Spec we read a list of type 
> declarations
> `type (
> A0 = []string
> A1 = A0
> A2 = struct{ a, b int }
> A3 = int
> A4 = func(A3, float64) *A0
> A5 = func(x int, _ float64) *[]string
>
> // Part unimportant for my point.
> )`
> and then we have list of types that are identical. Among them we can find 
> text
> "[]int and []int"
> It is obviously true, but feel out of place. I make a humble guess that 
> authors intended something along the lines
> "[]A3 and []int"
> Can someone look at this part of Go Spec? I feel that someone make a 
> mistake, but at the same time humble me saying that there is any mistake in 
> the Go Spec is something that I shouldn't do.
>
> Best regards,
> Kamil
> poniedziałek, 8 listopada 2021 o 10:59:23 UTC+1 Kamil Ziemian napisał(a):
>
>> Thank you Jan Mercl, now I start to understand this rule.
>>
>> Best
>> Kamil
>>
>> niedziela, 7 listopada 2021 o 19:34:41 UTC+1 Jan Mercl napisał(a):
>>
>>> On Sun, Nov 7, 2021 at 7:23 PM Kamil Ziemian  
>>> wrote: 
>>>
>>> > Can anyone give me explicit example when semicolon is omitted in 
>>> accordance to the second rule and explanation where it should be? I 
>>> probably see such situations dozens of times, I just not know that they 
>>> would needed semicolon in some places. 
>>>
>>> I think this is a simple example: https://play.golang.org/p/ZfKxTos6GjY 
>>>
>>> Click "Run" to see the code is valid, then "Format" to watch one 
>>> semicolon disappear and then "Run" again to see it's still valid code. 
>>>
>>

-- 
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/001d0306-0a43-4680-a03c-3dc87e89dc5an%40googlegroups.com.

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[Kamil Ziemian]

Hello,

In the section "Type identity" of Go Spec we read a list of type 
declarations
`type (
A0 = []string
A1 = A0
A2 = struct{ a, b int }
A3 = int
A4 = func(A3, float64) *A0
A5 = func(x int, _ float64) *[]string

// Part unimportant for my point.
)`
and then we have list of types that are identical. Among them we can find 
text
"[]int and []int"
It is obviously true, but feel out of place. I make a humble guess that 
authors intended something along the lines
"[]A3 and []int"
Can someone look at this part of Go Spec? I feel that someone make a 
mistake, but at the same time humble me saying that there is any mistake in 
the Go Spec is something that I shouldn't do.

Best regards,
Kamil
poniedziałek, 8 listopada 2021 o 10:59:23 UTC+1 Kamil Ziemian napisał(a):

> Thank you Jan Mercl, now I start to understand this rule.
>
> Best
> Kamil
>
> niedziela, 7 listopada 2021 o 19:34:41 UTC+1 Jan Mercl napisał(a):
>
>> On Sun, Nov 7, 2021 at 7:23 PM Kamil Ziemian  wrote: 
>>
>> > Can anyone give me explicit example when semicolon is omitted in 
>> accordance to the second rule and explanation where it should be? I 
>> probably see such situations dozens of times, I just not know that they 
>> would needed semicolon in some places. 
>>
>> I think this is a simple example: https://play.golang.org/p/ZfKxTos6GjY 
>>
>> Click "Run" to see the code is valid, then "Format" to watch one 
>> semicolon disappear and then "Run" again to see it's still valid code. 
>>
>

-- 
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/83a97c7c-9a79-41ff-a02d-6a1812db4059n%40googlegroups.com.

Re: [go-nuts] Help me study resources or guides

[Kamil Ziemian]

Hello,

I now try to read "Go Language Specification", which you must read to 
became true Gopher. If you want to read this document, I offer all my help, 
but not overestimate me. Recently I even doubt if I'm programmer at all, 
maybe just advanced hobbyist.

Because Go Spec my by too much for the begining I strongly advice you go 
trough all the "A Tour of Go".
https://go.dev/tour/welcome/1
"A Tour of Go" is easy, outside few excercise that need a background 
knowledge in things like networking. In any case, if you will have any 
question about "A Tour of Go" feel free to ask.

One thing I think is worth of pointing out in the context of "A Tour of 
Go". When we talk about language itself, not its toolchain, there was only 
Big addition with big "B" to it since the version 1.0 was introduced in the 
2012. By it I mean generics (or like Rob Pike call them more correctly: 
parametric polymorphism) introduced with Go 1.18 around February 2022. The 
part of "A Tour of Go" is that introduce generics is the only part that I 
don't like. It is too short and too sketchy for my taste.

I learn quite a lot about generics reading proposal of them, at the time 
where was no implementation of them in the language, but I cannot these 
proposals as a learning materials. Ian Lance Taylor, which is one of the 
highest Go authorities in the world, once stated here that even the last 
proposal of generics isn't what is in the language, due to some changes 
make during the phase of implementation (at least this is what I understood 
from his words). Taylor said that if you know how generics works in Go, you 
should read Go Spec, which I currently doing. As a result, I cannot give 
you any point where to learn generics, since I still don't know if 
particular part of is appropriate for the beginners and I don't know an 
good ones at this moment. Maybe someone else can point to such good 
resource.

At the bright side of things, I think generics are the last thing that you 
should learn in Go. They are important, but since are the last Addition 
with big "A" to the language, you should leave them to the end. At least in 
the my opinion.

Best regards,
Kamil Ziemian
wtorek, 2 maja 2023 o 18:52:56 UTC+2 Rajesh Pandian napisał(a):

> HI Nyilynn,
>
> I have watched Matt's Golang videos about concurrency and few others and I 
> have to say it is Brilliant!  I highly recommend it. (And Thank you Matt 
> for the brilliant content!!  )
>
> If you are interested in books then "Learning Go" from O'reilly was also 
> helpful to me. If you want start from absolute basic then "Head First Go" 
> is a good book too. I have all these two and the "The Go programming 
> language book which I frequently refer to as it's written by Brian W. 
> Kernighan and Alan A. A. Donovan which is a must have book if you reading 
> Go.
>
> And finally, practice and practise! As a Mandalorian would say "This is 
> the way" 
>
> Regards,
> Rajesh
>
>
>
>
>
>
>
>
> On Friday, April 28, 2023 at 8:52:34 PM UTC+5:30 Matt KØDVB wrote:
>
>> You can find my video class at 
>> https://www.youtube.com/playlist?list=PLoILbKo9rG3skRCj37Kn5Zj803hhiuRK6; 
>> people seem to like it
>>
>> Matt
>>
>> On Apr 26, 2023, at 9:45 PM, Nyilynn Htwe  wrote:
>>
>> I am starting to learn GO programming language with this course 
>> <https://www.coursera.org/specializations/google-golang>. Can you all 
>> guide me how to learn and how to be geek at Go? 
>> Thank you for reading
>>
>> -- 
>> 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/e12e-c9c9-4481-b0eb-c33a6632b768n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/e12e-c9c9-4481-b0eb-c33a6632b768n%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/bc042fc0-05c6-45a8-89b2-48aa7eeaa60cn%40googlegroups.com.

Re: [go-nuts] Various questions about posts from The Go Blog

[Kamil Ziemian]

Jan Mercl you right that only TestHello is broken, but it is still broken. 
As I said, the fact that such simple code in not portable is disturbing. I 
guess most of the code is tested on OS with English as the main language, 
at least code for this blog post seems to be, so you can guess what else 
may be broken but such silly bug? I guess not much, but this is still 
disturbing.

I have another problem, I don't understand what happened since version 1.13 
of Go with go.mod file. According to the post "Using Go Modules" 
https://go.dev/blog/using-go-modules "Only direct dependencies are recorded 
in the go.mod file". Today it seems that go.mod also list indirect 
dependencies, which is very good idea.

But I cannot understand why in the blog post we have in go.mod file
require rsc.io/quote v1.5.2
so "rsc.io/quote" is considered direct dependency, while go.mod produced by 
Go 1.20 give me
rsc.io/quote v1.5.2 // indirect
so now "rsc.io/quote" is indirect dependency, even when I write in package
import "rsc.io/quote"

I would be glad for any word of explanation.

Best regards,
Kamil

niedziela, 26 marca 2023 o 19:55:52 UTC+2 Jan Mercl napisał(a):

> The only broken thing in the code below is the TestHello function.
> rsc.io/quote uses rsc.io/sampler where the Hello func
> (https://pkg.go.dev/rsc.io/sampler#Hello) is documented to return a
> localized string by default. Localized, in the sense of respecting the
> user's locale. That is not compatible with your test function
> expecting to always get the same string regardless of locale. That's a
> bug.
>
> On Sun, Mar 26, 2023 at 7:47 PM Kamil Ziemian  wrote:
>
> > According to the law that any change can break your program/workflow, I 
> want to mention that code shown in "Using Go Modules" 
> https://go.dev/blog/using-go-modules is broken in funny way.
> >
> > Consider code below
> > package hello
> >
> > import "rsc.io/quote"
> >
> > func Hello() string {
> > return quote.Hello()
> > }
> >
> > We also have test file
> > package hello
> >
> > import "testing"
> >
> > func TestHello(t *testing.T) {
> > want := "Hello, world."
> > if got := Hello(); got != want {
> > t.Errorf("Hello() = %q, want %q", got, want)
> > }
> > }
> >
> > So I run `go test' and get
> > --- FAIL: TestHello (0.00s)
> > hello_test.go:9: Hello() = "Witaj świecie.", want "Hello, world."
> > FAIL
> > exit status 1
> > FAIL example.com/hello 0.002s
> >
> > What happened? My first language is polish, so my system, Ubuntu 22.04, 
> use it as main language. In some way "rsc.io/quote" figure it out and now 
> function quote.Hello() returns "Witaj świecie.", which in polish mean 
> "Hello, world.". Since we compered result we get with string "Hello, 
> world." we obviously fail the test.
> >
> > This is just teaching example, so this is not so big deal, but fact that 
> some code of this type is not portable between OS with different languages 
> is a bit disturbing.
>

-- 
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/86f5e89b-f65b-4936-9d59-75192e8fa6d2n%40googlegroups.com.

Re: [go-nuts] Various questions about posts from The Go Blog

[Kamil Ziemian]

Hello,

According to the law that any change can break your program/workflow, I 
want to mention that code shown in "Using Go Modules" 
https://go.dev/blog/using-go-modules is broken in funny way.

Consider code below
package hello

import "rsc.io/quote"

func Hello() string {
return quote.Hello()
}

We also have test file
package hello

import "testing"

func TestHello(t *testing.T) {
want := "Hello, world."
if got := Hello(); got != want {
t.Errorf("Hello() = %q, want %q", got, want)
}
}

So I run `go test' and get
--- FAIL: TestHello (0.00s)
hello_test.go:9: Hello() = "Witaj świecie.", want "Hello, world."
FAIL
exit status 1
FAIL example.com/hello 0.002s

What happened? My first language is polish, so my system, Ubuntu 22.04, use 
it as main language. In some way "rsc.io/quote" figure it out and now 
function quote.Hello() returns "Witaj świecie.", which in polish mean 
"Hello, world.". Since we compered result we get with string "Hello, 
world." we obviously fail the test.

This is just teaching example, so this is not so big deal, but fact that 
some code of this type is not portable between OS with different languages 
is a bit disturbing.

Best regards,
Kamil

niedziela, 26 marca 2023 o 19:36:59 UTC+2 Kamil Ziemian napisał(a):

> Hello,
>
> I try to learn how to use Go modules and Google PhD, recomended me Go blog 
> post "Using Go Modules" https://go.dev/blog/using-go-modules. It seems a 
> bit outdated and I want ask, if it so, should I use other source? I should 
> mention that I like Go blog.
>
> Example of things outdated, considering Go 1.20.
> 1) Running `go test' in directory without Go module doesn't run a test, 
> but writes something like "go: cannot find go module but find .git/confing 
> in ...".
> 2) After adding `import "rsc.io/quote"` to package hello, running go test 
> doesn't download for you rsc.io/quote, but insted you get
> hello.go:3:8: no required module provides package rsc.io/quote; to add it:
> go get rsc.io/quote
>
> I consider both changes improvement of Go workflow, but they may be 
> confused for total begginers.
>
> Best regards,
> Kamil
> poniedziałek, 24 stycznia 2022 o 23:56:46 UTC+1 Ian Lance Taylor 
> napisał(a):
>
>> On Mon, Jan 24, 2022 at 6:38 AM Kamil Ziemian  
>> wrote:, 
>> > 
>> > I have one more think to say about Go blog post "Why generics?". Again, 
>> nothing really important. 
>> > 
>> > In the section "Generic data structures" in the second counting from 
>> the end code example we have line. 
>> > > *pn = &node(E){val: v} 
>> > It is commented by the sentence "Notice the type argument E to the type 
>> node.". Maybe it should be "Notice the type argument E send to the type 
>> node."? Currently it sound odd to my ears. 
>> > 
>> > Also, I found out that in "Go 1.18 Beta 1 is available, with generics" (
>> https://go.dev/blog/go1.18beta1) written by Russ Cox on behalf of the Go 
>> team, post "Why generics?" is referenced in prominent place in third 
>> paragraph. I think it another reason to add block text to "Why generics?" 
>> to make clear for readers that they need to be aware, that actually 
>> implementation in beta of Go 18 at syntax level is quite different than 
>> that presented in this blog post. 
>> > 
>> > Best, 
>> > Kamil Ziemian 
>> > poniedziałek, 24 stycznia 2022 o 12:47:11 UTC+1 Kamil Ziemian 
>> napisał(a): 
>> >> 
>> >> Hello, 
>> >> 
>> >> Since with release of Go 1.18 we will have Go's generics, I started a 
>> preparation tour around Go blog and YouTube. And here is one suggestion and 
>> one unimportant comment of mine about blog post "Why Generics?" (
>> https://go.dev/blog/why-generics). 
>> >> 
>> >> This post is in my opinion very valuable, fortunately Go team abandons 
>> change few ideas to better ones, like removing concept of "contracts" in 
>> the name of new functionality of interfaces. In such situation I propose to 
>> add at the top of the page text block saying "Caution. Implementation of 
>> generics in Go different from draft discussed here. To learn about actual 
>> implementation of generics check [link to relevant materials]." 
>> >> 
>> >> Now unimportant comment. At the end of the section "Ordered types" we 
>> have paragraph 
>> >> "In practice this contract would probably go in

Re: [go-nuts] Various questions about posts from The Go Blog

[Kamil Ziemian]

Hello,

I try to learn how to use Go modules and Google PhD, recomended me Go blog 
post "Using Go Modules" https://go.dev/blog/using-go-modules. It seems a 
bit outdated and I want ask, if it so, should I use other source? I should 
mention that I like Go blog.

Example of things outdated, considering Go 1.20.
1) Running `go test' in directory without Go module doesn't run a test, but 
writes something like "go: cannot find go module but find .git/confing in 
...".
2) After adding `import "rsc.io/quote"` to package hello, running go test 
doesn't download for you rsc.io/quote, but insted you get
hello.go:3:8: no required module provides package rsc.io/quote; to add it:
go get rsc.io/quote

I consider both changes improvement of Go workflow, but they may be 
confused for total begginers.

Best regards,
Kamil
poniedziałek, 24 stycznia 2022 o 23:56:46 UTC+1 Ian Lance Taylor napisał(a):

> On Mon, Jan 24, 2022 at 6:38 AM Kamil Ziemian  wrote:,
> >
> > I have one more think to say about Go blog post "Why generics?". Again, 
> nothing really important.
> >
> > In the section "Generic data structures" in the second counting from the 
> end code example we have line.
> > > *pn = &node(E){val: v}
> > It is commented by the sentence "Notice the type argument E to the type 
> node.". Maybe it should be "Notice the type argument E send to the type 
> node."? Currently it sound odd to my ears.
> >
> > Also, I found out that in "Go 1.18 Beta 1 is available, with generics" (
> https://go.dev/blog/go1.18beta1) written by Russ Cox on behalf of the Go 
> team, post "Why generics?" is referenced in prominent place in third 
> paragraph. I think it another reason to add block text to "Why generics?" 
> to make clear for readers that they need to be aware, that actually 
> implementation in beta of Go 18 at syntax level is quite different than 
> that presented in this blog post.
> >
> > Best,
> > Kamil Ziemian
> > poniedziałek, 24 stycznia 2022 o 12:47:11 UTC+1 Kamil Ziemian napisał(a):
> >>
> >> Hello,
> >>
> >> Since with release of Go 1.18 we will have Go's generics, I started a 
> preparation tour around Go blog and YouTube. And here is one suggestion and 
> one unimportant comment of mine about blog post "Why Generics?" (
> https://go.dev/blog/why-generics).
> >>
> >> This post is in my opinion very valuable, fortunately Go team abandons 
> change few ideas to better ones, like removing concept of "contracts" in 
> the name of new functionality of interfaces. In such situation I propose to 
> add at the top of the page text block saying "Caution. Implementation of 
> generics in Go different from draft discussed here. To learn about actual 
> implementation of generics check [link to relevant materials]."
> >>
> >> Now unimportant comment. At the end of the section "Ordered types" we 
> have paragraph
> >> "In practice this contract would probably go into the standard library, 
> and so really the Min function (which will probably also be in the standard 
> library somewhere) will look like this. Here we’re just referring to the 
> contract Ordered defined in the package contracts."
> >> All this text use one kind of font, which contrast with all the rest of 
> the post. Names of Go functions such as "Min" and meta-types as "Ordered" 
> to this point was always typed with different font. I think this is simple, 
> unimportant mistake.
>
>
> Thanks, I sent https://go.dev/cl/380574 to address these issues.
>
> Ian
>

-- 
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/c59285e5-4dde-4e0c-a9e9-036f84439352n%40googlegroups.com.

Re: [go-nuts] With Go support of Generics I don't sure If interfaces are really about methods (behavior)

[Kamil Ziemian]

In the past that was idea to introduce new concept to Go, it was called 
"contract" if I remember correctly. With it we would write
type myNumber contract {
int | float64
}
Along the way they realize that contracts are just interface with few 
additions, so we ended where we are. Also it means no new keyword to the 
language which is of very high value for Go.

>From what I remember from year ago, you should distinguish between 
interface describing type and describing pure constraint. If you have 
interface
type Line interface {
Length() float64
Angle() float64
}
it can be used as both type and as constraint. You can write function
func Rotation(l Line) Line {
...
}
so Line here function as any other type. At the same time you can use it in 
generic function
func Draw[T Line](l T) outputType {
...
}
I hope that this example is right. And since such interface is defined just 
by listing its methods it is true that "Interfaces are about behaviors, not 
data". 

On the other hand I believe that you CANNOT write
func MyAdd(x myNumber, y myNumber) myNumber {
...
}
>From what I remember, when you write inside an interface anything other 
than method, it become pure constraint, as such it can be only used for 
type constraints in generic functions.

We can avoid this thing by introducing word "conrtract" (or some other 
word), but again, it was judged as more contrary to Go approach, than 
extending the meaning of interface.

Best regards,
Kamil


piątek, 24 lutego 2023 o 20:55:31 UTC+1 Ian Lance Taylor napisał(a):

On Fri, Feb 24, 2023 at 9:22 AM Mohab Alnajjar  wrote: 
> 
> As we always say: "Interfaces are about behaviors, not data". However, 
when it comes to Generics the only way to make type parameter constraints 
is by listing types in the interface! (Interface type list): 
> 
> type myNumber interface { 
> int | float64 
> // Other methods signatures 
> } 
> 
> This is very WEIRD to me and I didn't think it make sense. because it 
makes me think about interfaces in a different way. 
> 
> Is there any point in such a design? 

The design was worked out over many years of intensive public 
discussion involving many people. I wouldn't say that everybody 
agreed with all the decisions, but I do think that we got to a place 
where everybody could at least live with it. The result was released 
a year ago and many people are using it successfully. 

So, yes, there is a point to the design. 

Ian 

-- 
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/64ed9c14-460f-4b06-864a-694fe1e54e62n%40googlegroups.com.

Re: [go-nuts] Re: clarifying Go FAQ: Is Go an object-oriented language?

[Kamil Ziemian]

"Saying "yes or no" is a non-answer. :)"
>From people new to coding, I guess so. For people with good background, 
this is a good answer, since rest of the FAQ entry explain enough that they 
can say "Ok. I think I'm getting it.". BTW in FAQ it is "Yes and no.".

So true question is: who is asking and how detailed answer he or she needs?

Best regards,
Kamil
czwartek, 24 listopada 2022 o 12:44:56 UTC+1 Kamil Ziemian napisał(a):

> I will start with cautionary tell. At one of his public talks Bjarne 
> Stroustrup in some way, admited that he made a very bad job when teaching 
> people C++ and now we must live with many bad practices being a norm and 
> even adviced as good practices. In Stroustrup words
> "I didn't care about "Let them hear your message", "Show them the vision". 
> I was thinking, that it just a rabbish. It is not.".
>
> I would classify all questions like "Is Go OOP language?" in the category  
> "Let them hear your message". People like Rob Pike, Robert Griesemer and 
> Ian Lance Taylor probably don't need any labels like that, since, at the 
> end of the day, these labels answer very little important questions and 
> they can just go to the heart of the matter. But, let face it, very few 
> people is on thier level, especiall among newcommers.
>
> We know how much hot topic was "generics in Go" (one of the less know part 
> of the language in may case), when Robert Griesemer can just say in his 
> talks about adding them to Go "Generics are just glorified (type checked) 
> macros" (GopherCon 2020). For me it is one of the signs of how good people 
> like Griesemer are: for them the many hottest topics are just "no big deal".
>
> Previously, rightly, it was observed that 1990s OOP was a huge fad. 
> Unfortunetly, it is still big fad in many places. I'm from Poland, where 
> the most popular book, which I read myself as the beginner, in the last 30 
> years on C++ is written with this OOP fad spirit. And from many reasons, 
> people in Poland in the age span 15-25 still today starts they programming 
> journej with this book. People raised in such enviroment, when comming to 
> any other language will be asking "Is it OOP?". Languages for which answer 
> is "Yes" will be classified as "cool" and these for which answer is "No" as 
> "Uncool, outdated and passe". Which is rabbish, but new people just don't 
> know better.
>
> If this discussion about "Is X OOP language?" was just about which labels 
> applies where, I would probably shrug and go do more important things. But, 
> I consider it a case of "Let them hear you message" to use this slogan, and 
> I happy to spend some of my time expleining people who ask what I 
> understand about Go. For the same reason, I consider spending time in this 
> thread, a things that can lead to something valuable.
>
> Best regards,
> Kamil
> czwartek, 24 listopada 2022 o 11:40:45 UTC+1 Kamil Ziemian napisał(a):
>
>> " Let me ask, because I'm genuinely curious: Why does it matter? The 
>> labels we apply to things do not affect their function. Perhaps it affects 
>> how we think about them. Is that it?"
>> My point of view is that. In the moment when you learn the flow of 
>> language X, it doesn't matter. But, it is not a thing that you get without 
>> some work and many mistakes done along the way.
>>
>> Before that labels are important on at least two levels.
>> 1) As promotion/marketing tool. If someone think that OOP is cool, he 
>> would here that language X is OOP he would think "O, new language doing OOP 
>> in new cool way. Maybe I should learn it? You know, OOP is cool".
>> 2) As a guide for the people what to think and how to use about language 
>> X. In the original post was already mention, that C++ and Java programers 
>> have problem with writting good code in Go. My feeling is that, they try 
>> write C++/Java code in Go, "they all OOP languages", which is missing the 
>> point.
>>
>> Hard truth is that for most people, me included, our ways of thinking 
>> (about everything) and of coding ossified and stiffen after a time and we 
>> need to put quite a work to make them fresh and flexible again. To use 
>> somewhat radicolous example, if you put label "bike" on washing machine 
>> some people will try to ride to work on it and they will complaine, that is 
>> not very good bike.
>>
>> Best regards,
>> Kamil
>> czwartek, 24 listopada 2022 o 02:27:57 UTC+1 Rob 'Commander' Pike 
>

Re: [go-nuts] Re: clarifying Go FAQ: Is Go an object-oriented language?

[Kamil Ziemian]

I will start with cautionary tell. At one of his public talks Bjarne 
Stroustrup in some way, admited that he made a very bad job when teaching 
people C++ and now we must live with many bad practices being a norm and 
even adviced as good practices. In Stroustrup words
"I didn't care about "Let them hear your message", "Show them the vision". 
I was thinking, that it just a rabbish. It is not.".

I would classify all questions like "Is Go OOP language?" in the category  
"Let them hear your message". People like Rob Pike, Robert Griesemer and 
Ian Lance Taylor probably don't need any labels like that, since, at the 
end of the day, these labels answer very little important questions and 
they can just go to the heart of the matter. But, let face it, very few 
people is on thier level, especiall among newcommers.

We know how much hot topic was "generics in Go" (one of the less know part 
of the language in may case), when Robert Griesemer can just say in his 
talks about adding them to Go "Generics are just glorified (type checked) 
macros" (GopherCon 2020). For me it is one of the signs of how good people 
like Griesemer are: for them the many hottest topics are just "no big deal".

Previously, rightly, it was observed that 1990s OOP was a huge fad. 
Unfortunetly, it is still big fad in many places. I'm from Poland, where 
the most popular book, which I read myself as the beginner, in the last 30 
years on C++ is written with this OOP fad spirit. And from many reasons, 
people in Poland in the age span 15-25 still today starts they programming 
journej with this book. People raised in such enviroment, when comming to 
any other language will be asking "Is it OOP?". Languages for which answer 
is "Yes" will be classified as "cool" and these for which answer is "No" as 
"Uncool, outdated and passe". Which is rabbish, but new people just don't 
know better.

If this discussion about "Is X OOP language?" was just about which labels 
applies where, I would probably shrug and go do more important things. But, 
I consider it a case of "Let them hear you message" to use this slogan, and 
I happy to spend some of my time expleining people who ask what I 
understand about Go. For the same reason, I consider spending time in this 
thread, a things that can lead to something valuable.

Best regards,
Kamil
czwartek, 24 listopada 2022 o 11:40:45 UTC+1 Kamil Ziemian napisał(a):

> " Let me ask, because I'm genuinely curious: Why does it matter? The 
> labels we apply to things do not affect their function. Perhaps it affects 
> how we think about them. Is that it?"
> My point of view is that. In the moment when you learn the flow of 
> language X, it doesn't matter. But, it is not a thing that you get without 
> some work and many mistakes done along the way.
>
> Before that labels are important on at least two levels.
> 1) As promotion/marketing tool. If someone think that OOP is cool, he 
> would here that language X is OOP he would think "O, new language doing OOP 
> in new cool way. Maybe I should learn it? You know, OOP is cool".
> 2) As a guide for the people what to think and how to use about language 
> X. In the original post was already mention, that C++ and Java programers 
> have problem with writting good code in Go. My feeling is that, they try 
> write C++/Java code in Go, "they all OOP languages", which is missing the 
> point.
>
> Hard truth is that for most people, me included, our ways of thinking 
> (about everything) and of coding ossified and stiffen after a time and we 
> need to put quite a work to make them fresh and flexible again. To use 
> somewhat radicolous example, if you put label "bike" on washing machine 
> some people will try to ride to work on it and they will complaine, that is 
> not very good bike.
>
> Best regards,
> Kamil
> czwartek, 24 listopada 2022 o 02:27:57 UTC+1 Rob 'Commander' Pike 
> napisał(a):
>
>> Let me ask, because I'm genuinely curious: Why does it matter? The labels 
>> we apply to things do not affect their function. Perhaps it affects how we 
>> think about them. Is that it?
>>
>> -rob
>>
>>

-- 
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/b5b01263-8634-4ec8-847c-51db5a8699bbn%40googlegroups.com.

Re: [go-nuts] Re: clarifying Go FAQ: Is Go an object-oriented language?

[Kamil Ziemian]

" Let me ask, because I'm genuinely curious: Why does it matter? The labels 
we apply to things do not affect their function. Perhaps it affects how we 
think about them. Is that it?"
My point of view is that. In the moment when you learn the flow of language 
X, it doesn't matter. But, it is not a thing that you get without some work 
and many mistakes done along the way.

Before that labels are important on at least two levels.
1) As promotion/marketing tool. If someone think that OOP is cool, he would 
here that language X is OOP he would think "O, new language doing OOP in 
new cool way. Maybe I should learn it? You know, OOP is cool".
2) As a guide for the people what to think and how to use about language X. 
In the original post was already mention, that C++ and Java programers have 
problem with writting good code in Go. My feeling is that, they try write 
C++/Java code in Go, "they all OOP languages", which is missing the point.

Hard truth is that for most people, me included, our ways of thinking 
(about everything) and of coding ossified and stiffen after a time and we 
need to put quite a work to make them fresh and flexible again. To use 
somewhat radicolous example, if you put label "bike" on washing machine 
some people will try to ride to work on it and they will complaine, that is 
not very good bike.

Best regards,
Kamil
czwartek, 24 listopada 2022 o 02:27:57 UTC+1 Rob 'Commander' Pike 
napisał(a):

> Let me ask, because I'm genuinely curious: Why does it matter? The labels 
> we apply to things do not affect their function. Perhaps it affects how we 
> think about them. Is that it?
>
> -rob
>
>

-- 
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/9686ccdc-c9be-4238-a654-ac95c92334c1n%40googlegroups.com.

[go-nuts] Re: clarifying Go FAQ: Is Go an object-oriented language?

[Kamil Ziemian]

"But I feel like programmers bringing their ideas from other less 
ambiguously object oriented languages like Java and C++ often have 
difficulty writing idiomatic Go."
I personally think that Java and C++ are less ambiguously OOP, only because 
we informally define OOP language as "language that is similar enough to 
C++ or Java". But this is like defining car as being something that looks 
like Mercedes and then discussing problem "Is Toyota similar enough to 
Mercedes, to be called a car?".

We also should notice that Alan Kay, man that coined term OOP, said that in 
his opinion there are two languages that can be consider as OOP: Smalltalk 
and Lisp. Notable, he didn't think that C++ and Java counts as such.

I have no doubts that Java and C++ programmers would have a problem, at the 
beginning, with writing idiomatic Go. This is because, in my opinion and in 
much simplifies form, C++ is about gathering stuff, while Go is about 
adding behavior and abstracting from that on. To make you thing more clear, 
in C++ you gather all you data and functions in one entity that you call 
class. In Go, what you should do it to define some struct that gather data 
and after that you add methods that provide functionality for this data. 
Distinction between gathering and adding functionality, is probably more 
about feeling that how things working under the hood, but because we feel 
or don't feel a language, we can or can't write idiomatic code.

Going back to comparison, when you add enough functionality to some type in 
Go by writing methods, you can use interface to abstract from gathered 
data, to write code that care only about functionality. If we can do the 
same things with two different types, we don't care what data is inside of 
them. We don't care is square and circle have the same underlying data. If 
all we need to know is how to take their area and how to move them, we can 
ignore what is under the hood.

At this moment I cannot thing about good equivalent of Go interface in C++ 
(I don't know Java). I would guess that, maybe, it is closer to C++ 
template and far cry from inheritance. But this is a topic for another time.

I hope I didn't mess these things up.

Best regards,
Kamil
wtorek, 22 listopada 2022 o 16:05:25 UTC+1 ay...@ayan.net napisał(a):

>
> The Go FAQ begins the answer to the question, "Is Go an object-oriented 
> language," with, "yes and no."
>
>   https://go.dev/doc/faq#Is_Go_an_object-oriented_language
>
> The section goes on to say that Go has methods but there is no type 
> hierarchy.  I guess those are the yes and no.
>
> But I feel like programmers bringing their ideas from other less 
> ambiguously object oriented languages like Java and C++ often have 
> difficulty writing idiomatic Go.
>
> If the answer to that question is "yes and no," it'd be less ambiguous to 
> simply say, "no."  And that would be a definitive way of indicating that it 
> woul be inappropriate to apply many patterns from object oriented languages 
> to Go -- and to encourage people to accept Go for what it is.
>
> Since receivers are parameters and one could use methods without using the 
> method calling syntax at all, I'd suggest we'd classify it as a structured 
> programming language with methods.
>
> In either case, is there a way to make the FAQ more clear on this point?
>
> -ayan
>
>
>
>

-- 
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/dae9f6d6-d5f7-4242-9b14-4c95d42abdc9n%40googlegroups.com.

Re: [go-nuts] clarifying Go FAQ: Is Go an object-oriented language?

[Kamil Ziemian]

I think in the 1990s it was a debate if Lisp with Common List Object System 
(CLOS) is OOP language. The answer they arrive was something like that.
"No, if your definition of OOP is based on C++. But, why your definition of 
OOP should be based on C++?"

I think the same fits Go. Go is in many ways not a C++-like language, so if 
C++ is for someone golden standard of property X, then Go probably doesn't 
have X.

For these reasons I don't like question is language X is OOP? What matters 
for X = Go for me is that it provides you power to create new data types 
and abstractions that allow you to write reusable code. And it do it very 
well.

Best regards,
Kamil

środa, 23 listopada 2022 o 05:27:08 UTC+1 ren...@ix.netcom.com napisał(a):

> That seems nonsensical to me. What is the square root of a string?
>
> Types aka classes define properties and behavior. 
>
> Cars do not fly. Planes don’t use roads. Classes are abstractions that 
> model required attributes that in turn compose a system to do useful work. 
> Both boats and cars move. You can use a boat to get from a to b if there is 
> no water. 
>
> Go is OO like. Or Go is not OO. There’s reasoning to support both but 
> don’t mangle OO to make the claim. 
>
> On Nov 22, 2022, at 11:04 AM, 'Thomas Bushnell BSG' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
> 
>
> Late binding means you don't need to know the types of your parameters *at 
> all* when you write a method call. If the language supported late binding, 
> then you would be able to define all your variables as Object and 
> *everything would continue to work*. 
>
> In Go you could define everything as interface{} and then use small 
> interfaces around every call:
>
> foo.(interface{ Method() string}).Method()
>
> In Java, you can use the reflection interface. In this sense, it is 
> available "on demand", but that's not the same thing at all.
>
> Both Java and C++ made the mistake of confusing a class with a behavior, 
> and then using classes as names for behaviors.
>
>
>
> On Tue, Nov 22, 2022 at 11:46 AM Robert Engels  
> wrote:
>
>> What would be the purpose of writing B calling a method on A that doesn’t 
>> exist?
>>
>> On Nov 22, 2022, at 10:36 AM, 'Thomas Bushnell BSG' via golang-nuts <
>> golan...@googlegroups.com> wrote:
>>
>> 
>> Both Java and Go require that a method be instantiated in the declared 
>> interface of the type at compile time. This is contrary to the point of 
>> late binding.
>>
>> In the case of Go, this cannot be detected, because everything is built 
>> together. But with Java, you cannot call a method on an object unless that 
>> method has *already *been defined. In other words, late binding supports 
>> the following order of things:
>>
>> 1) Write class A, with method X and only X. Compile it.
>> 2) Write class B, which instantiates class A and calls method Y (which 
>> does not exist yet). Compile it.
>> 3) Extend class A to add method Y. Compile it.
>> 4) Execute class B.
>>
>> Late binding says this should work, but the Java compiler will throw an 
>> error at step two. Go never throws that error, because Go only builds the 
>> whole program at once, so the partial compilations don't make sense.
>>
>> In addition, any method marked final does not support late binding - 
>> indeed, this is the point of the keyword, and is why I remarked that this 
>> is because they couldn't figure out how to do it efficiently.
>>
>> Thomas
>>
>> On Tue, Nov 22, 2022 at 11:25 AM Robert Engels  
>> wrote:
>>
>>> Why do you say that Java does not have late binding. It 100% does. In 
>>> fact the JVM supports dynamic dispatch to make this as efficient as 
>>> possible. Then the JIT optimizes it even more based on runtime behavior. 
>>>
>>> On Nov 22, 2022, at 10:18 AM, Matt KØDVB  wrote:
>>>
>>> 
>>> But see https://en.wikipedia.org/wiki/Self_(programming_language)
>>>
>>> Self was considered an OO language back when I was a grad student and is 
>>> still listed that way today, even though it has neither classes nor 
>>> inheritance.
>>>
>>> Anyway, my point would be that the term OO originates with Alan Kay and 
>>> the team at Xerox PARC; Kay’s response to the OO flame wars was to 
>>> de-emphasize classes and inheritance.
>>>
>>> Of course, using his definition, neither Java nor Go would be “truly” OO 
>>> since not all things use late binding :-)
>>>
>>> Perhaps we can talk about class-based and non-class based OO languages?
>>>
>>> On Tue, Nov 22, 2022 at 10:07 AM Robert Engels  
>>> wrote:
>>>
 The wiki OO page lists classes as a requirement - but not necessarily 
 inheritance. Class variables require classes. 

 Also, your link does not work. 

 > On Nov 22, 2022, at 9:56 AM, Jan Mercl <0xj...@gmail.com> wrote:
 > 
 > On Tue, Nov 22, 2022 at 4:43 PM Robert Engels  
 wrote:
 > 
 >> Go is not listed as an OO language on Wikipedia.
 > 
 > Check https://en.wikipedia.org/wiki/Go_(programming_language):
 >

[go-nuts] Re: Go tour translation workflow

[Kamil Ziemian]

Hello,

I'm coautor of Polish translation, I can only tell how it looks like from 
my perspective.

"So, after all, what is needed is a link to the deployed Go tour with a new 
translation, right?"
I would need to check that, since the other person take care of it.

"However, what is the right way to keep it up to date with the original 
repository?
What approach do most people use?"
Well, when I need current version of the repository, I just clone it using 
Git, change what is needed, fetch-merge-push to my fork of GitHub 
repository with polish translation and after that I make Pull Request for 
main repository of polish version and other person take care about that.

"Is there any described journey of adding a new translation?"
Can you explain what you mean by "journey"? It is not clear to me, what you 
want to say.

If something that I wrote is unclear, feel free to ask. It is not easy feat 
to find how much details you should put in the answer.

As a aside. From my perspective, the most consuming part was the 
translation of Go vocabulary into destination language. How you should 
translate things like "slice" or "channel"? Or even translation  of "import 
path" can make a problem. Second thing was to smooth the translation. At 
first attempt it looks like someone took a dictionary and translate every 
word at once, which can result in very ackaword text. And since English 
text of Go tour is very compact, we try to make translation compat as well, 
which combined with demande that it will read naturaln, can be not easy.

Comparing to this, GitHub workflow was a piece of cake.

Best regards,
Kamil
środa, 9 listopada 2022 o 20:29:01 UTC+1 Viktor Pakhuchyi napisał(a):

> Hi there!
>
> I'm writing on behalf of Go community from Ukraine. 
>
> We want to add Ukrainian translation to the Go tour. 
> I've found that the already existing documentation doesn't cover all my 
> questions. 
> That's why I've decided to ask you here for some tips.
>
> What is clear:
> 1. Repository can be cloned by using this link - 
> https://go.googlesource.com/website
> 2. This document tells what files to change and that an App Engine 
> deployment is needed - 
> https://cs.opensource.google/go/x/website/+/master:tour/TRANSLATE
>
> So, after all, what is needed is a link to the deployed Go tour with a new 
> translation, right?
>
> However, what is the right way to keep it up to date with the original 
> repository? 
> What approach do most people use? 
>
> Is there any described journey of adding a new translation?
> I would be very grateful for that.
>
> Thanks in advance!
> Viktor
>

-- 
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/59174ec6-631e-4a4e-8b1e-08aeeb147dban%40googlegroups.com.

[go-nuts] Re: Golang make coding very explicit. People should be warned !

[Kamil Ziemian]

I hope they will join Go community.

sobota, 12 listopada 2022 o 04:51:10 UTC+1 mario.g...@gmail.com napisał(a):

> I'm about to do a presentation of Go for some coworkers. I thought it 
> shoul be required to warn them about explicit code ahead ;-)
>
> I make it this evening.
>
> Take it and share it !
>
> [image: Gopher software advisory.png]
>

-- 
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/797d0471-767d-43ab-b335-dc3e5151f12cn%40googlegroups.com.

[go-nuts] Re: Will Go be discontinued?

[Kamil Ziemian]

If Google stop developing Go, I think we just need to fork main repo and 
start United Gophers Foundation. :D

wtorek, 26 lipca 2022 o 17:01:17 UTC+2 richar...@gmail.com napisał(a):

> Yeah, and GMail and Google Search: their days are numbered
>
> On Sunday, July 28, 2013 at 10:25:11 AM UTC-7 Starfish wrote:
>
>> Hello!
>>
>> Every Google service I use and like seems to get pulled.
>>
>> Recently Google announced the retirement of Reader, iGoogle, Talk and 
>> Latitude.
>>
>> What guaranties can you give about Go?
>>
>> Will Rob, Andrew and the others be funded to continue this project?
>>
>> Go is open source of course, but without Google I think it will die. 
>>
>> A statement of intent from Google would be in order.
>>
>

-- 
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/65db06fe-be09-42e9-9a3e-a0cce8a8fcfen%40googlegroups.com.

Re: [go-nuts] Re: Blog: Calculating type sets is harder than you think

[Kamil Ziemian]

This blog post is extremely interesting. I wish I have better background in 
type theory and in complexity theory, I would understand this text much 
better.

Due to my work (C#, C++, and some trivial stuff) I have almost no time to 
follow development of Go, so I have question about "There are also still 
discussions about changing the generics design.". Is changing a design of 
generic still possible without breaking backward comparability? As I said, 
I have a little time for Go now (thought luck), so this question maybe just 
show how ignorant I'm.

"As one example, the limitations we introduced to fix all of this made one 
of the use cases from the design doc impossible to express." Time before 
release of Go 1.18 was the last moment, when I have more time for Go and in 
beta version some examples from "Type Parameters Proposal" 
(https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md)
 
refereed here already wasn't working. Ian Lance Taylor said that current 
descriptions of generics is to be found appropriate version of Go Spec and 
maybe latter "Type Parameters Proposal" would be updated.

So I want to ask, is this example from "Type Parameters Proposal" relevant 
today? I mean July 2022.

Few pedantic questions and comments. I always find things to gripe about. 
Like my English level.

In the section "SAT" we have definition of function
func F(x, y, z bool) bool
but in the example just below we call function
f(true, true, false)

Starting from the the section "Basic interfaces as type sets" we have
type X interface { X() }
type NotX interface{ X() int }
and it is quite consistent that interface X has "interface { X() }" and 
NotX has "interface{ X() int }" (there is no space just after "interface"). 
Is this by design or by accident?


In section "Adding unions" we have
type S interface{
I believe lack of space after "interface" is just mistake.

Best regards,
Kamil
wtorek, 17 maja 2022 o 14:01:31 UTC+2 axel.wa...@googlemail.com napisał(a):

> On Tue, May 17, 2022 at 11:44 AM Peter Galbavy  
> wrote:
>
>> I am neither enough of a Go expert ("yet) - I hope) or good enough in 
>> real math to say much apart from that is actually one of the clearest 
>> explanations of P/NP problems and the actual meaning of CNF/DNF that I have 
>> had the pleasure to read. Even setting aside the importance to the design 
>> decisions for Go 1.18, it actually made sense of things I have struggled in 
>> the past to "get".\
>
>
> Thanks for the kind words :) I've heard this a couple of times by now and 
> while I'm a bit surprised (it doesn't seem a very novel way to describe it 
> to me, but then again, I'm biased) I'm very happy that I apparently hit 
> home with this :)
>  
>
>>
>> Thanks.
>>
>> On Monday, 16 May 2022 at 11:24:22 UTC+1 axel.wa...@googlemail.com wrote:
>>
>>> Hi,
>>>
>>> I thought you might be interested in a new blog post I just published, 
>>> about the difficulties of proving that a type set is empty:
>>> https://blog.merovius.de/posts/2022-05-16-calculating-type-sets/
>>> It is based on a problem that came up when the notion of type sets was 
>>> proposed 
>>> . It 
>>> came up a couple of times lately in discussions about changing the generics 
>>> design, so I thought it might be good to do a clean writeup.
>>>
>>> Let me know what you think. 
>>>
>> -- 
>> 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/a2dd523a-56c4-4bfb-99e2-7245a708a578n%40googlegroups.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/9399a4ba-4a7c-45f7-a7fd-2a3bc1a260acn%40googlegroups.com.

[go-nuts] Why is Go fun?

[Kamil Ziemian]

Hello,

I lack a motivation to read Go spec (long story) and I seek few stories 
along the line "Go is fun", which it is, to motivate myself. Google didn't 
give me any results, maybe you can tell me few reasons, why Go is fun?

I feel that it is fun, but can't tell why.

Best,
Kamil Ziemian

-- 
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/eee514c5-530e-412e-a2bc-6232e9bea79an%40googlegroups.com.

[go-nuts] Re: Information for gophers in Ukraine

[Kamil Ziemian]

Here is a Google Sheet with contacts to private persons in Poland, that 
want to share a house or flat with refugees from Ukraine 
http://tinyurl.com/domdlaua. If you can share it somewhere, when Ukrainians 
can find it, please do this.

Google Sheet is in Polish (Latin script) and Ukrainian (Cyrillic script).

This Google Sheet is quite a mess, my actions are probably chaotic, but 
here in Poland we don't have enough time and energy to think too much about 
all nooks and crannies of this situation. We try to do our best using any 
means that we have. If we made something stupid along the away, please have 
a patience for us.

Best,
Kamil Ziemian
niedziela, 27 lutego 2022 o 03:06:00 UTC+1 al...@pbrane.org napisał(a):

> Yes, let's support everyone!
>
> If any gopher from the DNR or LNR is tired of their plight
> being ignored and wants to chat with a friendly US citizen
> from California, feel free to email me.
>
> Anthony
>

-- 
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/11a6587d-2735-4b66-8b7b-38c9dd7008c0n%40googlegroups.com.

[go-nuts] Information for gophers in Ukraine

[Kamil Ziemian]

I live in Poland in city of Cracov 
(https://en.wikipedia.org/wiki/Krak%C3%B3w) and at this moment I have one 
free room in my flat. If some gopher from Ukraine need a place to stay for 
himself/herself or for they loved ones, just write to me. I will try to 
help as much as I can.

Kamil Ziemian

-- 
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/10b0fb68-a87c-4f96-bc58-7fd7d6539f93n%40googlegroups.com.

[go-nuts] Re: Is Go good choice for porting graph based app?

[Kamil Ziemian]

"As a result I know, I currently try to kick this graph can down the road." 
Stupid me. It should be "As a result I currently kicking this graph can 
down the road.", only written in better English than mine.

Best,
Kamil

niedziela, 20 lutego 2022 o 21:43:10 UTC+1 Kamil Ziemian napisał(a):

> I think they use a set schema, but I need to check. To be honest, I have a 
> lot to do on my own now and people from this graph app are acting as they 
> were wanting to sabotage my work. I think that they just clueless about 
> consequences of their actions.
>
> As a result I know, I currently try to kick this graph can down the road.
>
> Best,
> Kamil
>
> poniedziałek, 7 lutego 2022 o 01:19:44 UTC+1 Mike Schinkel napisał(a):
>
>> Kamil,
>>
>> Are the JSON files using a set schema, or could they be any arbitrary 
>> schema?  
>>
>> Not that the latter can't be handled by Go, but IMO Go excels at the 
>> former because of ability to statically type.
>>
>> -Mike
>>
>> On Sunday, February 6, 2022 at 6:15:25 AM UTC-5 kziem...@gmail.com wrote:
>>
>>> Thank you Sebastian Binet, I need to check more gonum project.
>>>
>>> You are right drv drv that Python is not true culprit here. Problem is 
>>> that it seems a bad written code. Maybe after a while I will change my mind 
>>> about it, but it looks bad right now.
>>>
>>> Here you have list of dependencies that came with this code.
>>> attrs==21.2.0
>>> azure-functions==1.7.2
>>> certifi==2021.5.30
>>> charset-normalizer==2.0.4
>>> graphviz==0.18
>>> idna==3.2
>>> jmespath==0.10.0
>>> jsonschema==4.1.2
>>> Pillow==8.4.0
>>> pyrsistent==0.18.0
>>> raven==6.10.0
>>> requests==2.26.0
>>> svg.path==4.1
>>> urllib3==1.26.6
>>>
>>> I have a bunch of problem with it. I normal use Python 3.6, because it 
>>> is standard Python on Ubuntu OS and I'm fine with that. But, jsonschema v. 
>>> 4.1.2 wasn't available on Python 3.6. After installing new version of 
>>> Python I now have a problem with Pillow. I still don't know what to do with 
>>> that, so they told me to switch to Windows. And I just begin with it.
>>>
>>> Best,
>>> Kamil
>>>
>>> sobota, 5 lutego 2022 o 16:43:46 UTC+1 drv drv napisał(a):
>>>
>>>> I don't know the background of this Python code but *" It seems 
>>>> underdeveloped, buggy and running it first time is a pain, because of 
>>>> dependencies. "* is not a language problem.
>>>> I cannot imagine any dependencies in this kind of program.
>>>> JSON "equals" dictionaries in case of Python and it supports natively 
>>>> so it is quite fast and can be write very simple and elegant code.
>>>> It is true that GO is faster (in this case I guess 2x on single core) 
>>>> but if you cannot take advance of goroutines (and multicore) use Python.
>>>>
>>>> On Thursday, 3 February 2022 at 23:26:14 UTC+1 kziem...@gmail.com 
>>>> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I was handed proof-of-concept app written in Python. It seems 
>>>>> underdeveloped, buggy and running it first time is a pain, because of 
>>>>> dependencies. Basically it need to read some graphs stored in JSON files 
>>>>> and manipulated them accordingly and write them to JSON files again.
>>>>>
>>>>> It seems that porting it now to more suitable language is worth a gain 
>>>>> at this stage and I wonder if Go is a good choice? I read and watch many 
>>>>> Ian Lance Taylor presentations about generics, so I know that only that 
>>>>> generic graph (tree) data structure is something that can be a pain,  but 
>>>>> in this case it would be were small issue. It seems that we have only few 
>>>>> data types to be stored in graph, mostly strings and ints.
>>>>>
>>>>> I'm not true gopher, so I don't know if Go is proper choice for this 
>>>>> task. I don't believe that Python is any better, but maybe I should check 
>>>>> another language.
>>>>>
>>>>> Also, if someone know better thing to sore graphs than JSON, I would 
>>>>> appreciate it any suggestion.
>>>>>
>>>>> I don't write anymore about this app, since I don't know if company 
>>>>> allows for it.
>>>>>
>>>>> Best regards,
>>>>> Kamil
>>>>>
>>>>

-- 
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/1f08e7f0-858f-4abd-be19-9e2b793658d5n%40googlegroups.com.

[go-nuts] Re: Is Go good choice for porting graph based app?

[Kamil Ziemian]

I think they use a set schema, but I need to check. To be honest, I have a 
lot to do on my own now and people from this graph app are acting as they 
were wanting to sabotage my work. I think that they just clueless about 
consequences of their actions.

As a result I know, I currently try to kick this graph can down the road.

Best,
Kamil

poniedziałek, 7 lutego 2022 o 01:19:44 UTC+1 Mike Schinkel napisał(a):

> Kamil,
>
> Are the JSON files using a set schema, or could they be any arbitrary 
> schema?  
>
> Not that the latter can't be handled by Go, but IMO Go excels at the 
> former because of ability to statically type.
>
> -Mike
>
> On Sunday, February 6, 2022 at 6:15:25 AM UTC-5 kziem...@gmail.com wrote:
>
>> Thank you Sebastian Binet, I need to check more gonum project.
>>
>> You are right drv drv that Python is not true culprit here. Problem is 
>> that it seems a bad written code. Maybe after a while I will change my mind 
>> about it, but it looks bad right now.
>>
>> Here you have list of dependencies that came with this code.
>> attrs==21.2.0
>> azure-functions==1.7.2
>> certifi==2021.5.30
>> charset-normalizer==2.0.4
>> graphviz==0.18
>> idna==3.2
>> jmespath==0.10.0
>> jsonschema==4.1.2
>> Pillow==8.4.0
>> pyrsistent==0.18.0
>> raven==6.10.0
>> requests==2.26.0
>> svg.path==4.1
>> urllib3==1.26.6
>>
>> I have a bunch of problem with it. I normal use Python 3.6, because it is 
>> standard Python on Ubuntu OS and I'm fine with that. But, jsonschema v. 
>> 4.1.2 wasn't available on Python 3.6. After installing new version of 
>> Python I now have a problem with Pillow. I still don't know what to do with 
>> that, so they told me to switch to Windows. And I just begin with it.
>>
>> Best,
>> Kamil
>>
>> sobota, 5 lutego 2022 o 16:43:46 UTC+1 drv drv napisał(a):
>>
>>> I don't know the background of this Python code but *" It seems 
>>> underdeveloped, buggy and running it first time is a pain, because of 
>>> dependencies. "* is not a language problem.
>>> I cannot imagine any dependencies in this kind of program.
>>> JSON "equals" dictionaries in case of Python and it supports natively so 
>>> it is quite fast and can be write very simple and elegant code.
>>> It is true that GO is faster (in this case I guess 2x on single core) 
>>> but if you cannot take advance of goroutines (and multicore) use Python.
>>>
>>> On Thursday, 3 February 2022 at 23:26:14 UTC+1 kziem...@gmail.com wrote:
>>>
 Hello,

 I was handed proof-of-concept app written in Python. It seems 
 underdeveloped, buggy and running it first time is a pain, because of 
 dependencies. Basically it need to read some graphs stored in JSON files 
 and manipulated them accordingly and write them to JSON files again.

 It seems that porting it now to more suitable language is worth a gain 
 at this stage and I wonder if Go is a good choice? I read and watch many 
 Ian Lance Taylor presentations about generics, so I know that only that 
 generic graph (tree) data structure is something that can be a pain,  but 
 in this case it would be were small issue. It seems that we have only few 
 data types to be stored in graph, mostly strings and ints.

 I'm not true gopher, so I don't know if Go is proper choice for this 
 task. I don't believe that Python is any better, but maybe I should check 
 another language.

 Also, if someone know better thing to sore graphs than JSON, I would 
 appreciate it any suggestion.

 I don't write anymore about this app, since I don't know if company 
 allows for it.

 Best regards,
 Kamil

>>>

-- 
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/50cc82eb-b759-45ae-85b5-3c66b7b4cc89n%40googlegroups.com.

Re: [go-nuts] Going thorough "Type parameters proposal" with Go 1.18 beta

[Kamil Ziemian]

 except that a) Unicode is a 
>> standard trying to assign a number to ~any character used in human 
>> languages and b) UTF-8 is a standard for encoding those numbers into bytes. 
>> I don't think you really need to know anything beyond that to understand 
>> the Go spec."
>>
>> Yes, it is stupid excuse of not reading spec. I try to read it last 
>> October and after first paragraph I started reading Wikipedia page about 
>> EBNF notation, because I was so confused. After that I went back and stuck 
>> on the part of runes, so I go read about Unicode. Amount of materials on 
>> Unicode homepage is intimidating to me. For some reasons strings and runes 
>> are hardest part of Go to grasp for me. I can use them in the manner "shut 
>> up and write the code", but I don't feel satisfied. I read quite a lot 
>> about them, so next logical step is to read about Unicode. This is some 
>> stupid viscus circle for me.
>>
>> "I don't think you really need to know anything beyond that to understand 
>> the Go spec." Thank you for words of encouragement, I will try to read spec 
>> soon. I hope that I won't again stuck on runes. Runes combined with UTF-8 
>> make my brain into Mobius strip.
>>
>> Best,
>> Kamil
>> wtorek, 15 lutego 2022 o 13:27:42 UTC+1 axel.wa...@googlemail.com 
>> napisał(a):
>>
>>> Also, just as a side-note: The nomenclature "named type" is obsolete. 
>>> The concept was renamed to "defined type" in Go 1.9. I assume Ian 
>>> mistakenly used it out of habit. But just so you are not confused about the 
>>> terms when reading other material.
>>>
>>> And, I know that you asked to respect your wishes in regard to not 
>>> reading the Go spec, but to be clear, you really don't need to know 
>>> anything significant about Unicode or UTF-8 to understand the Go spec. I 
>>> don't really know anything about it either, except that a) Unicode is a 
>>> standard trying to assign a number to ~any character used in human 
>>> languages and b) UTF-8 is a standard for encoding those numbers into bytes. 
>>> I don't think you really need to know anything beyond that to understand 
>>> the Go spec.
>>>
>>> On Tue, Feb 15, 2022 at 1:19 PM Axel Wagner  
>>> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Feb 15, 2022 at 11:18 AM Kamil Ziemian  
>>>> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> While reading "Type Parameters Proposal" (
>>>>> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md)
>>>>>  
>>>>> I can't find a direct answer to question stated below. I should notice 
>>>>> that 
>>>>> I have idea how it works, but I'm not sure if it is correct.
>>>>>
>>>>> Consider slightly changed code (
>>>>> https://go.dev/play/p/R1gK9bdLXV0?v=gotip) from section "Element 
>>>>> constraint example" (
>>>>> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#element-constraint-example).
>>>>>  
>>>>> It shows that after passing `sliceMySlice` to the generic function 
>>>>> `Double` 
>>>>> it change a type from `MySlice` to `[]int`. My question is, why this 
>>>>> change 
>>>>> of type happens?
>>>>>
>>>>> Here how I understand this. Function `Double` has signature
>>>>> `func Double[E MyInteger](s []E) []E`
>>>>> so calling
>>>>> `Double(sliceMySlice)`
>>>>> requires function argument type inference. To do this we need to unify 
>>>>> type of `MySlice` to `[]int`. This can be done because [_For type 
>>>>> unification, two types that don‘t contain any type parameters are 
>>>>> equivalent if they are identical, or if they are channel types that are 
>>>>> identical ignoring channel direction, or if their underlying types are 
>>>>> equivalent._](
>>>>> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#type-unification).
>>>>>  
>>>>> And from my understanding last case is applied here. Which give us `E` -> 
>>>>> `int`. We now need to instantiated function `Double[int]` by replacing in 
>>>>> all palaces type parameter `E` with type argument `int` and c

Re: [go-nuts] Going thorough "Type parameters proposal" with Go 1.18 beta

[Kamil Ziemian]

"Also, just as a side-note: The nomenclature "named type" is obsolete. The 
concept was renamed to "defined type" in Go 1.9. I assume Ian mistakenly 
used it out of habit. But just so you are not confused about the terms when 
reading other material."

Thank you Axel for this information. I was thinking that they are both 
synonyms, because it was of these rare cases when I look at spec.

"And, I know that you asked to respect your wishes in regard to not reading 
the Go spec, but to be clear, you really don't need to know anything 
significant about Unicode or UTF-8 to understand the Go spec. I don't 
really know anything about it either, except that a) Unicode is a standard 
trying to assign a number to ~any character used in human languages and b) 
UTF-8 is a standard for encoding those numbers into bytes. I don't think 
you really need to know anything beyond that to understand the Go spec."

Yes, it is stupid excuse of not reading spec. I try to read it last October 
and after first paragraph I started reading Wikipedia page about EBNF 
notation, because I was so confused. After that I went back and stuck on 
the part of runes, so I go read about Unicode. Amount of materials on 
Unicode homepage is intimidating to me. For some reasons strings and runes 
are hardest part of Go to grasp for me. I can use them in the manner "shut 
up and write the code", but I don't feel satisfied. I read quite a lot 
about them, so next logical step is to read about Unicode. This is some 
stupid viscus circle for me.

"I don't think you really need to know anything beyond that to understand 
the Go spec." Thank you for words of encouragement, I will try to read spec 
soon. I hope that I won't again stuck on runes. Runes combined with UTF-8 
make my brain into Mobius strip.

Best,
Kamil
wtorek, 15 lutego 2022 o 13:27:42 UTC+1 axel.wa...@googlemail.com 
napisał(a):

> Also, just as a side-note: The nomenclature "named type" is obsolete. The 
> concept was renamed to "defined type" in Go 1.9. I assume Ian mistakenly 
> used it out of habit. But just so you are not confused about the terms when 
> reading other material.
>
> And, I know that you asked to respect your wishes in regard to not reading 
> the Go spec, but to be clear, you really don't need to know anything 
> significant about Unicode or UTF-8 to understand the Go spec. I don't 
> really know anything about it either, except that a) Unicode is a standard 
> trying to assign a number to ~any character used in human languages and b) 
> UTF-8 is a standard for encoding those numbers into bytes. I don't think 
> you really need to know anything beyond that to understand the Go spec.
>
> On Tue, Feb 15, 2022 at 1:19 PM Axel Wagner  
> wrote:
>
>>
>>
>> On Tue, Feb 15, 2022 at 11:18 AM Kamil Ziemian  
>> wrote:
>>
>>> Hello,
>>>
>>> While reading "Type Parameters Proposal" (
>>> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md)
>>>  
>>> I can't find a direct answer to question stated below. I should notice that 
>>> I have idea how it works, but I'm not sure if it is correct.
>>>
>>> Consider slightly changed code (
>>> https://go.dev/play/p/R1gK9bdLXV0?v=gotip) from section "Element 
>>> constraint example" (
>>> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#element-constraint-example).
>>>  
>>> It shows that after passing `sliceMySlice` to the generic function `Double` 
>>> it change a type from `MySlice` to `[]int`. My question is, why this change 
>>> of type happens?
>>>
>>> Here how I understand this. Function `Double` has signature
>>> `func Double[E MyInteger](s []E) []E`
>>> so calling
>>> `Double(sliceMySlice)`
>>> requires function argument type inference. To do this we need to unify 
>>> type of `MySlice` to `[]int`. This can be done because [_For type 
>>> unification, two types that don‘t contain any type parameters are 
>>> equivalent if they are identical, or if they are channel types that are 
>>> identical ignoring channel direction, or if their underlying types are 
>>> equivalent._](
>>> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#type-unification).
>>>  
>>> And from my understanding last case is applied here. Which give us `E` -> 
>>> `int`. We now need to instantiated function `Double[int]` by replacing in 
>>> all palaces type parameter `E` with type argument `int` and compiling such 
>>>

Re: [go-nuts] Going thorough "Type parameters proposal" with Go 1.18 beta

[Kamil Ziemian]

Hello,

While reading "Type Parameters Proposal" 
(https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md)
 
I can't find a direct answer to question stated below. I should notice that 
I have idea how it works, but I'm not sure if it is correct.

Consider slightly changed code (https://go.dev/play/p/R1gK9bdLXV0?v=gotip) 
from section "Element constraint example" 
(https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#element-constraint-example).
 
It shows that after passing `sliceMySlice` to the generic function `Double` 
it change a type from `MySlice` to `[]int`. My question is, why this change 
of type happens?

Here how I understand this. Function `Double` has signature
`func Double[E MyInteger](s []E) []E`
so calling
`Double(sliceMySlice)`
requires function argument type inference. To do this we need to unify type 
of `MySlice` to `[]int`. This can be done because [_For type unification, 
two types that don‘t contain any type parameters are equivalent if they are 
identical, or if they are channel types that are identical ignoring channel 
direction, or if their underlying types are 
equivalent._](https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#type-unification).
 
And from my understanding last case is applied here. Which give us `E` -> 
`int`. We now need to instantiated function `Double[int]` by replacing in 
all palaces type parameter `E` with type argument `int` and compiling such 
function.

In next step we take instantiated function `#Double[int](s []int) []int` 
and call `#Double[int](sliceMySlice)`. Assigning value of type `MySlice` to 
variable of type `[]int` is permissible in Go, so this is how this change 
of type happens. I hope that I correctly understood that `[]int` is unnamed 
(?) type.

I checked proposal for occurrence of word "instatiation", it find 13 
results. Of them 3 referee to instatiation of Go generic function.

Section "Omissions". "No currying. There is no way to partially instantiate 
a generic function or type, other than by using a helper function or a 
wrapper type. All type arguments must be either explicitly passed or 
inferred at instantiation time.".

Question "Why not use the syntax F like C++ and Java?". "When parsing 
code within a function, such as v := F, at the point of seeing the < 
it's ambiguous whether we are seeing a type instantiation or an expression 
using the < operator." "Without type information, it is impossible to 
decide whether the right hand side of the assignment is a pair of 
expressions (w < x and y > (z)), or whether it is a generic function 
instantiation and call that returns two result values ((w)(z))."

"Instantiating a function" 
(https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#instantiating-a-function).
 
"Go normally permits you to refer to a function without passing any 
arguments, producing a value of function type. You may not do this with a 
function that has type parameters; all type arguments must be known at 
compile time. That said, you can instantiate the function, by passing type 
arguments, but you don't have to call the instantiation. This will produce 
a function value with no type parameters."

This is the whole text of "Instantiating a function" and it is not to 
helpful for me in understanding how it works. Ideas and notations that I 
used above come from Robert Griesemer's talk "Typing [Generic] Go" from 
GopherCon 2020 (https://www.youtube.com/watch?v=TborQFPY2IM), whiteout it I 
would probably have no clue what may happen. I still can understand it 
wrongly, but it is my fault.

I hope this is not too silly question.

Best,
Kamil
piątek, 11 lutego 2022 o 18:37:48 UTC+1 Kamil Ziemian napisał(a):

> Hello,
>
> If you don't mind, I have few editorials suggestions to "Type parameters 
> proposal".
>
> Last code example in section "Type parameters" (
> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#type-parameters)
>  
> have very big and unecesary indentation, it should be removed.
>
> At the end of "The any constraint" (
> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#the-constraint)
>  
> I would change "discussed separately)." to "discussed separately.)". This 
> placement of dot before bracket is used in other parts of this document.
>
> In first code example in "Mutually referencing type parameters"
> (
> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#mutually-referencing-type-parameters)
>  
> we have function signature
> "func New[

Re: [go-nuts] Re: Why you can name variable or type parameter int or uint8???

[Kamil Ziemian]

After reading your answers, I was looking for Go gotchas and I find this. 
At the first look it looks promising, do you have opinion on it?

http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in-go-golang/

Best,
Kamil
niedziela, 13 lutego 2022 o 23:58:14 UTC+1 Kamil Ziemian napisał(a):

> Thank you Jason and Axel. I know that "nil" is predeclared identifier from 
> watching talk on YT "Understending nil" (or something like that) and know 
> that it can be redefined. But, due to my background I still struggle with 
> such things in Go. Old habits die hard, nothing more.
>
> Thank you Axel, you points are very helpful to me. They remained me title 
> of ones of Rob Pikes talks about Go "Simplicity is complicated".
>
> Best,
> Kamil
> piątek, 11 lutego 2022 o 21:21:03 UTC+1 axel.wa...@googlemail.com 
> napisał(a):
>
>> FWIW two useful aspects of this design are
>> 1. It makes the language simpler, as we have fewer keywords and the 
>> grammar doesn't need to mention `int`/… everywhere
>> 2. It makes it possible to extend the set of predeclared identifiers, 
>> without worrying about breakages. For example, we are adding a new `any` 
>> predeclared identifier in Go 1.18. This won't break any (hehe) code, as 
>> code which uses that identifier will just refer to the one it already 
>> declares.
>>
>> On Fri, Feb 11, 2022 at 8:38 PM Jason Phillips  
>> wrote:
>>
>>> In C and C++[1][2] "int" and "float" are reserved keywords and thus 
>>> can't be used as identifiers. In Go[3], "int" and "float64" are 
>>> "predeclared identifiers"[4] and can be redefined, just like any other 
>>> identifier.
>>>
>>> [1] - https://en.cppreference.com/w/c/keyword
>>> [2] - https://en.cppreference.com/w/cpp/keyword
>>> [3] - https://go.dev/ref/spec#Keywords
>>> [4] - https://go.dev/ref/spec#Predeclared_identifiers
>>>
>>> On Friday, February 11, 2022 at 1:20:37 PM UTC-5 kziem...@gmail.com 
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> I have so background in C and C++ so was used to that you CAN'T define 
>>>> variable with the name of predefined types. But, in Go 1.17 (go version 
>>>> go1.17.7 linux/amd64)
>>>> > package main
>>>> >
>>>> > import "fmt"
>>>> >
>>>> > func main() {
>>>> > var int float64 = 2.5
>>>> >
>>>> > fmt.Printf("int: %v, %T\n", int, int)
>>>> >
>>>> > // var varOne int = 1
>>>> >
>>>> > // fmt.Printf("varOne: %v", varOne)
>>>> > }
>>>> this code compile and produce result
>>>> > int: 2.5, float64
>>>>
>>>> When you uncomment two lines in this example you will get error
>>>> > int is not a type
>>>>
>>>> In Go 1.18beta2 (go version go1.18beta2 linux/amd64)
>>>> > package main
>>>> >
>>>> > import (
>>>> > "fmt"
>>>> > // "math"
>>>> > )
>>>> >
>>>> > type Constraint interface {
>>>> > float64
>>>> > }
>>>> >
>>>> > func someFunction[uint8 Constraint](x uint8) uint8 {
>>>> > x += uint8(1)
>>>> > return x
>>>> > }
>>>> >
>>>> > func main() {
>>>> > var x float64 = 1
>>>> >
>>>> > fmt.Printf("someFunction(%v): %v\n", x, someFunction(x))
>>>> > fmt.Printf("x type: %T\n", x)
>>>> > fmt.Printf("someFunction(x) type: %T\n", someFunction(x))
>>>> > }
>>>> this code compile and produce result
>>>> > someFunction(1): 2
>>>> > x type: float64
>>>> > someFunction(x) type: float64
>>>>
>>>> Can anyone tell me why this behavior is possible in Go? In the past I 
>>>> never write "var int int" because it is wicked and possible sinful, but 
>>>> syntax for generic functions make easier for me to produce such evil 
>>>> things.
>>>>
>>>> This is a bit too much shocking things for me for one day, I will be 
>>>> back tomorrow.
>>>>
>>>> Best,
>>>> Kamil
>>>
>>> -- 
>>> 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/78714732-cd31-49cf-a941-2ed228eb2b7fn%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/golang-nuts/78714732-cd31-49cf-a941-2ed228eb2b7fn%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/25d885e9-3ab9-47bd-8c0c-43ac99721132n%40googlegroups.com.

Re: [go-nuts] Strange cases of type definitions that use "[]", Go 1.17 and 1.18beta2

[Kamil Ziemian]

"This is why I said that this seems like a regression and suggested that 
you file an issue. We have an error message for this particular mistake. We 
have tests to see that the right error message is printed when it happens. 
We clearly care about providing helpful errors. The error message doesn't 
appear in a case where it seems that it should."

"This is purely about changing the error message from the compiler, not 
changing whether or not code is being accepted. There is absolutely no 
question that `type A[3] int` should continue to compile fine. There is no 
question that `type A[float64] int` shouldn't. It's just that the error for 
the latter case should include the "invalid array bounds" message."

Thank you for that Axel. You are very kind with explaining this to me in 
such details. I still have little understanding what is "regression in Go".

I file two issues yesterday. They are probably stupid, but after your 
explanation, I was thinking that if there are stupid, I would learn what to 
not post.

"Also note that `gofmt` will automatically reformat this code to be clear 
about the intention. So, I wouldn't worry about it being unreadable if 
people do."

Ooo, yes `gofmt`. Thank you for bringing it back to me, I constantly forgot 
about it. This is a quirk of mine, that I when I try to learn `gofmt` I 
constantly go back to my problems with understanding Unicode and UTF-8.

You should laugh at me, I deserve it. I also try to laugh at myself. :)

I have a lot to do in this week, so I maybe silent for few days.

Best,
Kamil
poniedziałek, 14 lutego 2022 o 00:05:04 UTC+1 axel.wa...@googlemail.com 
napisał(a):

> On Sun, Feb 13, 2022 at 11:23 PM Kamil Ziemian  wrote:
>
>> "So, no, this is not something that I made up to have an example or 
>> anything like that. I thought about a couple alternative ways to do it and 
>> they all don't work for one reason or another."
>>
>> Thank you for the information. Do you check if performance of generic 
>> code is good? I always want to know if there is regression in performance.
>>
>
> Performance does not matter in ~all cases I'm concerned with so far.
>
> I see no reason why performance would suffer for my case, though, as it 
> currently uses interfaces and reflect. If anything, performance should 
> improve (even if calls are still indirect) as I can completely remove 
> reflect and remove some of the type assertions.
>
> There are certainly cases where performance will suffer, when compared to 
> generated code for a specific types, FWIW. It's just that they are not what 
> I'm talking about here.
>
> "FWIW, here is code that assigns to varSI in two ways:  
>> https://go.dev/play/p/ypj6rQbpBBl";
>>
>> From what I understand "type someInterface [3]interface{ SomeMethod() }" 
>> define interface array of three elements of "interface{ SomeMethod() }" and 
>> as such it should rather be name "someArrayOfInterfaces". Am I right?
>>
>> Also, can someone give me an example, where it is desired to use such 
>> type?
>>
>> Best,
>> Kamil
>> niedziela, 13 lutego 2022 o 17:44:30 UTC+1 jake...@gmail.com napisał(a):
>>
>>> On Friday, February 11, 2022 at 10:02:42 AM UTC-5 kziem...@gmail.com 
>>> wrote:
>>>
>>>> I'm seriously lost here. Code below works in both Go 1.17 and Go 
>>>> 1.18beta2
>>>>
>>>> > package main
>>>> >
>>>> > import "fmt"
>>>> >
>>>> > type someInterface[3] interface {
>>>> > SomeMethod()
>>>> > }
>>>> >
>>>> > func main() {
>>>> > var varSI someInterface
>>>> >
>>>> > fmt.Printf("varSI value: %v\n", varSI)
>>>> > fmt.Printf("varSI type:  %T\n", varSI)
>>>> > }
>>>>
>>>> and give in both cases result
>>>> > varSI value: [  ]
>>>> > varSI type:  main.someInterface
>>>>
>>>> I didn't find any way to assign some new value to "varSI", but this is 
>>>> already disturbing to me.
>>>>
>>>
>>> FWIW, here is code that assigns to varSI in two ways:  
>>> https://go.dev/play/p/ypj6rQbpBBl
>>> Note that running this code in the playground will reformat ' type 
>>> someInterface[3] interface' to the proper ' type someInterface 
>>> [3]interface'. This is not a change in meaning, just a clarifying white 
>>> space change made 

Re: [go-nuts] Re: Why you can name variable or type parameter int or uint8???

[Kamil Ziemian]

Thank you Jason and Axel. I know that "nil" is predeclared identifier from 
watching talk on YT "Understending nil" (or something like that) and know 
that it can be redefined. But, due to my background I still struggle with 
such things in Go. Old habits die hard, nothing more.

Thank you Axel, you points are very helpful to me. They remained me title 
of ones of Rob Pikes talks about Go "Simplicity is complicated".

Best,
Kamil
piątek, 11 lutego 2022 o 21:21:03 UTC+1 axel.wa...@googlemail.com 
napisał(a):

> FWIW two useful aspects of this design are
> 1. It makes the language simpler, as we have fewer keywords and the 
> grammar doesn't need to mention `int`/… everywhere
> 2. It makes it possible to extend the set of predeclared identifiers, 
> without worrying about breakages. For example, we are adding a new `any` 
> predeclared identifier in Go 1.18. This won't break any (hehe) code, as 
> code which uses that identifier will just refer to the one it already 
> declares.
>
> On Fri, Feb 11, 2022 at 8:38 PM Jason Phillips  
> wrote:
>
>> In C and C++[1][2] "int" and "float" are reserved keywords and thus can't 
>> be used as identifiers. In Go[3], "int" and "float64" are "predeclared 
>> identifiers"[4] and can be redefined, just like any other identifier.
>>
>> [1] - https://en.cppreference.com/w/c/keyword
>> [2] - https://en.cppreference.com/w/cpp/keyword
>> [3] - https://go.dev/ref/spec#Keywords
>> [4] - https://go.dev/ref/spec#Predeclared_identifiers
>>
>> On Friday, February 11, 2022 at 1:20:37 PM UTC-5 kziem...@gmail.com 
>> wrote:
>>
>>> Hello,
>>>
>>> I have so background in C and C++ so was used to that you CAN'T define 
>>> variable with the name of predefined types. But, in Go 1.17 (go version 
>>> go1.17.7 linux/amd64)
>>> > package main
>>> >
>>> > import "fmt"
>>> >
>>> > func main() {
>>> > var int float64 = 2.5
>>> >
>>> > fmt.Printf("int: %v, %T\n", int, int)
>>> >
>>> > // var varOne int = 1
>>> >
>>> > // fmt.Printf("varOne: %v", varOne)
>>> > }
>>> this code compile and produce result
>>> > int: 2.5, float64
>>>
>>> When you uncomment two lines in this example you will get error
>>> > int is not a type
>>>
>>> In Go 1.18beta2 (go version go1.18beta2 linux/amd64)
>>> > package main
>>> >
>>> > import (
>>> > "fmt"
>>> > // "math"
>>> > )
>>> >
>>> > type Constraint interface {
>>> > float64
>>> > }
>>> >
>>> > func someFunction[uint8 Constraint](x uint8) uint8 {
>>> > x += uint8(1)
>>> > return x
>>> > }
>>> >
>>> > func main() {
>>> > var x float64 = 1
>>> >
>>> > fmt.Printf("someFunction(%v): %v\n", x, someFunction(x))
>>> > fmt.Printf("x type: %T\n", x)
>>> > fmt.Printf("someFunction(x) type: %T\n", someFunction(x))
>>> > }
>>> this code compile and produce result
>>> > someFunction(1): 2
>>> > x type: float64
>>> > someFunction(x) type: float64
>>>
>>> Can anyone tell me why this behavior is possible in Go? In the past I 
>>> never write "var int int" because it is wicked and possible sinful, but 
>>> syntax for generic functions make easier for me to produce such evil things.
>>>
>>> This is a bit too much shocking things for me for one day, I will be 
>>> back tomorrow.
>>>
>>> Best,
>>> Kamil
>>
>> -- 
>> 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/78714732-cd31-49cf-a941-2ed228eb2b7fn%40googlegroups.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/176cce79-e869-4afc-8c50-5b5b177f5704n%40googlegroups.com.

Re: [go-nuts] Strange cases of type definitions that use "[]", Go 1.17 and 1.18beta2

[Kamil Ziemian]

"I can't see a syntactical ambiguity, though. The series of tokens `type A 
[ B ] C` can, AFAICT, only be parsed as an array type declaration, generics 
or not (if there where *two* identifiers in the brackets, it would be 
something else, because that could be a generic type declaration. But not 
with one).

So, to me, this seems like a regression. The parser should parse this as an 
array declaration and the type checker should output the helpful error 
message, that the array bounds are invalid."

Thank you. I now understood what you meant. You are much, much better that 
me in the realms of the compilers and parsers.

Sorry if my response are chaotic. I will try to be more systematic in 
answering in the future, but for a while my answers will be messy.

Best,
Kamil
niedziela, 13 lutego 2022 o 23:21:24 UTC+1 Kamil Ziemian napisał(a):

> "I think there is arguably a difference between generic functions and 
> generic type declarations. In the former case, an argument name is rarely 
> needed for the documentation, whereas in the latter case it's probably 
> always needed. Though I'm not sure, really."
>
> I complain about, to make excuse for my ignorance, that current learning 
> materials are in 75% or more about generic functions and 25% is about 
> generic types. This is estimate based on learning materials, that I 
> watch/red. I don't know if this is accident, or it is more uncharted 
> territory? Either way, we need to learn a lot about using generic types and 
> it is hard to tell anything for sure now.
>
> "So, no, this is not something that I made up to have an example or 
> anything like that. I thought about a couple alternative ways to do it and 
> they all don't work for one reason or another."
>
> Thank you for the information. Do you check if performance of generic code 
> is good? I always want to know if there is regression in performance.
>
> "FWIW, here is code that assigns to varSI in two ways:  
> https://go.dev/play/p/ypj6rQbpBBl";
>
> From what I understand "type someInterface [3]interface{ SomeMethod() }" 
> define interface array of three elements of "interface{ SomeMethod() }" and 
> as such it should rather be name "someArrayOfInterfaces". Am I right?
>
> Also, can someone give me an example, where it is desired to use such type?
>
> Best,
> Kamil
> niedziela, 13 lutego 2022 o 17:44:30 UTC+1 jake...@gmail.com napisał(a):
>
>> On Friday, February 11, 2022 at 10:02:42 AM UTC-5 kziem...@gmail.com 
>> wrote:
>>
>>> I'm seriously lost here. Code below works in both Go 1.17 and Go 
>>> 1.18beta2
>>>
>>> > package main
>>> >
>>> > import "fmt"
>>> >
>>> > type someInterface[3] interface {
>>> > SomeMethod()
>>> > }
>>> >
>>> > func main() {
>>> > var varSI someInterface
>>> >
>>> > fmt.Printf("varSI value: %v\n", varSI)
>>> > fmt.Printf("varSI type:  %T\n", varSI)
>>> > }
>>>
>>> and give in both cases result
>>> > varSI value: [  ]
>>> > varSI type:  main.someInterface
>>>
>>> I didn't find any way to assign some new value to "varSI", but this is 
>>> already disturbing to me.
>>>
>>
>> FWIW, here is code that assigns to varSI in two ways:  
>> https://go.dev/play/p/ypj6rQbpBBl
>> Note that running this code in the playground will reformat ' type 
>> someInterface[3] interface' to the proper ' type someInterface 
>> [3]interface'. This is not a change in meaning, just a clarifying white 
>> space change made by `go fmt`. 
>>
>

-- 
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/dfbcc46a-1823-44e3-88a6-b668b5026805n%40googlegroups.com.

Re: [go-nuts] Strange cases of type definitions that use "[]", Go 1.17 and 1.18beta2

[Kamil Ziemian]

"I think there is arguably a difference between generic functions and 
generic type declarations. In the former case, an argument name is rarely 
needed for the documentation, whereas in the latter case it's probably 
always needed. Though I'm not sure, really."

I complain about, to make excuse for my ignorance, that current learning 
materials are in 75% or more about generic functions and 25% is about 
generic types. This is estimate based on learning materials, that I 
watch/red. I don't know if this is accident, or it is more uncharted 
territory? Either way, we need to learn a lot about using generic types and 
it is hard to tell anything for sure now.

"So, no, this is not something that I made up to have an example or 
anything like that. I thought about a couple alternative ways to do it and 
they all don't work for one reason or another."

Thank you for the information. Do you check if performance of generic code 
is good? I always want to know if there is regression in performance.

"FWIW, here is code that assigns to varSI in two ways: 
 https://go.dev/play/p/ypj6rQbpBBl";

>From what I understand "type someInterface [3]interface{ SomeMethod() }" 
define interface array of three elements of "interface{ SomeMethod() }" and 
as such it should rather be name "someArrayOfInterfaces". Am I right?

Also, can someone give me an example, where it is desired to use such type?

Best,
Kamil
niedziela, 13 lutego 2022 o 17:44:30 UTC+1 jake...@gmail.com napisał(a):

> On Friday, February 11, 2022 at 10:02:42 AM UTC-5 kziem...@gmail.com 
> wrote:
>
>> I'm seriously lost here. Code below works in both Go 1.17 and Go 1.18beta2
>>
>> > package main
>> >
>> > import "fmt"
>> >
>> > type someInterface[3] interface {
>> > SomeMethod()
>> > }
>> >
>> > func main() {
>> > var varSI someInterface
>> >
>> > fmt.Printf("varSI value: %v\n", varSI)
>> > fmt.Printf("varSI type:  %T\n", varSI)
>> > }
>>
>> and give in both cases result
>> > varSI value: [  ]
>> > varSI type:  main.someInterface
>>
>> I didn't find any way to assign some new value to "varSI", but this is 
>> already disturbing to me.
>>
>
> FWIW, here is code that assigns to varSI in two ways:  
> https://go.dev/play/p/ypj6rQbpBBl
> Note that running this code in the playground will reformat ' type 
> someInterface[3] interface' to the proper ' type someInterface 
> [3]interface'. This is not a change in meaning, just a clarifying white 
> space change made by `go fmt`. 
>

-- 
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/0966efb7-7b73-4001-87f6-71a6362fe350n%40googlegroups.com.

Re: [go-nuts] Does anyone gets automatic response from 944677...@qq.com?

[Kamil Ziemian]

Thank you for advise.

sobota, 12 lutego 2022 o 10:39:44 UTC+1 Ge napisał(a):

> The owner of this mail account may not even use it now. Just block this 
> email address.
>
> 在2022年2月11日星期五 UTC+8 22:02:11 写道：
>
>> Bad that this is not only my problem. Did anyone try to write to person 
>> that set up this auto replay?
>>
>> piątek, 11 lutego 2022 o 14:56:10 UTC+1 ren...@ix.netcom.com napisał(a):
>>
>>> Same issue. Some one set up auto reply to message threads. 
>>>
>>> On Feb 11, 2022, at 6:36 AM, Kamil Ziemian  wrote:
>>>
>>> 
>>>
>>> Hello,
>>>
>>> I try to don't care about this response, but I see them one time to 
>>> much. After most if not all my post here, I get email from 
>>> 9446...@qq.com with title
>>> "自动回复: [go-nuts]: title of the thread"
>>> and content
>>> "这是来自QQ邮箱的假期自动回复邮件。
>>>  
>>> 您好，我暂时无法亲自回复您的邮件。我将在最短的时间内尽快给您回复。谢谢。"
>>> Gmail translate it to
>>> "This is a holiday auto-reply email from QQ mailbox.
>>>
>>> Hello, I am temporarily unable to respond to your email in person. I 
>>> will reply to you as soon as possible in the shortest possible time. 
>>> thanks."
>>>
>>> It happens even if I gust open new thread, so no one other than me is 
>>> involved in it. Does anyone else has this problem? And how I can solve it?
>>>
>>> Best,
>>> Kamil
>>>
>>> -- 
>>> 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/271ada26-1629-41e9-8bed-ac0b0fa2d5a9n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/golang-nuts/271ada26-1629-41e9-8bed-ac0b0fa2d5a9n%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/f0b709e3-ee7e-439b-a22a-81bf3de0cbfcn%40googlegroups.com.

Re: [go-nuts] Strange cases of type definitions that use "[]", Go 1.17 and 1.18beta2

[Kamil Ziemian]

I'm seriously lost here. Code below works in both Go 1.17 and Go 1.18beta2

> package main
>
> import "fmt"
>
> type someInterface[3] interface {
> SomeMethod()
> }
>
> func main() {
> var varSI someInterface
>
> fmt.Printf("varSI value: %v\n", varSI)
> fmt.Printf("varSI type:  %T\n", varSI)
> }

and give in both cases result
> varSI value: [  ]
> varSI type:  main.someInterface

I didn't find any way to assign some new value to "varSI", but this is 
already disturbing to me.

Best,
Kamil
piątek, 11 lutego 2022 o 16:00:06 UTC+1 Kamil Ziemian napisał(a):

> "Why is it a sin? It's a perfectly normal type definition. Quite common, 
> because useful for attaching methods to a type. One cannotattach a method 
> to type [3]int."
> To write it with such white spaces
> > type typeName[3] int 
> looks like sinful thing to me. It should be 
> > type typeName [3]int
> No problem with that. But, from what I see, both examples works.
>
> Best,
> Kamil
>
> piątek, 11 lutego 2022 o 15:37:59 UTC+1 Jan Mercl napisał(a):
>
>> On Fri, Feb 11, 2022 at 3:13 PM Kamil Ziemian  
>> wrote: 
>>
>> > "> type someDifferentInt[float64] int 
>> > I can't see why the parser can't see that this should (if anything) be 
>> interpreted as an array type declaration. To me, this seems like a 
>> regression. I'd suggest maybe filing an issue." 
>> > 
>> > I think I know the reason. You can write 
>> > > type someArrayWithThreeInt [3]int 
>> > which is proper definition of new type that under the hood is just 
>> array of three int. Due to Go rules about names, white spaces and how Go 
>> parser work, this is equivalent (I think so) to 
>> > > type someArrayWithThreeInt[3] int 
>> > 
>> > I check this last code in simple example and it seems to work "as you 
>> might think". It defines type which under the hood is, again, array of 
>> three ints. But writing such thing is probably a sin. 
>>
>> Why is it a sin? It's a perfectly normal type definition. Quite 
>> common, because useful for attaching methods to a type. One cannot 
>> attach a method to type [3]int. 
>>
>> > I don't know if I should filing the issue. 
>>
>> I wonder what problem is perceived in `type name [expression]T` that 
>> would be the essence of the issue? 
>>
>> White space between tokens, once the lexer injects the semicolons 
>> according to the specified rules, becomes insignificant above 
>> separating adjacent tokens, as also defined in the language 
>> specification. 
>>
>

-- 
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/315e015d-94d9-4595-b68c-5726d3c12d03n%40googlegroups.com.

Re: [go-nuts] Strange cases of type definitions that use "[]", Go 1.17 and 1.18beta2

[Kamil Ziemian]

"Why is it a sin? It's a perfectly normal type definition. Quite common, 
because useful for attaching methods to a type. One cannotattach a method 
to type [3]int."
To write it with such white spaces
> type typeName[3] int 
looks like sinful thing to me. It should be 
> type typeName [3]int
No problem with that. But, from what I see, both examples works.

Best,
Kamil

piątek, 11 lutego 2022 o 15:37:59 UTC+1 Jan Mercl napisał(a):

> On Fri, Feb 11, 2022 at 3:13 PM Kamil Ziemian  wrote:
>
> > "> type someDifferentInt[float64] int
> > I can't see why the parser can't see that this should (if anything) be 
> interpreted as an array type declaration. To me, this seems like a 
> regression. I'd suggest maybe filing an issue."
> >
> > I think I know the reason. You can write
> > > type someArrayWithThreeInt [3]int
> > which is proper definition of new type that under the hood is just array 
> of three int. Due to Go rules about names, white spaces and how Go parser 
> work, this is equivalent (I think so) to
> > > type someArrayWithThreeInt[3] int
> >
> > I check this last code in simple example and it seems to work "as you 
> might think". It defines type which under the hood is, again, array of 
> three ints. But writing such thing is probably a sin.
>
> Why is it a sin? It's a perfectly normal type definition. Quite
> common, because useful for attaching methods to a type. One cannot
> attach a method to type [3]int.
>
> > I don't know if I should filing the issue.
>
> I wonder what problem is perceived in `type name [expression]T` that
> would be the essence of the issue?
>
> White space between tokens, once the lexer injects the semicolons
> according to the specified rules, becomes insignificant above
> separating adjacent tokens, as also defined in the language
> specification.
>

-- 
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/188ddcb9-4a48-4908-af40-514ce3c73a12n%40googlegroups.com.

Re: [go-nuts] Strange cases of type definitions that use "[]", Go 1.17 and 1.18beta2

[Kamil Ziemian]

"> type someDifferentInt[float64] int
I can't see why the parser can't see that this should (if anything) be 
interpreted as an array type declaration. To me, this seems like a 
regression. I'd suggest maybe filing an issue."

I think I know the reason. You can write
> type someArrayWithThreeInt [3]int
which is proper definition of new type that under the hood is just array of 
three int. Due to Go rules about names, white spaces and how Go parser 
work, this is equivalent (I think so) to
> type someArrayWithThreeInt[3] int

I check this last code in simple example and it seems to work "as you might 
think". It defines type which under the hood is, again, array of three 
ints. But writing such thing is probably a sin.

I don't know if I should filing the issue. There is already 5k+ issues and 
a lot of work for Go developers, I don't want to add another if there is 
not good enough reasons. Since this can possible break some code, I heisted 
about that. Better gophers should look at that.

Even if writing "type someArrayWithThreeInt[3] int" is evil, wicked thing, 
we know that everything can broke something to someone 
(https://xkcd.com/1172/) and Go backward compatibility police is quite 
strong. I want to write another 5k+ issue about thing that cannot be 
improved.

Best,
Kamil
piątek, 11 lutego 2022 o 14:47:07 UTC+1 Kamil Ziemian napisał(a):

> Axel I agree that "But there is at least some potential benefit to 
> allowing it.". But, by my humble understanding, true question is "Would Go 
> still feel likes Go after this?". This question is one of the reasons why 
> generics was so long, decade or even more, in the making. Somewhere on 
> GitHub there is a discussion about unused type of arguments in the 
> function. I think they agree that with benefits of hindsight you should be 
> force to write func f(_ int) ... for any unused argument, that is need for 
> function signature or some similar reason. But, now this will be to much 
> breaking of backward compatibility with to little benefit. So I think it is 
> worth pondering now, even if we it is already to late to change anything in 
> Go 1.18.
>
> "As I said, I'm not 100% yet on whether this is a good idea and much less 
> if that would be enough reason to keep allowing unused type parameters." I 
> like your approach. As I understand your code, because type inference works 
> only on types of arguments, not on types of return values, you define a 
> somepkg.ID to be just a string, that carries information about two 
> additional types. This allows Go type inference algorithm infer type of 
> return value from ID value and put it into place of return type of 
> particular instantiation of generic function. Am I right?
>
> You are almost surly more experience Go programmer than me, so anything 
> that I write next may be just silly. Ian Lance Taylor give us one 
> Go-proverb-like advice about generics in Go: "Write code, don't design 
> types". Was your code created according to this rule? It doesn't look like 
> that to me, but I'm in no case someone who should judge it. Better gophers 
> should look at it and decide if this is legitimate use of type parameters.
>
> My guts tell me that is not what I want to work with. It is some 
> workaround of type interference algorithm, by putting too much information 
> in one humble string-under-the-hood type. Dave Cheney said once that "Zen 
> of Python" is also valid in Go and maybe better followed by Go programmers 
> than by Python programmers. And this seems to be a breaking of rule 
> "Explicit is better implicit" and, more importantly, of Go proverb "Clear 
> is better than clever". But, again, so true gopher should judge your code, 
> not me. I just write this to start some discussion about that and I 
> remember that you yourself have doubts about it.
>
> Best,
> Kamil
> piątek, 11 lutego 2022 o 13:56:54 UTC+1 Kamil Ziemian napisał(a):
>
>> Thank you Jan Marcel. I see now that I wasn't precise enough. I 
>> understand that '[' and ']' are just tokens, even I have only intuitive 
>> understanding of concept of token. My problem is that as Ian Lance Taylor 
>> and other people said many times: adding generics will make Go more 
>> complicated. My problem is not in understanding why it is more complicated, 
>> but to accept disturbing cases of it becoming so. It less question of 
>> intellectually understanding, more about "feeling of Go". Which is of 
>> course hard to defined.
>>
>> I copied compilations errors, because in many cases I don't find Go 
>> compilers errors very useful. Don't get me wrong, in many cas

Re: [go-nuts] Does anyone gets automatic response from 944677...@qq.com?

[Kamil Ziemian]

Bad that this is not only my problem. Did anyone try to write to person 
that set up this auto replay?

piątek, 11 lutego 2022 o 14:56:10 UTC+1 ren...@ix.netcom.com napisał(a):

> Same issue. Some one set up auto reply to message threads. 
>
> On Feb 11, 2022, at 6:36 AM, Kamil Ziemian  wrote:
>
> 
>
> Hello,
>
> I try to don't care about this response, but I see them one time to much. 
> After most if not all my post here, I get email from 9446...@qq.com with 
> title
> "自动回复: [go-nuts]: title of the thread"
> and content
> "这是来自QQ邮箱的假期自动回复邮件。
>  
> 您好，我暂时无法亲自回复您的邮件。我将在最短的时间内尽快给您回复。谢谢。"
> Gmail translate it to
> "This is a holiday auto-reply email from QQ mailbox.
>
> Hello, I am temporarily unable to respond to your email in person. I will 
> reply to you as soon as possible in the shortest possible time. thanks."
>
> It happens even if I gust open new thread, so no one other than me is 
> involved in it. Does anyone else has this problem? And how I can solve it?
>
> Best,
> Kamil
>
> -- 
> 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/271ada26-1629-41e9-8bed-ac0b0fa2d5a9n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/golang-nuts/271ada26-1629-41e9-8bed-ac0b0fa2d5a9n%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/e7105c45-ed9c-43b1-b608-542242df046bn%40googlegroups.com.

Re: [go-nuts] Strange cases of type definitions that use "[]", Go 1.17 and 1.18beta2

[Kamil Ziemian]

Axel I agree that "But there is at least some potential benefit to allowing 
it.". But, by my humble understanding, true question is "Would Go still 
feel likes Go after this?". This question is one of the reasons why 
generics was so long, decade or even more, in the making. Somewhere on 
GitHub there is a discussion about unused type of arguments in the 
function. I think they agree that with benefits of hindsight you should be 
force to write func f(_ int) ... for any unused argument, that is need for 
function signature or some similar reason. But, now this will be to much 
breaking of backward compatibility with to little benefit. So I think it is 
worth pondering now, even if we it is already to late to change anything in 
Go 1.18.

"As I said, I'm not 100% yet on whether this is a good idea and much less 
if that would be enough reason to keep allowing unused type parameters." I 
like your approach. As I understand your code, because type inference works 
only on types of arguments, not on types of return values, you define a 
somepkg.ID to be just a string, that carries information about two 
additional types. This allows Go type inference algorithm infer type of 
return value from ID value and put it into place of return type of 
particular instantiation of generic function. Am I right?

You are almost surly more experience Go programmer than me, so anything 
that I write next may be just silly. Ian Lance Taylor give us one 
Go-proverb-like advice about generics in Go: "Write code, don't design 
types". Was your code created according to this rule? It doesn't look like 
that to me, but I'm in no case someone who should judge it. Better gophers 
should look at it and decide if this is legitimate use of type parameters.

My guts tell me that is not what I want to work with. It is some workaround 
of type interference algorithm, by putting too much information in one 
humble string-under-the-hood type. Dave Cheney said once that "Zen of 
Python" is also valid in Go and maybe better followed by Go programmers 
than by Python programmers. And this seems to be a breaking of rule 
"Explicit is better implicit" and, more importantly, of Go proverb "Clear 
is better than clever". But, again, so true gopher should judge your code, 
not me. I just write this to start some discussion about that and I 
remember that you yourself have doubts about it.

Best,
Kamil
piątek, 11 lutego 2022 o 13:56:54 UTC+1 Kamil Ziemian napisał(a):

> Thank you Jan Marcel. I see now that I wasn't precise enough. I understand 
> that '[' and ']' are just tokens, even I have only intuitive understanding 
> of concept of token. My problem is that as Ian Lance Taylor and other 
> people said many times: adding generics will make Go more complicated. My 
> problem is not in understanding why it is more complicated, but to accept 
> disturbing cases of it becoming so. It less question of intellectually 
> understanding, more about "feeling of Go". Which is of course hard to 
> defined.
>
> I copied compilations errors, because in many cases I don't find Go 
> compilers errors very useful. Don't get me wrong, in many cases there are 
> fine, but messages as
> > type someDifferentInt[float64] int
> > error: float64 (type) is not an expression
> are not something that I understand. I often end up ignoring the message 
> and just stare for few minutes in the line where the error was found, 
> compare it to working examples, tweak code a little bit and find what 
> happens. I hope that someone give me some advise how to deal with that, 
> that Go errors are going to be even harder to me to read. Even if this 
> advise is "Just accept it and carry on", it will be valuable.
>
> Best,
> Kamil
>
> piątek, 11 lutego 2022 o 13:38:44 UTC+1 axel.wa...@googlemail.com 
> napisał(a):
>
>> On Fri, Feb 11, 2022 at 12:51 PM Kamil Ziemian  
>> wrote:
>>
>>> Can someone explain me, why compiler can't throw an error when it find 
>>> unused type parameter? I like that in Go unused variable, or import, is 
>>> compile time error and I would appreciate the same behavior with unused 
>>> type parameters.
>>>
>>
>> I'm not sure it's reason enough, but I do have a case where I want to 
>> have unused type-parameters on a type.
>> Essentially, I have
>>
>> type ID string
>> func Call(ctx context.Context, id ID, req Message) (Message, error)
>>
>> which does an RPC-like call. It's used as
>>
>> r, err := framework.Call(ctx, somepkg.ID, somepkg,Request{…})
>> resp := r.(somepkg.Response)
>>
>> With generics, this would be
>>
>> type ID string
>> func Cal

Re: [go-nuts] Strange cases of type definitions that use "[]", Go 1.17 and 1.18beta2

[Kamil Ziemian]

Thank you Jan Marcel. I see now that I wasn't precise enough. I understand 
that '[' and ']' are just tokens, even I have only intuitive understanding 
of concept of token. My problem is that as Ian Lance Taylor and other 
people said many times: adding generics will make Go more complicated. My 
problem is not in understanding why it is more complicated, but to accept 
disturbing cases of it becoming so. It less question of intellectually 
understanding, more about "feeling of Go". Which is of course hard to 
defined.

I copied compilations errors, because in many cases I don't find Go 
compilers errors very useful. Don't get me wrong, in many cases there are 
fine, but messages as
> type someDifferentInt[float64] int
> error: float64 (type) is not an expression
are not something that I understand. I often end up ignoring the message 
and just stare for few minutes in the line where the error was found, 
compare it to working examples, tweak code a little bit and find what 
happens. I hope that someone give me some advise how to deal with that, 
that Go errors are going to be even harder to me to read. Even if this 
advise is "Just accept it and carry on", it will be valuable.

Best,
Kamil

piątek, 11 lutego 2022 o 13:38:44 UTC+1 axel.wa...@googlemail.com 
napisał(a):

> On Fri, Feb 11, 2022 at 12:51 PM Kamil Ziemian  wrote:
>
>> Can someone explain me, why compiler can't throw an error when it find 
>> unused type parameter? I like that in Go unused variable, or import, is 
>> compile time error and I would appreciate the same behavior with unused 
>> type parameters.
>>
>
> I'm not sure it's reason enough, but I do have a case where I want to have 
> unused type-parameters on a type.
> Essentially, I have
>
> type ID string
> func Call(ctx context.Context, id ID, req Message) (Message, error)
>
> which does an RPC-like call. It's used as
>
> r, err := framework.Call(ctx, somepkg.ID, somepkg,Request{…})
> resp := r.(somepkg.Response)
>
> With generics, this would be
>
> type ID string
> func Call[Req, Resp Message](context.Context, ID, Req) (Resp, error)
>
> But this requires writing
>
> resp, err := framework.Call[somepkg.Request, somepkg.Response](ctx, 
> somepkg.ID, somepkg.Request{…})
>
> as return types can't be inferred. Instead, I plan to do
>
> type ID[Req, Resp Message] string // unused type-parameters
> func Call[Req, Resp Message](context.Context, ID[Req, Resp], Req) (Resp, 
> error)
>
> which allows `somepkg` to declare
>
> var ID = framework.ID[MyRequest, MyResponse]("my-name")
>
> letting the client write
>
> resp, err := framework.Call(ctx, somepkg.ID, somepkg.Request)
>
> Now somepkg.ID carries both types and is in an argument, so both types 
> can be inferred.
>
> As I said, I'm not 100% yet on whether this is a good idea and much less 
> if that would be enough reason to keep allowing unused type parameters. But 
> there is at least some potential benefit to allowing it.
>  
>
>>
>> I need to go for a while, I will go back with more questions about what 
>> you can get when using "[]" in Go.
>>
>> Best,
>> Kamil
>>
>> -- 
>> 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/b085b991-e59e-4225-a4d6-36b2391e1dc2n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/b085b991-e59e-4225-a4d6-36b2391e1dc2n%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/94fce34e-0922-48a8-a26b-46811c06ab1en%40googlegroups.com.

[go-nuts] Does anyone gets automatic response from 944677...@qq.com?

[Kamil Ziemian]

Hello,

I try to don't care about this response, but I see them one time to much. 
After most if not all my post here, I get email from 944677...@qq.com with 
title
"自动回复: [go-nuts]: title of the thread"
and content
"这是来自QQ邮箱的假期自动回复邮件。
 
您好，我暂时无法亲自回复您的邮件。我将在最短的时间内尽快给您回复。谢谢。"
Gmail translate it to
"This is a holiday auto-reply email from QQ mailbox.

Hello, I am temporarily unable to respond to your email in person. I will 
reply to you as soon as possible in the shortest possible time. thanks."

It happens even if I gust open new thread, so no one other than me is 
involved in it. Does anyone else has this problem? And how I can solve it?

Best,
Kamil

-- 
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/271ada26-1629-41e9-8bed-ac0b0fa2d5a9n%40googlegroups.com.

[go-nuts] Strange cases of type definitions that use "[]", Go 1.17 and 1.18beta2

[Kamil Ziemian]

Hello,

I should mention that I still don't read Go Language Specification 
(https://go.dev/ref/spec), due to my decision to first study Unicode and 
UTF-8, before reading it. It maybe strange thing to do, but I just how I 
need to deal with Unicode and UTF-8.

Regardless of that I quickly check few sections of it and I still baffled 
by what I find that compiler accepts. I write this to ask some gophers to 
help me find a way to think about this. I hope that you forgive me some 
stupid questions, I have so knowledge of Go, but still very little of 
"feeling" of Go.

I also have almost no knowledge about compilers. I just compiler front-end 
user.

In all code examples I use two following versions of Go.
go version go1.17.7 linux/amd64
go version go1.18beta2 linux/amd64

"Type parameters proposal" 
(https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md)
 
add new "[]" in new role. It allows to write
> func someFunction[T Constraint](...) { ... }
> type someType[T Constraint] ...
where "Constraint" is constraint on allowed type parameters and "T"" is a 
type parameter. (I hope that I didn't mess up names.)

As a byproduct of some obvious mistakes I find that
> type someInt[3] int
work fine in both Go 17 and 18beta2. It defines someInt as new type with 
underling type [3]int. This looks weird and pouting something like that in 
the working code is probably a sin, but this is not that big issue.

I'm now trying to play with compilers with this construction.
> type someDifferentInt[float64] int
In Go 1.17 I get this complain
> invalid array bound float64
> type float64 is not an expression
while in Go 1.18beta2 I get
> float64 (type) is not an expression
It probably need be this way, that with using "[T Constraint]" to define 
(?) type parameters, compiler can't says that it is "invalid array bound 
float64", but new error message is still less useful. I guess we need to 
live with that.

> type someOtherInt[float64 float64] int
This is awful thing to write, but I still perplexed by what compilers say.
Go 1.17:
> syntax error: unexpected float64, expecting ]
Go 1.18beta2:
> cannot use a type parameter as constraint

This example is to compare Go compilers with and without generics.
> type someAnotherInt[T any] int
Go 1.17:
> syntax error: unexpected any, expecting ]

Go 1.18beta2: it compile just fine. Can someone explain me, why compiler 
can't throw an error when it find unused type parameter? I like that in Go 
unused variable, or import, is compile time error and I would appreciate 
the same behavior with unused type parameters.

I need to go for a while, I will go back with more questions about what you 
can get when using "[]" in Go.

Best,
Kamil

-- 
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/b085b991-e59e-4225-a4d6-36b2391e1dc2n%40googlegroups.com.

Re: [go-nuts] Going thorough "Type parameters proposal" with Go 1.18 beta

[Kamil Ziemian]

Thank you so much, about explanation. This is the first time that I hear 
about named type and unnamed type in Go.

Thank you even more for giving my another reason to learn Go Spec. I try it 
before, but then I was lost in section about runes, so I go to learn UTF-8. 
But soon enough I understand that to learn UTF-8 I need to go learn about 
Unicode and I try to find time for it.

Best regards,
Kamil
niedziela, 6 lutego 2022 o 03:47:36 UTC+1 Ian Lance Taylor napisał(a):

> On Sat, Feb 5, 2022 at 4:27 PM Kamil Ziemian  wrote:
> >
> > On the other hand this code compiled
> > > package main
> > >
> > > import "fmt"
> > >
> > > type Stringer interface {
> > > String() string
> > > }
> > >
> > > type StringableVector[T Stringer] []T
> > >
> > > type someFloat float64
> > >
> > > func (sF someFloat) String() string {
> > > return fmt.Sprintf("someFloat: %v", float64(sF))
> > > }
> > >
> > > func main() {
> > > var varStringer Stringer = someFloat(7)
> > > sliceSomeFloat := make([]someFloat, 3)
> > >
> > > var varStringableVector StringableVector[someFloat] = sliceSomeFloat
> > >
> > > fmt.Printf("varStringer type: %T\n", varStringer)
> > > fmt.Printf("sliceSomeFloat type: %T\n", sliceSomeFloat)
> > > fmt.Printf("varStringableVector type: %T\n", varStringableVector)
> > > }
> >
> > and produced result
> >
> > > stringerVar type: main.someFloat
> > > sliceScomeFloat type: []main.someFloat
> > > stringableVectorVar type: main.StringableVector[main.someFloat]
> >
> > Variable stringableVectorVar is not of interface type, because in such 
> case its type printed by fmt.Printf should be []main.someFloat. So, it 
> looks like to me as []main.someFloat is implicitly conversed to 
> main.StringableVector[main.someFloat].
> >
> > Answer to my previous questions was that []stupidFloat/[]someFloat is 
> not of type StringableVector[stupidFloat] so it doesn't have method 
> String() string. But in my poor understanding of Go, this code shouldn't 
> compile due to implicit conversion of two types.
> >
> > Can anyone explain to me, where am I wrong?
>
> You are not permitted to assign directly from one named type to
> another named type. But here you are assigning an unnamed type,
> []someFloat, to a named type, StringableVector[someFloat]. Assigning
> an unnamed type to a named type is permitted if the underlying type of
> the named is identical to the unnamed type, which in this case it is.
> The same is true in non-generic Go. The exact rules are at
> https://go.dev/ref/spec#Assignability.
>
> Ian
>

-- 
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/cd1e67f7-0b56-4223-92ae-04663625f70cn%40googlegroups.com.

[go-nuts] Re: Is Go good choice for porting graph based app?

[Kamil Ziemian]

Thank you Sebastian Binet, I need to check more gonum project.

You are right drv drv that Python is not true culprit here. Problem is that 
it seems a bad written code. Maybe after a while I will change my mind 
about it, but it looks bad right now.

Here you have list of dependencies that came with this code.
attrs==21.2.0
azure-functions==1.7.2
certifi==2021.5.30
charset-normalizer==2.0.4
graphviz==0.18
idna==3.2
jmespath==0.10.0
jsonschema==4.1.2
Pillow==8.4.0
pyrsistent==0.18.0
raven==6.10.0
requests==2.26.0
svg.path==4.1
urllib3==1.26.6

I have a bunch of problem with it. I normal use Python 3.6, because it is 
standard Python on Ubuntu OS and I'm fine with that. But, jsonschema v. 
4.1.2 wasn't available on Python 3.6. After installing new version of 
Python I now have a problem with Pillow. I still don't know what to do with 
that, so they told me to switch to Windows. And I just begin with it.

Best,
Kamil

sobota, 5 lutego 2022 o 16:43:46 UTC+1 drv drv napisał(a):

> I don't know the background of this Python code but *" It seems 
> underdeveloped, buggy and running it first time is a pain, because of 
> dependencies. "* is not a language problem.
> I cannot imagine any dependencies in this kind of program.
> JSON "equals" dictionaries in case of Python and it supports natively so 
> it is quite fast and can be write very simple and elegant code.
> It is true that GO is faster (in this case I guess 2x on single core) but 
> if you cannot take advance of goroutines (and multicore) use Python.
>
> On Thursday, 3 February 2022 at 23:26:14 UTC+1 kziem...@gmail.com wrote:
>
>> Hello,
>>
>> I was handed proof-of-concept app written in Python. It seems 
>> underdeveloped, buggy and running it first time is a pain, because of 
>> dependencies. Basically it need to read some graphs stored in JSON files 
>> and manipulated them accordingly and write them to JSON files again.
>>
>> It seems that porting it now to more suitable language is worth a gain at 
>> this stage and I wonder if Go is a good choice? I read and watch many Ian 
>> Lance Taylor presentations about generics, so I know that only that generic 
>> graph (tree) data structure is something that can be a pain,  but in this 
>> case it would be were small issue. It seems that we have only few data 
>> types to be stored in graph, mostly strings and ints.
>>
>> I'm not true gopher, so I don't know if Go is proper choice for this 
>> task. I don't believe that Python is any better, but maybe I should check 
>> another language.
>>
>> Also, if someone know better thing to sore graphs than JSON, I would 
>> appreciate it any suggestion.
>>
>> I don't write anymore about this app, since I don't know if company 
>> allows for it.
>>
>> Best regards,
>> Kamil
>>
>

-- 
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/a4b87d2e-b72b-447f-8aa3-ad58479da573n%40googlegroups.com.

Re: [go-nuts] Going thorough "Type parameters proposal" with Go 1.18 beta

[Kamil Ziemian]

Excuse me, but I'm lost again. I think I read it in the "A Tour of Go" and 
"Go FAQ", that "In Go types just are" and "There is no implicit conversion 
of types in Go". Because of that code below doesn't compile.

> package main
>
> import "fmt"
>
> type someFloat float64
>
> func main() {
> var floatVar float64 = 1.0
> var someFloatVar someFloat = floatVar
>
> fmt.Println(someFloatVar)
> }

We need explicit type conversion "someFloat(floatVar)" to make it compile.

On the other hand this code compiled
> package main
>
> import "fmt"
>
> type Stringer interface {
> String() string
> }
>
> type StringableVector[T Stringer] []T
>
> type someFloat float64
>
> func (sF someFloat) String() string {
> return fmt.Sprintf("someFloat: %v", float64(sF))
> }
>
> func main() {
> var varStringer Stringer = someFloat(7)
> sliceSomeFloat := make([]someFloat, 3)
>
> var varStringableVector StringableVector[someFloat] = 
sliceSomeFloat
>
> fmt.Printf("varStringer type: %T\n", varStringer)
> fmt.Printf("sliceSomeFloat type: %T\n", sliceSomeFloat)
> fmt.Printf("varStringableVector type: %T\n", varStringableVector)
> }

and produced result

> stringerVar type: main.someFloat
> sliceScomeFloat type: []main.someFloat
> stringableVectorVar type: main.StringableVector[main.someFloat]

Variable stringableVectorVar is not of interface type, because in such case 
its type printed by fmt.Printf should be []main.someFloat. So, it looks 
like to me as []main.someFloat is implicitly conversed to 
main.StringableVector[main.someFloat].

Answer to my previous questions was that []stupidFloat/[]someFloat is not 
of type StringableVector[stupidFloat] so it doesn't have method String() 
string. But in my poor understanding of Go, this code shouldn't compile due 
to implicit conversion of two types.

Can anyone explain to me, where am I wrong?

Best,
Kamil
sobota, 5 lutego 2022 o 11:44:06 UTC+1 Kamil Ziemian napisał(a):

> Thank you very much for information. I think now I understand my problem. 
> I was thinking about method just as a function ("methods are just a 
> functions" is one line from "A Tour of Go", that I know but don't 
> understand its depth-in-simplicity) and for some reason I assumed 
> StringableVector[T Stringer] is a kind of constraint. A such my thinking 
> was that sliceStupidFloat is of type []stupidFloat, when stupidFloat 
> satisfying constraint Stringer, so function (method) find that such 
> constraint is satisfied.
>
> Good gopher probably from the start would understand that since 
> StringableVector[T Stringer] is NOT an interface type, it is a concrete 
> generic type, not constraint. (Is calling something "concrete generic type" 
> correct statement?) My stupid excuse is that materials on generics in Go 
> focus on using generic functions, not generic types. I don't want to be 
> misunderstood, in materials about Go I find a lot of examples how to define 
> and call generic function. There is also many examples of defining generic 
> types, but very little of creating and using objects (?) of generic types.
>
> For example "Tutorial: Getting started with generics" (
> https://go.dev/doc/tutorial/generics) deals only with generic functions. 
> I guess some additional tutorial about generic types will be good thing for 
> people like me.
>
> Best regards,
> Kamil
> sobota, 5 lutego 2022 o 02:57:23 UTC+1 Ian Lance Taylor napisał(a):
>
>> On Fri, Feb 4, 2022 at 5:01 PM Kamil Ziemian  wrote: 
>> > 
>> > 
>> > I title say, I download Go 1.18 beta (at this moment "go version 
>> go1.18beta2 linux/amd64") and I try to work through "Type Parameters 
>> Proposal" with it (
>> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md).
>>  
>> This thread is about thing that I can't code properly into Go 1.18 beta. 
>> > 
>> > I hope that you forgive me if I ask some questions before reading full 
>> proposal for the second time, previously I read in the September of the 
>> last year, and trying every solution obvious to good gopher. I have a 
>> little time and energy recently and I still want to try my hand with 
>> generics ASAP. 
>> > 
>> > I read and try every example from "Tutorial: Getting started with 
>> generics" (https://go.dev/doc/tutorial/generics), but it didn't help me 
>> with my problems. Maybe I just not advanced enough gopher (I

Re: [go-nuts] Going thorough "Type parameters proposal" with Go 1.18 beta

[Kamil Ziemian]

Thank you very much for information. I think now I understand my problem. I 
was thinking about method just as a function ("methods are just a 
functions" is one line from "A Tour of Go", that I know but don't 
understand its depth-in-simplicity) and for some reason I assumed 
StringableVector[T Stringer] is a kind of constraint. A such my thinking 
was that sliceStupidFloat is of type []stupidFloat, when stupidFloat 
satisfying constraint Stringer, so function (method) find that such 
constraint is satisfied.

Good gopher probably from the start would understand that since 
StringableVector[T Stringer] is NOT an interface type, it is a concrete 
generic type, not constraint. (Is calling something "concrete generic type" 
correct statement?) My stupid excuse is that materials on generics in Go 
focus on using generic functions, not generic types. I don't want to be 
misunderstood, in materials about Go I find a lot of examples how to define 
and call generic function. There is also many examples of defining generic 
types, but very little of creating and using objects (?) of generic types.

For example "Tutorial: Getting started with generics" (
https://go.dev/doc/tutorial/generics) deals only with generic functions. I 
guess some additional tutorial about generic types will be good thing for 
people like me.

Best regards,
Kamil
sobota, 5 lutego 2022 o 02:57:23 UTC+1 Ian Lance Taylor napisał(a):

> On Fri, Feb 4, 2022 at 5:01 PM Kamil Ziemian  wrote:
> >
> >
> > I title say, I download Go 1.18 beta (at this moment "go version 
> go1.18beta2 linux/amd64") and I try to work through "Type Parameters 
> Proposal" with it (
> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md).
>  
> This thread is about thing that I can't code properly into Go 1.18 beta.
> >
> > I hope that you forgive me if I ask some questions before reading full 
> proposal for the second time, previously I read in the September of the 
> last year, and trying every solution obvious to good gopher. I have a 
> little time and energy recently and I still want to try my hand with 
> generics ASAP.
> >
> > I read and try every example from "Tutorial: Getting started with 
> generics" (https://go.dev/doc/tutorial/generics), but it didn't help me 
> with my problems. Maybe I just not advanced enough gopher (I'm at most 
> medicore gopher) or I'm to tired recently to think creatively about Go.
> >
> > My first stumbling block is from section "Generic types" (
> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#generic-types).
>  
> At the end of it we have code.
> > > type StringableVector[T Stringer] []T
> > >
> > > func (s StringableVector[T]) String() string {
> > > var sb strings.Builder
> > > for i, v := range s {
> > > if i > 0 {
> > > sb.WriteString(", ")
> > > }
> > > // It's OK to call v.String here because v is of type T
> > > // and T's constraint is Stringer.
> > > sb.WriteString(v.String())
> > > }
> > > return sb.String()
> > > }
> >
> > So, I try to code it.
> >
> > > package main
> > >
> > > import (
> > > "fmt"
> > > "strings"
> > > )
> > >
> > > type Stringer interface {
> > > String() string
> > > }
> > >
> > > type StringableVector[T fmt.Stringer] []T
> > >
> > > type stupidFloat float64
> > >
> > > func (sF stupidFloat) String() string {
> > > return fmt.Sprintf("Stupid float %v", float64(sF))
> > > }
> > >
> > > func main() {
> > > var varStupidFloat stupidFloat = -1.0
> > >
> > > sliceStupidFloat := make([]stupidFloat, 3)
> > >
> > > for i := 0; i < 3; i++ {
> > > sliceStupidFloat[i] = stupidFloat(float64(i))
> > > }
> > >
> > > fmt.Println("stupidFloat.String(): ", varStupidFloat.String())
> > >
> > > fmt.Println("sliceStupidFloat:", sliceStupidFloat)
> > >
> > > fmt.Println("sliceStupidFloat:", sliceStupidFloat)
> > // fmt.Println("sliceStupidFloat.String():", sliceStupidFloat.String())
> > > }
> > >
> > > func (s StringableVector[T]) String() string {
> > > var sb strings.Builder
> > >
> > > for i, v := range s {
> > > if i > 0 {
> > > sb.WriteString(", ")
> > > }
> > > sb.WriteString(v.Str

[go-nuts] Going thorough "Type parameters proposal" with Go 1.18 beta

[Kamil Ziemian]

Hello,

I title say, I download Go 1.18 beta (at this moment "go version 
go1.18beta2 linux/amd64") and I try to work through "Type Parameters 
Proposal" with it 
(https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md).
 
This thread is about thing that I can't code properly into Go 1.18 beta.

I hope that you forgive me if I ask some questions before reading full 
proposal for the second time, previously I read in the September of the 
last year, and trying every solution obvious to good gopher. I have a 
little time and energy recently and I still want to try my hand with 
generics ASAP.

I read and try every example from "Tutorial: Getting started with generics" 
(https://go.dev/doc/tutorial/generics), but it didn't help me with my 
problems. Maybe I just not advanced enough gopher (I'm at most medicore 
gopher) or I'm to tired recently to think creatively about Go.

My first stumbling block is from section "Generic types" 
(https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#generic-types).
 
At the end of it we have code.
> type StringableVector[T Stringer] []T
>
> func (s StringableVector[T]) String() string {
> var sb strings.Builder
> for i, v := range s {
> if i > 0 {
> sb.WriteString(", ")
> }
> // It's OK to call v.String here because v is of type T
> // and T's constraint is Stringer.
> sb.WriteString(v.String())
> }
> return sb.String()
> }

So, I try to code it.

> package main
>
> import (
> "fmt"
> "strings"
> )
>
> type Stringer interface {
> String() string
> }
>
> type StringableVector[T fmt.Stringer] []T
>
> type stupidFloat float64
>
> func (sF stupidFloat) String() string {
> return fmt.Sprintf("Stupid float %v", float64(sF))
> }
>
> func main() {
> var varStupidFloat stupidFloat = -1.0
>
> sliceStupidFloat := make([]stupidFloat, 3)
>
> for i := 0; i < 3; i++ {
> sliceStupidFloat[i] = stupidFloat(float64(i))
> }
>
> fmt.Println("stupidFloat.String(): ", varStupidFloat.String())
>
> fmt.Println("sliceStupidFloat:", sliceStupidFloat)
>
> fmt.Println("sliceStupidFloat:", sliceStupidFloat)
// fmt.Println("sliceStupidFloat.String():", 
sliceStupidFloat.String())
> }
>
> func (s StringableVector[T]) String() string {
> var sb strings.Builder
>
> for i, v := range s {
> if i > 0 {
> sb.WriteString(", ")
> }
> sb.WriteString(v.String())
> }
>
> return sb.String()
> }

It works fine and produce result.
> stupidFloat.String():  Stupid float -1
> sliceStupidFloat: [Stupid float 0 Stupid float 1 Stupid float 2]
> sliceStupidFloat: [Stupid float 0 Stupid float 1 Stupid float 2]

But, when I uncommon last line in function main I get
> ./Go-s11-08.go:46:61: sliceStupidFloat.String undefined
> (type []stupidFloat has no field or method String)

I try to change my code in several ways, but result is always the same. How 
correct code should look like?

Best regards,
Kamil

-- 
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/85a60176-a22d-46fb-9676-3d5360d44d05n%40googlegroups.com.

Re: [go-nuts] Is Go good choice for porting graph based app?

[Kamil Ziemian]

Are you code available somewhere on Internet? Looking at some graph 
handling code in Go would be very helpful to me.

I have a very little time today, maybe I will write more about it in future.

Best,
Kamil
piątek, 4 lutego 2022 o 02:16:28 UTC+1 kortschak napisał(a):

> On Thu, 2022-02-03 at 14:26 -0800, Kamil Ziemian wrote:
> > Hello,
> >
> > I was handed proof-of-concept app written in Python. It seems
> > underdeveloped, buggy and running it first time is a pain, because of
> > dependencies. Basically it need to read some graphs stored in JSON
> > files and manipulated them accordingly and write them to JSON files
> > again.
> >
> > It seems that porting it now to more suitable language is worth a
> > gain at this stage and I wonder if Go is a good choice? I read and
> > watch many Ian Lance Taylor presentations about generics, so I know
> > that only that generic graph (tree) data structure is something that
> > can be a pain, but in this case it would be were small issue. It
> > seems that we have only few data types to be stored in graph, mostly
> > strings and ints.
> >
> > I'm not true gopher, so I don't know if Go is proper choice for this
> > task. I don't believe that Python is any better, but maybe I should
> > check another language.
> >
> > Also, if someone know better thing to sore graphs than JSON, I would
> > appreciate it any suggestion.
> >
> > I don't write anymore about this app, since I don't know if company
> > allows for it.
> >
>
>
> I have had success writing graph handling code in Go. The answer to
> your question though lies in the details of what it is that you want to
> do.
>
>
>

-- 
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/7a605d15-5aca-49bf-b0c2-486821deaf97n%40googlegroups.com.

[go-nuts] Is Go good choice for porting graph based app?

[Kamil Ziemian]

Hello,

I was handed proof-of-concept app written in Python. It seems 
underdeveloped, buggy and running it first time is a pain, because of 
dependencies. Basically it need to read some graphs stored in JSON files 
and manipulated them accordingly and write them to JSON files again.

It seems that porting it now to more suitable language is worth a gain at 
this stage and I wonder if Go is a good choice? I read and watch many Ian 
Lance Taylor presentations about generics, so I know that only that generic 
graph (tree) data structure is something that can be a pain,  but in this 
case it would be were small issue. It seems that we have only few data 
types to be stored in graph, mostly strings and ints.

I'm not true gopher, so I don't know if Go is proper choice for this task. 
I don't believe that Python is any better, but maybe I should check another 
language.

Also, if someone know better thing to sore graphs than JSON, I would 
appreciate it any suggestion.

I don't write anymore about this app, since I don't know if company allows 
for it.

Best regards,
Kamil

-- 
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/1a879e65-98c1-49be-bee9-c114f1d4ef1fn%40googlegroups.com.

[go-nuts] Re: Optimizing GoAWK with a bytecode compiler and virtual machine

[Kamil Ziemian]

I will try to follow development of GoAWK.

czwartek, 3 lutego 2022 o 22:38:46 UTC+1 ben...@gmail.com napisał(a):

> Recently I switched (so to speak) my GoAWK interpreter from using a 
> tree-walking interpreter to a bytecode compiler with a virtual machine, and 
> got a noticeable performance boost. Write-up here if you're interested: 
> https://benhoyt.com/writings/goawk-compiler-vm/
>
> TLDR: It's significantly more code, but also 10-20% faster. It'll get even 
> faster when Go implements "switch" using jump tables (looking forward to 
> https://go-review.googlesource.com/c/go/+/357330/).
>
> -Ben
>
>

-- 
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/0e22549d-7d48-487d-b1bf-e5d6b4c8d100n%40googlegroups.com.

Re: [go-nuts] Why Go allow function with unused arguments?

[Kamil Ziemian]

> By enforcing blanks, you'd lose the chance to name them something useful 
to tell the reader why they're ignored.

For me this is quite straightforward: they are omitted because, they aren't 
needed. True question to me is: why other functions need them? But, this 
wouldn't be answered by looking at this correct function. For my money, 
answers lies in place to which you send function with given signature, it 
decides what and why passed function signature is. I maybe wrong about that.

Best regards,
Kamil
poniedziałek, 31 stycznia 2022 o 12:40:08 UTC+1 Kamil Ziemian napisał(a):

> Thank you kortschak for explanation. It was clear to me why abstraction 
> by interface, require us to allow need unused parameter for methods, it 
> didn't come to my mind that you need to pass the function with proper 
> signature and some of this function may not need to use all parameters from 
> signature. When it will be uncomfortable, it probably occur more times that 
> we want.
>
> I strongly wish that blank identifier will be the norm, but I'm 
> pessimistic about arriving of Go 2. Probably everyone know that Go 2 is not 
> like releases in other languages, when you know that it will be done, 
> unless some big disaster happens along the way. To quote few of the biggest 
> gophers "We may never release Go 2". Backward compatibility is a big asset 
> of Go 1, so I'm pessimistic about Go 2 that need to introduce 3 or 4 
> breaking changes. Again I quote some big gopher about this 3 or 4 breaking 
> changes.
>
> Best regards,
> Kamil
> niedziela, 30 stycznia 2022 o 21:09:46 UTC+1 kortschak napisał(a):
>
>> On Sun, 2022-01-30 at 12:01 -0800, Kamil Ziemian wrote: 
>> > Hello, 
>> > 
>> > This is a question from ignorant in the meters of compilers and 
>> > mediocre Go users at best, so it may be stupid. 
>> > 
>> > I really like that in Go unused variable or import is compiler time 
>> > error. As such I wonder why function like 
>> > > func funTest(x int) int { 
>> > > return 3 
>> > > } 
>> > is allowed? I would guess that it is possible to check if function 
>> > argument is used in function body or not, so it seem plausible to 
>> > forbid it. 
>> > 
>> > Again, it maybe a stupid question from ignorant person. I have a lot 
>> > things to learn about Go, but I'm stuck in learning about Unicode and 
>> > UFT-8, so I guess it will be a long time before I can go back to 
>> > learning proper Go. I read FAQ and I didn't remember answer to this 
>> > question from it. This is my excuse for asking this question. 
>> > 
>> > Best regards, 
>> > Kamil Ziemian 
>>
>> It is necessary for methods to sometimes have parameters that are not 
>> used in order for the type to satisfy an interface. Similarly, if 
>> function values are being passed around the signatures will need to 
>> match even if the parameters are not being used. 
>>
>> It is possible to use the blank identifier in these cases to signal 
>> that a parameter is not being used and that can be linted for. 
>>
>> See https://github.com/golang/go/issues/39118 for discussion on a 
>> proposal relating to this. 
>>
>>
>>

-- 
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/c25988d6-918b-42cf-af86-fc75d19c2aa9n%40googlegroups.com.

Re: [go-nuts] Why Go allow function with unused arguments?

[Kamil Ziemian]

Thank you kortschak for explanation. It was clear to me why abstraction by 
interface, require us to allow need unused parameter for methods, it didn't 
come to my mind that you need to pass the function with proper signature 
and some of this function may not need to use all parameters from 
signature. When it will be uncomfortable, it probably occur more times that 
we want.

I strongly wish that blank identifier will be the norm, but I'm pessimistic 
about arriving of Go 2. Probably everyone know that Go 2 is not like 
releases in other languages, when you know that it will be done, unless 
some big disaster happens along the way. To quote few of the biggest 
gophers "We may never release Go 2". Backward compatibility is a big asset 
of Go 1, so I'm pessimistic about Go 2 that need to introduce 3 or 4 
breaking changes. Again I quote some big gopher about this 3 or 4 breaking 
changes.

Best regards,
Kamil
niedziela, 30 stycznia 2022 o 21:09:46 UTC+1 kortschak napisał(a):

> On Sun, 2022-01-30 at 12:01 -0800, Kamil Ziemian wrote:
> > Hello,
> >
> > This is a question from ignorant in the meters of compilers and
> > mediocre Go users at best, so it may be stupid.
> >
> > I really like that in Go unused variable or import is compiler time
> > error. As such I wonder why function like
> > > func funTest(x int) int {
> > > return 3
> > > }
> > is allowed? I would guess that it is possible to check if function
> > argument is used in function body or not, so it seem plausible to
> > forbid it.
> >
> > Again, it maybe a stupid question from ignorant person. I have a lot
> > things to learn about Go, but I'm stuck in learning about Unicode and
> > UFT-8, so I guess it will be a long time before I can go back to
> > learning proper Go. I read FAQ and I didn't remember answer to this
> > question from it. This is my excuse for asking this question.
> >
> > Best regards,
> > Kamil Ziemian
>
> It is necessary for methods to sometimes have parameters that are not
> used in order for the type to satisfy an interface. Similarly, if
> function values are being passed around the signatures will need to
> match even if the parameters are not being used.
>
> It is possible to use the blank identifier in these cases to signal
> that a parameter is not being used and that can be linted for.
>
> See https://github.com/golang/go/issues/39118 for discussion on a
> proposal relating to this.
>
>
>

-- 
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/b4017e62-f86a-4b6a-8a96-d95e35e04a0an%40googlegroups.com.

[go-nuts] Why Go allow function with unused arguments?

[Kamil Ziemian]

Hello,

This is a question from ignorant in the meters of compilers and mediocre Go 
users at best, so it may be stupid.

I really like that in Go unused variable or import is compiler time error. 
As such I wonder why function like
> func funTest(x int) int {
> return 3
> }
is allowed? I would guess that it is possible to check if function argument 
is used in function body or not, so it seem plausible to forbid it.

Again, it maybe a stupid question from ignorant person. I have a lot things 
to learn about Go, but I'm stuck in learning about Unicode and UFT-8, so I 
guess it will be a long time before I can go back to learning proper Go. I 
read FAQ and I didn't remember answer to this question from it. This is my 
excuse for asking this question.

Best regards,
Kamil Ziemian

-- 
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/fda89503-fde5-4b5b-80c3-50e74da1dc51n%40googlegroups.com.

[go-nuts] Re: Anyone else writing an interpreter with Thorsten Ball?

[Kamil Ziemian]

Thank you for the feedback!

piątek, 28 stycznia 2022 o 20:40:40 UTC+1 timphar...@gmail.com napisał(a):

> It's very well-explained and the code's easy to read. And you can build on 
> it. I've been able to modify his code to my language spec, use syntactic 
> whitespace instead of braces, utf8 instead  of ASCII, my idea of how 
> continuations should work, line numbers in error messages, the ability to 
> define infixes and suffixes, optional typing in functions, my own notion of 
> conditional syntax, and I've just been able to rationalize my code by 
> getting the 1.18 beta version of Go and implementing a generic Set type. 
> It's going good. Recommend.
> On Wednesday, January 26, 2022 at 3:15:11 PM UTC-8 kziem...@gmail.com 
> wrote:
>
>> I found this books last weeks, on community page of different language 
>> and I consider buying them. But I have a lot thing to learn for Go with 
>> learning materials for free (unicode, UTF-8, Go spec, etc.), that I will 
>> probably postpone this book to the future. If you don't mind, I want to ask 
>> you about your experience of writing interpreter with them.
>>
>> Best regards,
>> Kamil
>> środa, 26 stycznia 2022 o 20:35:37 UTC+1 timphar...@gmail.com napisał(a):
>>
>>> How's it going? I'd just like to talk with someone who's doing the same 
>>> thing, it's kind of a lonely hobby.
>>>
>>> I'm just about to start on the actual interpreter, I've got my lexer and 
>>> parser working, and I also have a thing called a "relexer" which is kind of 
>>> an elegant kludge that makes syntactic whitespace work, and an "uberparser" 
>>> which breaks the program down into chunks ... my language is very different 
>>> from Monkey, there's going to be hardly a line of Ball's code left when I'm 
>>> finished, but I couldn't do it without him.
>>>
>>> (And for those of you who haven't seen his books, I recommend them, 
>>> they're like crack if crack made you a better and smarter person.)
>>>
>>

-- 
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/2c77c04a-be23-43dd-9d18-0c36f57edb60n%40googlegroups.com.

Re: [go-nuts] Go 1.18, generics and fuzz testing

[Kamil Ziemian]

Thank you for information. There is so many things about Go and its tool 
chain that I need to learn and think about.

Best regards,
Kamil
czwartek, 27 stycznia 2022 o 01:22:36 UTC+1 Ian Lance Taylor napisał(a):

> On Wed, Jan 26, 2022 at 4:17 PM Kamil Ziemian  wrote:
> >
> > I accidentally initialize go.mod files for both tutorial on generics (
> https://go.dev/doc/tutorial/generics) and for fuzzing (
> https://go.dev/doc/tutorial/fuzz) with command
> > > go mod init example/nameOfSubject
> > and as a result both contains in respective go.mod file line
> > > go 1.17
> >
> > In the case of generic mere writing function definition
> > > func SumIntsOrFloats[K comparable, V int64 | float64](m map[K]V) V {
> > > var s V
> > for _, v := range m {
> > s += v
> > }
> > return s
> > }
> > without even calling it produce a compile error
> > > ./main.go:39:22: type parameters require go1.18 or later
> > To make it work I needed to change go.mod file to this with proper 
> version 1.18.
> >
> > But in the case of fuzzing I have done all the examples from tutorial 
> without once encountering error of this type.
> >
> > Can anyone check if it have similar issue? I don't know if it is minor 
> problem or sign of some substantial flaw, but it is worth checking on few 
> machines.
>
> Fuzzing is implemented in the tools, not the language itself, so if
> you are using the 1.18 tools it works regardless of the requested
> language version.
>
> Ian
>

-- 
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/22a63a33-f9f3-4ea4-b275-4c5e627696cdn%40googlegroups.com.

[go-nuts] Go 1.18, generics and fuzz testing

[Kamil Ziemian]

Hello,

I accidentally initialize go.mod files for both tutorial on generics 
(https://go.dev/doc/tutorial/generics) and for fuzzing 
(https://go.dev/doc/tutorial/fuzz) with command
> go mod init example/nameOfSubject
and as a result both contains in respective go.mod file line
> go 1.17

In the case of generic mere writing function definition
> func SumIntsOrFloats[K comparable, V int64 | float64](m map[K]V) V {
 >var s V
for _, v := range m {
s += v
}
return s
}
without even calling it produce a compile error
> ./main.go:39:22: type parameters require go1.18 or later
To make it work I needed to change go.mod file to this with proper version 
1.18.

But in the case of fuzzing I have done all the examples from tutorial 
without once encountering error of this type.

Can anyone check if it have similar issue? I don't know if it is minor 
problem or sign of some substantial flaw, but it is worth checking on few 
machines.

Best regards,
Kamil 

-- 
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/cfef4efa-2773-4b02-875c-7219b385dc15n%40googlegroups.com.

[go-nuts] Re: Anyone else writing an interpreter with Thorsten Ball?

[Kamil Ziemian]

I found this books last weeks, on community page of different language and 
I consider buying them. But I have a lot thing to learn for Go with 
learning materials for free (unicode, UTF-8, Go spec, etc.), that I will 
probably postpone this book to the future. If you don't mind, I want to ask 
you about your experience of writing interpreter with them.

Best regards,
Kamil
środa, 26 stycznia 2022 o 20:35:37 UTC+1 timphar...@gmail.com napisał(a):

> How's it going? I'd just like to talk with someone who's doing the same 
> thing, it's kind of a lonely hobby.
>
> I'm just about to start on the actual interpreter, I've got my lexer and 
> parser working, and I also have a thing called a "relexer" which is kind of 
> an elegant kludge that makes syntactic whitespace work, and an "uberparser" 
> which breaks the program down into chunks ... my language is very different 
> from Monkey, there's going to be hardly a line of Ball's code left when I'm 
> finished, but I couldn't do it without him.
>
> (And for those of you who haven't seen his books, I recommend them, 
> they're like crack if crack made you a better and smarter person.)
>

-- 
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/e82c0d58-f474-4324-92ef-372fd27d3d84n%40googlegroups.com.

[go-nuts] Re: G 1.18, remarks on "Tutorial: Getting started with fuzzing (beta content)"

[Kamil Ziemian]

Hello,

I have few other suggestions about [Tutorial: Getting started with 
fuzzing](https://go.dev/doc/tutorial/fuzz).

In section "Fix the double reverse error", second "Write the code" point 
three states.
> Don’t forget to import the new errors package. The first lines of main.go 
should look like the following.
>
> import (
> "fmt"
> "errors"
  "unicode/utf8"
> )

>From this text I read that we need new packages errors in main.go file. But 
fact we need to import two new packages, because unicode/utf8 wasn't 
previously used in this file, so it wouldn't compile. It was previously 
imported and used in reverse_test.go file and authors of tutorial probably 
forget about it when their wrote this part.

Also I would change "The first lines of main.go should look like the 
following." to "The import statement of main.go should look like the 
following.". I like this more since first line on the file is "package 
main" and it is not shown in code example.

Best regards,
Kamil
środa, 26 stycznia 2022 o 11:33:32 UTC+1 Kamil Ziemian napisał(a):

> Ups, I just push button to send it. Bellow I will continue it.
>
> For more experience users it says "The first lines of code should look 
> like this:", when it can just say "Import "fmt" library to use 
> fmt.Printf" or something similar.
>
> I hope that I didn't sound to harsh about this tutorial. My English is not 
> good enough to allow to me to write with desired tone. This only my 
> suggestions and thoughts and I want to hear opinions of more competent 
> people about this tutorial.
>
> Best regards,
> Kamil
> środa, 26 stycznia 2022 o 11:28:19 UTC+1 Kamil Ziemian napisał(a):
>
>> Hello,
>>
>> I have few doubts about "Tutorial: Getting started with fuzzing (beta 
>> content)" (https://go.dev/doc/tutorial/fuzz) and I want to hear your 
>> opinions on them.
>>
>> First few disclaimers. I new to fuzzy testing and while I like this idea, 
>> I'm to ignorant to say much about it. 
>>
>> Also I already read "Go Slices: usage and internals" (
>> https://go.dev/blog/slices-intro) by Andrew Gerrand, "Arrays, slices 
>> (and strings): The mechanics of 'append'" (https://go.dev/blog/slices) 
>> by Rob Pike two times each and "Strings, bytes, runes and characters in 
>> Go" (https://go.dev/blog/strings) by Rob Pike three times or more and I 
>> still struggles with thinking about code points, runes, UTF-8 and strings 
>> on theoretical level. At practice level I'm doing well enough to write and 
>> test all my simple programs. (I have plane to read Unicode standard and 
>> some technical works on UTF-8, but this takes time.) So I may say some dumb 
>> things about this topic.
>>
>> In the section "Fix the double reverse error" in the third paragraph of 
>> "Diagnose 
>> the error" we have "When the input string is set to rune[]". For my money 
>> it should be "[]rune", but maybe I miss something.
>>
>> Here are my thoughts about "Add code to test". I read few others Go 
>> official tutorials and this section seems to me messy when compared to 
>> them, but it my by only my impression. For me it read as "Put this code at 
>> the top of the file, then past this below it, then past this between this 
>> two. After that below rewrite beginning of the file to look like that.". 
>>
>> This method of explanation is fine if you say "Write this code" spend 
>> some time explaining it and next say "We now modified code in following 
>> way". I fine with that, but in this tutorial you have one line of 
>> explanation and you go to next point. I'm intermediate (maybe) Go 
>> programmer enough to this making no problem to me, but this tutorial in 
>> many places want be beginner friendly and I believe that for beginner this 
>> part can be confusing.
>>
>> I think it will be more clearly if you just write whole code of main.go 
>> and after that explain it in points, as it is done now. Also in "Add a 
>> unit test" second point in "Write the code" states "Paste the following 
>> code into reverse_test.go.", so it be now problem to write the same about 
>> main.go.
>>
>> Also in section "Add code to test" in point 5 of "Write the code" we 
>> read.
>>
>> > Near the top of main.go, just beneath the package declaration, import 
>> the package you’ll need to support the code you’ve just 

[go-nuts] Proposition for Go proverb on generics: Write code, don't design types.

[Kamil Ziemian]

"Write code, don't design types." This statement is a title of the section 
of *Generics!*  talk by Robert 
Griesemer and Ian Lance Taylor at GopherCon 2021, time 21:09 and while I 
start to try my hands with generics in beta of Go 1.18 I think that it look 
like good new Go proverb. What do you think about it?

Anyone interested in generics (type parameters) should watch this whole 
talk. As a side effect he/she will know what is the meaning of this proverb 
by Ian Lance Taylor.

Best regards,
Kamil

-- 
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/f14030eb-e506-437d-beaa-ed00cb285fa5n%40googlegroups.com.

[go-nuts] Re: G 1.18, remarks on "Tutorial: Getting started with fuzzing (beta content)"

[Kamil Ziemian]

Ups, I just push button to send it. Bellow I will continue it.

For more experience users it says "The first lines of code should look like 
this:", when it can just say "Import "fmt" library to use fmt.Printf" or 
something similar.

I hope that I didn't sound to harsh about this tutorial. My English is not 
good enough to allow to me to write with desired tone. This only my 
suggestions and thoughts and I want to hear opinions of more competent 
people about this tutorial.

Best regards,
Kamil
środa, 26 stycznia 2022 o 11:28:19 UTC+1 Kamil Ziemian napisał(a):

> Hello,
>
> I have few doubts about "Tutorial: Getting started with fuzzing (beta 
> content)" (https://go.dev/doc/tutorial/fuzz) and I want to hear your 
> opinions on them.
>
> First few disclaimers. I new to fuzzy testing and while I like this idea, 
> I'm to ignorant to say much about it. 
>
> Also I already read "Go Slices: usage and internals" (
> https://go.dev/blog/slices-intro) by Andrew Gerrand, "Arrays, slices (and 
> strings): The mechanics of 'append'" (https://go.dev/blog/slices) by Rob 
> Pike two times each and "Strings, bytes, runes and characters in Go" (
> https://go.dev/blog/strings) by Rob Pike three times or more and I still 
> struggles with thinking about code points, runes, UTF-8 and strings on 
> theoretical level. At practice level I'm doing well enough to write and 
> test all my simple programs. (I have plane to read Unicode standard and 
> some technical works on UTF-8, but this takes time.) So I may say some dumb 
> things about this topic.
>
> In the section "Fix the double reverse error" in the third paragraph of 
> "Diagnose 
> the error" we have "When the input string is set to rune[]". For my money 
> it should be "[]rune", but maybe I miss something.
>
> Here are my thoughts about "Add code to test". I read few others Go 
> official tutorials and this section seems to me messy when compared to 
> them, but it my by only my impression. For me it read as "Put this code at 
> the top of the file, then past this below it, then past this between this 
> two. After that below rewrite beginning of the file to look like that.". 
>
> This method of explanation is fine if you say "Write this code" spend some 
> time explaining it and next say "We now modified code in following way". I 
> fine with that, but in this tutorial you have one line of explanation and 
> you go to next point. I'm intermediate (maybe) Go programmer enough to this 
> making no problem to me, but this tutorial in many places want be beginner 
> friendly and I believe that for beginner this part can be confusing.
>
> I think it will be more clearly if you just write whole code of main.go 
> and after that explain it in points, as it is done now. Also in "Add a 
> unit test" second point in "Write the code" states "Paste the following 
> code into reverse_test.go.", so it be now problem to write the same about 
> main.go.
>
> Also in section "Add code to test" in point 5 of "Write the code" we read.
>
> > Near the top of main.go, just beneath the package declaration, import 
> the package you’ll need to support the code you’ve just written. 
>
> > The first lines of code should look like this:
> > package main 
> >
> > import "fmt" 
>
> Personally, I don't like how this point is written. It doesn't explain 
> what we add and why, so it can have little worth for beginners. For anyone 
> who had more experience with Go it will be clear just by looking at code: 
> we import "fmt" library to have ability to print results with "fmt.Printf". 
> On the other hand "The first lines of code should look like this:" looks 
> like line dedicated to beginner, that need the compare what he/she write in 
> file with what he/she see on the screen. Everyone was beginner at some 
> point and I'm probably not even intermediate Go programmer, so I don't 
> have problem with that.
>
> I don't like this point because it seems not well tailored to anyone. For 
> beginners it doesn't explain what we add and why. From my memory when you 
> start even remembering what "import "fmt"" is doing and how to use it can 
> be a problem. For more experience users it says 
>

-- 
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/be3367e6-949d-4bc2-89df-f5bfa8532b46n%40googlegroups.com.

[go-nuts] G 1.18, remarks on "Tutorial: Getting started with fuzzing (beta content)"

[Kamil Ziemian]

Hello,

I have few doubts about "Tutorial: Getting started with fuzzing (beta 
content)" (https://go.dev/doc/tutorial/fuzz) and I want to hear your 
opinions on them.

First few disclaimers. I new to fuzzy testing and while I like this idea, 
I'm to ignorant to say much about it. 

Also I already read "Go Slices: usage and internals" 
(https://go.dev/blog/slices-intro) by Andrew Gerrand, "Arrays, slices (and 
strings): The mechanics of 'append'" (https://go.dev/blog/slices) by Rob 
Pike two times each and "Strings, bytes, runes and characters in Go" 
(https://go.dev/blog/strings) by Rob Pike three times or more and I still 
struggles with thinking about code points, runes, UTF-8 and strings on 
theoretical level. At practice level I'm doing well enough to write and 
test all my simple programs. (I have plane to read Unicode standard and 
some technical works on UTF-8, but this takes time.) So I may say some dumb 
things about this topic.

In the section "Fix the double reverse error" in the third paragraph of 
"Diagnose 
the error" we have "When the input string is set to rune[]". For my money 
it should be "[]rune", but maybe I miss something.

Here are my thoughts about "Add code to test". I read few others Go 
official tutorials and this section seems to me messy when compared to 
them, but it my by only my impression. For me it read as "Put this code at 
the top of the file, then past this below it, then past this between this 
two. After that below rewrite beginning of the file to look like that.". 

This method of explanation is fine if you say "Write this code" spend some 
time explaining it and next say "We now modified code in following way". I 
fine with that, but in this tutorial you have one line of explanation and 
you go to next point. I'm intermediate (maybe) Go programmer enough to this 
making no problem to me, but this tutorial in many places want be beginner 
friendly and I believe that for beginner this part can be confusing.

I think it will be more clearly if you just write whole code of main.go and 
after that explain it in points, as it is done now. Also in "Add a unit 
test" second point in "Write the code" states "Paste the following code 
into reverse_test.go.", so it be now problem to write the same about 
main.go.

Also in section "Add code to test" in point 5 of "Write the code" we read.

> Near the top of main.go, just beneath the package declaration, import the 
package you’ll need to support the code you’ve just written. 

> The first lines of code should look like this:
> package main 
>
> import "fmt" 

Personally, I don't like how this point is written. It doesn't explain what 
we add and why, so it can have little worth for beginners. For anyone who 
had more experience with Go it will be clear just by looking at code: we 
import "fmt" library to have ability to print results with "fmt.Printf". On 
the other hand "The first lines of code should look like this:" looks like 
line dedicated to beginner, that need the compare what he/she write in file 
with what he/she see on the screen. Everyone was beginner at some point and 
I'm probably not even intermediate Go programmer, so I don't have problem 
with that.

I don't like this point because it seems not well tailored to anyone. For 
beginners it doesn't explain what we add and why. From my memory when you 
start even remembering what "import "fmt"" is doing and how to use it can 
be a problem. For more experience users it says 

-- 
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/19de7599-a2b2-49f4-97f7-e273b8a7975fn%40googlegroups.com.

Re: [go-nuts] Various questions about posts from The Go Blog

[Kamil Ziemian]

Hello,

I have one more think to say about Go blog post "Why generics?". Again, 
nothing really important.

In the section "Generic data structures" in the second counting from the 
end code example we have line.
> *pn = &node(E){val: v}
It is commented by the sentence "Notice the type argument E to the type 
node.". Maybe it should be "Notice the type argument E send to the type 
node."? Currently it sound odd to my ears.

Also, I found out that in "Go 1.18 Beta 1 is available, with generics" 
(https://go.dev/blog/go1.18beta1) written by Russ Cox on behalf of the Go 
team, post "Why generics?" is referenced in prominent place in third 
paragraph. I think it another reason to add block text to "Why generics?" 
to make clear for readers that they need to be aware, that actually 
implementation in beta of Go 18 at syntax level is quite different than 
that presented in this blog post.

Best,
Kamil Ziemian
poniedziałek, 24 stycznia 2022 o 12:47:11 UTC+1 Kamil Ziemian napisał(a):

> Hello,
>
> Since with release of Go 1.18 we will have Go's generics, I started a 
> preparation tour around Go blog and YouTube. And here is one suggestion and 
> one unimportant comment of mine about blog post "Why Generics?" (
> https://go.dev/blog/why-generics).
>
> This post is in my opinion very valuable, fortunately Go team abandons 
> change few ideas to better ones, like removing concept of "contracts" in 
> the name of new functionality of interfaces. In such situation I propose to 
> add at the top of the page text block saying "Caution. Implementation of 
> generics in Go different from draft discussed here. To learn about actual 
> implementation of generics check [link to relevant materials]."
>
> Now unimportant comment. At the end of the section "Ordered types" we 
> have paragraph
> "In practice this contract would probably go into the standard library, 
> and so really the Min function (which will probably also be in the standard 
> library somewhere) will look like this. Here we’re just referring to the 
> contract Ordered defined in the package contracts."
> All this text use one kind of font, which contrast with all the rest of 
> the post. Names of Go functions such as "Min" and meta-types as "Ordered" 
> to this point was always typed with different font. I think this is simple, 
> unimportant mistake.
>
> Best,
> Kamil
>
> poniedziałek, 8 listopada 2021 o 14:54:39 UTC+1 Leam Hall napisał(a):
>
>> I agree with Kamil. Go is young and growing. Committing to keeping at 
>> least the "official" blogs updated will help us on-board new gophers and 
>> get them productive quickly. 
>>
>> I appreciate the effort the Go team puts into the blogs and documents. 
>> How can we make it easier and better? 
>>
>> Leam 
>>
>> On 11/8/21 06:03, Kamil Ziemian wrote: 
>> > "Blog posts should really be viewed as a snapshot that is valid when 
>> they're published (that's why they contain a date)" 
>> > I agree, but since page that you are referring contains numbers of 
>> links to Go Blog posts with description "The official blog of the Go 
>> project <https://blog.golang.org/>, featuring news and in-depth articles 
>> by the Go team and guests.", I feel that they should put this disclaimer on 
>> this page or move links to posts to another page. "Using Go Module <
>> https://golang.org/blog/using-go-modules>" is among posts linked on 
>> Documentation. 
>> > 
>> > Maybe there is a way to suggest such a simple change to this page to 
>> people that maintain documentation? Or maybe this is over the top idea? 
>> > 
>> > Best 
>> > Kamil 
>> > 
>> > pon., 8 lis 2021 o 12:31 Sean Liao > seank...@gmail.com>> napisał(a): 
>> > 
>> > Blog posts should really be viewed as a snapshot that is valid when 
>> they're published (that's why they contain a date) 
>> > The guides under https://golang.org/doc/#getting-started <
>> https://golang.org/doc/#getting-started> however should be kept up to 
>> date with the latest releases 
>> > 
>> > On Monday, November 8, 2021 at 11:24:48 AM UTC+1 kziem...@gmail.com 
>> <mailto:kziem...@gmail.com> wrote: 
>> > 
>> > "Technically that behaviour is still available via GO111MODULE=auto. 
>> > Go 1.16 changed the default from "auto" to "on"." 
>> > 
>> > Thank you for that information. It is surprisingly hard to me to learn 
>> basic of Go

Re: [go-nuts] Various questions about posts from The Go Blog

[Kamil Ziemian]

Hello,

Since with release of Go 1.18 we will have Go's generics, I started a 
preparation tour around Go blog and YouTube. And here is one suggestion and 
one unimportant comment of mine about blog post "Why Generics?" 
(https://go.dev/blog/why-generics).

This post is in my opinion very valuable, fortunately Go team abandons 
change few ideas to better ones, like removing concept of "contracts" in 
the name of new functionality of interfaces. In such situation I propose to 
add at the top of the page text block saying "Caution. Implementation of 
generics in Go different from draft discussed here. To learn about actual 
implementation of generics check [link to relevant materials]."

Now unimportant comment. At the end of the section "Ordered types" we have 
paragraph
"In practice this contract would probably go into the standard library, and 
so really the Min function (which will probably also be in the standard 
library somewhere) will look like this. Here we’re just referring to the 
contract Ordered defined in the package contracts."
All this text use one kind of font, which contrast with all the rest of the 
post. Names of Go functions such as "Min" and meta-types as "Ordered" to 
this point was always typed with different font. I think this is simple, 
unimportant mistake.

Best,
Kamil

poniedziałek, 8 listopada 2021 o 14:54:39 UTC+1 Leam Hall napisał(a):

> I agree with Kamil. Go is young and growing. Committing to keeping at 
> least the "official" blogs updated will help us on-board new gophers and 
> get them productive quickly.
>
> I appreciate the effort the Go team puts into the blogs and documents. How 
> can we make it easier and better?
>
> Leam
>
> On 11/8/21 06:03, Kamil Ziemian wrote:
> > "Blog posts should really be viewed as a snapshot that is valid when 
> they're published (that's why they contain a date)"
> > I agree, but since page that you are referring contains numbers of links 
> to Go Blog posts with description "The official blog of the Go project <
> https://blog.golang.org/>, featuring news and in-depth articles by the Go 
> team and guests.", I feel that they should put this disclaimer on this page 
> or move links to posts to another page. "Using Go Module <
> https://golang.org/blog/using-go-modules>" is among posts linked on 
> Documentation.
> > 
> > Maybe there is a way to suggest such a simple change to this page to 
> people that maintain documentation? Or maybe this is over the top idea?
> > 
> > Best
> > Kamil
> > 
> > pon., 8 lis 2021 o 12:31 Sean Liao  seank...@gmail.com>> napisał(a):
> > 
> > Blog posts should really be viewed as a snapshot that is valid when 
> they're published (that's why they contain a date)
> > The guides under https://golang.org/doc/#getting-started <
> https://golang.org/doc/#getting-started> however should be kept up to 
> date with the latest releases
> > 
> > On Monday, November 8, 2021 at 11:24:48 AM UTC+1 kziem...@gmail.com 
> <mailto:kziem...@gmail.com> wrote:
> > 
> > "Technically that behaviour is still available via GO111MODULE=auto.
> > Go 1.16 changed the default from "auto" to "on"."
> > 
> > Thank you for that information. It is surprisingly hard to me to learn 
> basic of Go and Go tools, when things don't works as described.
> > 
> > I found few another places where "Using Go Modules" (
> https://go.dev/blog/using-go-modules <https://go.dev/blog/using-go-modules>) 
> is not up to date with out of box Go version 1.17.2.
> > 
> > 1) According to part "Adding a dependency" (end of fourth block of text) 
> "Only direct dependencies are recorded in the go.mod file". But my go.mod 
> file contains lines.
> > 
> > require (
> > golang.org/x/text <http://golang.org/x/text> 
> v0.0.0-20170915032832-14c0d48ead0c // indirect
> > rsc.io/sampler <http://rsc.io/sampler> v1.3.0 // indirect
> > )
> > 
> > 2) After using "go get golang.org/x/text <http://golang.org/x/text>" 
> command "go list -m all" I get one line more that in blog post
> > 
> > golang.org/x/tools <http://golang.org/x/tools> 
> v0.0.0-20180917221912-90fa682c2a6e
> > 
> > 3) After function TestProverb(t *testing.T) is and running "go test" 
> (I'm quite sure that when I did this few years ago, this was the command 
> that I used) I get
> > 
> > hello.go:5:2: no required module provides package rsc.io/quote/v3 <
> http://rsc.io/quote/v3>; to add it:
> > 

Re: [go-nuts] Amateur question: when you should use runes?

[Kamil Ziemian]

Thank you all for answers. I have a lot to do in next few weeks, after that 
I will go back to runes and think more about your answers.

Best,
Kamil

poniedziałek, 15 listopada 2021 o 21:52:27 UTC+1 imsach...@gmail.com 
napisał(a):

> On Tue, Nov 16, 2021 at 12:38 AM burak serdar  wrote:
>
>>
>>
>> On Mon, Nov 15, 2021 at 11:00 AM Kamil Ziemian  
>> wrote:
>>
>>> Hello,
>>>
>>> I read quite a few blog posts, articles, listen to nice number to talks 
>>> about strings, runes and encoding in Go. I now reading Go Language Spec and 
>>> I just stuck in the section about runes. I mean, it isn't hard as itself, 
>>> but it raises to much questions to me. I decided that I need to learn more 
>>> about Unicode and UTF-8, so from today I'm reading Unicode Technical Site 
>>> (?), currently the Glossary (https://www.unicode.org/glossary/). *But I 
>>> can't understand one thing: when in practice you should use runes?*
>>
>>
> *An example of data type "rune"*
> *Lets say we want to retrieve 5th digit from an integer ( 1234567 )*
> *Step 1 = convert an integer to string using "strconv.Itoa()" *
> *Step 2 = convert that string to slice of rune using "rune"*
> *Step 3 = retrieve 5th digit from slice of rune*
> *Step 4 = convert the retrieved 5th digit to string*
>
> *here is an example* https://play.golang.org/p/M22Awjcu2-0
>
>
>
>
>
>
>  
>
>>
>>> My understanding at this moment is like that. Unicode assign every 
>>> symbol a number (at this moment I disregard normalization and any other 
>>> more advance stuff), rune is alias for int32 that stores integer 
>>> representation of this number. UTF-8 is variable size encoding using one or 
>>> more bytes to encode symbol and shouldn't and DOESN'T represent integer 
>>> value of symbols Unicode number. Virtues of UTF-8 are clear as how it 
>>> allows to save a space is clear to me, but I can't find a reason why I 
>>> should transform my text to runes? In Go stdlib there is a RuneReader 
>>> interface (?) so this reason must exists, but I just can't find anything. 
>>> Maybe it have something to do with sending information using internet? I 
>>> don't know, this is totally outside my humble knowledge.
>>>
>>
>> In general, you should work with runes whenever you are working with text 
>> that is entered by humans, or text that will be read by humans.
>>
>> When you work with a string as a stream of bytes, then you either assume 
>> the string does not contain any bytes over 127, or you have to decode the 
>> UTF-8 string yourself. Working with runes eliminates both problems. 
>>
>>
>>  
>>
>>>
>>> You can say, that since I don't see a reason to use runes, I probably 
>>> shouldn't care about it. This is a valid point, but I want to know Go 
>>> reasonable well and constantly find code with runes which reason of 
>>> existence I don't understand (e.g. functions in stdlib that operates on 
>>> runes) is quite demoralising to me.
>>>
>>> Best
>>> Kamil
>>>
>>> -- 
>>> 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/f3dad0e1-cd25-4e33-a7f2-34e0118bf68an%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/golang-nuts/f3dad0e1-cd25-4e33-a7f2-34e0118bf68an%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...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/CAMV2Rqovfg9k9ALawv%2BC36_AxT0sbOb%2BEpcpKNO9r2kmg_T1nQ%40mail.gmail.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/CAMV2Rqovfg9k9ALawv%2BC36_AxT0sbOb%2BEpcpKNO9r2kmg_T1nQ%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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/fdd0b249-b7ab-435a-a8f1-76b105bc8f83n%40googlegroups.com.

[go-nuts] Amateur question: when you should use runes?

[Kamil Ziemian]

Hello,

I read quite a few blog posts, articles, listen to nice number to talks 
about strings, runes and encoding in Go. I now reading Go Language Spec and 
I just stuck in the section about runes. I mean, it isn't hard as itself, 
but it raises to much questions to me. I decided that I need to learn more 
about Unicode and UTF-8, so from today I'm reading Unicode Technical Site 
(?), currently the Glossary (https://www.unicode.org/glossary/). But I 
can't understand one thing: when in practice you should use runes?

My understanding at this moment is like that. Unicode assign every symbol a 
number (at this moment I disregard normalization and any other more advance 
stuff), rune is alias for int32 that stores integer representation of this 
number. UTF-8 is variable size encoding using one or more bytes to encode 
symbol and shouldn't and DOESN'T represent integer value of symbols Unicode 
number. Virtues of UTF-8 are clear as how it allows to save a space is 
clear to me, but I can't find a reason why I should transform my text to 
runes? In Go stdlib there is a RuneReader interface (?) so this reason must 
exists, but I just can't find anything. Maybe it have something to do with 
sending information using internet? I don't know, this is totally outside 
my humble knowledge.

You can say, that since I don't see a reason to use runes, I probably 
shouldn't care about it. This is a valid point, but I want to know Go 
reasonable well and constantly find code with runes which reason of 
existence I don't understand (e.g. functions in stdlib that operates on 
runes) is quite demoralising to me.

Best
Kamil

-- 
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/f3dad0e1-cd25-4e33-a7f2-34e0118bf68an%40googlegroups.com.

Re: [go-nuts] Various questions about posts from The Go Blog

[Kamil Ziemian]

"Blog posts should really be viewed as a snapshot that is valid when
they're published (that's why they contain a date)"
I agree, but since page that you are referring contains numbers of links to
Go Blog posts with description "The official blog of the Go project
<https://blog.golang.org/>, featuring news and in-depth articles by the Go
team and guests.", I feel that they should put this disclaimer on this page
or move links to posts to another page. "Using Go Module
<https://golang.org/blog/using-go-modules>" is among posts linked on
Documentation.

Maybe there is a way to suggest such a simple change to this page to people
that maintain documentation? Or maybe this is over the top idea?

Best
Kamil

pon., 8 lis 2021 o 12:31 Sean Liao  napisał(a):

> Blog posts should really be viewed as a snapshot that is valid when
> they're published (that's why they contain a date)
> The guides under https://golang.org/doc/#getting-started however should
> be kept up to date with the latest releases
>
> On Monday, November 8, 2021 at 11:24:48 AM UTC+1 kziem...@gmail.com wrote:
>
>> "Technically that behaviour is still available via GO111MODULE=auto.
>> Go 1.16 changed the default from "auto" to "on"."
>>
>> Thank you for that information. It is surprisingly hard to me to learn
>> basic of Go and Go tools, when things don't works as described.
>>
>> I found few another places where "Using Go Modules" (
>> https://go.dev/blog/using-go-modules) is not up to date with out of box
>> Go version 1.17.2.
>>
>> 1) According to part "Adding a dependency" (end of fourth block of text)
>> "Only direct dependencies are recorded in the go.mod file". But my go.mod
>> file contains lines.
>>
>> require (
>> golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c // indirect
>> rsc.io/sampler v1.3.0 // indirect
>> )
>>
>> 2) After using "go get golang.org/x/text" command "go list -m all" I get
>> one line more that in blog post
>>
>> golang.org/x/tools v0.0.0-20180917221912-90fa682c2a6e
>>
>> 3) After function TestProverb(t *testing.T) is and running "go test" (I'm
>> quite sure that when I did this few years ago, this was the command that I
>> used) I get
>>
>> hello.go:5:2: no required module provides package rsc.io/quote/v3; to
>> add it:
>> go get rsc.io/quote/v3
>>
>> This is easy to solve by running "go get rsc.io/quote/v3", but still
>> annoying when you are going through this post.
>>
>> Best
>> Kamil
>> niedziela, 31 października 2021 o 00:29:57 UTC+2 Kamil Ziemian napisał(a):
>>
>>> This is probably silly thing, but I will write it down just in case.
>>>
>>> I mentioned before Go blog post "Using Go Modules" (
>>> https://go.dev/blog/using-go-modules), we first write a function
>>>
>>> func Hello() string {
>>> return "Hello, world."
>>> }
>>>
>>> and test for it which basically check condition
>>>
>>> Hello() == "Hello, world."
>>>
>>> In the next step we change our function to
>>>
>>> func Hello() string {
>>> return quote.Hello()
>>> }
>>>
>>> using the module "rsc.io/quote". But this is "not portable example" and
>>> when test on my computer PASS when using the first version of our Hello()
>>> function, it FAILS with the second.
>>>
>>> According to description quote.Hello() (
>>> https://pkg.go.dev/rsc.io/quote#Hello), but from source code we know
>>> that in fact it returns a string returned by sampler.Hello(prefs
>>> ...language.Tag). The last function "returns a localized greeting. If no
>>> prefs are given, Hello uses DefaultUserPrefs." (
>>> https://pkg.go.dev/rsc.io/sampler#Hello).
>>>
>>> On my computer it correctly detected polish language so quote.Hello()
>>> returns "Witaj świecie." and since "Witaj świecie." != "Hello, world." the
>>> test now fails.
>>>
>>> Best
>>> Kamil
>>>
>>> sob., 30 paź 2021 o 23:28 Sean Liao  napisał(a):
>>>
>>>> Technically that behaviour is still available via GO111MODULE=auto.
>>>> Go 1.16 changed the default from "auto" to "on".
>>>>
>>>> On Saturday, October 30, 2021 at 11:17:05 PM UTC+2 kziem...@gmail.com
>>>> wrote:
>>>

Re: [go-nuts] Various questions about posts from The Go Blog

[Kamil Ziemian]

"Technically that behaviour is still available via GO111MODULE=auto.
Go 1.16 changed the default from "auto" to "on"."

Thank you for that information. It is surprisingly hard to me to learn 
basic of Go and Go tools, when things don't works as described.

I found few another places where "Using Go Modules" 
(https://go.dev/blog/using-go-modules) is not up to date with out of box Go 
version 1.17.2.

1) According to part "Adding a dependency" (end of fourth block of text) 
"Only direct dependencies are recorded in the go.mod file". But my go.mod 
file contains lines.

require (
golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c // indirect
rsc.io/sampler v1.3.0 // indirect
)

2) After using "go get golang.org/x/text" command "go list -m all" I get 
one line more that in blog post

golang.org/x/tools v0.0.0-20180917221912-90fa682c2a6e

3) After function TestProverb(t *testing.T) is and running "go test" (I'm 
quite sure that when I did this few years ago, this was the command that I 
used) I get

hello.go:5:2: no required module provides package rsc.io/quote/v3; to add 
it:
go get rsc.io/quote/v3

This is easy to solve by running "go get rsc.io/quote/v3", but still 
annoying when you are going through this post.

Best
Kamil
niedziela, 31 października 2021 o 00:29:57 UTC+2 Kamil Ziemian napisał(a):

> This is probably silly thing, but I will write it down just in case.
>
> I mentioned before Go blog post "Using Go Modules" (
> https://go.dev/blog/using-go-modules), we first write a function
>
> func Hello() string {
> return "Hello, world."
> }
>
> and test for it which basically check condition
>
> Hello() == "Hello, world."
>
> In the next step we change our function to
>
> func Hello() string {
> return quote.Hello()
> }
>
> using the module "rsc.io/quote". But this is "not portable example" and 
> when test on my computer PASS when using the first version of our Hello() 
> function, it FAILS with the second.
>
> According to description quote.Hello() (
> https://pkg.go.dev/rsc.io/quote#Hello), but from source code we know that 
> in fact it returns a string returned by sampler.Hello(prefs 
> ...language.Tag). The last function "returns a localized greeting. If no 
> prefs are given, Hello uses DefaultUserPrefs." (
> https://pkg.go.dev/rsc.io/sampler#Hello).
>
> On my computer it correctly detected polish language so quote.Hello() 
> returns "Witaj świecie." and since "Witaj świecie." != "Hello, world." the 
> test now fails.
>
> Best
> Kamil
>
> sob., 30 paź 2021 o 23:28 Sean Liao  napisał(a):
>
>> Technically that behaviour is still available via GO111MODULE=auto.
>> Go 1.16 changed the default from "auto" to "on".
>>
>> On Saturday, October 30, 2021 at 11:17:05 PM UTC+2 kziem...@gmail.com 
>> wrote:
>>
>>> Hello,
>>>
>>> I don't have energy today to read Go language spec or learning how UTF-8 
>>> works, so I decided to make a look at Go blog post "Using Go Modules" (
>>> https://go.dev/blog/using-go-modules). I have a simple question: is 
>>> this post up to date?
>>>
>>> I guess not, here is my reason why. According to it if I run command "go 
>>> test" outside $GOPATH and in director without go.mod file I should get 
>>> result similar to
>>>
>>> PASS
>>> ok  _/some path/hello 0.020s
>>>
>>> When I run it with my go version go1.17.1 linux/amd64, result is
>>>
>>> go: go.mod file not found in current directory or any parent directory; 
>>> see 'go help modules'
>>>
>>> This is one of the Go blog post listed on Documentation page (
>>> https://golang.org/doc/), so I guess it should have note "If you use Go 
>>> in version x.y.z or latter, some code may not work", but maybe I just think 
>>> about it in the wrong way.
>>>
>>> From practical reason this particular thing isn't important, because 
>>> go.mod file is the way to go (or at least this is what I read in the last 
>>> week).
>>>
>>> Best
>>> Kamil
>>>
>>> wtorek, 7 września 2021 o 22:23:19 UTC+2 Ian Lance Taylor napisał(a):
>>>
>>>> On Tue, Sep 7, 2021 at 3:40 AM Kamil Ziemian  
>>>> wrote: 
>>>> > 
>>>> > In the post "Concurrency is not parallelism" by Andrew Gerrand (
>>>> https://go.dev/blog/waza-talk) under the paragraph starting

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[Kamil Ziemian]

Thank you Jan Mercl, now I start to understand this rule.

Best
Kamil

niedziela, 7 listopada 2021 o 19:34:41 UTC+1 Jan Mercl napisał(a):

> On Sun, Nov 7, 2021 at 7:23 PM Kamil Ziemian  wrote:
>
> > Can anyone give me explicit example when semicolon is omitted in 
> accordance to the second rule and explanation where it should be? I 
> probably see such situations dozens of times, I just not know that they 
> would needed semicolon in some places.
>
> I think this is a simple example: https://play.golang.org/p/ZfKxTos6GjY
>
> Click "Run" to see the code is valid, then "Format" to watch one
> semicolon disappear and then "Run" again to see it's still valid code.
>

-- 
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/6ee00e8b-c928-46af-8f2b-e99f4bfcbb20n%40googlegroups.com.

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[Kamil Ziemian]

Hello,

I go back to reading Go spec and I read about omitting semicolon in Go 
code. I know from some Rob Pike talks on YT or similar source, that 
compiler inserts semicolon in "places where C programmer would expected it 
to write". And since I try to follow Go style of writing code (Emacs also 
helps), outside "if", "for", "switch" and maybe "select" (I really works 
with channels), I probably never need to write semicolon myself.

To avoid making myself looking stupid by not knowing why simple Go program 
doesn't compile, when I read part of spec  "Semicolons" 
(https://golang.org/ref/spec#Semicolons), I try to work out where these 
semicolons are placed. First rule is easy, but second "To allow complex 
statements to occupy a single line, a semicolon may be omitted before a 
closing ")" or "}".", is quite hard to me.

Can anyone give me explicit example when semicolon is omitted in accordance 
to the second rule and explanation where it should be? I probably see such 
situations dozens of times, I just not know that they would needed 
semicolon in some places.

Best
Kamil
piątek, 29 października 2021 o 19:05:02 UTC+2 patryk.w...@gmail.com 
napisał(a):

> In order to standardize something, you need to establish things
> thanks to which you are able to express what you want to say.
>
> For example a Notation.
>
> The Go Reference manual uses Extended Backus-Naur Form (EBNF) for that and 
> this part is just expressing that.
> Think of this point not as "Go documentation," but as establishing a "way 
> to communicate".
>
> The excerpt you are asking about defines Production's syntax:
> Production = production_name "=" [ Expression ] "." .
> and a little further down you have an explanation of what Productions is:
> Productions are expressions constructed from terms and the following 
> operators, in increasing precedence.
>
> So in other words, we are defining here the syntax that will be used later 
> in the documentation, not the specific fields
> and that is why you can not find "production_name" throughout the rest of 
> the docs.
> However, for example, hex_digit is a in-docs Production built similarly to 
> what you are looking for:
> hex_digit = "0" … "9" | "A" … "F" | "a" … "f" .
>
> Best Regards,
>
> On Fri, 29 Oct 2021 at 12:53, Kamil Ziemian  wrote:
>
>> From what I understand about EBNF production_name should be defined using 
>> EBNF notation in manner like below.
>>
>> production_name = something1 | something2
>>
>> But I don't see such definition in Spec.
>>
>> Best
>> Kamil
>>
>> czwartek, 28 października 2021 o 21:31:07 UTC+2 seank...@gmail.com 
>> napisał(a):
>>
>>> There isn't much to it, a "production_name" is just an identifier for 
>>> the set of values defined on the other side of the =, some of which may 
>>> also be identifiers that should be dereferenced/expanded
>>>
>>> If it helps, there's a wikipedia entry on it: 
>>> https://en.wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_form
>>>
>>> On Thursday, October 28, 2021 at 7:33:27 PM UTC+2 kziem...@gmail.com 
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> From what I understand proper Gopher read at least one time "The Go 
>>>> Programming Language Specification" (https://golang.org/ref/spec) and 
>>>> now I need to read it too.
>>>>
>>>> I learn something of Extended Backus-Naur Form to understand it, so if 
>>>> I say something stupid beyond belief, I hope you will forgive me. In the 
>>>> first part "Notation" (https://golang.org/ref/spec#Notation) I believe 
>>>> that I understand meaning of all concepts except of "production_name". On 
>>>> one hand "production_name" means that it is name of the production, not 
>>>> rocket science here. On the other, after reading about EBNF I feel that I 
>>>> should have more information about it. Can you explain it to me?
>>>>
>>>> Again I'm new to EBNF, so maybe this is stupid question.
>>>>
>>>> Best
>>>> Kamil
>>>>
>>>> -- 
>> 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/02647258-d529-4dac-ac63-8c72874b4a89n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/02647258-d529-4dac-ac63-8c72874b4a89n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>
>
> -- 
>
> *Patryk Węgrzynek*
>
> Backend Developer
> Site Reliability Engineer
>
>

-- 
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/34207690-ba92-439b-b9f2-73163f75cd86n%40googlegroups.com.

Re: [go-nuts] Various questions about posts from The Go Blog

[Kamil Ziemian]

This is probably silly thing, but I will write it down just in case.

I mentioned before Go blog post "Using Go Modules" (
https://go.dev/blog/using-go-modules), we first write a function

func Hello() string {
return "Hello, world."
}

and test for it which basically check condition

Hello() == "Hello, world."

In the next step we change our function to

func Hello() string {
return quote.Hello()
}

using the module "rsc.io/quote". But this is "not portable example" and
when test on my computer PASS when using the first version of our Hello()
function, it FAILS with the second.

According to description quote.Hello() (
https://pkg.go.dev/rsc.io/quote#Hello), but from source code we know that
in fact it returns a string returned by sampler.Hello(prefs
...language.Tag). The last function "returns a localized greeting. If no
prefs are given, Hello uses DefaultUserPrefs." (
https://pkg.go.dev/rsc.io/sampler#Hello).

On my computer it correctly detected polish language so quote.Hello()
returns "Witaj świecie." and since "Witaj świecie." != "Hello, world." the
test now fails.

Best
Kamil

sob., 30 paź 2021 o 23:28 Sean Liao  napisał(a):

> Technically that behaviour is still available via GO111MODULE=auto.
> Go 1.16 changed the default from "auto" to "on".
>
> On Saturday, October 30, 2021 at 11:17:05 PM UTC+2 kziem...@gmail.com
> wrote:
>
>> Hello,
>>
>> I don't have energy today to read Go language spec or learning how UTF-8
>> works, so I decided to make a look at Go blog post "Using Go Modules" (
>> https://go.dev/blog/using-go-modules). I have a simple question: is this
>> post up to date?
>>
>> I guess not, here is my reason why. According to it if I run command "go
>> test" outside $GOPATH and in director without go.mod file I should get
>> result similar to
>>
>> PASS
>> ok  _/some path/hello 0.020s
>>
>> When I run it with my go version go1.17.1 linux/amd64, result is
>>
>> go: go.mod file not found in current directory or any parent directory;
>> see 'go help modules'
>>
>> This is one of the Go blog post listed on Documentation page (
>> https://golang.org/doc/), so I guess it should have note "If you use Go
>> in version x.y.z or latter, some code may not work", but maybe I just think
>> about it in the wrong way.
>>
>> From practical reason this particular thing isn't important, because
>> go.mod file is the way to go (or at least this is what I read in the last
>> week).
>>
>> Best
>> Kamil
>>
>> wtorek, 7 września 2021 o 22:23:19 UTC+2 Ian Lance Taylor napisał(a):
>>
>>> On Tue, Sep 7, 2021 at 3:40 AM Kamil Ziemian 
>>> wrote:
>>> >
>>> > In the post "Concurrency is not parallelism" by Andrew Gerrand (
>>> https://go.dev/blog/waza-talk) under the paragraph starting with "To
>>> clear up this conflation, Rob Pike gave a talk at Heroku’s Waza" in my
>>> browser is big blank space. I believe that that I can see rectangle in it,
>>> with slightly different hue of with, but I can't be sure.
>>> >
>>> > Is it my browser not working or something goes wrong with the page?
>>> Can someone check if he/she has the same problem? I use Mozilla Firefox for
>>> Ubuntu canonical - 1.0, version 91.0.2 (64 bits). I hope I don't mess up
>>> Fierfox data.
>>>
>>> Thanks, sent https://golang.org/cl/348013 to fix this.
>>>
>>> Ian
>>>
>> --
> 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/p4YTbDqTUhI/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/fce2cfcc-993d-4c25-8863-484b67b02870n%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/fce2cfcc-993d-4c25-8863-484b67b02870n%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/CAB3gO8q7rA%2BV_gg-dPrjCJC0481nBcT2p3T8Ldb-mjabU%2B7Kqw%40mail.gmail.com.

Re: [go-nuts] Various questions about posts from The Go Blog

[Kamil Ziemian]

Hello,

I don't have energy today to read Go language spec or learning how UTF-8 
works, so I decided to make a look at Go blog post "Using Go Modules" 
(https://go.dev/blog/using-go-modules). I have a simple question: is this 
post up to date?

I guess not, here is my reason why. According to it if I run command "go 
test" outside $GOPATH and in director without go.mod file I should get 
result similar to

PASS
ok  _/some path/hello 0.020s

When I run it with my go version go1.17.1 linux/amd64, result is

go: go.mod file not found in current directory or any parent directory; see 
'go help modules'

This is one of the Go blog post listed on Documentation page 
(https://golang.org/doc/), so I guess it should have note "If you use Go in 
version x.y.z or latter, some code may not work", but maybe I just think 
about it in the wrong way.

>From practical reason this particular thing isn't important, because go.mod 
file is the way to go (or at least this is what I read in the last week).

Best
Kamil

wtorek, 7 września 2021 o 22:23:19 UTC+2 Ian Lance Taylor napisał(a):

> On Tue, Sep 7, 2021 at 3:40 AM Kamil Ziemian  wrote:
> >
> > In the post "Concurrency is not parallelism" by Andrew Gerrand (
> https://go.dev/blog/waza-talk) under the paragraph starting with "To 
> clear up this conflation, Rob Pike gave a talk at Heroku’s Waza" in my 
> browser is big blank space. I believe that that I can see rectangle in it, 
> with slightly different hue of with, but I can't be sure.
> >
> > Is it my browser not working or something goes wrong with the page? Can 
> someone check if he/she has the same problem? I use Mozilla Firefox for 
> Ubuntu canonical - 1.0, version 91.0.2 (64 bits). I hope I don't mess up 
> Fierfox data.
>
> Thanks, sent https://golang.org/cl/348013 to fix this.
>
> Ian
>

-- 
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/688f8d55-69c7-49a2-a03f-49bd36873b2fn%40googlegroups.com.

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[Kamil Ziemian]

Thank you Patryk Węgrzynek for these notes. I often feel uneasy when things
like "ways of comunications” are unclean to me just at the beginning of
reading of text. I like have everything clear at start and you help me
clear some mess in my head.

Best
Kamil

pt., 29 paź 2021 o 16:00 Kamil Ziemian  napisał(a):

> Thank you Jan Marcel, now I understand this part of Spec. I now will go
> back to read rest of it.
>
> Best
> Kamil
>
> piątek, 29 października 2021 o 13:29:16 UTC+2 Jan Mercl napisał(a):
>
>> On Fri, Oct 29, 2021 at 12:53 PM Kamil Ziemian 
>> wrote:
>> >
>> > From what I understand about EBNF production_name should be defined
>> using EBNF notation in manner like below.
>> >
>> > production_name = something1 | something2
>> >
>> > But I don't see such definition in Spec.
>>
>> Because production_name is a terminal symbol of the EBNF grammar per se.
>>
>> """"
>> Lower-case production names are used to identify lexical tokens.
>> Non-terminals are in CamelCase.
>> """"
>>
>> src: https://golang.org/ref/spec#Notation
>>
>> The above link defines a meta-grammar, ie. a grammar of the EBNF
>> grammar in which the actual Go EBNF grammar is later on defined. In
>> the Go case the terminals are really defined, like here
>> https://golang.org/ref/spec#Letters_and_digits.
>>
>> The EBNF grammar per se is outlined only loosely and is strictly not
>> complete in this case, so you're right. The reader is expected to
>> assume "usual" grammar of an identifier, like "a letter followed by 1
>> or more letters or digits", for example. The "real" definition of EBNF
>> can be found for example here:
>> https://en.wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_form. It
>> seems too long to include in the Go specs, moreover I think it even
>> differs in some details.
>>
>> -j
>>
> --
> 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/xwavrjBZbeE/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/413421f3-914c-4a71-8cd5-4464b8262802n%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/413421f3-914c-4a71-8cd5-4464b8262802n%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/CAB3gO8owOOfJzpUm_PPh8AKQ74m%2BD8GJFfCuS-CgjXx8q2j0nA%40mail.gmail.com.

Re: [go-nuts] Re: Amateur's questions about "Go lang spec"

[Kamil Ziemian]

Thank you Jan Marcel, now I understand this part of Spec. I now will go 
back to read rest of it.

Best
Kamil

piątek, 29 października 2021 o 13:29:16 UTC+2 Jan Mercl napisał(a):

> On Fri, Oct 29, 2021 at 12:53 PM Kamil Ziemian  wrote:
> >
> > From what I understand about EBNF production_name should be defined 
> using EBNF notation in manner like below.
> >
> > production_name = something1 | something2
> >
> > But I don't see such definition in Spec.
>
> Because production_name is a terminal symbol of the EBNF grammar per se.
>
> """"
> Lower-case production names are used to identify lexical tokens.
> Non-terminals are in CamelCase.
> """"
>
> src: https://golang.org/ref/spec#Notation
>
> The above link defines a meta-grammar, ie. a grammar of the EBNF
> grammar in which the actual Go EBNF grammar is later on defined. In
> the Go case the terminals are really defined, like here
> https://golang.org/ref/spec#Letters_and_digits.
>
> The EBNF grammar per se is outlined only loosely and is strictly not
> complete in this case, so you're right. The reader is expected to
> assume "usual" grammar of an identifier, like "a letter followed by 1
> or more letters or digits", for example. The "real" definition of EBNF
> can be found for example here:
> https://en.wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_form. It
> seems too long to include in the Go specs, moreover I think it even
> differs in some details.
>
> -j
>

-- 
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/413421f3-914c-4a71-8cd5-4464b8262802n%40googlegroups.com.

[go-nuts] Re: Amateur's questions about "Go lang spec"

[Kamil Ziemian]

>From what I understand about EBNF production_name should be defined using 
EBNF notation in manner like below.

production_name = something1 | something2

But I don't see such definition in Spec.

Best
Kamil

czwartek, 28 października 2021 o 21:31:07 UTC+2 seank...@gmail.com 
napisał(a):

> There isn't much to it, a "production_name" is just an identifier for the 
> set of values defined on the other side of the =, some of which may also be 
> identifiers that should be dereferenced/expanded
>
> If it helps, there's a wikipedia entry on it: 
> https://en.wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_form
>
> On Thursday, October 28, 2021 at 7:33:27 PM UTC+2 kziem...@gmail.com 
> wrote:
>
>> Hello,
>>
>> From what I understand proper Gopher read at least one time "The Go 
>> Programming Language Specification" (https://golang.org/ref/spec) and 
>> now I need to read it too.
>>
>> I learn something of Extended Backus-Naur Form to understand it, so if I 
>> say something stupid beyond belief, I hope you will forgive me. In the 
>> first part "Notation" (https://golang.org/ref/spec#Notation) I believe 
>> that I understand meaning of all concepts except of "production_name". On 
>> one hand "production_name" means that it is name of the production, not 
>> rocket science here. On the other, after reading about EBNF I feel that I 
>> should have more information about it. Can you explain it to me?
>>
>> Again I'm new to EBNF, so maybe this is stupid question.
>>
>> Best
>> Kamil
>>
>>

-- 
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/02647258-d529-4dac-ac63-8c72874b4a89n%40googlegroups.com.

[go-nuts] Amateur's questions about "Go lang spec"

[Kamil Ziemian]

Hello,

>From what I understand proper Gopher read at least one time "The Go 
Programming Language Specification" (https://golang.org/ref/spec) and now I 
need to read it too.

I learn something of Extended Backus-Naur Form to understand it, so if I 
say something stupid beyond belief, I hope you will forgive me. In the 
first part "Notation" (https://golang.org/ref/spec#Notation) I believe that 
I understand meaning of all concepts except of "production_name". On one 
hand "production_name" means that it is name of the production, not rocket 
science here. On the other, after reading about EBNF I feel that I should 
have more information about it. Can you explain it to me?

Again I'm new to EBNF, so maybe this is stupid question.

Best
Kamil

-- 
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/4538aab0-5b71-4055-9991-29c26d2b302cn%40googlegroups.com.

Re: [go-nuts] Re: Questions about documentation of Go standard library

[Kamil Ziemian]

> you can probably read it as Invalid argument index or invalid use of 
 > argument index. 
> Hope that helps

Thank you mb0, now it make sense. I'm not confident as Go user to guess 
things like that.

Thank you Ian Lance Taylor. I have now quite a pile of Go must read texts, 
when I end my day job I will read them all and after that, I will 
"contribute" in this small way.

Best
Kamil

sobota, 9 października 2021 o 02:46:56 UTC+2 Ian Lance Taylor napisał(a):

> On Fri, Oct 8, 2021 at 12:36 PM Kamil Ziemian  wrote:
> >
> > I found unimportant typo in English part of the documentation of "fmt". 
> How can I correct it? GitHub pull request or open issue "Unimportant typos 
> in documentation"? I don't know how I should treat such unimportant typo.
>
> You can send a pull request or a Gerritt CL. See
> https://golang.org/doc/contribute.html. Thanks.
>
> Ian
>

-- 
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/92bf64db-3d9d-4e85-ba3f-d8ac4f023e4bn%40googlegroups.com.

Re: [go-nuts] Re: Questions about documentation of Go standard library

[Kamil Ziemian]

Hello,

I now read documentation of "fmt" package and in "Format errors" 
(https://pkg.go.dev/fmt@go1.17.2#hdr-Format_errors) we have
Invalid or invalid use of argument index: %!(BADINDEX)
Printf("%*[2]d", 7):   %!d(BADINDEX)
Printf("%.[2]d", 7):   %!d(BADINDEX)

I cannot understand what "Invalid or invalid use of argument index" was 
intended to mean? Can anyone help me with that?

Best
Kamil

piątek, 8 października 2021 o 21:36:11 UTC+2 Kamil Ziemian napisał(a):

> Hello,
>
> I found unimportant typo in English part of the documentation of "fmt". 
> How can I correct it? GitHub pull request or open issue "Unimportant typos 
> in documentation"? I don't know how I should treat such unimportant typo.
>
> Best
> Kamil
> piątek, 8 października 2021 o 00:53:11 UTC+2 Kamil Ziemian napisał(a):
>
>> > The io.ReadAll function and the io.Reader interface Read method are not 
>> the same, don't conflate them.
>> Thank you for stressing that point, but I don't think that I conflate 
>> them. Maybe I wrong, but I believe that many entries in "io" package share 
>> decriptions that states "A successful call returns err == nil, not err == 
>> EOF. Because ReadAll is defined to read from src until EOF, it does not 
>> treat an EOF from Read as an error to be reported.", so I quote it just 
>> because it was at my hand.
>>
>> > Have you read https://go.dev/blog/errors-are-values by Rob Pike?
>> Thank you very much Michael, I read few things about errors in Go, but 
>> never that blog post. Now I need for my job to process few files in Go, so 
>> I need to read "io" first, but after that, I will read this mail. In some 
>> sense I'm a fan of Rob Pike blog posts, articles and talks. Hard to say 
>> why, maybe he is "no nonsense guy"?
>>
>> Best
>> Kamil
>> czwartek, 7 października 2021 o 15:13:22 UTC+2 michael...@gmail.com 
>> napisał(a):
>>
>>> Kamil,
>>> Have you read https://go.dev/blog/errors-are-values by Rob Pike?  
>>> Wrapping my head around the concept that an error is simply a value 
>>> returned from a function was tremendously helpful when I had questions 
>>> along the same lines as yours.
>>>
>>

-- 
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/3ccc88a8-419b-44af-8bdc-d96b59b2eb38n%40googlegroups.com.

Re: [go-nuts] Re: Questions about documentation of Go standard library

[Kamil Ziemian]

Hello,

I found unimportant typo in English part of the documentation of "fmt". How 
can I correct it? GitHub pull request or open issue "Unimportant typos in 
documentation"? I don't know how I should treat such unimportant typo.

Best
Kamil
piątek, 8 października 2021 o 00:53:11 UTC+2 Kamil Ziemian napisał(a):

> > The io.ReadAll function and the io.Reader interface Read method are not 
> the same, don't conflate them.
> Thank you for stressing that point, but I don't think that I conflate 
> them. Maybe I wrong, but I believe that many entries in "io" package share 
> decriptions that states "A successful call returns err == nil, not err == 
> EOF. Because ReadAll is defined to read from src until EOF, it does not 
> treat an EOF from Read as an error to be reported.", so I quote it just 
> because it was at my hand.
>
> > Have you read https://go.dev/blog/errors-are-values by Rob Pike?
> Thank you very much Michael, I read few things about errors in Go, but 
> never that blog post. Now I need for my job to process few files in Go, so 
> I need to read "io" first, but after that, I will read this mail. In some 
> sense I'm a fan of Rob Pike blog posts, articles and talks. Hard to say 
> why, maybe he is "no nonsense guy"?
>
> Best
> Kamil
> czwartek, 7 października 2021 o 15:13:22 UTC+2 michael...@gmail.com 
> napisał(a):
>
>> Kamil,
>> Have you read https://go.dev/blog/errors-are-values by Rob Pike?  
>> Wrapping my head around the concept that an error is simply a value 
>> returned from a function was tremendously helpful when I had questions 
>> along the same lines as yours.
>>
>

-- 
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/33f0e536-d7bb-4e11-9a39-de3d0610e839n%40googlegroups.com.

Re: [go-nuts] Re: Questions about documentation of Go standard library

[Kamil Ziemian]

> The io.ReadAll function and the io.Reader interface Read method are not 
the same, don't conflate them.
Thank you for stressing that point, but I don't think that I conflate them. 
Maybe I wrong, but I believe that many entries in "io" package share 
decriptions that states "A successful call returns err == nil, not err == 
EOF. Because ReadAll is defined to read from src until EOF, it does not 
treat an EOF from Read as an error to be reported.", so I quote it just 
because it was at my hand.

> Have you read https://go.dev/blog/errors-are-values by Rob Pike?
Thank you very much Michael, I read few things about errors in Go, but 
never that blog post. Now I need for my job to process few files in Go, so 
I need to read "io" first, but after that, I will read this mail. In some 
sense I'm a fan of Rob Pike blog posts, articles and talks. Hard to say 
why, maybe he is "no nonsense guy"?

Best
Kamil
czwartek, 7 października 2021 o 15:13:22 UTC+2 michael...@gmail.com 
napisał(a):

> Kamil,
> Have you read https://go.dev/blog/errors-are-values by Rob Pike?  
> Wrapping my head around the concept that an error is simply a value 
> returned from a function was tremendously helpful when I had questions 
> along the same lines as yours.
>

-- 
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/a44f9c63-cea5-4325-a872-83c71a5e28a5n%40googlegroups.com.

Re: [go-nuts] Re: Questions about documentation of Go standard library

[Kamil Ziemian]

>
> I'm not sure what you mean when you say that io.EOF is not treated as an
> error.  io.EOF is an error: it implements the error interface, and is
> returned as the error value by methods such as Read.


I am mediocre at best at programming and I'm quite a picky person, so I
just have a problem with wrapping my head around texts like this below,
which is a documentation of io.ReadAll. Nothing more.

ReadAll reads from r until an error or EOF and returns the data it read. A
> successful call returns err == nil, not err == EOF. Because ReadAll is
> defined to read from src until EOF, it does not treat an EOF from Read as
> an error to be reported.
>

This mental dissonans is probably caused by the simple fact that I think
about error as information that something doesn't work as it should, but
arriving at the end of the file means that we are where we should be.

But that doesn't mean that it's not an error.  The Read failed.  Every
> failure is reported via an error.  For the case in which Read fails because
> it reaches the end of the file, the error that it returns is io.EOF.
>

Thank you very much. I will try to digest that io.EOF means that Read
fails, so this is an error of Read method/function. I never think about it
that way.

Best
Kamil

czw., 7 paź 2021 o 06:25 peterGo  napisał(a):

> Kamil,
>
> A Go interface implements a particular behavior. For example, io.Reader is
> the interface that wraps the basic Read method.
>
> type Reader interface {
> Read(p []byte) (n int, err error)
> }
>
> The outcome of the Read method ranges from good to catastrophic failure.
> The outcome is reported in the err error type return value. The err return
> value for good is nil. For a finite stream of data, a particular outcome of
> interest is end-of-file.
>
> var EOF = errors.New("EOF")
>
> io.EOF is the error returned by Read when no more input is available.
>
> See package io.
> https://pkg.go.dev/io
>
> Peter
>
> On Wednesday, October 6, 2021 at 5:35:11 PM UTC-4 kziem...@gmail.com
> wrote:
>
>> Hello,
>>
>> I currently read about "io" package and again I read that "io.EOF" is not
>> treated as error, since it is what you expect to end file, which is almost
>> tautology. At the same time it satisfies error interface and is created
>> busing errors.New function.
>>
>> I understand why this is done, doing it other way would probably make
>> serious mess in the code, but pedantic said of me is unsettled by this.
>> Does any experience Gopher can give my advice how to think about situation
>> when some object satisfy interface, but it is exception that proves the
>> rule? I should just get used to it, or is it some better way of thinking?
>>
>> Best
>> Kamil
>>
>> sobota, 4 września 2021 o 23:28:20 UTC+2 Brian Candler napisał(a):
>>
>>> Ah, I missed the bit where it says "Flag syntax is xyz (set)
>>> or -xyz (clear) or xy-z (set xy, clear z)."  You're quite right, there's a
>>> much simpler way:
>>> https://play.golang.org/p/upupUQUcsR8
>>>
>>> On Saturday, 4 September 2021 at 20:51:53 UTC+1 kziem...@gmail.com
>>> wrote:
>>>
>>>> Thank you for your answer and opinion Briana Candler.
>>>>
>>>> I ask about unset only because of the cryptic text, at least to me, in
>>>> the description of RE2 (https://github.com/google/re2/wiki/Syntax).
>>>> From practical point of view, your solutions look good.
>>>>
>>>> I try to google about changes in examples in Go's stdlib, maybe this
>>>> can be done?
>>>>
>>>> Best
>>>> Kamil
>>>>
>>>> pt., 3 wrz 2021 o 21:42 Brian Candler  napisał(a):
>>>>
>>>>> I believe (?m) applies to the current group only; if you want to
>>>>> "unset" it then start a separate group.
>>>>> https://play.golang.org/p/wT_ZTrUSABL
>>>>>
>>>>> And I think you're right, there's no need to have capture groups for
>>>>> FindIndex.
>>>>>
>>>>> On Friday, 3 September 2021 at 20:33:14 UTC+1 kziem...@gmail.com
>>>>> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> My struggles with regexp is going and I have another problem. I read
>>>>>> closely syntax page of RE2 (https://github.com/google/re2/wiki/Syntax)
>>>>>> and I still not sure if I understand one example from regexp package.
>>>>>>
>

Re: [go-nuts] Re: Questions about documentation of Go standard library

[Kamil Ziemian]

Hello,

I currently read about "io" package and again I read that "io.EOF" is not 
treated as error, since it is what you expect to end file, which is almost 
tautology. At the same time it satisfies error interface and is created 
busing errors.New function.

I understand why this is done, doing it other way would probably make 
serious mess in the code, but pedantic said of me is unsettled by this. 
Does any experience Gopher can give my advice how to think about situation 
when some object satisfy interface, but it is exception that proves the 
rule? I should just get used to it, or is it some better way of thinking?

Best
Kamil

sobota, 4 września 2021 o 23:28:20 UTC+2 Brian Candler napisał(a):

> Ah, I missed the bit where it says "Flag syntax is xyz (set) 
> or -xyz (clear) or xy-z (set xy, clear z)."  You're quite right, there's a 
> much simpler way:
> https://play.golang.org/p/upupUQUcsR8
>
> On Saturday, 4 September 2021 at 20:51:53 UTC+1 kziem...@gmail.com wrote:
>
>> Thank you for your answer and opinion Briana Candler.
>>
>> I ask about unset only because of the cryptic text, at least to me, in 
>> the description of RE2 (https://github.com/google/re2/wiki/Syntax). From 
>> practical point of view, your solutions look good.
>>
>> I try to google about changes in examples in Go's stdlib, maybe this can 
>> be done?
>>
>> Best
>> Kamil
>>
>> pt., 3 wrz 2021 o 21:42 Brian Candler  napisał(a):
>>
>>> I believe (?m) applies to the current group only; if you want to "unset" 
>>> it then start a separate group.
>>> https://play.golang.org/p/wT_ZTrUSABL
>>>
>>> And I think you're right, there's no need to have capture groups for 
>>> FindIndex.
>>>
>>> On Friday, 3 September 2021 at 20:33:14 UTC+1 kziem...@gmail.com wrote:
>>>
>>>> Hello,
>>>>
>>>> My struggles with regexp is going and I have another problem. I read 
>>>> closely syntax page of RE2 (https://github.com/google/re2/wiki/Syntax) 
>>>> and I still not sure if I understand one example from regexp package.
>>>>
>>>> In example in method func (*Regexp) FindIndex (
>>>> https://pkg.go.dev/reg...@go1.17#Regexp.FindIndex 
>>>> <https://pkg.go.dev/regexp@go1.17#Regexp.FindIndex>) we have line
>>>>
>>>> pattern := regexp.MustCompile(`(?m)(?P\w+):\s+(?P\w+)$`)
>>>>
>>>> Does (?m) set value of flag m to true and if I want set it to false I 
>>>> should write (?-m) or not? By default m should be false, but as example it 
>>>> is fine.
>>>>
>>>> As a side note, this regular expression is used in other examples, when 
>>>> we need  and , but looks unnecessary complex for method 
>>>> FindIndex. I guess
>>>> `(?m)\w+:\s+\w+$`
>>>> would work fine. Am I wrong?
>>>>
>>>> Best
>>>> Kamil
>>>>
>>>> środa, 1 września 2021 o 12:29:58 UTC+2 Kamil Ziemian napisał(a):
>>>>
>>>>> Kurtis Rader, peterGo thank you for the answers. I probably need to 
>>>>> learn more about RPC protocols, for now I can only expand acronym. But 
>>>>> this 
>>>>> point with ignoring leading zeros is clear enough. And probalby more 
>>>>> "elementary (and stupid)?" questions is comming.
>>>>>
>>>>> Kamil
>>>>> poniedziałek, 30 sierpnia 2021 o 03:02:51 UTC+2 peterGo napisał(a):
>>>>>
>>>>>>
>>>>>>
>>>>>> K,
>>>>>>
>>>>>> For a finite, unsigned binary number, ignoring leading zeros, how 
>>>>>> many binary digits (the length in bits) are needed to represent a number?
>>>>>>
>>>>>> Peter
>>>>>> On Sunday, August 29, 2021 at 4:07:41 PM UTC-4 kziem...@gmail.com 
>>>>>> wrote:
>>>>>>
>>>>>>> Thank for explanation, but I don't understand "But how many bits do 
>>>>>>> you need to represent 0? The question is malformed as there are no set 
>>>>>>> bits 
>>>>>>> in the used representation of 0.". Why this is malformed questions? 
>>>>>>> When I 
>>>>>>> think of coding 1, I think about thaking one bit with 1 inside and when 
>>>>>>> it 
>>>>>>> goes to 0, I would take one bit with 0 inside.
>>>&g

Re: [go-nuts] Type Parameters Proposal, few unimportant questions

[Kamil Ziemian]

> It's a detail of Go scoping. If we write "f := func(...)" then f goes 
into scope after that statement. As a consequence,
> if we used :=, the recursive call to f in the function literal would not 
refer to the f declared with the := statement, 
> but to the f that is in scope before the := statement. SInce there is no 
such f, that code would not 
> compile (and if there were such an f, it would be the wrong one). See the 
discussion at https://golang.org/issue/33167. 

In the future I will read this discussion about closures and scoping, 
before that I still plenty materials about Go to read, listen and watch.

> Thanks for the careful reading.

I'm glad if I can help. :)

Best
Kamil
piątek, 24 września 2021 o 19:34:43 UTC+2 Ian Lance Taylor napisał(a):

> On Thu, Sep 23, 2021 at 10:07 AM Kamil Ziemian  wrote:
> >
> > On the beginning of "More on type sets" (
> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#more-on-type-sets)
>  
> we read "These are not additional rules or concepts, but are consequences 
> of how type sets work.". And in the subsection of it "Composite types in 
> constraints" (
> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#composite-types-in-constraints)
>  
> under second code is stated "For composite types (string, pointer, array, 
> slice, struct, function, map, channel) we impose an additional restriction: 
> an operation may only be used if the operator accepts identical input types 
> (if any) and produces identical result types for all of the types in the 
> type set.".
> >
> > I probably don't understand part of text that stated this rule before, 
> but since I can't find it out, I wrote it down here to be sure.
>
> Thanks, I'll delete the sentence "these are not additional rules or
> concepts." It was true a while back but it clearly no longer is.
>
>
> > In "What happened to contracts?" (
> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#what-happened-to-contracts)
>  
> we have "Type sets appeared only in contracts, rather than on interface 
> types.". My English is not good enough to decide should it be "on interface 
> types" or "in interface types". I have the same problem with title "Why not 
> put type parameters on packages?" (
> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#why-not-put-type-parameters-on-packages).
>  
> "On packages" or "in packages"?
>
> Will change "on interface types" to "in interface types". "On
> packages" is correct. Everything in Go can be described as being "in"
> a package. The idea being discussed in that section is to add type
> parameters to packages themselves, something like "package List[T
> any]".
>
>
> > Pure curiosity. Why in "Containers" (
> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#containers)
>  
> in body of definition (?) of method "func (m *Map[K, V]) InOrder() 
> *Iterator[K, V]", we have
> > var f func(*node[K, V]) bool
> > f = func(n *node[K, V]) bool { ... }
> > instead of code:
> > f := func(n *node[K, V]) bool { ... }
>
> It's a detail of Go scoping. If we write "f := func(...)" then f goes
> into scope after that statement. As a consequence, if we used :=, the
> recursive call to f in the function literal would not refer to the f
> declared with the := statement, but to the f that is in scope before
> the := statement. SInce there is no such f, that code would not
> compile (and if there were such an f, it would be the wrong one). See
> the discussion at https://golang.org/issue/33167.
>
>
> > In "Type inference for composite literals" (
> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#type-inference-for-composite-literals)
>  
> in comment in the code (so this have no impact on the proposed code 
> working) we have "inferred as Pair(int){1, 2}". Maybe I still don't 
> understand this proposal enough, because I think it should be "Pair[int]{1, 
> 2}".
>
> Thanks, will fix.
>
>
> > Finally, some hair splitting.
> >
> > In first code in "Both elements and methods in constraints" (
> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#both-elements-and-methods-in-constraints),
>  
> we have
> > "~int32| ~int64"
> > more consistent with rest 

Re: [go-nuts] Type Parameters Proposal, few unimportant questions

[Kamil Ziemian]

>
> You can try out examples online in the go2 playground:
> https://go2goplay.golang.org/
>
Thank you Brian Candler for the information, I didn't know about go2
playground before. There are so many things that I need to learn about Go.

I guess this comment is something that was missed.
>
I also think this is the reason. I hope someone will correct it.

Best
Kamil

pt., 24 wrz 2021 o 08:58 Brian Candler  napisał(a):

> On Thursday, 23 September 2021 at 18:07:19 UTC+1 kziem...@gmail.com wrote:
>
>> Understand this whole text without running code in compiler is just above
>> my mediocre (at best) programming skills. Compilers errors are one of mine
>> favorite teachers.
>
>
> You can try out examples online in the go2 playground:
> https://go2goplay.golang.org/
>
>
>> "inferred as Pair(int){1, 2}". Maybe I still don't understand this
>> proposal enough, because I think it should be "Pair[int]{1, 2}".
>>
>
> An older version of the generics proposal used round parentheses for the
> type parameters, so a generic function call could look like "myfunc(int,
> string)(a, b)" when you weren't inferring the types.  This was changed to
> square brackets later.  I guess this comment is something that was missed.
>
> --
> 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/haLIqHOue7g/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/0429f448-df3a-4adb-8c38-a6233d9af7f2n%40googlegroups.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/CAB3gO8pX-fc-d1ctvoyPHmA3yz9BsqvzevuskLTdY%3Dnx5E1k1w%40mail.gmail.com.

Re: [go-nuts] Type Parameters Proposal, few unimportant questions

[Kamil Ziemian]

Hello,

I finish reading this proposal 
(https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md).
 
It is hard to judge how much I understand of it probably between 40% and 
70%, so I apologize if I make some stupid comment below, because I just 
miss something. Understand this whole text without running code in compiler 
is just above my mediocre (at best) programming skills. Compilers errors 
are one of mine favorite teachers. Also section "Discarded ideas" and 
"Examples" are quite easy to understand but I didn't count it my estimation 
above.

I need to say that I like what I understand. This proposal have a Go 
feeling, which is quite hard to describe. One part of it is stress on 
minimalism and simplicity, even as stated there this make Go more 
complicated. Other part is clearness of writing of these proposal in this 
part which I understand.

On the beginning of "More on type sets" 
(https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#more-on-type-sets)
 
we read "These are not additional rules or concepts, but are consequences 
of how type sets work.". And in the subsection of it "Composite types in 
constraints" 
(https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#composite-types-in-constraints)
 
under second code is stated "For composite types (string, pointer, array, 
slice, struct, function, map, channel) we impose an additional restriction: 
an operation may only be used if the operator accepts identical input types 
(if any) and produces identical result types for all of the types in the 
type set.".

I probably don't understand part of text that stated this rule before, but 
since I can't find it out, I wrote it down here to be sure.

In "What happened to contracts?" 
(https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#what-happened-to-contracts)
 
we have "Type sets appeared only in contracts, rather than on interface 
types.". My English is not good enough to decide should it be "on interface 
types" or "in interface types". I have the same problem with title "Why not 
put type parameters on packages?" 
(https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#why-not-put-type-parameters-on-packages).
 
"On packages" or "in packages"?

Pure curiosity. Why in "Containers" 
(https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#containers)
 
in body of definition (?) of method "func (m *Map[K, V]) InOrder() 
*Iterator[K, V]", we have
var f func(*node[K, V]) bool
f = func(n *node[K, V]) bool { ... }
instead of code:
f := func(n *node[K, V]) bool { ... }

In "Type inference for composite literals" 
(https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#type-inference-for-composite-literals)
 
in comment in the code (so this have no impact on the proposed code 
working) we have "inferred as Pair(int){1, 2}". Maybe I still don't 
understand this proposal enough, because I think it should be "Pair[int]{1, 
2}".

Finally, some hair splitting.

In first code in "Both elements and methods in constraints" 
(https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#both-elements-and-methods-in-constraints),
 
we have
"~int32| ~int64"
more consistent with rest of the code would be
"~int32 | ~int64".

In section "List transform" 
(https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#list-transform)
 
in method func (lst *List[T]) Push(v T) we have
lst.tail.next = &element[T]{val: v }
For my money, space before last bracket should be removed to be consistent 
with other examples.

Best regards
Kamil


piątek, 10 września 2021 o 20:12:54 UTC+2 Kamil Ziemian napisał(a):

> Thank you very much, now this sentence about type parameters with 
> structural constraint is clear and I know that I basically get it right.
>
> Best
> Kamil
>
>
> pt., 10 wrz 2021 o 19:07 Ian Lance Taylor  napisał(a):
>
>> On Fri, Sep 10, 2021 at 5:28 AM Kamil Ziemian  wrote:
>> >
>> > I try to work my way through "Type Parameters Proposal" (
>> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md).
>>  
>> With my speed, I maybe and reading this very well written document before 
>> type parameters will be implemented in Go. xD Jokes aside, when I read it I 
>> found few sentences that sounds odd to me. Maybe some good soul would 
>> explain to me, am I right, or this is my bad, not good English?
>> >
>> > At the beginning of the s

Re: [go-nuts] Type Parameters Proposal, few unimportant questions

[Kamil Ziemian]

Thank you very much, now this sentence about type parameters with
structural constraint is clear and I know that I basically get it right.

Best
Kamil


pt., 10 wrz 2021 o 19:07 Ian Lance Taylor  napisał(a):

> On Fri, Sep 10, 2021 at 5:28 AM Kamil Ziemian 
> wrote:
> >
> > I try to work my way through "Type Parameters Proposal" (
> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md).
> With my speed, I maybe and reading this very well written document before
> type parameters will be implemented in Go. xD Jokes aside, when I read it I
> found few sentences that sounds odd to me. Maybe some good soul would
> explain to me, am I right, or this is my bad, not good English?
> >
> > At the beginning of the section (?) "Using a constraint" (
> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#using-a-constraint)
> there is sentence "As shown above, constraints appear in the type parameter
> list as the meta-type of a type parameter." But I think that is should read
> "shown below".
>
> I think "shown above" is correct.  The document has already shown
> using the constraint "any".
>
>
> > In the second paragraph (?) of the section "Operations based on type
> sets" (
> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#operations-based-on-type-sets)
> we read "For special purpose operators like range loops, we permit their
> use of the type parameter has a structural constraint". Meaning of it is
> clear to me (at least it is), but it sound odd when I read it. Maybe is
> should be something like "the type parameter that has a structural
> constraint"?
>
> Thanks, it should be "if" rather than "of".  I'll fix it.
>
>
> > At the end totally pedantic hair splitting. At the end of the "Type
> sets" (
> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#type-sets)
> we have code snippet "interface{ E1; E2}". I feel that more consistent with
> the rest of the code would be with one more space: "interface{ E1; E2 }".
>
> Thanks, I'll fix that too.
>
> Ian
>

-- 
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/CAB3gO8rsqFvXGLDfbaqfCq2dY1L44R_3dgDb4uBF5mHn7z3FYA%40mail.gmail.com.

[go-nuts] Type Parameters Proposal, few unimportant questions

[Kamil Ziemian]

Hello,

I try to work my way through "Type Parameters Proposal" 
(https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md).
 
With my speed, I maybe and reading this very well written document before 
type parameters will be implemented in Go. xD Jokes aside, when I read it I 
found few sentences that sounds odd to me. Maybe some good soul would 
explain to me, am I right, or this is my bad, not good English?

At the beginning of the section (?) "Using a constraint" 
(https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#using-a-constraint)
 
there is sentence "As shown above, constraints appear in the type parameter 
list as the meta-type of a type parameter." But I think that is should read 
"shown below".

In the second paragraph (?) of the section "Operations based on type sets" 
(https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#operations-based-on-type-sets)
 
we read "For special purpose operators like range loops, we permit their 
use of the type parameter has a structural constraint". Meaning of it is 
clear to me (at least it is), but it sound odd when I read it. Maybe is 
should be something like "the type parameter that has a structural 
constraint"?

At the end totally pedantic hair splitting. At the end of the "Type sets" 
(https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#type-sets)
 
we have code snippet "interface{ E1; E2}". I feel that more consistent with 
the rest of the code would be with one more space: "interface{ E1; E2 }".

Best,
Kamil

-- 
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/de7fe316-ce69-48cd-8684-1c500cd058f6n%40googlegroups.com.

[go-nuts] Re: Questions raised by "Understanding Allocations: the Stack and the Heap - GopherCon SG 2019"

[Kamil Ziemian]

Thank you Brian Candler. I finally need to learn EBNF, because it kill me 
when I tried to read Go Spec last time.

Best
Kamil

wtorek, 7 września 2021 o 12:22:19 UTC+2 Brian Candler napisał(a):

> > By the way, if someone can explain me what is going on with "println", I 
> would be gratefully. This isn't important to me, since "fmt" give me what I 
> need, but I just curious what Walker used it.
>
> https://golang.org/ref/spec#Bootstrapping
> https://golang.org/ref/spec#Predeclared_identifiers
>
>

-- 
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/77b4ec9e-56b3-4403-b5fe-d40411242531n%40googlegroups.com.

Re: [go-nuts] Various questions about posts from The Go Blog

[Kamil Ziemian]

Hello,

In the post "Concurrency is not parallelism" by Andrew Gerrand 
(https://go.dev/blog/waza-talk) under the paragraph starting with "To clear 
up this conflation, Rob Pike gave a talk at Heroku’s Waza" in my browser is 
big blank space. I believe that that I can see rectangle in it, with 
slightly different hue of with, but I can't be sure.

Is it my browser not working or something goes wrong with the page? Can 
someone check if he/she has the same problem? I use Mozilla Firefox for 
Ubuntu canonical - 1.0, version 91.0.2 (64 bits). I hope I don't mess up 
Fierfox data.

Best,
Kamil
środa, 18 sierpnia 2021 o 18:13:31 UTC+2 Ian Lance Taylor napisał(a):

> On Wed, Aug 18, 2021 at 1:30 AM Kamil Ziemian  wrote:
> >
> > I guess it should say "any number type", but I'm not 100% sure. Am I 
> right?
> >
> > Thank you for the answer. I'm not good at computer science, so I'm often 
> can't decide is this mistake or is there some subtlety that I'm missing.
>
> Thanks for pointing it out. I sent https://golang.org/cl/342992 to
> fix the problem.
>
>
> > Small mistake and typos are quite common in blogs and talks and I am 
> always quite unsettled by them (long story why). Unfortunately, they can be 
> also in the presented code, at least in talks that I saw. "Never trust 
> yourself, always run compiler" seems be the moral of the story.
> >
> > As a aside, today I found in "Why Generics?" (
> https://blog.golang.org/why-generics) at the end of the section "Ordered 
> types" sentence "In practice this contract would probably go into the 
> standard library. and so really the Min function". Punctuation in natural 
> languages is beyond me, but I guess changing period to coma make it correct.
>
> I sent https://golang.org/cl/343251 to fix this. Thanks again.
>
> Ian
>
>
> > PS. I know that now Go has Type Parameters Proposal (
> https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md),
>  
> but I need to wrap my head around generics, so I try to read as much as 
> possible, even about outdated things like contracts.
> >
> > Kamil
> > wtorek, 17 sierpnia 2021 o 21:20:25 UTC+2 Ian Lance Taylor napisał(a):
> >>
> >> On Tue, Aug 17, 2021 at 9:13 AM Kamil Ziemian  
> wrote:
> >> >
> >> > I'm now rereading post "Constants" and in the last section "Numbers" 
> there is a text
> >> >
> >> > BEGINNING
> >> > Therefore, although they have different implicit default types, 
> written as untyped constants they can be assigned to a variable of any 
> integer type:
> >> >
> >> > var f float32 = 1
> >> > var i int = 1.000
> >> > var u uint32 = 1e3 - 99.0*10.0 - 9
> >> > var c float64 = '\x01'
> >> > var p uintptr = '\u0001'
> >> > var r complex64 = 'b' - 'a'
> >> > var b byte = 1.0 + 3i - 3.0i
> >> >
> >> > fmt.Println(f, i, u, c, p, r, b)
> >> > END
> >> >
> >> > I guess it should say "any number type", but I'm not 100% sure. Am I 
> right?
> >>
> >> I think you're right.
> >>
> >> Ian
> >
> > --
> > 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/8bfe4d66-470f-42c0-b33d-35e16a89be33n%40googlegroups.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/8d691501-9bf1-4095-a072-25c648ace0f9n%40googlegroups.com.

[go-nuts] Questions raised by "Understanding Allocations: the Stack and the Heap - GopherCon SG 2019"

[Kamil Ziemian]

Hello,

I often punch above my weight trying to understand various problem, so when 
I saw talk "Understanding Allocations: the Stack and the Heap - GopherCon 
SG 2019" by Jacob Walker (https://www.youtube.com/watch?v=ZMZpH4yT7M0), I 
cannot resist it. I'm basically compiler front-end user and nothing more, 
but this talk is very clear, so I learn something.

I'm using "go version go1.17 linux/amd64" and I puzzled by what I get when 
i run "go build -gcflags="-m -l" go_program.go", which should print 
optimization decisions with disable inlining (I hope that I get it 
correctly). When Jacob Walker use "println" I follow what he said at the 
beginning and use "fmt.Println".

For the program presented at 13:20 I get

x does not escape
 ... argument does not escape
n escapes to heap

while at presentation you have "&n does not escape". It seems to me, that 
on my computer much more things "escapes to heap". Can anyone point me in 
the right direction, to understand why I get "n escapes to heap"? Two 
simple answer that I can think about is "You don't use println" or 
"Compiler has changed.", but I want to know more about that. (I probably 
again punch above my weight.)

I also reworked first code shown at 16:47 to form

package main

import "fmt"

func main() {
b := read()
fmt.Println("b:", b)
}

func read() []byte {
b := make([]byte, 32)
return b
}

and get
make([]byte, 32) escapes to heap
... argument does not escape
"b:" escapes to heap
b escapes to heap
I guess fmt.Println can force "b:" to be of type interface{}, but this is 
still puzzling, why such simple thing "escapes to heap", since in the talk 
he says that "interfaces may escapes to the heap".

By the way, if someone can explain me what is going on with "println", I 
would be gratefully. This isn't important to me, since "fmt" give me what I 
need, but I just curious what Walker used it.

Best
Kamil

-- 
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/ed5fe55f-09c3-41c5-83fd-12a04c27dbd3n%40googlegroups.com.