Re: [go-nuts] Nillable basic types?

lifetime (from `interface{ int }` - does not allow arithmetic - to `int` - does allow arithmetic), which would create numerous problems for existing tooling, as it violates assumptions made by the `go/*` packages. On Wed, Mar 20, 2024 at 11:26 AM Mike Schinkel wrote: On Wednesday, March 20, 2024 a

Re: [go-nuts] Nillable basic types?

On Wednesday, March 20, 2024 at 5:47:00 AM UTC-4 Brian Candler wrote: If you change fundamental things like this in the language, then you'll suggesting turning Go into something that looks like Rust. In which case, you may as well just use Rust. Agreed. Which is why I was asking if using

Re: [go-nuts] Nillable basic types?

On Wednesday, March 20, 2024 at 5:31:08 AM UTC-4 Brian Candler wrote: It's in the very first post that opened this thread, under the heading "## Summary". I did in-fact miss it. Thank you for pointing to it. -Mike -- You received this message because you are subscribed to the Google

Re: [go-nuts] Nillable basic types?

lars. Or maybe I misread? Maybe the best thing to do is let him tell us what he was thinking? -Mike On Wednesday 20 March 2024 at 07:34:10 UTC Mike Schinkel wrote: On Mar 19, 2024, at 2:43 PM, Daniel Lepage wrote: I'm not proposing that *any* value be made nillable, I'm proposing the

Re: [go-nuts] Nillable basic types?

> On Mar 19, 2024, at 2:43 PM, Daniel Lepage wrote: > > I'm not proposing that *any* value be made nillable, I'm proposing the > explicit syntax > > var x uint8 | nil > > that would create a nillable uint8. A variable of type `byte` would still > only take up one byte; a variable of type

Re: [go-nuts] Why can't I use an interface which needs another interface inside of it

> On Mar 13, 2024, at 10:27 AM, Brian Hatfield wrote: > > Client.GetChild() must return GetChilder, not Child. Actually, Client.GetChild() must return b.GetDataer, not b.GetChilder, but the example is a mind bender so it was easy to get wrong. I only got it correct by testing the code and

Re: [go-nuts] How To Reduce Json Marshalling Time

On Saturday, March 9, 2024 at 10:16:12 AM UTC-5 Robert Engels wrote: When I went to the github site the OP linked it seemed to me the original question was not genuine and ... Since the OP of this thread did not link anything, I assume you by "OP" you are referring to my comments on the

Re: [go-nuts] How To Reduce Json Marshalling Time

On Saturday, March 9, 2024 at 12:16:51 AM UTC-5 Robert Engels wrote: My guess is that most applications are decoding 25gb json files with any regularity. Even transferring 25 GB over the fastest of networks takes 20 secs? So that reduces the cost to less than 10%??? How about rather than

Re: [go-nuts] How To Reduce Json Marshalling Time

in performance it is almost certainly > related to IO management concerns (buffering, window sizes, etc) > > Without detailed measurements along with how they were measured it’s hard > to know with any certainty- so this was a Large guess to help you know > where to look. > > On

Re: [go-nuts] How To Reduce Json Marshalling Time

y the description and > reference to the previous implementation I doubt that is the case here. > > On Mar 8, 2024, at 6:53 PM, Mike Schinkel wrote: > > Hi Pragya, > > > While Robert Engles is probably correct in identifying your bottleneck, if > it does turn out to be slow

Re: [go-nuts] How To Reduce Json Marshalling Time

Hi Pragya, While Robert Engles is probably correct in identifying your bottleneck, if it does turn out to be slow JSON parsing here are a few things you can look at . 1. You mention you have to use a map because of response keys not

Re: [go-nuts] Enums, Go1 and proposals

> On Mar 4, 2024, at 5:14 PM, Ian Lance Taylor wrote: >> P.S. Seems to me that #4 might be the simplest way forward as it would allow >> for creation of types that cannot be represented as their literal subtype >> value to pass as a parameter to a `func`, and it would not require any new >>

Re: [go-nuts] Enums, Go1 and proposals

> On Mar 4, 2024, at 12:18 PM, Jeremy French wrote: > > More, to prevent PrintMonth(14) which the function would have to check for > and either return an error or panic, since there is no meaningful output. ... > I was more just answering Mike Schinkel's question about why it would be >

Re: [go-nuts] Enums, Go1 and proposals

I have recently seen many are complaining about a lack of enums in Go. But while there are many ways in which I would like to see Go improved, enums barely even rank on my list of priorities. The majority of my experience prior to Go was with dynamic languages that did not have explicit

Re: [go-nuts] Ghost/indirect dependency on a custom package

Is there no `cmd/migrations/go.mod`? Have you not tried debugging with Delve? -Mike On Tuesday, February 20, 2024 at 5:29:19 AM UTC-5 Peter Bočan wrote: > That seems to work on the repo/go.mod level, if I am not mistaken. I would > need something finer on the binary/compilation unit level. >

Re: [go-nuts] Re: Trying to understand aversion to main package

Hi Jerry, On Wed, 2024-02-14 at 15:31 -0800, Jeremy French wrote: > I really think the testability issue is the biggest one. On Wednesday, February 14, 2024 at 7:37:11 PM UTC-5 Dan Kortschak wrote: With a Main() int, you can use e.g.

[go-nuts] Re: Trying to understand aversion to main package

I cannot speak for others but I can tell you why I keep my `main()` small: 1. I prefer to put as much logic into reusable packages as I can, and `main()` is not reusable outside the current app. 2. CLI packages like Viper are configured to be invoked with just one or a few small commands in

Re: [go-nuts] Is there a way to cast interface to embedded type?

> On Feb 9, 2024, at 3:37 PM, Christopher C > wrote: > > I have a base struct that implements an interface. There are multiple other > structs that embed this base struct. I would like to pass the an interface > into a function that can cast it as the base struct and call some functions >

[go-nuts] Re: Blog Article: Go Generics (and also mocking)

On Sunday, January 7, 2024 at 9:39:31 PM UTC-5 Corin Lawson wrote: *also thoughts on the mock lib (apologies for the lack of naming creativity),* On Monday, January 8, 2024 at 9:00:24 AM UTC-5 TheDiveO wrote: *As for the naming: kudos for naming it what it is, clear and concise* A

Re: [go-nuts] Type parameter embedded field

On Saturday, January 6, 2024 at 7:58:55 AM UTC-5 Axel Wagner wrote: I took this idea into account in my original message. It is bullet point 2. The case against this is that it would likely make type-checking Go code (co-)NP-complete. If you watch my talk about methods in union elements

Re: [go-nuts] Type parameter embedded field

On Friday, January 5, 2024 at 9:12:13 AM UTC-5 Axel Wagner wrote: If the signature of a function says you are allowed to call the function, you should be allowed to call the function. While I'd argue we would be best to stick to objective arguments and not ones that affirm the consequent,

Re: [go-nuts] Type parameter embedded field

On Friday, January 5, 2024 at 12:59:25 AM UTC-5 Axel Wagner wrote: 3. Someone comes up with a clever new compromise. Here is a strawman proposal: Allow `Nullable`: type Nullable[T any] struct { T valid bool } By generating a compile error when a developer attempts to use a type as a

Re: [go-nuts] Is "When in doubt, use a pointer receiver" misleading advice?

On Thursday, November 16, 2023 at 9:16:22 AM UTC-5 Victor Giordano wrote: Lads, I guess this entry and the subsequent entries are very important regarding the discussion. *Also we shall recall that T and *T are different types. * *Golang performs some implicit

Re: [go-nuts] Is "When in doubt, use a pointer receiver" misleading advice?

> On Nov 15, 2023, at 7:08 AM, 'Brian Candler' via golang-nuts > wrote: > > On Tuesday, 14 November 2023 at 03:38:04 UTC Mike Schinkel wrote: > 1. A value variable and multiple value receivers <--- compiles > 2. A pointer variable and multiple value receivers <---

Re: [go-nuts] Re: Is "When in doubt, use a pointer receiver" misleading advice?

On Tuesday, November 14, 2023 at 6:16:58 PM UTC-5 burak serdar wrote: It is a data race because calling rpc.version() makes a copy of rpc, which causes reading the field rpc.result concurrently while it is being written by the goroutine. Thank you for explaining. I think I am starting to see

Re: [go-nuts] Re: Is "When in doubt, use a pointer receiver" misleading advice?

On Monday, November 13, 2023 at 11:28:00 PM UTC-5 Dan Kortschak wrote: https://dave.cheney.net/2015/11/18/wednesday-pop-quiz-spot-the-race Thanks for that link. However, after studying it for well more than an hour I cannot figure out why it is a data race, and unfortunately Dave Cheney

[go-nuts] Re: Is "When in doubt, use a pointer receiver" misleading advice?

That's a really good question, IMO. I have been wondering for a while why the advice against mixing pointer and value receivers, which GoLang so often flags me for doing. Ideally I think that I would like to be able use value receivers most of the time when I want the method to leave the

Re: [go-nuts] Re: I think in Golang， Array， Slice， and Map ， all of them are very difficult to use。

Hi Vicktoriia, Go has reflection: https://pkg.go.dev/reflect And in its various packages it also has many (though not all) of the types of functions mentioned above that PHP has: - https://pkg.go.dev/slices & https://pkg.go.dev/golang.org/x/exp/slices - https://pkg.go.dev/maps &

[go-nuts] Re: Any option to substitute plug-in package ?

Oops! Meant to say *“Using Lua to develop plugins in Go would NOT be ideal IMO.”* On Saturday, October 28, 2023 at 10:47:56 PM UTC-4 Mike Schinkel wrote: > I recently started using github.com/yuin/gopher-lua for a project to > allow users to add filtering criteria that would be

[go-nuts] Re: Any option to substitute plug-in package ?

I recently started using github.com/yuin/gopher-lua for a project to allow users to add filtering criteria that would be highly-specific to a user, but I would never consider using it for implementing a general-purpose plugin. Using Lua to develop plugins in Go would be ideal IMO. It is not

Re: [go-nuts] Can Generics match implementers of an interface?

ode should work with Go toolchain 1.21.n. >> >> >> Aha, it actually doesn't. I'm surprised. >> >> >> On Sunday, October 22, 2023 at 4:40:55 PM UTC+8 Mike Schinkel wrote: >> >> How so? >> >> Can you give an example scenario where it c

Re: [go-nuts] Can Generics match implementers of an interface?

.com wrote: > On Monday, October 23, 2023 at 10:38:59 AM UTC+8 tapi...@gmail.com wrote: > > Sorry, I didn't look your full code. > I think the full code should work with Go toolchain 1.21.n. > > > Aha, it actually doesn't. I'm surprised. > > > On Sunday, October 22, 2023 at 4:40:

Re: [go-nuts] Can Generics match implementers of an interface?

How so? Can you give an example scenario where it could cause unintended consequences? Or some other negative? -Mike On Saturday, October 21, 2023 at 11:57:52 PM UTC-4 tapi...@gmail.com wrote: It is hard to call such type inference better. That is too aggressive. -- You received this

Re: [go-nuts] Can Generics match implementers of an interface?

ot; in https://github.com/golang/go/issues/58650 > Until then, it's expected that there will be some cases where you need to > specify the types. > > On Sat, Oct 21, 2023 at 9:45 PM Mike Schinkel > wrote: > >> No, that pre-generics case is not sufficient for my use-case.

Re: [go-nuts] Can Generics match implementers of an interface?

See full code in playground <https://goplay.tools/snippet/FwSn1BaWg7k>. On Saturday, October 21, 2023 at 3:15:03 PM UTC-4 Dan Kortschak wrote: > On Sat, 2023-10-21 at 11:58 -0700, Mike Schinkel wrote: > > Recently I was trying to write a func using generics where I wanted > >

[go-nuts] Can Generics match implementers of an interface?

Recently I was trying to write a func using generics where I wanted to use a slice of an interface that would contain implementers of that interface and then pass those types to a generic function, but I ran into this error: type MyStruct of MySlice{} does not match inferred type MyInterface

Re: [go-nuts] Re: Recommended way to distribute pre-compiled C-dependencies for modules using CGO ?

Hi Jan, I'm going to go out on a limb here and suggest looking at using Go's `embed` feature? https://blog.jetbrains.com/go/2021/06/09/how-to-use-go-embed-in-go-1-16/ I have not tried it with C libraries so there may be numerous reasons why it may not work for your needs. For example, I do

[go-nuts] Re: [slog] customize defaultHandler

Hi Tamás, Have you actually tried that and gotten it to work? It does not compile for me but this does (note method call vs. property reference): slog.SetDefault(slog.New(myHandler{Handler:slog.Default().Handler()})) However, when delegating the Handle() method it seems to cause an infinite

Re: [go-nuts] Reason for "goto jumps over declaration" being disallowed

2023, at 10:51 PM, Kurtis Rader wrote: > > On Sat, Aug 26, 2023 at 6:02 PM Mike Schinkel <mailto:m...@newclarity.net>> wrote: > OTOH, in my quest to provide the simplest example I could, I provided an > example that does not expose the use-case I was interested in exploring,

Re: [go-nuts] Reason for "goto jumps over declaration" being disallowed

nk you. -Mike > On Aug 26, 2023, at 7:00 PM, Ian Lance Taylor wrote: > > On Sat, Aug 26, 2023 at 2:11 PM Mike Schinkel wrote: >> >> Question about disallowing `goto ` jumping over a variable >> declaration? >> >> >> And please, before bikes

[go-nuts] Reason for "goto jumps over declaration" being disallowed

Hi All, Question about disallowing `goto ` jumping over a variable declaration? And please, before bikeshedding opinions about the use of `goto` pro or con — note that the Go standard library uses `goto` in some places — this question is purely for me to gain better understanding the choices

[go-nuts] Re: Best IDE for GO ?

her than emacs, but this is a fundament thing, > that I cannot give up. > > On Friday, August 25, 2023 at 6:21:35 PM UTC+1 Mike Schinkel wrote: > >> Yes, as Luke Crook mentioned I think those requirements are more ALM >> functionality than IDE functionality. >> >> Ge

[go-nuts] Re: Best IDE for GO ?

assembled and installed there and > the tests are successfully passed again. > > Question: is there any IDE or plugin which one support that kind of > dependencies in a graphical mode ? > > Thank you. > > вторник, 22 августа 2023 г. в 18:22:52 UTC+3, Mike Schinkel:

[go-nuts] Re: Best IDE for GO ?

On Saturday, August 19, 2023 at 5:27:34 AM UTC-4 alex-coder wrote: What I'm looking for is the ability to manage dependencies not only in code, but entirely in a project from requirements to deployment. I assume you mean a lot more than just Go package dependencies, as `go mod` handles those

Re: [go-nuts] [RFC] Yet another proposal for Go2 error handling

e conventional try-catch-finally has its own problems. I > appreciate the Go Team's restraint in this matter. > > On Monday, July 3, 2023 at 9:42:02 AM UTC+7 Mike Schinkel wrote: > >> On Wednesday, June 28, 2023 at 1:30:41 PM UTC-4 Sven Anderson wrote: >> >> I think for

Re: [go-nuts] [RFC] Yet another proposal for Go2 error handling

On Wednesday, June 28, 2023 at 1:30:41 PM UTC-4 Sven Anderson wrote: I think for what you want to do you don't need any language extension. On Sunday, July 2, 2023 at 2:04:29 PM UTC-4 Harri L wrote: *The sample block below is what we can have without any language updates.* Many times when

Re: [go-nuts] [RFC] Yet another proposal for Go2 error handling

own proposals that present new ideas before their benefits can be fully understood I have been trying to find a way to introduce the idea without it falling victim to that fate. On Saturday, July 1, 2023 at 8:42:14 AM UTC-4 Sven Anderson wrote: Mike Schinkel <...> schrieb am Fr. 30. Juni 2

Re: [go-nuts] [RFC] Yet another proposal for Go2 error handling

There are many aspects of this proposal that I really like, and a few that I think need to be reconsidered. In general I like that it: 1. Does not try to handle errors *above *where the errors occurred, which is the pattern when using both *defer* and *recover(). *I personally find

Re: [go-nuts] please continue High Sierra mac OSX support

Hi Ian, I too would like to see support for High Sierra continue. Here is some additional information to support the hardware argument. Currently on eBay there are over 300 Mac Minis from mid 2010 and mid 2011 and a quick eyeball makes it seem like they can be had for less than US$100. (And

Re: [go-nuts] Help Bootstrapping to ESXi

> On Jan 13, 2023, at 1:32 AM, Anthony Brown wrote: > > I haven't made a bootstrapped Go toolchain so I can't help with that but I > can provide the following information: > > ESXi knows how to run ELF binaries, the interesting part then becomes what > architecture of CPU do you have the

[go-nuts] Re: Help Bootstrapping to ESXi

Is your ESXi server not running an Intel x86 processor? That is what the article is about. Also, what OS is your guest VM running? -Mike On Monday, January 9, 2023 at 4:20:15 PM UTC-5 brett@gmail.com wrote: > Good afternoon, hoping to get a little help. > > I am trying to build a

Re: [go-nuts] Idea for a language addition for error handling: inject/eject

Hi G., It takes guts to make a proposal in the Go community. Kudos for doing so. However, the issue with this proposal for me is the issue I have with almost(?) every other proposal to handle errors in Go differently from what Go currently allows. They all make the assumption that as soon as

Re: [go-nuts] Preemptive interfaces in Go

On Tuesday, August 9, 2022 at 3:52:13 PM UTC-4 t...@timpeoples.com wrote: > I've come to learn that my new shop is ... utilizing ... a complete > dependency injection framework and rather strict adherence to *Clean > Architecture*™ >

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

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

Re: [go-nuts] Generics and parentheses

Hi Russ, In general, I think the proposal is a really good one. I like that you abandoned contracts as interfaces were just too similar, and personally I like the choice of square brackets. There are a few aspects I do not like — 1.) no zero value and 2.) lack of covariance and

[go-nuts] Re: Generics and parentheses

JMTCW: I think using square brackets [...] instead of parenthesis (...) is a good decision. And as someone whose programming experience has not been in C++ or Java, I always found angle brackets for generics to be rather confusing but do not find square brackets as confusing. So in my

[go-nuts] Re: Do Any Editors Support Customisable Code collapsing?

> > Are there any editors that support some kind of customisable collapsing > behaviour? Where the above code could be collapsed to something like: > Might be worth reading, commenting on and/or possibly upvoting this feature proposal for GoLand? https://youtrack.jetbrains.com/issue/GO-7747

Re: [go-nuts] Go if else syntax .. suggested replacement

> As language choice becomes more arbitrary, and transpilers more common, > personal preferred syntax / language features may end up being handled like > code formatting rules. So In Peter++ I could then use all the syntax I like, > transpile that to WASM or LLVM, and someone else working on

Re: [go-nuts] Go if else syntax .. suggested replacement

I was assuming the compiler did not eliminate it. If it does then my point is moot. -Mike Sent from my iPad > On Apr 26, 2019, at 9:13 AM, Ian Lance Taylor wrote: > >> On Thu, Apr 25, 2019 at 10:57 PM Mike Schinkel wrote: >> >> Marcus Low wrote: >>&

Re: [go-nuts] Go if else syntax .. suggested replacement

> David Riley wrote: > same potential for abuse (no one is gonna stop you from nesting expressions). Yes, but only assuming it were implemented as an expression. However, if it were instead implemented as an “if-assignment" statement? result := if temperature > 80 then "red" else

Re: [go-nuts] Go if else syntax .. suggested replacement

On Thursday, April 25, 2019 at 10:20:54 AM UTC-4, Sam Whited wrote: > > On Wed, Apr 24, 2019, at 14:08, Mark Volkmann wrote: > > Are there really developers that find this unreadable? > > > > color := temperature > 80 ? “red” : “green” > > Yes. > > What is "?"? If I've never seen that before

Re: [go-nuts] Go if else syntax .. suggested replacement

Marcus Low wrote: > > datalen := removedKeyken // removedKeyken must have been int32 in your > example. > if value != nil { >datalen = len(value) > } > The issue with this is it makes two assignments when value != nil instead of just one. -- You received this message because you are

Re: [go-nuts] Re: Vue-inspired library with Go+WebAssembly

ah, it's different. But it would certainly be cool to have a solution that > provides an Electron-like shell around a Vugu application. I'll make an > issue for it so it's noted for later. > > On Friday, March 29, 2019 at 9:12:31 PM UTC-7, Mike Schinkel wrote: > Oops. I think I

[go-nuts] Re: Vue-inspired library with Go+WebAssembly

Hi Brad, This sounds *very* interesting. We are currently building a product using Lorca ( https://github.com/zserge/lorca) but am worried that it is not mature and may never be, and that Chrome could change and disable to features that make it possible at any time. What are your plans for

[go-nuts] Re: Vue-inspired library with Go+WebAssembly

Oops. I think I spoke to soon. I don't think what you have is an alternative to Lorca, but an alternative to Vue.js *(which might still be interesting.)* *Whoever is moderating **if you see this in time **please just delete both messages.* On Friday, March 29, 2019 at 12:39:42 AM UTC-4, Brad