Re: [go-nuts] Re: Go Module Mirror

Also I don’t see the version hash listed on the package page (browsing in iOS Safari). That would help to compare against the repo for tampering.On Feb 5, 2025, at 9:25 AM, will@gmail.com wrote:Looks like the package is still in the proxy, and sadly is used by one known person.It would be use

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

Thanks. I tried searching for std, but it just did the literal search, as you’d expect.WillOn Feb 1, 2025, at 10:27 PM, Axel Wagner wrote:Yupp:https://pkg.go.dev/stdOn Sun, 2 Feb 2025 at 07:21, will@gmail.com wrote:To be clear, I mean see a listing of all the packages

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

Hi Jason! Thanks, makes sense. Will On Fri, Nov 29, 2024 at 7:07 AM Jason E. Aten wrote: > Hi Will! > > For Windows, there is some context here > https://github.com/golang/go/issues/21881 > > I think the short answer is that Windows does time zones differently > enough that there would be subt

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

Thanks, but it looks like that issue is only about enabling `go env -w GOTELEMETRY=off`. Isn't it incorrect for `go env GOTELEMETRY` to work, yet `go env -u GOTELEMETRY` prints `unknown go command variable GOTELEMETRY`? Shouldn't it insead print something like `go command variable GOTELEMETRY cann

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

I see. That doesn't seem very useful to me, so I won't be making a patch for it. Thanks anyways. On Sat, Jun 22, 2024 at 5:48 PM Ian Lance Taylor wrote: > On Sat, Jun 22, 2024 at 5:45 PM Will Faught wrote: > > > > Ian,refer> > > I see. I'm concerned tha

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

-msan] [-asan] [-cover] [-covermode set,count,atomic] [-coverpkg pattern1,pattern2,pattern3] ... That doesn't seem too useful. Will On Sat, Jun 22, 2024 at 5:09 PM Ian Lance Taylor wrote: > On Sat, Jun 22, 2024 at 12:03 AM Will Faught > wrote: > > > > Sure thing. > > &g

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

wrote: > On Mon, Jun 17, 2024 at 10:52 PM Will Faught > wrote: > > > > > People who already know what the command does can use that short > summary to remind themselves of the available options. > > > > Which options do you mean? My point was that it doesn

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

> People who already know what the command does can use that short summary to remind themselves of the available options. Which options do you mean? My point was that it doesn't document any options. On Mon, Jun 17, 2024 at 5:57 PM Ian Lance Taylor wrote: > On Mon, Jun 17, 2024 at 5:28 PM will.

[go-nuts] Built-in benchmark tracking and regression failures

I'm wondering if it would be useful to build benchmark regression detection into Go test benchmarks, and policy enforcement in terms of making regressions fail a benchmark "test". If I understand correctly, as Go benchmarks currently stand, they tell you the numbers, but it's left to you to interp

Re: [go-nuts] Nil could be the zero value for type variables

Thanks. I think these are more complicated and less consistent, since they require adding syntax for `_`, but I can see a similar motivation. On Sun, Jun 5, 2022 at 9:44 PM Nigel Tao wrote: > On Tue, May 31, 2022 at 1:39 AM Will Faught wrote: > >> Why not allow nil to be used as th

Re: [go-nuts] Nil could be the zero value for type variables

ing how the language spec introduces the idea of zero (now nil) values (by moving the zero value [now nil] specification closer to, or within, the type section, or something like that). Thanks for your thoughts. On Tue, May 31, 2022 at 6:19 PM Ian Lance Taylor wrote: > On Mon, May 30, 2022 a

Re: [go-nuts] Nil could be the zero value for type variables

Value V > > On Mon, May 30, 2022, 6:39 PM Will Faught wrote: > >> Hello, fellow Gophers! >> >> Currently, if I understand correctly, there's no expression for the zero >> value for a type variable: >> >> type Map[K comparable, V any] struct {

[go-nuts] Nil could be the zero value for type variables

Hello, fellow Gophers! Currently, if I understand correctly, there's no expression for the zero value for a type variable: type Map[K comparable, V any] struct { ks []K vs []V } func (m Map[K, V]) Get(k K) V { for i, k2 := range m.ks { if k2 == k { return m.vs[i]

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

The proposal was declined, so no need to respond. Some responses inline below. Thanks so much for your feedback, Axel. :) On Thu, May 5, 2022 at 11:39 AM 'Axel Wagner' via golang-nuts < golang-nuts@googlegroups.com> wrote: > On Thu, May 5, 2022 at 7:32 PM Will Faught wrote

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

Yeah, it would have performance implications, which is a good counter argument. Regardless, it seems from the discussion that function values can have multiple addresses, so it wouldn't work currently anyway. On Thu, May 5, 2022 at 6:39 AM David Arroyo wrote: > On Mon, May 2, 2022, at 22:43, wil

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

On Thu, May 5, 2022 at 2:53 AM Axel Wagner wrote: > On Thu, May 5, 2022 at 3:11 AM Will Faught wrote: > >> The reason to include capacity in comparisons, aside from it being >>> convenient when doing comparisons, is that the capacity is an observable >>> attri

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

On Wed, May 4, 2022 at 1:00 PM Ian Lance Taylor wrote: > On Tue, May 3, 2022 at 11:01 PM Will Faught wrote: > > > > On Tue, May 3, 2022 at 7:27 PM Ian Lance Taylor wrote: > >> > >> Does a program like this print true or false? > >> > >>

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

Makes sense, although I chuckled when I realized that the creator of that issue didn't actually have his issue resolved. Creator: This behavior is undefined. Which one should it be? Go Team: Both. 😆 On Wed, May 4, 2022 at 12:46 PM Ian Lance Taylor wrote: > On Tue, May 3, 2022 at 10:59 PM 'Axel

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

a Go without operators and do everything with > functions and generics. This is essentially the Java model. > > This is pretty much the approach that the sync, sort, etc packages took > and with generics you can have type safety and less code duplication. > > On May 4, 2022,

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

Can you explain what you mean by tokens? Do you mean something like: ``` var red, green, blue = new(struct{}), new(struct{}), new(struct{}) ``` If so, I don't see how that's useful. Why not use integers or bytes instead? On Wed, May 4, 2022 at 12:35 AM 'Dan Kortschak' via golang-nuts < golang-nu

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

On Wed, May 4, 2022 at 12:13 AM Axel Wagner wrote: > On Wed, May 4, 2022 at 8:42 AM Will Faught wrote: > >> Yes. I understand what you suggested and I understood how it *would* >>> work, if implemented that way. But why is that the best way to compare >>> them? Do

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

Well, I agree! :) Comparisons should be shallow where possible for every type, including slices and maps. That's my initial argument. On Tue, May 3, 2022 at 11:22 PM Jan Mercl <0xj...@gmail.com> wrote: > On Wed, May 4, 2022 at 12:15 AM Will Faught wrote: > > > I'

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

t;> >>>> 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,

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

On Tue, May 3, 2022 at 7:27 PM Ian Lance Taylor wrote: > On Tue, May 3, 2022 at 6:08 PM Will Faught wrote: > > > > My apologies, it seems that "reply all" in the Google Groups UI doesn't > send email to individuals like "reply all" in Gmail do

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

> On Tue, May 3, 2022 at 8:32 AM Will Faught wrote: > > > Just as pointer comparisons are shallow, so too are comparisons for > types that contain pointers. > > Pointer comparisons are not shallow. Comparing two pointers compares > the entire values. a == b and *a == *b comp

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

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 > > On Tue, May 3, 2022 at 2:41 PM Will Faught wrote: > > > > You seem to h

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

You seem to have misunderstood the point. It's an idea for changing the language. You're just demonstrating the current behavior, which is what would be changed. The argument is to make `make([]int, 2) == make([]int, 2)` legal, and evaluate to false. On Mon, May 2, 2022 at 8:22 PM Kurtis Rader wr

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

Makes sense. Thanks! On Wed, Apr 27, 2022 at 4:47 PM Ian Lance Taylor wrote: > On Wed, Apr 27, 2022 at 3:56 PM will@gmail.com > wrote: > > > > Do slices and maps have compatible type sets regarding the range > operator? > > > > I was trying to iterate through either, where slice keys are th

Re: [go-nuts] Do you check in vendor packages?

Kevin, Henrik: Thanks for replying! Have you ever had to check in very large dependencies? Would you still do it if just one dep added 30 MB to your 10 MB repo? What if the size of your code is dwarfed by the size of your deps 10:1? I'm curious how far people are willing to go to check in their d

[go-nuts] Do you check in vendor packages?

According to https://github.com/golang/dep/blob/master/docs/FAQ.md#should-i-commit-my-vendor-directory, the pros and cons are: Pros: - Only way to get truly reproducible builds - Don't need to `dep ensure` (or whatever your tool is) every time you check out or merge/pull Cons: - PR vendor d

[go-nuts] Re: bash completion for flag package

Can it complete subcommands? By the way, there's a small syntax error in the readme example: []string{"work", "dring} On Tuesday, May 23, 2017 at 12:21:07 PM UTC-7, Eyal Posener wrote: > > I recently did the complete package , > that enables bash completion

Re: [go-nuts] can i get goroutine`s id or have some local storage of a goroutine?

Can you wrap them in a struct and call them through a method? -- 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. For more

Re: [go-nuts] Zero value of the map

Yes, you're right, the receiver should be a pointer. What's bad about a double pointer dereference? Isn't that what, say, bytes.Buffer does, more or less, at least conceptually? On Thursday, April 20, 2017 at 1:22:56 AM UTC-7, Jan Mercl wrote: > > On Thu, Apr 20, 2017 a

[go-nuts] "Selling" Go to Management

If you're talking to middle management or higher, you might want to stay high-level. That being said, if technical arguments do actually help now, or might in the future, I listed some technical reasons and asked for others here: https://groups.google.com/forum/m/#!topic/golang-nuts/Fg1I34HrtqU

Re: [go-nuts] Zero value of the map

Why couldn't maps be implemented as a pointer to the map implementation? If you try to use the map and the pointer is nil, then the map allocates the backing implementation. Pseudocode for a built-in implementation: type map struct { impl *mapimpl } func (m map) set(k, v interface{}) { // u

Re: [go-nuts] Re: Algorithm Club

On Sat, Apr 1, 2017 at 12:11 AM, Egon Elbre wrote: > On Sat, Apr 1, 2017 at 1:42 AM, Will Faught wrote: > >> >>> For example []GenericElement could be boxed as: >>> >>> struct{ itab ptr; ... data []struct{elem ptr} } >>> or >>> []struct{

Re: [go-nuts] Re: Algorithm Club

ompared to using interface{} as is done now, boxing generics improves type safety and expressiveness and has no performance regression. That's a clear net win. On Wednesday, March 29, 2017 at 9:18:01 PM UTC-7, Egon wrote: > > On Thursday, 30 March 2017 03:15:33 UTC+3, Will Faught wrote:

Re: [go-nuts] Re: Algorithm Club

e the performance is too slow, one could always copy/paste the code and remove the generics from it. On Tue, Mar 28, 2017 at 12:28 AM, Egon wrote: > On Tuesday, 28 March 2017 07:56:57 UTC+3, Will Faught wrote: >> >> Something I've never seen addressed in the generics tradeoffs

[go-nuts] Re: Algorithm Club

Something I've never seen addressed in the generics tradeoffs debate (not saying it hasn't been, but I haven't see it personally) is that without generics, you're forced to use interface{}, which just boxes the values anyway. So you're already paying a performance cost for type-agnostic code wi

Re: [go-nuts] Algorithm Club

Generics is polymorphism, though; actually, it's a kind of polymorphism called parametric polymorphism. It's program behavior that doesn't depend on the types of the data it uses. It's useful for algorithms for types that contain variable types. There are numerous slice, map, and chan utility f

[go-nuts] Re: Arguments for writing fast, high-load servers in Go instead of Scala?

tion, not class inheritance; avoids complex type hierarchies - Built-in equality/comparisons and hashing - Simple package model for encapsulation and distribution/use - Unit tests for service interfaces can double as integration tests On Friday, February 17, 2017 at 10:55:37 PM UTC-8, Will Faught wr

Re: [go-nuts] Re: Arguments for writing fast, high-load servers in Go instead of Scala?

> to run into cases where I made s silly mistake and then the rest of the > team would use that to say Go is terrible, when in fact it was just me > making a mistake/misusing a feature, etc. > > Hope that helps. > > Diego > > > > On Saturday, February 18, 2017

[go-nuts] Arguments for writing fast, high-load servers in Go instead of Scala?

I want to make the case to a software architect where I work that we should write some fast, high-load servers we need in Go rather than Scala. What pragmatic arguments should I use? Note that the architect isn't against ever using Go; the question is whether to use Go now, for these servers in

Re: [go-nuts] Re: go/types.Typ is a slice-of-pointer-to-struct yet uses map syntax

Ah, I forgot about that syntax. Thanks! On Wed, Feb 15, 2017 at 11:31 AM wrote: > Invalid, Bool, Int, Int8 there are const integers, and they are specifying > the entry's position in the slice, allowing gaps in the list to be > implicitly defined. > > See this example: https://play.golang.org/p/

[go-nuts] go/types.Typ is a slice-of-pointer-to-struct yet uses map syntax

The go/types.Typ decl: var Typ = []*Basic{ Invalid: {Invalid, 0, "invalid type"}, Bool: {Bool, IsBoolean, "bool"}, Int: {Int, IsInteger, "int"}, Int8: {Int8, IsInteger, "int8"}, ... } Typ is a slice of pointer to Basic—got

[go-nuts] http://github.com/golang/protobuf has been broken for like 2 months?

Have you tried go get -u path/... ? -- 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. For more options, visit https://grou

Re: [go-nuts] Short vs. long variable declarations

Variable shadowing is rarely, if ever, a problem for me too; but what about for newcomers? I think my copy/paste point stands, though; everyone has those problems, at least occasionally. On Fri, Jan 27, 2017 at 3:00 PM Tyler Compton wrote: > While theoretically, I agree with your argument again

Re: [go-nuts] Short vs. long variable declarations

This seems to be a discussion about short variable names. What's the connection? On Fri, Jan 27, 2017 at 10:58 AM Shawn Milochik wrote: > Here's a good discussion about it: > > https://groups.google.com/d/msg/golang-nuts/J9QeizedpuI/ECifbR0YGcsJ > > TL;DR: scope > > -- > You received this messag

[go-nuts] Short vs. long variable declarations

Which do you default to? I see a lot of code using short decls in most cases, and only using long decls with no initialization where the zero value is needed. It seems to me that long decls should be the default declaration used because short decls are context-sensitive. That is, you have no