Re: [go-nuts] Re: Why we don't have simple throws error statement

I do not consider error handling an issue but then again I tend to either use the Doit() err{} or MustDoit(){} panic and then use DI (dependency injection implemented by interface) for error-handling so that I can get an email when we get a new error. So then it would be MustDoit(errorHandler(

Re: [go-nuts] Is it possible to build without TLS (thread local storage)?

On Sat, Aug 1, 2020 at 2:46 PM wrote: > > You're right - after re-reading this I realize I could have been more > specific. > > I am working with a custom OS kernel that supports a subset of Linux > syscalls. However, it does not support TLS, which on i386 I believe typically > requires OS supp

Re: [go-nuts] Is a variation on Templates a better way for Generics?

On Sat, Aug 1, 2020 at 1:41 PM Kevin Chadwick wrote: > > On 2020-08-01 18:34, Ian Lance Taylor wrote: > > Personally, when it comes to interpretation by the reader, I think > > that the new generic syntax in the design draft is fairly minor. I > > don't see how a template based approach will be a

[go-nuts] Re: [ANN] scheduler microservice

Congrats, it looks very well structured. On Saturday, August 1, 2020 at 2:43:51 PM UTC-3, Andriy Kornatskyy wrote: > > Hi folks! Here is release of scheduler microservice [1], written in go and > nodejs. > > The scheduler is a fully managed cron job scheduler. It allows you to > schedule virtual

Re: [go-nuts] Is it possible to build without TLS (thread local storage)?

Hi Jan, You're right - after re-reading this I realize I could have been more specific. I am working with a custom OS kernel that supports a subset of Linux syscalls. However, it does not support TLS, which on i386 I believe typically requires OS support to set up and restore the GDT and %gs s

Re: [go-nuts] Is a variation on Templates a better way for Generics?

On 2020-08-01 18:34, Ian Lance Taylor wrote: > Personally, when it comes to interpretation by the reader, I think > that the new generic syntax in the design draft is fairly minor. I > don't see how a template based approach will be any clearer; it won't > be less clear, but I don't see why it wil

Re: [go-nuts] Is a variation on Templates a better way for Generics?

On Sat, Aug 1, 2020 at 11:32 AM Kevin Chadwick wrote: > > On 2020-08-01 18:20, Ian Lance Taylor wrote: > >> I'm wondering. Would it be better to have say a template in a folder that > >> is > >> used to generate all the various typed Golang ready for the compiler. > >> > >> This way the code woul

Re: [go-nuts] Is a variation on Templates a better way for Generics?

On 2020-08-01 18:20, Ian Lance Taylor wrote: >> I'm wondering. Would it be better to have say a template in a folder that is >> used to generate all the various typed Golang ready for the compiler. >> >> This way the code would be fully typed and could be maintained in one place. >> The >> compile

Re: [go-nuts] Re: Why we don't have simple throws error statement

On Sat, Aug 1, 2020 at 10:59 AM wrote: > > Has anyone ever tallied the number of different forum threads related to > changing Go error handling ? > The current method is obviously a vexing issue to many Go users, and > It seems silly that this issue has never been resolved by the Go team beyond

Re: [go-nuts] Type parameters on another line

On Sat, Aug 1, 2020 at 10:50 AM josvazg wrote: > > Let me know if this or something similar was already proposed and rejected > for some reason but otherwise... > > What if instead of trying to cram all into a single line we use a previous > line before the function or type definition explaining

Re: [go-nuts] Is it possible to build without TLS (thread local storage)?

Not sure I understand correctly, but TLS is usually provided on some level by the kernel of the specific OS. Another level is TLS as in, for example pthreads. The Go runtime probably uses one or the other additionally to goroutine local storage. Can you please clarify? On Sat, Aug 1, 2020, 20:08

Re: [go-nuts] Is a variation on Templates a better way for Generics?

On Sat, Aug 1, 2020 at 3:00 AM Kevin Chadwick wrote: > > I'm wondering. Would it be better to have say a template in a folder that is > used to generate all the various typed Golang ready for the compiler. > > This way the code would be fully typed and could be maintained in one place. > The > co

[go-nuts] Is it possible to build without TLS (thread local storage)?

Hi all, Is it possible to build pure Go (no cgo) programs targeting i386 without TLS support? From reviewing the compiler flags and the compiler build options it looks like this isn't possible, but I am hoping someone with knowledge on the matter can comment definitively. Thanks, Evan -- You

Re: [go-nuts] In the smippet herunder, are strings copied or passed by address (they seem copied, but maybe only the addresses are copied) ?

Thank you! On Saturday, 1 August 2020 19:48:50 UTC+2, Brian Candler wrote: > > In Go, everything is passed by value: that is, assignments and function > calls make a copy of the value. > > However, some types are effectively structs which contain pointers > embedded within them. Strings, slic

[go-nuts] Re: Why we don't have simple throws error statement

Has anyone ever tallied the number of different forum threads related to changing Go error handling ? The current method is obviously a vexing issue to many Go users, and It seems silly that this issue has never been resolved by the Go team beyond maintaining the status quo... despite, IMHO, se

[go-nuts] Type parameters on another line

Let me know if this or something similar was already proposed and rejected for some reason but otherwise... What if instead of trying to cram all into a single line we use a previous line before the function or type definition explaining how the type parameter aliases are to be interpreted. Lik

Re: [go-nuts] In the smippet herunder, are strings copied or passed by address (they seem copied, but maybe only the addresses are copied) ?

In Go, everything is passed by value: that is, assignments and function calls make a copy of the value. However, some types are effectively structs which contain pointers embedded within them. Strings, slices, maps, channels and interface values fall into this category. string is roughly equi

[go-nuts] [ANN] scheduler microservice

Hi folks! Here is release of scheduler microservice [1], written in go and nodejs. The scheduler is a fully managed cron job scheduler. It allows you to schedule virtually any job (e.g. such as calling HTTP/S endpoints). You can automate everything, including retries in case of failure, run job

Re: [go-nuts] In the smippet herunder, are strings copied or passed by address (they seem copied, but maybe only the addresses are copied) ?

Please post code as just text. Also, inverted color schemes are hard to read for some people. Wrt string copying, see https://research.swtch.com/godata to;dr Copying a string copies two machine words. On Sat, Aug 1, 2020, 16:49 Serge Hulne wrote: > ``` > package main > > import ( > "fmt" >

Re: [go-nuts] Non-alphanumerics in template field names?

You could use the "index" built-in function instead of the dot operator: {{index . "foo:bar"}} On Fri, 31 Jul 2020, 17:16 Bob DuCharme, wrote: > I have seen that a map key name of "foo:bar" works just fine... unless I > reference it in a template. {{.foo:bar}} gives me a segmentation violation

[go-nuts] Re: Why we don't have simple throws error statement

Your "throws" statement (why is it called "throws" when it "catches" according to the comment?) looks a lot like the "handle" block from the first draft design by the Go team: the check/handle proposal . On Friday

[go-nuts] In the smippet herunder, are strings copied or passed by address (they seem copied, but maybe only the addresses are copied) ?

``` package main import ( "fmt" ) func f(s *string) { a := "Hello" b := "Hello" c := "bye" d := a fmt.Printf("pa: %p\n", &a) fmt.Printf("pb: %b\n", &b) fmt.Printf("pc: %v\n", &c) fmt.Printf("pd: %v\n", &d) fmt.Printf("p(f(u)): %p\n", s) } func main() {

[go-nuts] Re: Why we don't have simple throws error statement

I think that's because no-one has been able to come up with a detailed, specific proposal where the end result is both simple and clear, when compared to the current situation. My idea, if it's worth anything, is to have Python-style post conditionals: return "", err if err != nil I expect it

[go-nuts] Re: Why we don't have simple throws error statement

I did not see clear and simple either. As I wrote, I don't like complex solutions. Just trying to ask: why we don't have simple solution. The function just simple example, this isn't a draft or something. On Friday, 31 July 2020 at 23:25:26 UTC+3 b.ca...@pobox.com wrote: > On Friday, 31 July 2

[go-nuts] Re: Is a variation on Templates a better way for Generics?

On 2020-08-01 10:29, Kevin Chadwick wrote: > I'm wondering. Would it be better to have say a template in a folder that is > used to generate all the various typed Golang ready for the compiler. > > This way the code would be fully typed and could be maintained in one place. > The > compiler could

[go-nuts] Is a variation on Templates a better way for Generics?

I'm wondering. Would it be better to have say a template in a folder that is used to generate all the various typed Golang ready for the compiler. This way the code would be fully typed and could be maintained in one place. The compiler could maybe still be as fast as today post generation and t