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

> On Feb 6, 2025, at 1:55 PM, 'Sean Liao' via golang-nuts > wrote: > > a delete in the control of the module author would make it worse, as you can > serve malicious modules for a while, then delete and hide it, making it > unsuitable, unlike the current situation. > > - Sean Yes. Immediate

Re: [go-nuts] Best Practices for Error Handling in Go APIs

Hi Uzondo, Thanks for the comments. > On Feb 5, 2025, at 3:44 PM, Uzondu Enudeme wrote: > On the naming I also thought TraceError could be called StackError so that > NewStackError would return *StackError. > Maybe we can just rename it to be NewTraceError() since it returns > *TraceError.

Re: [go-nuts] Best Practices for Error Handling in Go APIs

> On Feb 4, 2025, at 4:59 PM, Darren Grant wrote: > > What's the current best practice for getting a stack trace from an error > passed up from further down in the stack? > > E.g. a web server middleware uses recover to catch panics. In the recover, we > want the stack trace of the code that c

Re: [go-nuts] Best Practices for Error Handling in Go APIs

> On Feb 3, 2025, at 6:01 AM, Byungjun You wrote: > In Java, checked exceptions allow developers to define in advance which > exceptions a function can throw. However, it seems that Go does not have such > a feature. Would it be considered a best practice in Go to document the > possible errors

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

> On Feb 2, 2025, at 1:20 AM, will@gmail.com wrote: > > To be clear, I mean see a listing of all the packages in the stdlib, or at > least the root package directories. > If per-chance you use JetBrain's Goland then you can view all of Go's standard library packages in the project's file

Re: [go-nuts] PDF to text

Hi Hugh, I have been planning to do some Go work with PDF files, so your email triggered me to do some research. Not sure it using heussd/pdftotext-go is critical to you, or if you are just trying to read text in a PDF? I tried to get pdf2text installed but my dev laptop is still running macO

Re: [go-nuts] Allow relaxed type casting on more general assignments?

> On Jan 15, 2025, at 2:38 AM, 'Dan Kortschak' via golang-nuts > wrote: > > On Wed, 2025-01-15 at 02:33 -0500, Mike Schinkel wrote: >> When you say compatibility, what would be a use-case where existing >> code would break? Something related to using r

Re: [go-nuts] Allow relaxed type casting on more general assignments?

> On Jan 15, 2025, at 12:05 AM, Ian Lance Taylor wrote: > > On Tue, Jan 14, 2025 at 8:10 PM Mike Schinkel wrote: >> >> P.S. If I instead asked that all funcs in the standard library accepting >> strings be converted to use that generic signature, I assume that wou

Re: [go-nuts] Allow relaxed type casting on more general assignments?

> On Jan 14, 2025, at 8:06 PM, Ian Lance Taylor wrote: > > On Tue, Jan 14, 2025 at 4:19 PM Mike Schinkel wrote: >> >> Given this I am now pondering why it would not be possible and acceptable it >> Go could allow relaxing of the need to type cast — on an opt-in ba

[go-nuts] Allow relaxed type casting on more general assignments?

Hi all, I have been wondering about the following for quite a while. In Go when assigning or passing values we all know we need to type-cast between two values whose types are derived from the same base type, and I assume most (all?) of us view that as good software engineering. For example:

Re: [go-nuts] Golang ORM Performances

> On Jan 8, 2025, at 11:56 PM, Henry wrote: > > I am not aware of any SQL wrapper in Go, but then I didn't look hard enough. > At work, we implemented our own SQL wrapper for a few databases we commonly > work with. In .Net, you have LINQ, but LINQ is a query-only language. But the > idea is t

Re: [go-nuts] Golang ORM Performances

> On Jan 8, 2025, at 1:38 AM, Henry wrote: > > The reason people use ORMs is because they don't want to write SQL. ... A > thin wrapper over SQL language that is portable across databases is a better > solution. That is insightful. Do you know of such an existing solution that meets said re

Re: [go-nuts] Strip HTML comments before processing template

If it stripped HTML comments then it would not be possible to generate output that contains wanted comments. Not all generated code is destined to be delivered to a renderer. Some might be targeting developers who need to modify it manually and for whom comments would be desired, i

Re: [go-nuts] Is it necessary to change the behavior of maps.Keys and maps.Values?

> On Dec 29, 2024, at 5:11 PM, Axel Wagner > wrote: > > Why don't I use the sequence versions more frequently? Because I try not to > create huge in-memory maps and instead prefer to move logic that manipulates > large amounts of data into a proper database. > > Iterators are more efficient

Re: [go-nuts] Is it necessary to change the behavior of maps.Keys and maps.Values?

> On Dec 29, 2024, at 1:38 AM, Amnon wrote: > > A nice thing about Go is that it is easy on the eye. Names are short, and > easy to read. When you look at Go code, you are not faced with a wall of > black text. The signal to noise ratio is high. Variable and function names > general convey wha

Re: [go-nuts] Is it necessary to change the behavior of maps.Keys and maps.Values?

> On Dec 29, 2024, at 1:28 AM, Axel Wagner > wrote: > > At the end of the day, it's purely a question of what you think would be more > frequently used. That should get the better name. `Values` (as is) composes > naturally with `slices.Collect` and so you get both in one function and it > s

Re: [go-nuts] Is it necessary to change the behavior of maps.Keys and maps.Values?

> On Dec 28, 2024, at 2:41 PM, Amnon wrote: > > There are big advantages in maps.Keys and maps.Values returning iterators. > It allows us to iterate very big maps without having to allocate vast amounts > of memory. I definitely agree there is a big advantage to have functions in the standard

Re: [go-nuts] Golang ORM Performances

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 Candle

Re: [go-nuts] Where should I define the errors in a Go project?

> On Dec 2, 2024, at 10:03 PM, JUAN DIEGO LATORRE RAMIREZ > wrote: > > I am trying to standardize an architecture for my Go projects, so I have a > file structure like this: > > ├── go.mod > ├── go.sum > ├── internal > │ ├── domain > │ │ ├── models > │ │ │ └

Re: [go-nuts] Suppress GoFmt-generated error with/tools.go?

> On Sep 2, 2024, at 8:40 PM, Ian Lance Taylor wrote: > > On Sun, Sep 1, 2024 at 1:08 AM Mike Schinkel wrote: >> >> Ian — if you are reading this — does this rise enough to the level of a bug >> — checking imports on a `go fmt` — that I should submit as an issue

Re: [go-nuts] Suppress GoFmt-generated error with/tools.go?

> On Aug 31, 2024, at 9:45 AM, Axel Wagner > wrote: > > On Sat, 31 Aug 2024 at 14:22, Mike Schinkel <mailto:m...@newclarity.net>> wrote: > Hi Alex & Peter, > > Thank you both for your replies. > >> On Aug 30, 2024, at 2:43 AM, Axel Wagner > <m

Re: [go-nuts] Suppress GoFmt-generated error with/tools.go?

> On Aug 31, 2024, at 8:29 AM, Jan Mercl <0xj...@gmail.com> wrote: > > On Sat, Aug 31, 2024 at 2:22 PM Mike Schinkel wrote: > >> go fmt ./tools.go > > 'go fmt' is not gofmt. They are different? Well that is positively confusing. Thank you for po

Re: [go-nuts] Suppress GoFmt-generated error with/tools.go?

Hi Alex & Peter, Thank you both for your replies. > On Aug 30, 2024, at 2:43 AM, Axel Wagner > wrote: > I don't think that error message comes from gofmt. As far as I am aware, > gofmt only parses source code, it does not even do type-checking. As you sure about that? Running this: go fmt .

[go-nuts] Suppress GoFmt-generated error with/tools.go?

Hi all, I think I already know the answer, but hoping there is a way I am missing to get gofmt to stop generating the "import in a program, not an importable package" error when parsing a `tools.go` file with the `tools` build tag. If you are not familiar, there is an approach several people ha

Re: [go-nuts] Advice on Using Pure Go with eBPF

I for one would really like to see Go or TinyGo find a way to target eBPF similar to how it can target WASM. -Mike > On Aug 14, 2024, at 4:40 PM, twp...@gmail.com wrote: > > For eBPF support in Go, see https://github.com/cilium/ebpf. > > AFAIK at the moment you can't compile Go to eBPF. The

Re: [go-nuts] How does bytealg.MakeNoZero() work?

> On Jun 26, 2024, at 2:46 AM, Axel Wagner > wrote: > > It is defined in the runtime and go:linkname'd into the bytealg package: > https://github.com/golang/go/blob/90bcc552c0347948166817a602f612f219bc980c/src/runtime/slice.go#L394 > >

[go-nuts] How does bytealg.MakeNoZero() work?

Can someone help me understand how `bytealg.MakeNoZero()` in the Go standard library works, please? https://github.com/golang/go/blob/master/src/internal/bytealg/bytealg.go#L118 In the source it is a `func` without

Re: [go-nuts] Nillable basic types?

e over its 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

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 int

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 Grou

Re: [go-nuts] Nillable basic types?

uot;unset"* state for scalars. 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 m

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 `byt

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 fai

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 thread

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 guess

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

table difference 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

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

t by 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

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 be

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 >> key

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 > usefu

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 enums,

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. https://pkg.go.dev/github.com/rogpeppe/go-internal/tests

[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 `ma

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 > ti

[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 different

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, I'll

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 parame

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 conv

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 receive

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 it

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 didn

[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 state

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 & https://

[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 p

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

e. >> 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:55 PM UTC+8 Mike Schinkel wrote: >> >> How so? >> >> Can yo

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

ote: > 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

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 mess

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-

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 for

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 not

[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 loop

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

-Mike > On Aug 26, 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

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 ma

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

IDE other 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. >&

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

tion is 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 Schi

[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

en the 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

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 pe

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

oot down 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. J

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 ha

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 th

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 ESXi

[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 bootst

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 a

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 yo

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 contravariance

[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 mind,

[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 tha

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 "green"

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 I

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

Andrew Klager wrote: > > Is this so bad? > > func ternary(cond bool, pos, neg interface{}) interface{} { > if cond { > return pos > } else { > return neg > } > } > > color := ternary( temp < 80, "blue", "red" ) > The issue with that proposal is both true and false expressions are always e

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 subsc

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

; > Yeah, 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 wro

[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 i

[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 w