[go-nuts] Alternative generics design with some interesting aspects

[will....@gmail.com]

Hey all,

Congrats to the Go Team for shipping generics!

I was experimenting with a design for generics for a long time. I thought 
I'd share it anyway for fun. I think it has some interesting (IMHO) aspects 
and trade-offs compared to the design that shipped:

   - Type variable declarations are implicit
   - Type arguments for functions are implicit
   - Type variable constraints can be omitted for the empty interface
   - Methods can be generic
   - Operations are represented with generics as normal methods
   - It can simplify the Go language specification
   
Here's a quick sample:

type Number interface {
$N Add($N) $N
}

type MyInt struct {
my int
}

func (x MyInt) Add(y MyInt) MyInt {
return MyInt{my: x + y}
}

type MyFloat struct {
my float64
}

func (x MyFloat) Add(y MyFloat) MyFloat {
return MyFloat{my: x + y}
}

func Add[$N Number](a, b $N) $N {
return a.Add(b)
}

var _ MyInt = Add(MyInt{1}, MyInt{2})
var _ MyFloat = Add(MyFloat{1}, MyFloat{2})

There are also a few other feature ideas at the end, for those interested 
(sum types, tuple types, unifying signatures and structures).

Here it is:

https://gist.github.com/willfaught/70f178ff52296d1865ae1f5ea0e574c4

-- 
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/efa7c07e-4a92-48b3-80e0-2820d1831ecan%40googlegroups.com.

[go-nuts] What is the Go build cache for fuzz testing?

[will....@gmail.com]

`go help clean` says:






*The -fuzzcache flag causes clean to remove files stored in the Go 
buildcache for fuzz testing. The fuzzing engine caches files that 
expandcode coverage, so removing them may make fuzzing less effective 
untilnew inputs are found that provide the same coverage. These files 
aredistinct from those stored in testdata directory; clean does not 
removethose files.*

What's the difference between the fuzz cache in the testdata/fuzz directory 
in your own package, and this "Go build cache for fuzz testing"? Is it 
duplicating testdata/fuzz per package? And where is it?

-- 
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/3a699718-196f-48b8-a414-19f6d8835d35n%40googlegroups.com.

[go-nuts] Slice and map type sets for range operations

[will....@gmail.com]

Do slices and maps have compatible type sets regarding the range operator?

I was trying to iterate through either, where slice keys are the indexes, 
such that this would work:

type KV[K comparable, V any] interface {
~[]V | map[K]V
}

func f[KV2 KV[K, V], K comparable, V any](kv KV2) {
for k, v := range kv { // line 12
fmt.Println(k, v)
}
}

func main() {
f[map[string]string, string, string](map[string]string{"a": "b", "c": 
"d"}) // works
f[[]string, int, string]([]string{"e", "f"}) // error
}

I get this error:

./prog.go:12:20: cannot range over kv (variable of type KV2 constrained by 
KV[K, V]) (KV2 has no core type)

Play link: https://go.dev/play/p/jSfaEaTmcQ1

I'm having trouble understanding this error message. Is this saying that 
maps and slices don't have a core type because they're not compatible for 
the range operator?

-- 
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/69a847c2-cf16-40c4-b6b9-22569009731an%40googlegroups.com.

[go-nuts] Add comparisons to all types

[will....@gmail.com]

All types should have unrestricted comparisons (`==`, `!=`), but a few 
pre-declared types don't. Adding them would bridge a semantic gap between 
pre-declared and user-declared types, enabling all types to be used as map 
keys, and otherwise make reasoning about them more consistent and intuitive.

For the types that don't yet have unrestricted comparisons:

   - Functions: Compare the corresponding memory addresses. The time 
   complexity is constant.
   - Maps: Compare the corresponding `*runtime.hmap` (pointer) values. The 
   time complexity is constant.
   - Slices: Compare the corresponding `runtime.slice` (non-pointer struct) 
   values. The time complexity is constant.
   
Examples:

```
// Functions

func F1() {}
func F2() {}

var _ = F1 == F1 // True
var _ = F1 != F2 // True

// Maps

var M1 = map[int]int{}
var M2 = map[int]int{}

var _ = M1 == M1 // True
var _ = M1 != M2 // True

// Slices

var S1 = make([]int, 2)
var S2 = make([]int, 2)

var _ = S1 == S1 // True
var _ = S1 != S2 // True

var _ = S1 == S1[:] // True because the lengths, capacities, and pointers 
are equal
var _ = S1 != S1[:1] // True because the lengths aren't equal
var _ = S1[:1] != S1[:1:1] // True because the capacities aren't equal
var _ = S1 != append(S1, 0)[:2:2] // True because the pointers aren't equal
```

Function and map equality are consistent with channel equality, where 
non-nil channels are equal if they were created by the same call to `make`. 
Function values are equal if they were created by the same function literal 
or declaration. Map values are equal if they were created by the same map 
literal or the same call to `make`. Functions that are equal will always 
produce the same outputs and side effects given the same inputs and 
conditions; however, the reverse is not necessarily true. Maps that are 
equal will always contain the same keys and values; however, the reverse is 
not necessarily true.

Slice equality is consistent with map equality. Slice values are equal if 
they have the same array pointer, length, and capacity. Slices that are 
equal will always have equal corresponding elements. However, like maps, 
slices that have equal corresponding elements are not necessarily equal.

This approach to comparisons for functions, maps, and slices makes all 
values of those types immutable, and therefore usable as map keys.

This would obviate the `comparable` constraint, since all type arguments 
would now satisfy it. In my opinion, this would make the language simpler 
and more consistent. Type variables could be used with comparison 
operations without needing to be constrained by `comparable`.

If you think slice equality should incorporate element equality, here's an 
example for you:

```
type Slice1000[T any] struct {
xs *[1000]T
len, cap int
}

func (s Slice1000[T]) Get(i int) T {
// ...
return s.xs[i]
}

func (s Slice1000[T]) Set(i int, x T) {
// ...
s.xs[i] = x
}

var xs1, xs2 [1000]int

var a = Slice1000[int]{&xs1, 1000, 1000}
var b = Slice1000[int]{&xs2, 1000, 1000}
var c = a == b
```

Do you expect `c` to be true? If not (it's false, by the way), then why 
would you expect `make([]int, 2) == make([]int, 2)` to be true?

Any thoughts?

-- 
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/8cdc4dae-95f8-4a38-b977-b5b228867c6fn%40googlegroups.com.

Re: [go-nuts] Add comparisons to all types

[will....@gmail.com]

son to include capacity in comparisons, aside from it being 
convenient when doing comparisons, is that the capacity is an observable 
attribute of slices in regular code. Programmers are *encouraged* to reason 
about slice capacity, so it should be included in comparisons. `cap(S1[:1]) 
!= cap(S1[:1:1])` is true, therefore `S1[:1] != S1[:1:1]` *should* be true, 
even though `len(S1[:1]) == len(S1[:1:1])` is true.

I assume `make([]T, 0)` sets the array pointer to nil, because 
`reflect.DeepEqual` says two of those expressions are equal.

The thing is, for pointers there pretty much is exactly one *useful* way to 
> define comparison. For slices, there are multiple useful ways to define it, 
> none of them *clearly* superior to any of the others.
>
>
We *could* do deep comparisons for pointers, but we don't, because shallow 
comparisons are useful, and we can dereference pointers when we need to do 
deep comparisons. As I argued above, this is exactly the same situation for 
slices regarding shallow and deep comparisons.
 

> Why should we compare pointer values when doing so won't compare the 
>> referenced, logical values? Because sometimes we want to compare just the 
>> pointer values because it's fast, and pointers are small, and you can 
>> conclude logical equivalence if they're equal. Sometimes shallow/literal 
>> comparisons are useful, and sometimes deep/logical comparisons are useful.
>>
>> Just as pointer comparisons are shallow, so too are comparisons for types 
>> that contain pointers. I included the Slice1000 example above specifically 
>> to address your point. Based on your argument here, I assume your answer to 
>> the question about `c` in that example would be "yes," however the answer 
>> is no, according to current Go behavior. Comparison of structs containing 
>> pointers does a shallow comparison of the pointer value, not the value it 
>> references. My argument is that under the hood, Go slices work the same way.
>>
>> I'm proposing a shallow comparison, not a deep comparison, and that's 
>> arguably a feature here. I highlighted the time complexity for a reason, 
>> because I recall someone in the Go Team at one point arguing somewhere that 
>> doing a logical comparison would be too slow, since one of the benefits of 
>> Go comparisons is that their time complexity is small and well-understood. 
>> Checking for equality for your struct-based type won't ever cause your 
>> program to slow or hang; it's "safe."
>>
>> The point isn't to provide equivalence operations; it's to provide useful 
>> comparison operations that are consistent with the other types' comparison 
>> operations, to make all types consistent and simplify 
>> <https://go.dev/doc/faq#map_keys> the language. We could provide a 
>> separate equivalence operation, perhaps something like `===` that behaves 
>> like `reflect.DeepEquals`, but that's a separate issue. Shallow slice 
>> comparisons *do* allow you to conclude that elements are equal if slices 
>> compare equal, and we can still iterate slices manually to compare elements.
>>
>> On Mon, May 2, 2022 at 9:58 PM Rob Pike  wrote:
>>
>>> * Functions: Compare the corresponding memory addresses. The time
>>> complexity is constant.
>>>
>>> There are cases involving closures, generated trampolines, late
>>> binding and other details that mean that doing this will either
>>> eliminate many optimization possibilities or restrict the compiler too
>>> much or cause surprising results. We disabled function comparison for
>>> just these reasons. It used to work this way, but made closures
>>> surprising, so we backed out and allow comparison only to nil.
>>>
>>> * Maps: Compare the corresponding `*runtime.hmap` (pointer) values.
>>> The time complexity is constant.
>>> * Slices: Compare the corresponding `runtime.slice` (non-pointer
>>> struct) values. The time complexity is constant.
>>>
>>> In LISP terms, these implementations do something more like `eq`, not
>>> `equal`. I want to know if the slices or maps are _equivalent_, not if
>>> they point to identical memory. No one wants this semantics for slice
>>> equality. Checking if they are equivalent raises difficult issues
>>> around recursion, slices that point to themselves, and other problems
>>> that prevent a clean, efficient solution.
>>>
>>> Believe me, if equality for these types was efficient _and_ useful, it
>>> would already be done.
>>>
>>> -rob
>>>
>&

[go-nuts] Show your support for GitHub adding Gerrit features

[will....@gmail.com]

https://github.com/github-community/community/discussions/18879

It would be nice if the Go project could do reviews on GitHub too.

-- 
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/425e5724-0bc4-431b-b158-5a450626c0c6n%40googlegroups.com.

[go-nuts] Re: Package structure & testing

[will....@gmail.com]

>Collapse all three. This works but I really don't like having Fake code in 
the same package as real code.

This is the answer, in my opinion. Don't split code across packages unless 
there's a reason to do so. A fake implementation is a feature. If it hurts 
that much, just call it something more general, like InMemoryClient, and 
note in the doc that it's only for testing. Keep it simple.
On Monday, June 19, 2023 at 6:18:02 PM UTC-7 Salvatore Domenick Desiano 
wrote:

> Interesting point. Two questions:
>
>- Is there a standard library example of a client library that 
>provides a fake?
>- I've always been taught that Go packages stand alone so names like 
>"api" and "model" are verboten. Am I wrong?
>
>
>
> On Monday, June 19, 2023 at 1:22:03 AM UTC-4 TheDiveO wrote:
>
>> Maybe not the best way either, but the POD part might benefit from slight 
>> refactoring and you already in part hinted at it.
>>
>>- gopher/api -- some PODs here
>>- gopher/model -- don't repeat gopher as in gophermodel; some PODs 
>>here
>>
>> It won't ever perfect, so YMMV. But at the same time it allows your 
>> module to grow.
>>
>> On Monday, June 19, 2023 at 7:04:24 AM UTC+2 Salvatore Domenick Desiano 
>> wrote:
>>
>>> I've been using Go for almost a decade and I still don't have a library 
>>> package structure I like. I'm hoping I can post what I want here and 
>>> someone can tell me either (a) what the idiomatic way of doing this is, or 
>>> (a) how to break the dependency cycle.
>>>
>>> Let's imagine we're building the fancy Gopher Client library. What I 
>>> want is:
>>>
>>>- *gopher*: public POD (plain old data) types, public interfaces, 
>>>func NewClient(), struct clientImpl
>>>- *gopher/testing*: func NewFakeClient(), struct fakeClientImpl, all 
>>>testing-specific code (*not* gopher _test files... just code for 
>>>*other* libraries that want a fake of this one)
>>>- *gopher/internal*: internal types, implementation details shared 
>>>between gopher and gopher/testing.
>>>
>>> This doesn't work. Having POD types in gopher means that everything else 
>>> has to depend on it. This means that NewClient() can't be in gopher because 
>>> it would depend on gopher/internal (shared implementation details) and 
>>> gopher/internal depends on gopher (PODs).
>>>
>>> At various points I've tried:
>>>
>>>- Collapse gopher and gopher/internal. This works, but requires 
>>>private types to be available to gopher/testing.
>>>- Collapse all three. This works but I really don't like having Fake 
>>>code in the same package as real code.
>>>- Create gopher/gophermodel for the PODs and interfaces. This works, 
>>>but it's really ugly to have to refer to the PODS as (for example) 
>>>gophermodel.Response.
>>>- Create gopher/gopherclient for NewClient() and clientImpl. This is 
>>>probably the least ugly but it still feel strange to call 
>>>gopherclient.New() and have the PODs in gopher.
>>>
>>> What am I missing?
>>>
>>> Thank you!
>>>
>>> -- Salvatore
>>> smile.
>>>
>>>

-- 
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/6354aa27-06ff-4fee-bc9a-7afd2ed81e09n%40googlegroups.com.

[go-nuts] comment.Printer.DocLinkURL isn't being called

[will....@gmail.com]

I'm trying to print the Markdown for package documentation using the new 
go/doc/comment package. It seems like I have everything set up correctly to 
customize the doc link URLs, but the comment.Printer.DocLinkURL callback 
isn't being called:

https://go.dev/play/p/7irKc6dTRRw

The comment.Printer.HeadingID and HeadingLevel settings are working just 
fine.

Am I missing something?

-- 
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/41ce3de2-84a4-47a3-856d-0bc4543115fbn%40googlegroups.com.

Re: [go-nuts] comment.Printer.DocLinkURL isn't being called

[will....@gmail.com]

Thanks, that was it!

On Sunday, July 9, 2023 at 5:10:08 PM UTC-7 Sean Liao wrote:

> your parsing setup is missing the lookup to identify which things are 
> actually linkable symbols
>
> https://go.dev/play/p/sDtGA_JJZdz
>
> - sean
>
> On Sun, Jul 9, 2023, 23:45 will@gmail.com  wrote:
>
>> I'm trying to print the Markdown for package documentation using the new 
>> go/doc/comment package. It seems like I have everything set up correctly to 
>> customize the doc link URLs, but the comment.Printer.DocLinkURL callback 
>> isn't being called:
>>
>> https://go.dev/play/p/7irKc6dTRRw
>>
>> The comment.Printer.HeadingID and HeadingLevel settings are working just 
>> fine.
>>
>> Am I missing something?
>>
>> -- 
>> 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/41ce3de2-84a4-47a3-856d-0bc4543115fbn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/41ce3de2-84a4-47a3-856d-0bc4543115fbn%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/1d775d08-7898-4c94-a038-9499e36d45edn%40googlegroups.com.

Re: [go-nuts] comment.Printer.DocLinkURL isn't being called

[will....@gmail.com]

The documentation for comment.Parser.LookupSym is unclear. When would you 
ever not return true?

Looking at Parser more, it isn't clear how you'd implement 
comment.Parser.LookupPackage in a general way. Has that been done somewhere?

I don't see a way to disable links to declarations entirely, so `[MyType]` 
doc syntax is rendered in Markdown as just `MyType` instead of `\[MyType]`. 
Is there a way to do that?
On Sunday, July 9, 2023 at 5:55:02 PM UTC-7 will@gmail.com wrote:

> Thanks, that was it!
>
> On Sunday, July 9, 2023 at 5:10:08 PM UTC-7 Sean Liao wrote:
>
>> your parsing setup is missing the lookup to identify which things are 
>> actually linkable symbols
>>
>> https://go.dev/play/p/sDtGA_JJZdz
>>
>> - sean
>>
>> On Sun, Jul 9, 2023, 23:45 will@gmail.com  wrote:
>>
>>> I'm trying to print the Markdown for package documentation using the new 
>>> go/doc/comment package. It seems like I have everything set up correctly to 
>>> customize the doc link URLs, but the comment.Printer.DocLinkURL callback 
>>> isn't being called:
>>>
>>> https://go.dev/play/p/7irKc6dTRRw
>>>
>>> The comment.Printer.HeadingID and HeadingLevel settings are working just 
>>> fine.
>>>
>>> Am I missing something?
>>>
>>> -- 
>>> 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/41ce3de2-84a4-47a3-856d-0bc4543115fbn%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/golang-nuts/41ce3de2-84a4-47a3-856d-0bc4543115fbn%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/69ac8814-8210-48db-81b4-ea402f48e61en%40googlegroups.com.

[go-nuts] Unused local constants not a compiler error

[will....@gmail.com]

Was this always the case? Is this a bug? Seems like it should be a compiler 
error, like unused local variables.

-- 
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/94970f93-00a3-4f1b-82f8-93906c0e9deen%40googlegroups.com.

[go-nuts] go clean -h isn't helpful

[will....@gmail.com]

❯ go clean -h
usage: go clean [clean flags] [build flags] [packages]
Run 'go help clean' for details.

This just tells me to invoke another help command.

The flags package has the opinion that command help should print the doc 
for flags. Shouldn't we do that for go clean -h too?

-- 
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/61723ff5-6183-4ab0-83ef-50f0f278e8ddn%40googlegroups.com.

Re: [go-nuts] Go import redirect docs are unclear

[will....@gmail.com]

>Most web servers automatically serve an `index.html` for a request to a 
directory. The intent is to use something like that. Though note that you 
can also use a fuller path: That is, if your git-repo is at 
`https://code.org/r/exproj` and has import path `example.com/exproj`, you 
can host a single HTML file at `example.com/exproj` containing
`https://code.org/r/p/exproj";>` (I believe).

The linked-to documentation 
 seems to conflict with 
that (emphasis mine):

>For example,
>
>import "example.org/pkg/foo"
>
>will result in the following requests:
>
>https://example.org/pkg/foo?go-get=1 (preferred)
>http://example.org/pkg/foo?go-get=1  (fallback, only with use of correctly 
set GOINSECURE)
>
>If that page contains the meta tag
>
>https://code.org/r/p/exproj";>
>
>*the go tool will verify that https://example.org/?go-get=1 contains the 
same meta tag* and then git clone https://code.org/r/p/exproj into 
GOPATH/src/example.org.

There's a proposal for removing this 
requirement: https://github.com/golang/go/issues/54530
On Sunday, June 23, 2024 at 7:43:54 AM UTC-7 Axel Wagner wrote:

> On Sun, 23 Jun 2024 at 16:17, Tobias Klausmann  
> wrote:
>
>> Hi! 
>>
>> On https://pkg.go.dev/cmd/go#hdr-Remote_import_paths, in the section
>> about using meta tags to redirect from some domain to a known forge, it
>> says:
>>
>> > For example,
>> > 
>> > `import "example.org/pkg/foo"`
>> > 
>> > will result in the following requests:
>> > 
>> > `https://example.org/pkg/foo?go-get=1` 
>>  
>> > 
>> > If that page contains the meta tag 
>> >
>> > `https://code.org/r/p/exproj";>`
>> > 
>> > the go tool will verify that https://example.org/?go-get=1 contains
>> > the same meta tag and then git clone https://code.org/r/p/exproj into
>> > GOPATH/src/example.org.
>>
>> This is confusing me. I get that https://example.org/pkg/foo?go-get=1
>> should have a meta tag of this form:
>>
>> ```
>> https://code.org/r/p/exproj";>
>> ```
>>
>> But what meta tag should the / page have? The same? Then just doing this
>> with static files (which I vastly prefer) is not possible.
>
>
> Most web servers automatically serve an `index.html` for a request to a 
> directory. The intent is to use something like that. Though note that you 
> can also use a fuller path: That is, if your git-repo is at `
> https://code.org/r/exproj`  and has import 
> path `example.com/exproj` , you can host a 
> single HTML file at `example.com/exproj`  
> containing
> `https://code.org/r/p/exproj";>`
> (I believe).
>
> It's also unclear what purpose this has (or why the request to /pkg/foo is 
>> made).
>>
>
> The Request to `/pkg/foo` is made, because the Go tool does not know 
> whether the repository root (today probably the module path) is at the 
> import path referred to as `example.com/pkg/foo` 
> , `example.com/pkg`  
> (and the wanted package is in the folder `foo` of that repo) or `
> example.com` (and the wanted package is in the folder `pkg/foo` of that 
> repo). Making the deepest request first is intended to answer that question.
>
> I'm not entirely certain what the purpose of the second request is. My 
> guess is, that it is to prevent some form of hijacking, but how exactly 
> that would work, I'm not sure off the top of my hat.
>  
>
>>
>> Can anybody shed some light?
>>
>> Best,
>> Tobias
>>
>> -- 
>> 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/a0a7d30f-8e83-4769-8e03-dd57a76a8a88%40skade.local
>> .
>>
>

-- 
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/80214469-3211-4799-a67f-867f57adcbcen%40googlegroups.com.

[go-nuts] go doc broken in official go repo

[will....@gmail.com]

I cloned the official Go repo locally, went into src/text/template, ran `go 
doc .`, and got this error:

go: downloading go1.23.0 (darwin/arm64)
go: download go1.23.0 for darwin/arm64: toolchain not available

It looks like src/go.mod declares 1.23. Shouldn't it be the latest 
self-host version, whatever that was? v1.20 or something? It seems like an 
error to declare a Go version that doesn't exist.

Will

-- 
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/b4047237-8390-48dd-87f9-c935396a35e8n%40googlegroups.com.

[go-nuts] go env doesn't seem to work well with GOTELEMETRY

[will....@gmail.com]

Despite showing up an an env var, it's not treated consistently as one:

❯ go telemetry off
# nothing printed
# as expected

❯ go env | grep GOTELEMETRY=
GOTELEMETRY='off'
# as expected

❯ go env GOTELEMETRY
off
# as expected

❯ go env -changed
# nothing printed
# as expected

❯ go env -u GOTELEMETRY
go: unknown go command variable GOTELEMETRY
*# expected nothing printed, success*

❯ go env -w GOTELEMETRY=on
go: unknown go command variable GOTELEMETRY
*# expected nothing printed, success*

❯ go telemetry on
# snip
# as expected

❯ go env | grep GOTELEMETRY=
GOTELEMETRY='on'
# as expected

❯ go env GOTELEMETRY
on
# as expected

❯ go env -changed
# nothing printed
*# expected to be printed: GOTELEMETRY='on'*

❯ go env -u GOTELEMETRY
go: unknown go command variable GOTELEMETRY
*# expected nothing printed, success*

❯ go env -w GOTELEMETRY=off
go: unknown go command variable GOTELEMETRY
*# expected nothing printed, success*

-- 
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/4820db28-6397-4c1f-a7b1-bb829b8ed525n%40googlegroups.com.

[go-nuts] Why isn't the memory model part of the spec?

[will....@gmail.com]

It seems required to understand how Go programs work.

If the memory model was never written, or is omitted from an 
implementation, would the concurrency features still be reliable and useful?

-- 
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/968f781b-599d-4eb9-8ad1-066c8e6c071en%40googlegroups.com.

[go-nuts] Why doesn't Go use Windows's time zone data for time.LoadLocation?

[will....@gmail.com]

I read in a recent Go issue that Go uses time zone data in GOROOT for 
Windows and Plan 9. 

I looked through the Go proposal documents, but couldn't find one for the 
time package that had the original reasons, but I assume the reasons are 
because Windows didn't used to have IANA-compatible time zone info, and 
Plan 9 still doesn't.

Can anyone point me to info about why Go doesn't use the time zone info in 
the Windows registry instead? It looks like there is now a full mapping 
from IANA zones to Windows zones 

.

I'm also curious why Plan 9 doesn't include a tzdata or zoneinfo database 
file for programs to use for time zone logic/math, like most OSs, if anyone 
happens to know. I understand wanting to keep the system time simple, but 
the database still seems useful for generally doing math with times from 
different time zones. Why not just include it for programs?

Will

-- 
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 visit 
https://groups.google.com/d/msgid/golang-nuts/0e1fcf87-4569-4de5-a34d-f4b6a3a0f11en%40googlegroups.com.

Re: [go-nuts] "go-import" is great, we need "go-delete"

[will....@gmail.com]

Jeffrey,

If modules worked like you suggested, a domain owner could be compromised, 
and the cryptographic module hashes for the domain could be changed to 
disrupt or infect dependencies. Version immutability prevents that: a 
module version is code + current import path ownership at the time the 
version is published. Authors can publish new versions to correct old ones, 
which the module/versioning designs took into account. You have to be 
careful about what Git version tags you publish. This is the deal the Go 
community made when it adopted the current module/versioning designs.

That being said, I see four paths you could take at this point:

If the package has never been downloaded by the Go proxy or a go tool, then 
change or delete the tag.

If the package has been downloaded by the Go proxy but not a go tool, then 
request  that the package 
be removed from the proxy.

If the package has been downloaded by a go tool, then instruct the owner of 
every single one of them to manually delete the content from their local go 
tool cache.

If you have to, just make a v2 package in the same module, or a v2 module, 
and start from scratch.

Will
On Saturday, January 4, 2025 at 8:53:27 AM UTC-8 Christoph Berger wrote:

> > We need "go-delete". Security is not important to us. There should be a 
> balance between people that need security and people that don't need it.
>
> Security might not be important to you, but it is important for the 
> clients of your code—for the users that won't expect that a module provider 
> removes their repo or specific versions of a module, thus breaking all 
> downstream projects.
>
> Remember left-pad 
> 
> .
>
> A per-domain go-delete would not be any better than a global go-delete. An 
> immutable log guarantees, or at least greatly increases, supply chain 
> security. Allowing anyone to rug-pull their libraries (or even just 
> rug-pull specific versions) effectively prohibits any supply chain 
> security. 
>
> Consider using the GOPROXY or GONOPROXY 
> 
>  
> environment variables during development to advise your Go toolchain to 
> fetch specific or all modules directly rather than checking the proxy. Or 
> use a Go workspace  that can 
> redirect any dependency to a local directory. This way, a new module or a 
> new module version won't hit the Go proxy as long as they're only 
> downloaded directly, bypassing the proxy. You can then make all kinds of 
> dumb mistakes (frankly, we all do!) during development and fix them without 
> a trace. 
>
> Once you push a release version, clients may download the module normally, 
> that is, through the proxy, and thus engrave the released version into the 
> log.
>
>
> On Saturday, December 28, 2024 at 3:04:04 AM UTC+1 Jeffery Carr wrote:
>
>> On Fri, Dec 27, 2024 at 7:30 PM Sean Liao  wrote:
>>
>>> The zips (of your code) cached by the proxy can be removed.
>>> The checksums held by the subdb cannot. The design for this is similar
>>> to https://en.wikipedia.org/wiki/Certificate_Transparency not
>>> blockchains which can hold arbitrary data.
>>>
>>
>> It does hold arbitrary information.
>>
>> Allowing you to change the contents of a given module+version is a non
>>> goal as that opens the ecosystem up to supply chain attacks.
>>>
>>
>> Cool for those people that need that, but if this means I can't 
>> "go-delete" and start over, kinda not helpful then.
>>
>> If the transparency log was domain based (make a log for each hostname in 
>> the namespace) then this would be possible to more easily solve.
>>
>> peace,
>> jcarr
>>
>

-- 
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 visit 
https://groups.google.com/d/msgid/golang-nuts/760f87d5-ad56-477b-98a7-9747e5d4d4b2n%40googlegroups.com.

[go-nuts] Re: Go Module Mirror

[will....@gmail.com]

Looks like the package is still in the proxy, and sadly is used by one 
known person.

It would be useful if the proxy site had a tamper warning at the top of a 
package’s page when the code hash for the version has changed. Perhaps it 
would be useful to list all the tampered packages in a master list so we 
can see how pervasive the problem is.

On Wednesday, February 5, 2025 at 5:11:17 AM UTC-8 peterGo wrote:

> Go Module Mirror
>
> FYI
>
> Go Supply Chain Attack: Malicious Package Exploits Go Module Proxy Caching 
> for Persistence
>
> https://socket.dev/blog/malicious-package-exploits-go-module-proxy-caching-for-persistence
>  
>
>
> Go Module Mirror served backdoor to devs for 3+ years
>
> https://arstechnica.com/security/2025/02/backdoored-package-in-go-mirror-site-went-unnoticed-for-3-years/
>  
>
>
> Go Supply Chain Attack: Malicious Package Exploits Go Module Proxy Caching 
> for Persistence
>
> https://www.reddit.com/r/golang/comments/1ii6l00/go_supply_chain_attack_malicious_package_exploits/?rdt=54944
>  
>
>
> x/pkgsite: links can point at source code that may not match what is 
> served by the module proxy #66653
> https://github.com/golang/go/issues/66653
>
> peter
>
>

-- 
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 visit 
https://groups.google.com/d/msgid/golang-nuts/339b5b35-f44c-4b2a-ac7c-7d7e7a4ffa5an%40googlegroups.com.

[go-nuts] Is there a way to browse the stdlib packages in pkg.go.dev?

[will....@gmail.com]

To be clear, I mean see a listing of all the packages in the stdlib, or at 
least the root package directories.

Thanks,
Will

-- 
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 visit 
https://groups.google.com/d/msgid/golang-nuts/6391c491-2784-4211-9b29-3b9d3032d13fn%40googlegroups.com.

Re: [go-nuts] Golang ORM Performances

[will....@gmail.com]

https://github.com/ent/ent seemed to perform well, and was quite flexible.

Will

On Thursday, December 19, 2024 at 7:27:46 AM UTC-8 Robert Engels wrote:

> I go back and forth on ORMs. I think a lot depends on the complexity of 
> the project. 
>
> Still, I wouldn’t expect the overhead of an ORM to be more than 1-2% for 
> IO/db bound systems - if it is I suspect it is not properly configured and 
> it is generating inefficient queries or the database tables lack proper 
> indexing. 
>
> On Dec 19, 2024, at 9:17 AM, Mike Schinkel  wrote:
>
> Hi Bhavesh,
>
>
> I am also not a fan of ORMs, but I am a big fan of sqlc so I will 2nd 
> Brian Candler's recommendation. 
>
> Sqlc is one of the few Go packages/tools I consider a must-use for any of 
> my projects that need to interact with SQL databases.
>
> -Mike
>
> On Dec 19, 2024, at 8:23 AM, 'Brian Candler' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
> I am not a fan of ORMs. Application performance problems are usually down 
> to poorly formed SQL queries (and/or lack of supporting indexes), which 
> ORMs can mask or amplify.
>
> For an alternative approach, have a look at 
> https://github.com/sqlc-dev/sqlc
>
> In short, you write the set of SQL queries to meet your application's 
> needs, and then they get automatically wrapped in idiomatic Go.
>
> For joins, see: https://docs.sqlc.dev/en/stable/howto/embedding.html
>
> Refs:
> https://conroy.org/introducing-sqlc
> https://sqlc.dev/
> https://play.sqlc.dev/
>
> https://alanilling.com/exiting-the-vietnam-of-programming-our-journey-in-dropping-the-orm-in-golang-3ce7dff24a0f
>
> On Thursday, 19 December 2024 at 13:01:25 UTC Bhavesh Kothari wrote:
>
>> I read few posts regarding ORMs in golang & realized, few peoples are not 
>> happy with it.
>>
>> They mentioned to use raw queries with our own wrapper if want to make 
>> few things reusable.
>>
>> I was actually using Gorm, which was super slow, then I started research 
>> regarding performance efficient ORMs, and found *Bun* which was indeed 
>> faster compared to Gorm. But then I explored documentation more and 
>> realized it doesn't provide enough function to make life easier, this ORM 
>> even doesn't have community I felt.
>>
>> 1. I want to know readers view regarding ORMs in Go.
>>
>> Let me tell you something, my project is a huge project, and I decided to 
>> use Golang for better performance. But now I feel I've to write a lot of 
>> code and slow/less-featured ORMs here making me irritated.
>>
>> 2. What do you guys suggest is go really good for large projects?
>>
>
> -- 
> 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 visit 
> https://groups.google.com/d/msgid/golang-nuts/6addef83-3e2d-4b6c-b543-8127f5754f0en%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...@googlegroups.com.
>
> To view this discussion visit 
> https://groups.google.com/d/msgid/golang-nuts/C487B8AE-D8EF-47AE-A06C-48AC422DFD07%40newclarity.net
>  
> 
> .
>
>

-- 
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 visit 
https://groups.google.com/d/msgid/golang-nuts/710e10e4-8e6f-45da-99c6-c84aceb1077an%40googlegroups.com.

Re: [go-nuts] Looking for Go module path (contains version) suggestion for github.com/spdx/spdx-go-model

[will....@gmail.com]

Meng,

It's unclear to me what you're asking. Are you asking whether the path 
should be changed to be more idiomatic? I would have expected it to 
be github.com/spdx/spdx-go-model if the major version is 0 or 1; 
and github.com/spdx/spdx-go-model/v3 if the major version is 3.

Will

On Thursday, January 23, 2025 at 7:54:00 PM UTC-8 Dan Kortschak wrote:

> On Thu, 2025-01-23 at 19:17 -0800, Meng Zhuo wrote:
> > Hi, 
> > 
> > What should we do if module named with version?
> > ```
> > import (
> > "testing"
> > 
> > Spdx3_0_1 "github.com/spdx/spdx-go-model/v3_0_1"
> > ```
> > 
> > https://github.com/spdx/spdx-go-model/pull/1
>
> From the code that's in that change, the import path is
> github.com/spdx/spdx-go-model/spdx_v3_0_1, not github.com/spdx/spdx-go-
> model/v3_0_1.
>
>

-- 
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 visit 
https://groups.google.com/d/msgid/golang-nuts/a5732850-d7c3-46bd-b847-2a3761340807n%40googlegroups.com.

[go-nuts] GC hint for collection timing

[will....@gmail.com]

I recently recalled that someone in the Go Team—I forget who—said that the 
Go compiler slowed down a lot after converting from C to Go because the Go 
GC was freeing a lot of memory that the C code wasn't.

I wonder if an approach like that of memory regions 
(https://github.com/golang/go/discussions/70257) could be used to hint to 
the GC that memory allocated in a function doesn't need to be freed unless 
there is severe memory pressure.

For example (for lack of a better name):

func main() {
runtime.DeferCollection(func() {
runCommand()
})
}

Will

-- 
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 visit 
https://groups.google.com/d/msgid/golang-nuts/433bc550-fbf5-457c-b685-e9ac21a27ecdn%40googlegroups.com.