Re: [go-nuts] Nillable basic types?

[Mike Schinkel]

Hi Axel,

Thank you for that link. I had not seen it before, but it is rather 
insightful.

-Mike

On Wednesday, March 20, 2024 at 10:29:20 AM UTC-4 Axel Wagner wrote:

FWIW I believe (as Brian sort of points out) this proposal is fully 
subsumed under #57644 <https://github.com/golang/go/issues/57644>. Under 
that proposal, the proposed type `int | nil` would be spelled `interface{ 
int }`. The other syntactical constructs are, as far as I can tell, 
identical - you'd have to use a type-assertion to use an `interface{ int }` 
as an integer (e.g. to do arithmetic), you can use it with type-switches, 
and any `int` as well as `nil` would be assignable to it.

I think the one difference would be that `x == 42` would work on 
`interface{ int }`, but would (presumably) not work on `int | nil`. I 
personally doubt that this difference would justify an extra construction, 
but I'm mentioning it for completeness sake.

The "nice to have" of type guards is, I think, an easy idea to mention, but 
not an easy idea to add to Go. Note that the other languages mentioned, 
that do that, use a function-scoped type-inference (as far as I know) - 
that is, they look at an identifiers use over the entire function and then 
infer the most general type it would have.
Go has so far tried to avoid doing anything like that, limiting any 
inference to the statement (or expression) a value appears in. And this 
idea effectively means an identifier would change its type 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 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 interfaces as type constraints 
would address the concern.

And as discussed, probably not.  

But it is an interesting thought exercise. If an interface-based solution 
could be found, it would address the concern without turning us effectively 
into Rust programmers. ¯\_(ツ)_/¯ 

-Mike

-- 

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/b3cf8686-b0fb-4cdd-938e-deee4a6af273n%40googlegroups.com
 
<https://groups.google.com/d/msgid/golang-nuts/b3cf8686-b0fb-4cdd-938e-deee4a6af273n%40googlegroups.com?utm_medium=email_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/b13c0f3c-2f87-4270-bc57-a22c577473d9n%40googlegroups.com.

Re: [go-nuts] Nillable basic types?

[Mike Schinkel]

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 interfaces as type constraints 
would address the concern.

And as discussed, probably not.  

But it is an interesting thought exercise. If an interface-based solution 
could be found, it would address the concern without turning us effectively 
into Rust programmers. ¯\_(ツ)_/¯ 

-Mike

-- 
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/b3cf8686-b0fb-4cdd-938e-deee4a6af273n%40googlegroups.com.

Re: [go-nuts] Nillable basic types?

[Mike Schinkel]

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 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/7e807f38-97a2-4890-9a9b-bd0e535e481bn%40googlegroups.com.

Re: [go-nuts] Nillable basic types?

[Mike Schinkel]

On Wednesday, March 20, 2024 at 4:14:27 AM UTC-4 Brian Candler wrote:

When you say "var x NillableUint8" then you've just declared a variable of 
an interface type, and interface types are already nilable, so there's no 
need for "| nil" in the type!


Well, I was thinking  of 1.) explicitness of intent, and 2.) potentially a 
signal to the compiler for the use-case.  

But you probably have a point.
 

However, I don't think this meets the OP's  objective number 3:

> 3. It is a compile-time error to use a `T | nil` as a `T` without first 
checking that it is non-nil.


Hmm.  While I did not read the whole proposal at first, my initial takeaway 
was that his intent was more about allowing a way for a scalar value to 
have an invalid value so it would be possible to determine if a scalar had 
been set or not rather than being unsure if zero means *"It was set to 0"* 
vs *"It was never set and defaulted to 0."*

Your comments made me go back and read the whole thing, but I was unable to 
find a list of enumerated objectives, and I did not find the text you 
quoted.  Did I miss it somehow?

What I did see is his *"Nice to have"* section which talked about checking 
for non-nil.  Since he titled it *"nice to have"* I presume he did not 
consider that a primary objective of his proposal?

OTOH, even if it is an explicit call-out of `nil` in a type constraint 
*could* be the signal for the compiler to enforce that, if that was 
something the Go team agreed with that. Still, it is probably too obscure 
to be an appropriate signal. ¯\_(ツ)_/¯

Therefore I think the underlying request a completely different one: that 
you should never be able to use an interface (or a pointer or a channel, or 
insert into a map), without first checking that it's not nil, in a way that 
can be statically validated by the compiler. I'm sure that suggestion has 
come up before and been discussed to death - e.g. you end up with static 
types like "a pointer which can never be nil".


I definitely see there is an argument one could make for having the 
compiler guarantee against incorrectly using `nil`.  But I got the 
impression the proposal was motivated by scalars that did not currently 
allow `nil` values and not by reference types like pointers, channels and 
maps. Although he did not state that explicitly, his examples implied that 
to me.

For the compiler to guarantee that an `int` is properly set it needs as a 
prerequisite the potential for what it effectively a `nil` state. But 
ensuring against a misused `nil` feels to me to be orthogonal to first 
allowing an *"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 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 `byte | nil` would be larger. 
Existing code, which obviously doesn't use the `| nil` syntax because it 
doesn't exist yet, would be completely unaffected by this change.


Focusing the proposal like that was helpful, at least for me.  The original 
proposal? tldr; 

Question: Assuming the following was currently possible with type 
constraints, how would your proposal differ from the following?

type NillableUInt8 interface {

   uint8 | nil 

}

var x NillableUInt8


Also, if the above were possible in future Go, would that achieve the same 
objectives you are seeking, or not?  And if not, why not?

Finally, for the Go team, if that would be meet his objectives, would 
extending type constraints in this manner be a viable potential?


-Mike

-- 
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/66a9f1f6-a05d-4fed-b41d-5cfec262fb5bn%40googlegroups.com.

Re: [go-nuts] Nillable basic types?

[Mike Schinkel]

> 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 `byte | nil` would be larger. 
> Existing code, which obviously doesn't use the `| nil` syntax because it 
> doesn't exist yet, would be completely unaffected by this change.

Focusing the proposal like that was helpful, at least for me.  The original 
proposal? tldr; 

Question: Assuming the following was currently possible with type constraints, 
how would your proposal differ from the following?

type NillableUInt8 interface {
   uint8 | nil 
}
var x NillableUInt8

Also, if the above were possible in future Go, would that achieve the same 
objectives you are seeking, or not?  And if not, why not?

Finally, for the Go team, if that would be meet his objectives, would extending 
type constraints in this manner be a viable potential?

-Mike

-- 
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/3CC3FD1B-D591-4B21-AE7B-0D9E5C821F31%40newclarity.net.

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

[Mike Schinkel]

> 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 failing to get it right a few times.


> On Mar 13, 2024, at 12:59 PM, Rodrigo Araujo  
> wrote:
> 
> 'Cause this dependency makes code more "rigid". A refactor in an isolated 
> package would let to change other packages. Also makes testing more difficult.
> It is kind of described here: 
> https://go.dev/wiki/CodeReviewComments#interfaces 
> 

Besides that Jason Phillips already explained the reason what you've attempted 
doesn't work, consider that something needs be shared.  And in Go that 
something is often an interface. As stated though, interfaces in Go do not work 
with covariance types. #fwiw

Lastly, a suggestion on naming.  My understanding is that it would be more 
idiomatic to name `b.GetChilder` as `b.ChildGetter()` and `b.GetDataer` as 
`b.DataGetter()`; that certainly reads easier, at least to me. Again, #fwiw

-Mike

-- 
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/B6C0495B-74C4-4AEF-84C9-9C615DD52793%40newclarity.net.

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

[Mike Schinkel]

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?  

And from the fact that the original questioner is a different person than 
myself, how is it that you can conclude that her question was *"not 
genuine?"*  Do you have some kind of supernatural powers to discern her 
question? Or are you somehow implying sock-puppetry on my part here?!? 

Unbelievable.  
 

was rather asked to generate traffic to the site. 


*Are you f-ing serious?!?*  *WHAT* site are you saying the* "OP" (me?)* was 
trying to drive traffic to?!?

My original post on the thread included links to many sites, NONE of which 
I own, have control of, or gain any benefit from.  WHY would I be trying to 
drive traffic to those sites?

Or are you referring to my gist in follow up?  So I initially made the 
effort to research JSON unmarshalling and then write an in-depth answer — 
which started by saying *"Robert is probably right, but if it is JSON then 
consider this" —* *none* of which you had any critique for on its merits. 
Instead you passive-aggressively undermined my reply with your immediate *"just 
to be clear for others"* reply to my email that happened to ignore that I 
said your initial reply was probably the concern. And why? To assert 
dominance on this list?

Do you think I want to generate traffic to my gist?!?  That I would go 
through all the effort to write that detailed reply, expect someone would 
be a jerk, *then* plan to post a link to my gist to generate traffic? For 
what benefit would I get for sending traffic to a gist?!?  I use gists to 
*clearly* indicate to others that I get would *zero* benefit from traffic 
to the link. 

Make your accusations explicit if you are going to accuse.
 

Reading the content was more evidence the question was not genuine 


Again, the person asking the question was different than me *(or are you 
accusing otherwise?)*  So how the heck would* my* reply indicate that the 
original questioner's question was not genuine? * (Maybe it is not, I have 
no idea, but I assumed on face value that it was genuine. Would be a pretty 
sad world if we all assumed nefarious motives when there is zero evidence 
to indicate otherwise.)* What benefit would they get from asking it if it 
were not genuine? What specifically about their question indicates to you 
it was not genuine?

And what benefit would I get from answering her, other than to feel good 
about helping someone? *(Which, unfortunately, your replies have completely 
overwhelmed that tiny benefit.)*
 

states “I am doing unscientific testing for orders of magnitude”

 
Wat?!?  

I wanted to do a sanity check to make sure that PHP *json_decode()* was 
in-fact faster than Go *json.UnMarshal()* before commenting further, but as 
I have other things to do in my life so I did not want to devote days to an 
exhaustive, scientific benchmark, so I did some basic testing to get an 
understanding of if in fact the reason the OP was seeing a performance 
difference could be Go vs. PHP.  

And since I did not want you or someone else to say *"why didn't you show 
your work?"* I went ahead and put in the extra effort to publish my code 
and results. I wrote *“I am doing unscientific testing for orders of 
magnitude” in a *pro-active attempt to keep some jerk from having a *"Duty 
Calls "* moment and take me to task for by claiming *"my 
benchmark was not scientific."  *But clearly my proactive attempt to ward 
of specious criticism did not stop you from being that jerk. No good deed 
goes unpunished, it seems.

makes a big deal of a 14 second difference on 100 iterations


So presenting results is* "making a big deal?!?"  *Good to know, I guess.

And what exact results would rise to meet your bar for a* "big deal?"*
 

and was merely a article on a flawed micro benchmark. 


If the benchmark was so flawed, why don't you fix it then. I published all 
the work I did.

Rather than taking easy pot-shots like a jerk, why not do some work and 
present alternate numbers?  

Or better, just not criticize in a passive-aggressive manner anything you 
think is not up to your standards?
 

Lots of bold letters on the differences, etc. 


So now we are determining that if someone uses formatting to make their 
posts easier to scan — an approach to writing technical documents I have 
used for decades, as evidence from my former life 
 — that that 
somehow indicates they have *nefarious* intent?!?  Wow, you must really be 
fun at parties.
 

So yea, I was annoyed that I wasted my time posting trying to help on this. 


You were annoyed that you spent 3 minutes to shoot off an initial response 
that required no time to research or prepare?

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

[Mike Schinkel]

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 guessing, you let the OP consider the input you gave 
in your first reply — which I acknowledged was likely the issue in my first 
reply — and then move on?

This is either a troll post or by someone that needs more education in 
performance monitoring. Sorry. 


Everything beyond your first reply on this thread — except when you replied 
to my ask for clarification — was unnecessary as you had already made your 
only point.

If there was trolling here, your reply to my first reply on the thread was 
the start of that trolling.

-Mike

P.S. The types of replies you've made on this thread is why I always ask 
myself if it worth the pain to answer someone's questions. Rest assured I 
will think twice next time before going to the effort.

-- 
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/aa71ba9c-a2fe-4c81-aaa8-275662dff42dn%40googlegroups.com.

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

[Mike Schinkel]

Hi Robert,

Thanks for the reply.

I decided to run a quick benchmark so I compared Go 1.22's 
*json.UnMarshal(any)* using an *any* type with PHP 8.3.2's *json_decode()*
and found that PHP's option is 85% faster for a ~25Mb JSON file.  
Optimizing it with a *struct* I was able to get Go down to being only about 
25% slower than PHP's  *json_decode().*

Note that they are very rough benchmarks, probably only valid in gauging 
magnitude, not specific performance.

I wrote up the results and provided the code in *this gist* 
<https://gist.github.com/mikeschinkel/14106e1aaa2b66f05ccce73b1af336e1> for 
anyone who might be interested.  For me, the takeaway is that if you really 
need fast JSON unmarshalling you probably need to look to one of the 3rd 
party JSON parser packages.

Whether or not the extra time it takes Go to parse JSON vs. PHP is actually 
relevant for her use-case remains to be seen given the potential 
order-of-magnitude difference in web request latency.  Still, given that 
she seems to be controlling for that web request latency by comparing her 
PHP API to her Go API would indicate — sans issues like buffering or slow 
Go middleware — that the performance of JSON parsing made indeed by one of 
the reasons she is seeing a difference.

Pragya, it would be really nice if you could follow up to close the loop 
and let us know what the actual bottleneck was and how you ended up solving 
it.

-Mike

On Friday, March 8, 2024 at 9:58:26 PM UTC-5 Robert Engels wrote:

> Related, 30k of anything is largely meaningless for modern hardware in 
> terms of cpu processing - where billions of operations a second is the 
> norm. 
>
> On Mar 8, 2024, at 8:55 PM, Robert Engels  wrote:
>
> 
>
> The point I was trying to make - maybe unclear - is that it is doubtful 
> any raw performance differences between PHP and Go in terms of json 
> encoding/decoding would be noticeable- unless it was a hft/hpc system which 
> would be doubtful given that the original system was PHP. 
>
> So if there is detectable 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 look. 
>
> On Mar 8, 2024, at 8:33 PM, Mike Schinkel  wrote:
>
> Hi Robert,
>
> I am now confused.  While your original reply to this thread made perfect 
> sense to me, your follow up for the purposes of clarification had the 
> opposite effect, at least for me. I am not clear the point you are trying 
> to make.
>
> You mention the difference between compiled and interpreted and point out 
> that typically there is not a large performance difference — where I assume 
> you were referring to use of standard library functions in the interpreted 
> language such as *json_decode()* in PHP. That is of course often true and 
> I concur. *(Of course, try writing a full JSON parser in pure PHP and 
> we'll find a big difference in performance with a compiled language like 
> Go.) *
>
> But I am not seeing why that point is relevant in the thread because she 
> was not asking *"Why is PHP code slower than Go code?"* in which case I 
> would understand why you chose to make that distinction.
>
> You also mention that IO performance *(and design(?))* over the web is 
> typically much more relevant performance-wise, on which I also concur, but 
> given that both her PHP and her Go API endpoints presumably had much the 
> same web-based latency and response time concerns, I'm struggling to 
> understand why it was relevant to state it in this context.  Of course your 
> point simply could have been not using a buffered output stream,  but you 
> already mentioned, and your follow up did not make that connection clear.
>
> So, can you please help me better understand the point you were trying to 
> make?  As a follow up to my reply were you trying to imply that 
> illustrating ways to optimize JSON parsing was something you felt I should 
> not have posted in response to her question? That feels like in might have 
> been your intent, but I could certainly have misinterpreted and if so would 
> prefer to know rather than wrongly assume.
>
> -Mike
>
> On Friday, March 8, 2024 at 8:28:38 PM UTC-5 Robert Engels wrote:
>
>> Just to be clear for others - from a raw cpu performance perspective when 
>> looking at a typical application in whole - there is very little 
>> performance difference between compiled and even GC platforms- interpreted 
>> can lag behind a bit - but in almost all cases over the web it is IO 
>> performance/design that matters the most (most middleware connects to other 
>> middleware, etc). 
>&

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

[Mike Schinkel]

Hi Robert,

I am now confused.  While your original reply to this thread made perfect 
sense to me, your follow up for the purposes of clarification had the 
opposite effect, at least for me. I am not clear the point you are trying 
to make.

You mention the difference between compiled and interpreted and point out 
that typically there is not a large performance difference — where I assume 
you were referring to use of standard library functions in the interpreted 
language such as *json_decode()* in PHP. That is of course often true and I 
concur. *(Of course, try writing a full JSON parser in pure PHP and we'll 
find a big difference in performance with a compiled language like Go.) *

But I am not seeing why that point is relevant in the thread because she 
was not asking *"Why is PHP code slower than Go code?"* in which case I 
would understand why you chose to make that distinction.

You also mention that IO performance *(and design(?))* over the web is 
typically much more relevant performance-wise, on which I also concur, but 
given that both her PHP and her Go API endpoints presumably had much the 
same web-based latency and response time concerns, I'm struggling to 
understand why it was relevant to state it in this context.  Of course your 
point simply could have been not using a buffered output stream,  but you 
already mentioned, and your follow up did not make that connection clear.

So, can you please help me better understand the point you were trying to 
make?  As a follow up to my reply were you trying to imply that 
illustrating ways to optimize JSON parsing was something you felt I should 
not have posted in response to her question? That feels like in might have 
been your intent, but I could certainly have misinterpreted and if so would 
prefer to know rather than wrongly assume.

-Mike

On Friday, March 8, 2024 at 8:28:38 PM UTC-5 Robert Engels wrote:

> Just to be clear for others - from a raw cpu performance perspective when 
> looking at a typical application in whole - there is very little 
> performance difference between compiled and even GC platforms- interpreted 
> can lag behind a bit - but in almost all cases over the web it is IO 
> performance/design that matters the most (most middleware connects to other 
> middleware, etc). 
>
> Some HFT/HPC systems deviate from this but 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 to be slow JSON parsing here are a few things you can 
> look at <https://yalantis.com/blog/speed-up-json-encoding-decoding/>.
>
> 1. You mention you have to use a map because of response keys not being 
> fixed. Be aware that you *do not need to 
> <https://stackoverflow.com/a/33222371/102699>* create a struct to match 
> the full JSON. You can easily just create a flyweight struct which is a 
> subset if for your use-case containing only the specific parts you need, *for 
> example* <https://goplay.tools/snippet/c5qV5MfwAb->.  
>
> 2. If you optionally need to parse portions of the JSON, but not always, 
> you can use *json.RawMessage* 
> <https://stackoverflow.com/a/52250578/102699> to capture the properties 
> you don't always need to parse, and then *parse them only when you need 
> to <https://stackoverflow.com/a/23256630/102699>*.
>
> 3. You can also declare an *.UnmarshalJSON()* method on a struct you are 
> passing to *json.Unmarshal()*, or on any struct that is a property of 
> your top level object, and then be *fully in control of parsing the data* 
> <https://stackoverflow.com/a/65275814/102699>, meaning you could combine 
> with (a) *json.RawMessage* property(s) to part just the non-fixed keys as 
> a map, and only for use-cases when you need to.
>
> 4. And finally, if you are willing to venture out from the Go standard 
> library, there are numerous open-source packages that claim to be much 
> faster than the standard library.  Usually you want to stick with the Go 
> standard library so other Go developers will be familiar with it and to 
> minimize dependencies that could potentially introduce a bug or security 
> hole.  However, if you really need better performance it might be worth the 
> added dependency.
>
> While I cannot validate the performance claims of any of these packages, I 
> can provide you with this list of packages that claim better JSON 
> unmarshalling performance:
>
>- https://github.com/valyala/fastjson
>- https://github.com/bytedance/sonic
>- https://github.com/buger/jsonparser
>- https://github.com/mailru/easyjson
>- https://github.com/sugawarayuuta/sonn

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

[Mike Schinkel]

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 being 
fixed. Be aware that you *do not need to 
* create a struct to match the 
full JSON. You can easily just create a flyweight struct which is a subset 
if for your use-case containing only the specific parts you need, *for 
example* .  

2. If you optionally need to parse portions of the JSON, but not always, 
you can use *json.RawMessage*  
to capture the properties you don't always need to parse, and then *parse 
them only when you need to *.

3. You can also declare an *.UnmarshalJSON()* method on a struct you are 
passing to *json.Unmarshal()*, or on any struct that is a property of your 
top level object, and then be *fully in control of parsing the data* 
, meaning you could combine 
with (a) *json.RawMessage* property(s) to part just the non-fixed keys as a 
map, and only for use-cases when you need to.

4. And finally, if you are willing to venture out from the Go standard 
library, there are numerous open-source packages that claim to be much 
faster than the standard library.  Usually you want to stick with the Go 
standard library so other Go developers will be familiar with it and to 
minimize dependencies that could potentially introduce a bug or security 
hole.  However, if you really need better performance it might be worth the 
added dependency.

While I cannot validate the performance claims of any of these packages, I 
can provide you with this list of packages that claim better JSON 
unmarshalling performance:

   - https://github.com/valyala/fastjson
   - https://github.com/bytedance/sonic
   - https://github.com/buger/jsonparser
   - https://github.com/mailru/easyjson
   - https://github.com/sugawarayuuta/sonnet
   - https://github.com/json-iterator/go
   - https://github.com/segmentio/encoding
   - https://github.com/goccy/go-json
   - https://github.com/simdjson/simdjson
   
Benchmarks from authors of some of the packages *(so take with a grain of 
salt):*

   - https://github.com/sugawarayuuta/benchmark
   - 
   https://blog.min.io/simdjson-go-parsing-gigabyes-of-json-per-second-in-go/
   
And benchmarks from someone who is not an author of one of those packages:

   - 
   
https://kokizzu.blogspot.com/2022/12/map-to-struct-and-struct-to-map-golang.html

   
Hope this helps.

-Mike
On Friday, March 8, 2024 at 4:15:25 PM UTC-5 Robert Engels wrote:

> It is highly unlikely that the Go marshaling is the cause. I’m guessing 
> you are probably not using a buffered output stream. 
>
> PHP is written in C but depending on what you are doing it is either a 
> script or calling out to another process (afaik) 
>
> On Mar 8, 2024, at 2:35 PM, pragya singh  wrote:
>
> Hi,
>
>
> "I am facing an issue in my Go code. I converted my read API from PHP to 
> Go, but the response time of Go API is higher than PHP. We are returning 
> the response in JSON format, and the response contains around 30k keys, 
> which is taking too much time in JSON marshaling. We are adding all the 
> response in map format as we can't use struct because response keys are not 
> fixed and vary from user to user. 
>
> -- 
> 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/a57a2a71-b0f9-41fb-93e9-bd54b57829b1n%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7345c383-1529-489c-b156-72601bd80530n%40googlegroups.com.

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

[Mike Schinkel]

> 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 
>> keywords or concepts added to Go the language, or at least I don't think it 
>> would?
>> 
>> Is there any reason Go could not relax the allowable values for const to be 
>> able to support constructs that can be determined at runtime such as `const 
>> April = [1]byte{4}`?
> 
> I think this is https://go.dev/issue/6386.

Thank you Ian for acknowledging, and for the link, and yes that issue does 
cover it.

However, that issue is a general superset whereas I was proposed a very 
constraint language enhancement.

In that issue it seems the pushback was:

1. It is unclear where to draw the line on what to allow because of all the 
ramifications, and 

2. "Nice to have" is not sufficient reason to add a feature to the language.

> The simple version only works if the variable
> can be declared and initialized in the same statement.  That isn't
> alway feasible, which is why init functions exist.  It absolutely
> prohibits circular data structures, which could be limiting. 

Those are definitely challenging concerns when considering the larger ask for 
the proposal in issue 6386.

However, to address the enum use-case maybe a much smaller subset proposal 
could suffice, one that can be declared and initialized in the same statement 
and that has no need for circular data structures.  

One that could also address both of those aforementioned criticisms:

1. The subset to include would only be those things that would be needed to 
address the enum use-case, which I think would be fixed-sized arrays and 
structs (and not maps nor slices I previously pondered.) 

Those should be able to contain only other constants, which I think would 
include contained fixed-sized arrays and structs, but nothing with a pointer 
and attempting to take the address of any of those constants should throw a 
compiler error.

2. This proposal would not be because it is "nice to have" but instead it would 
enable a developer to create function whose parameters could only be satisfied 
by one of the values of a type used for enums as specified by the developer.  
IOW, it solves a legitimate development concern and is not just a nice-to-have.

The only real downside I can see is if implementing this would someone paint 
the language in a corner so that it could not be enhanced in a better way in 
the future. Maybe my vision is too limited, but that doesn't seem likely with 
such a small, backward compatible change that introduces nothing new other than 
relaxing an existing constraint.

Certainly some people would say "Well if you are going to do that, why not do 
the entirety of 6386?" And if one of my hot buttons required arbitrary types to 
be assigned to a const, I might be one of those people too. But the Go team 
seems to be particularly adept at saying "We are doing this because we have a 
specific reason, and today, we are only doing this. Maybe we'll do more in the 
future, but not today." Maybe that could allow improves enums in the next 
version of Go without having to eat the elephant all at once?

Here I modified is Brian Candler's example to be what I envision could address 
the enum use-case:

1. Non-pointer instances of `struct` and `[...]array` are assignable to a 
`const`, and 
2. Casting a literal to a `struct` `[...]array` type would instantiate the type 
and assign the literal's value to the first element or property.

https://goplay.tools/snippet/xuGipbUVlKz 


Maybe this is a sufficiently small proposal to address this valid use-case that 
the Go team could get behind it?

-Mike


-- 
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/9434DAAB-C203-43C0-A4E3-C0B5BDA0DD77%40newclarity.net.

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

[Mike Schinkel]

> 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 
> useful.

Thank you for answering my question.

I tried to come up with a solution to that problem in Go using existing 
features and — assuming we want our enum-like values to be immutable and we 
don't want write a large amount of boilerplate — I was not successful.

> On Monday, March 4, 2024 at 10:47:27 AM UTC-5 Brian Candler wrote:
> Does this represent the problem statement?
> https://go.dev/play/p/kLME_dJE9a5 

I'd like to present my simple analysis of the catch-22 and see if others concur?

1. In order to get immutability without significant boilerplate, we need to use 
`const`.

2. We *can* define a type like `Month` as Brian Candler's example showed.

3. We also can assign values of our type to our `const` constants.

4. However, we can *only* assign literals or simple expressions to a `const`. 
i.e. we cannot assign `Month{1}` to a `const` if `Month` were a `struct`, 
`map`, `array`, or `slice`.

5. Further, funcs allow literals to be used as a type without requiring them to 
be cast as that type which is why `PrintMonth(14)` is both possible and 
problematic.

6. All values that we can validly assigned to a `const` are literal values that 
can also stand-in for the type when passed to a func that expects that type as 
a parameter.

Does that summarize our quandary correctly?  Did I leave anything out?

Assuming I did summarized correctly then it seems that any one or more of these 
potentially simple language enhancements would suffice to address the stated 
concern?

1. Allow a `const` to somehow be defined as `strict` where `strict` is a 
placeholder for the concept; i.e. that  `PrintMonth(14)` would not be possible 
but  `PrintMonth(April)` would be.

2. Allow a `func` too somehow have its parameter defined as `strict`, i.e. that 
again, `PrintMonth(14)` would not be possible but  `PrintMonth(April)` would be.

3. Allow a `var` to somehow be defined as immutable thus allowing immutable 
vars and 
types of subtypes `struct`, `map`, array, and/or slices to be used as 
pseudo-enums.

4. Relax the allowable values that can be assigned to a `const` to include 
values that can be fully determined at compile time such as `const April = 
[1]byte{4}` thus allowing `const` and 
types of subtypes `struct`, `map`,  array, and/or slices to be used as 
pseudo-enums.

Did I miss any potentials?  Did I get anything wrong? 


-Mike

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 keywords 
or concepts added to Go the language, or at least I don't think it would? 

Is there any reason Go could not relax the allowable values for const to be 
able to support constructs that can be determined at runtime such as `const 
April = [1]byte{4}`?

As an aside, if this solution is viable then it would also be nice if the cast 
`Month(4)` could translate to `[1]byte{4}` when `Month` is defined as 
`[1]byte`, and equivalent for `struct` and slices, i.e. that `Month(4) would 
assign to the first element or property of the `struct`, array, or slice. It 
could easily be limited to those with only one element or property, though.

-- 
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/21C8009D-F312-45CE-99C7-2B017603F60B%40newclarity.net.

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

[Mike Schinkel]

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, and in working with Go I never really felt that enum 
functionality was missing.

That said, what am I missing?  What it is about enums that have so many people 
clamoring for them in Go?  Is it having a textual representation managed by the 
compiler that a go:generate cannot solve?  Is it having a syntax that allows 
treating them like an object with a property, e.g. HttpStatuses.NotFound that 
otherwise requires too much boilerplate?  Or is it something else?

Further, what can you envision doing with a "proper" enum that you cannot 
already do with a custom-typed constant?

Thank you in advance to whoever helps me understand why enums are such as 
burning desire for so many developers.

-Mike

> On Mar 3, 2024, at 12:25 AM, Nicolas Serna  
> wrote:
> 
> Hello, gophers. Lately I've been working quite a bit with enums as I'm moving 
> a C program I had tGo, so I wondered if there was any progress on enums 
> proposals and realized that none of them get anywhere without breaking the 
> Go1 compatibility.
> 
> I've decided to get a bit creative and share with you the proposals I've 
> thought of. 
> 
> The fundamental thing when we talk about the incorporation of "robust enums" 
> is, similarly to the case of generics, to propose a syntax extension to the 
> language without breaking compatibility with the previous software.
> 
> We use enumerations simply to handle states and encapsulate them under a 
> name. Therefore I wanted to propose the following syntax:
> 
> ```proposal
> const ()   = 
> ```
> 
> The idea of this syntax is that, roughly speaking, it reminds us of what we 
> do when we declare a method, with the only difference that in this case we 
> use constant values associated to some "enum type". Then, we should be able 
> to call our constants as follows: ., the same would 
> be true for an already instantiated type.
> 
> ```example
> type Statement struct{ /* ... */ } 
> 
> type StatementTyp int 
> 
> const (Statement) (
>  Prepared StatementTyp = iota
>  Success
>  Fail
> )
> 
> func main() {
> stmt := Statement{}
> fmt.Println(Statement.Prepared) // 0
> fmt.Println(stmt.Success) // 1
> }
> ```
> 
> Realistically speaking this doesn't solve much. It just gives us a way to 
> encapsulate constants in an "elegant" way and keeps the "const-iota" syntax, 
> but little else.
> 
> I think it is essential to have an extra way to reference these internal 
> values of a type so that we can work with the help of the go-typechecker. For 
> this I could only come up with two types of syntax, let's see:
> 
> ```prop1
> var bar const 
> 
> func foo(arg const ) {...}
> ```
> ```prop2
> var foo .const
> 
> func bar(arg .const)
> ```
> 
> That would be all, I hope you can give some feedback and know what you think. 
> I read in the go2-language-template 
>  that 
> it was better to post my ideas in this group instead of making a issue.
> 
> Thanks for reading ^^
> 
> 
> -- 
> 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/134fd31b-9081-4d22-b098-412244338fc5n%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/39D18DF3-2832-4905-979D-83B83CE06D68%40newclarity.net.

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

[Mike Schinkel]

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. 
>
> Peter.
> On Tuesday 20 February 2024 at 10:19:04 UTC Jan Mercl wrote:
>
>> On Tue, Feb 20, 2024 at 11:07 AM Peter Bočan  wrote: 
>>
>> > Is there a way to debug this? Is there a way to step over the 
>> initialisation order? 
>>
>> I try to get help from '$ go mod graph' in similar investigations. 
>>
>

-- 
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/3eb0f13b-6043-47b6-88ea-614e0231ba5en%40googlegroups.com.

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

[Mike Schinkel]

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/testscript for 
testing complete application behaviour.


These both are really the essential answer to your question.  I just did 
not think of it when I first replied.

-Mike

-- 
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/840f6cf3-8bbf-44a9-86df-3aa7e654ae01n%40googlegroups.com.

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

[Mike Schinkel]

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 `main()`, and then there is an idiomatic standard for 
putting the code for commands in a `/cmd` directory, so that's were most of 
the code is typically found that is still part of the app but that is not 
in reusable packages.

Is there a reason this approach is problematic for you?  Just curious.  

If you prefer to put more in `main()` then AFAIK there are no real issues 
with it other than lacking package reusability, so if it works for you, 
knock yourself out. #jmtcw

-Mike

On Wednesday, February 14, 2024 at 6:12:49 AM UTC-5 Jerry Londergaard wrote:

> I see quite a few modules out there where they seem to be putting in as 
> little into the main package as possible. Literally they will sometimes be 
> a few lines:
> ```
> import foobar
> func main() {
> os.Exit(foobar.Run())
> }
> ```
> Yet then go on to do all the things I would've thought are the domain of a 
> main package, in the foobar package, like arg parsing, pulling in config 
> items from env vars, setting up deps etc, and then running the actual thing.
>
> Why not just put that code into the actual main package? Sure, maybe not 
> all into the main *function* itself, but in the main package at least.
>
> I understand that you don't want to be putting any real business logic 
> into that main package, but I'm just talking about entry point type 
> specific stuff. People might say they want to keep main 'light', but 
> sometimes it feels like it's a competition to have the fewest lines as 
> possible in the main package. 
>
> kube-proxy[1] is an example of this. Maybe this starts to make more sense 
> when the amount of code you would be putting into main become a lot, 
> kube-proxy may qualify for this, but I see other cases where I don't 
> understand the reasoning.
>
> Certainly not all are like that[2], but in some circles that I travel it 
> seems to be a common way of thinking.
>
> Am I missing something ?
>
> 1. 
> https://github.com/kubernetes/kubernetes/blob/master/cmd/kube-proxy/proxy.go 
> 2. https://github.com/ethereum/go-ethereum/blob/master/cmd/geth/main.go

-- 
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/aa139a11-2359-48db-a9f9-0902ff96da77n%40googlegroups.com.

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

[Mike Schinkel]

> 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 
> tied to the base struct.
>  
> Something like this...
> https://go.dev/play/p/DUzXr31s8Pn

You can't cast like in your example, but you can create an interface — call is 
`Baser` using idiomatic interface naming to identify the `Base` type which will 
have an empty `Base()` method — and then type assert to it after which, if it 
succeeds you can type assert to `*Base`, like so:

https://go.dev/play/p/-gcKGf4_AFg 

Hope this helps.

-Mike

-- 
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/1149B1AB-059E-42B4-A593-549D4793F7B5%40newclarity.net.

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

[Mike Schinkel]

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 perspective: Given the nature of Go package names and imports, 
I find it regrettable when people Go packages have generic names that have 
a high likelihood of conflicting with other package names.  

When it's for your own use, especially internal and not on a team, it's 
typically less problem. However, when the intent is to publish and 
encourage others to use I would respectfully advocate for a name that is 
not likely to be duplicated by someone else who is lacking in naming 
creativity . 

Certainly, when there are conflicts in names people can use aliases for 
their imports, as aliases were intended.  When programming one's own side 
project app, using aliases typically doesn't become a big problem. 

However, when working on a Go codebase with tens or hundreds of developer 
those same-named packages quickly become a nightmare of differently named 
aliases making it really hard to tell what-is-what when looking at code in 
a complex codebase. IOW, which "util" is being used when "util2.DoStuff()" 
is called?  And believe me, I have seen a *ton* of this kind of aliasing in 
production code.

My comments apply even more 
 to CLI tools 
 
like 'mockgen' in this case  because, 
while aliases are available on a CLI, it can cause problems for initial and 
ongoing setup for the tool.

On Monday, January 8, 2024 at 9:00:24 AM UTC-5 TheDiveO wrote:

*imagination be reserved to where it applies, not just here.*


It doesn't have to be imaginative nor obfuscated to be cognizant of naming 
conflicts.  

Rather than "go-mock" it would be better IMO if the OP had named it *(something 
like) **"*go-vermock"  *(the company he works for is Versant) *and if he 
chose to name his CLI "vermockgen," or similar.

-Mike
#jmtcw #fwiw

-- 
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/83b6fb46-41e5-45dd-afe6-f66a4c315d3fn%40googlegroups.com.

Re: [go-nuts] Type parameter embedded field

[Mike Schinkel]

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 
 (or read the supplemental 
blog post about it 
), 
you'll see that I have to spend a bit of work on constructing a negation to 
prove (co-)NP-completeness.
If we just put in a negation operator, that work would no longer even be 
necessary and the proof becomes trivial. In fact, C++ concepts *have* a 
plain negation operator in their constraint language and are known to be 
NP-complete to type-check.

 
One of the things I have really appreciated about the Go language — and a 
main reason I was drawn to it — was how the Go team has been pragmatic in 
the past instead of allowing conceptual purity to block functionality that 
would be useful in service of software engineering.

Specifically to your argument about negation and NP-completeness, yes in 
the general case unrestrained negation could result in NP-completeness.  

However, a better and more pragmatic approach would be to restrain negation 
to those things that can be performed efficiently. 

Alternately the Go team could recast the solution as something other than 
negation; e.g. an *"exception" *as in *"allow `any` type, excepting those 
types that conflict with type `Y`."  *

For the case of type embedding, the methods of *`**Y**`* are known at 
compile time and the type methods can be compared as efficiently with the 
type parameter as checking methods of an interface parameter. That is 
unless there is some other unintended consequences I am not seeing and you 
have not mentioned.

-Mike 

P.S. Ironically, ensuring the benefits of embedded type parameters are *"too 
small"* is itself a class of NP problem.


-- 
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/5f4208fe-730b-41cb-bd55-62f7d9bdbb58n%40googlegroups.com.

Re: [go-nuts] Type parameter embedded field

[Mike Schinkel]

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 nonetheless revise the proposal that 
does include all knowledge in the signature, see below.

It was a conscious decision during the generics design to *not* do 
type-checking of generic function bodies during instantiation time, but to 
be able to compile the body of a generic function and the caller of a 
generic function separately.


Unless I am misunderstanding how the compiler works, I was proposing 
type-checking during compile-time, not instantiation time.  Besides, prior 
decisions should not in-and-of themselves eclipse hindsight 
after-the-fact.  As even Rob Pike said in his keynote[1] just a few days 
ago, there are *"still lingering problems"* to do with generics, and 
*"sometimes 
it takes many years to figure something out."*  So to lean into commitment 
bias ensures future improvements will be less than they could be.
 
On to the revised proposal.  Assuming your example type again:





*type X[T any] struct {  T  *bufio.Reader}*

Let us agree that it should not compile because of the stated conflicts.  

Instead, let us assume an extension to type constraints that would allow us 
to say that *"A valid type is `any` type, except for those that implement 
the methods of type Y."  *Using `*!*` as an placeholder sigil for that 
intent, and adding the sigil `*&*`, we could have the following type 
constraint:




*type Xable interface {  any & !*bufio.Reader}*
*(While `!` is probably a bad choice — which is why I said it was a 
placeholder — it allows me to illustrate the concept in potential code.)*

Alternately, maybe using `*-*` would be better?:




*type Xable interface {  any -*bufio.Reader}*

>From the type constraint `*Xable*` it seems to me we could have the 
following, which should allow the compiler to do compile-type checking, 
without having to reach into deeply nested dependencies:




*type X[T Xable] struct {  T  *bufio.Reader}*
 
The above should give the OP all reasonable functionality I believe they 
were requesting and usefully expand the capabilities of generics. That is, 
unless there are objective arguments for why that can't reasonably be 
compiled, or there are unintended conflict elsewhere in the language?

-Mike

[1] https://www.youtube.com/watch?v=yE5Tpp2BSGw

-- 
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/67c3cf8d-a6ae-4968-991f-df09e9f86475n%40googlegroups.com.

Re: [go-nuts] Type parameter embedded field

[Mike Schinkel]

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 
parameter that would create ambiguity, e.g. throw a compile error on these 
lines from your examples: 

var y X[*strings.Reader]


And:

F[*strings.Reader]()


I do recognize that deep call stacks may cause difficulty for this 
proposal, but my logical reasoning about them (vs. me knowing how it would 
to be implemented) tells me that `main()` should be able to see the generic 
type that `F()` requires because `F()` should be able to see the generic 
type that `G()` requires which is type `X`, and type `X` implements a 
`Read()` thus making it ambiguous with `*strings.Reader`:

type X[T any] struct {
T
*bufio.Reader
}

func F[T any]() {
G[T]()
}
func G[T any]() {
var x X[T]
x.Read
}


Unless it is effectively not possible to implement that type of logic in 
the Go compiler because of design decisions — possibly related to 
compilation performance — then it seems logical the Go compiler should be 
able to recognize the conflict and generate a compile error on such 
combinations at the point of passing the type parameter, explicitly or 
implicitly.  

While not a perfect solution — since it would disallow edge cases where a 
developer feels they really must create a struct with both type parameters 
and use with types that create ambiguity — such a compromise would stop 
perfect from being the enemy of the good.

Anyway, as stated this is a strawman proposal. Please shoot holes in it if 
there are any opportunities to do so.

-Mike

-- 
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/eaf71dec-e078-48bd-907c-ed7ff1ada222n%40googlegroups.com.

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

[Mike Schinkel]

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 conversions in order to make the code more 
readable when we use the methods "directly" on a concrete type, but when we 
use interfaces there is no implicit conversion.  I guess this entry 
 has key information about this affair.*


For clarity, that was mentioned in this discussion, here 
. 

-Mike

-- 
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/9f7c1d63-aa73-41a8-aeaf-1b191bec4cebn%40googlegroups.com.

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

[Mike Schinkel]

> 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 <--- compiles
> 3. A pointer variable and multiple pointer receivers.  <--- compiles 
> 4. A value variable and multiple pointer receivers.  <--- will NOT compile
> 5. A pointer variable and mixed value+pointer receivers  <--- compiles 
> 6. A value variable and mixed value+pointer receivers. <--- will NOT compile
> 
> Permutation #4 and #6 are consistent with the description above, and they 
> both have a value variable in common.
> 
> However, given than #5 DOES compile, I was left wondering why the standard 
> that mixed receivers should be flagged as an error? 
> 
> I am not sure that "the standard" is for mixed receivers to be flagged as an 
> error. Can you give a specific example of where the standard Go toolchain 
> does this?

Thanks for asking.

In hindsight I was in-artful in my use of words. I should not have said 
"flagged as an error" even though that is what GoLand does.  I should have 
instead asked why the Go FAQ 
<https://go.dev/doc/faq#methods_on_values_or_pointers> advised to use all 
pointer receivers when there are any pointer receivers:

> Next is consistency. If some of the methods of the type must have pointer 
> receivers, the rest should too, so the method set is consistent regardless of 
> how the type is used. See the section on method sets 
> <https://go.dev/doc/faq#different_method_sets> for details.

BTW, I am assuming that GoLand flags mixed receivers as a concern because of 
what the Go FAQ recommends.

-Mike

> Is this question really about Goland, a third-party product, and/or some 
> underlying third-party linter that it uses?  If so, it's an issue for that 
> third party.
> 
> Arguably it's not great style to do this, and it might make it confusing for 
> users of your package. But it's not an error, either for the compiler or "go 
> vet". https://go.dev/play/p/fBgrltIEjA2
> 
> -- 
> 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 
> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/4fe6a954-696c-40f1-86cf-ea9148e42ba2n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/golang-nuts/4fe6a954-696c-40f1-86cf-ea9148e42ba2n%40googlegroups.com?utm_medium=email_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/470BA5FB-72A9-4E00-A01C-CA8D4D9ED631%40newclarity.net.

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

[Mike Schinkel]

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.

On Tuesday, November 14, 2023 at 7:08:57 PM UTC-5 burak serdar wrote:

I do not agree that this is because how the compiler works. A value
receiver is equivalent to pass-by-value argument, that is:

rcp.version()

is equivalent to:

RPC.version(rpc)

thus, creating the copy of the rpc variable. So, the compiler may
choose to avoid the race by not copying it, or by inlining the version
function, but according to the spec, it is passed by value, i.e., it
is copied.


I agree with your assertion — if you fix it to work correctly by using 
*RPC.version(*rpc)*— but that is actually a different concern than I and I 
think Robert Engels were discussing.  

Your example above calls a method directly on the struct, we were 
discussing calling via an interface. 

Given that Go already performs some *"magic"* when it calls an interface — 
i.e. when the interface value contains a pointer and the method receive is 
a value — I think he was exploring whether it would be viable to *avoid* 
creating a copy when the method does not read or update any property.

Still, that doesn't seem to be all that useful because most of the time a 
value method would want to read a property so it is probably not worth the 
effort.



But back to the original concern. It seems that *race conditions do not 
arise* *when using mixed receivers while only executing the main goroutine*
*,* right?

And *if using only pointer receivers then we can still have a data race **if 
those* methods are being called in multiple goroutines where methods both 
read and update the same properties, right?.  

Given that, *the race conditions and the mixed pointers seem orthogonal 
concerns?*   But I do now recognize that if you are using the same objects 
across goroutines and you have an updating pointer method then calling *any* 
value method would create a race condition so mixing receivers is more 
likely to cause a race condition when sharing objects across goroutines.

Still, it seems to me then that *the guidance should be to not to access 
any object concurrently in more than one goroutine* instead of to *avoid 
mixed receivers*, since that laters only addresses part of the race 
condition problem?  *(BTW, by "not-concurrently" I mean that you could 
first access in goroutine 1 then pass it via a channel to goroutine 2 where 
you could access it, but once goroutine 1 submits the object to the channel 
it should no longer attempt to access it.)*

Or again, am I missing something obvious?   

-Mike


-- 
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/8f46fecc-1d5f-4507-8209-76adef294bafn%40googlegroups.com.

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

[Mike Schinkel]

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't explain it in 
his post. 

Robert Engels seems to be saying this isn't conceptually a data race but it 
is an unfortunate artifact of how the compiler works?

-Mike

-- 
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/241c13d1-9d9a-4028-9bce-ba856405f9edn%40googlegroups.com.

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

[Mike Schinkel]

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 unmodified, and only use 
pointer receivers when I want state to be modified.  And, I don't want to 
have to ignore GoLand's warnings or have a CI/CD linter warn me about it 
considering that I want to do it on purpose.  I could turn off the warning 
in GoLand, but that doesn't change coding standards on teams I might work 
on who religiously follow the Go team's recommendations.

Given this thread I finally did some research. Tracking it down in the Go 
FAQ  it says:


*> Next is consistency. If some of the methods of the type must have 
pointer receivers, the rest should too, so the method set is consistent 
regardless of how the type is used. See the section on method sets 
 for details. *
Tracking down method sets it says *(abridged):*

> *the method set of a type T consists of all methods with receiver type T, 
while that of the corresponding pointer type *T consists of all methods 
with receiver *T or T. That means the method set of *T includes that of T, 
but not the reverse.*
*> This distinction arises because if an interface value contains a pointer 
*T, a method call can obtain a value by dereferencing the pointer, but if 
an interface value contains a value T, there is no safe way for a method 
call to obtain a pointer. (Doing so would allow a method to modify the 
contents of the value inside the interface, which is not permitted ...)*
*> Even in cases where the compiler could take the address of a value to 
pass to the method, if the method modifies the value the changes will be 
lost in the caller. ... This is almost never the desired behavior.*

I decided to so some experimentation and turns out it a compile error 
occurs when a value variable is used with a pointer receiver:  

- https://goplay.tools/snippet/_AiFRsc9w-r

There are six (6) permutations of an interface and the variable of the 
interface type, two (2) of which will not compile:

1. A value variable and multiple value receivers  <--- compiles
2. A pointer variable and multiple value receivers <--- compiles
3. A pointer variable and multiple pointer receivers.  <--- compiles 
4. A value variable and multiple pointer receivers.  <--- will NOT compile
5. A pointer variable and mixed value+pointer receivers  <--- compiles 
6. A value variable and mixed value+pointer receivers. <--- will NOT compile

Permutation #4 and #6 are consistent with the description above, and they 
both have *a value variable *in common.

However, given than #5 DOES compile, I was left wondering why the standard 
that mixed receivers should be flagged as an error? 

I ask rhetorically — or better yet, to the Go team — shouldn't mixed 
receivers be considered acceptable, especially when they would allows 
ensuring the receiver is not changed by the method that should not change 
it? And then shouldn't the guidance in the FAQ be to use *value* receivers 
unless the receiver needs to be modified within the method?

I do get that changing the guidance could violate the conceptual purity of 
the *"method set "* 
definition, but pragmatically is being able to mix receiver types not more 
useful in practice?  If the developer makes a mistake and passes a 
non-pointer interface value to a method with a pointer receiver they will 
get a compile error, so there does not appear to be any downside for 
changing the recommendation regarding consistency with method receivers?

Or is there something really obvious I am just missing?

-Mike
On Monday, November 13, 2023 at 4:49:56 PM UTC-5 Brad Johnson wrote:

> Google's style guide is a popular reference for Go programmers. In it, 
> they list off a number of scenarios where one would use a value receiver vs 
> a pointer receiver. But, ultimately, they end the list with "when in doubt, 
> use a pointer receiver".
>
> In my experience, I've noticed the majority of Go programmers I encounter 
> default to using pointer receivers in all circumstances. And I have a hard 
> time justifying any protest because the scenarios typically don't fall into 
> the "approved" set where value receivers are recommended.
>
> I also notice that my IDE (GoLand) defaults to returning a pointer to a 
> struct when I use its "Generate Constructor" auto-complete functionality. I 
> can't help but suspect this was motivated by the "when in doubt" advice 
> from Google.
>
> I'd be curious to hear thoughts on this topic. I tend to advise developers 
> to default to value receivers because I perceive benefits to avoiding nil 
> pointer exceptions. But it's hard to substantiate my advice as anything 
> idiomatic.

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

[Mike Schinkel]

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://pkg.go.dev/golang.org/x/exp/maps
   - https://pkg.go.dev/strings
   - https://pkg.go.dev/sort
   
Go does not have equivalent functions for working with PHP-style arrays 
because it does not support PHP style arrays. Few other languages (any?) 
do, in part I think because they are weird, and likely hard to make 
performant. But in Go you can simulate them with `map[any]any` I think.

Before Go, I spent around a decade working in PHP. After about 6 months I 
never wanted to work in PHP again.  One of the reasons PHP has so many 
array functions is that you cannot make low-level data manipulation 
functions performant, such as working character by character, or executing 
many loops. So PHP *needs* to have them in its standard library in order to 
be usable.

Go OTOH handles low-lever data manipulation performantly, so there is not 
nearly as much need to have every conceivable array operation in the 
standard library like there is in PHP.  Over the five years I've been 
coding in Go the Go team has added many functions to the standard library, 
including many of those from the links I included above. 

So It is quite possible the Go team will add a function to create an 
intersection and a union of slices to the standard lib at some point. And 
this is especially true since Generics are a recent addition and their 
inclusion allows functions to apply to many different data types. This 
means there is now arguable benefit for the Go team to add some of the 
functionality they are missing when compared to PHP.

But even if they do not, it would be trivial to write many of them and add 
them to your own package of functions, publish them to GitHub, and then 
they would also be just an import statement away.

If you are new to Go, allow yourself to get to know it for several months 
before judging it.  If you are anything like me, you will come to 
appreciate Go by leaps and bounds more than working with PHP. #fwiw

-Mike 

On Thursday, November 9, 2023 at 12:35:38 PM UTC-5 Viktoriia Kapyrina 
Yelizarova wrote:

> Well, reflection is one of the things I love in language and it is a 
> "must".  
>  On the other hand, the automation is exactly what common libraries do, I 
> can not find any reason to make a loops if they are repeated actions which 
> might be implemented in general library.  array_intersect is a common 
> example of automation. It makes no sense to right it again and again as it 
> is common operation which works the same way. 
> On Sunday, June 22, 2014 at 12:08:50 AM UTC+3 Milan P. Stanic wrote:
>
>> On Fri, 2014-06-20 at 04:57, Larry Clapp wrote: 
>> > I don't know PHP, but from what I've seen of it, it looks a lot like 
>> Perl. 
>> > I know Perl fairly well. 
>> > 
>> > One of the key differences between Perl and Go (and possibly PHP and 
>> Go) is 
>> > that Go has structs and Perl has only hashes (as far as named data 
>> > structures)[1]. It's very important to not try to write Perl in Go 
>> (i.e. 
>> > duplicating your Perl hashes in Go hashes, etc), but write more native, 
>> > idiomatic Go, that takes full advantage of Go's structs and other 
>> native 
>> > data structures. 
>>
>> From my PoV main difference is that the Go is strongly typed while most 
>> 'scripting' languages (Perl, PHP, Python etc.) are untyped (weak typed 
>> or whatever) and I don't like to argue what typing means). 
>> [...] 
>>
>> -- 
>> Best regards 
>>
>

-- 
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/315dcbb3-cf56-45d6-a4d7-57691209d6b9n%40googlegroups.com.

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

[Mike Schinkel]

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 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 
> performant like Go, not type-safe like Go, debugging embedded Lua code is 
> difficult compared to working with Delve and Go, and you will have to ship 
> plugin source code, or embed and write to a possibly hidden directory.
>
> For real-world plugins I'd say stick with Hashicorp's go-plugin 
> <https://github.com/hashicorp/go-plugin> or similar as others have 
> recommended, and then only fall back to Lua when you want to allow 
> end-users who are not Go developers to extend your app in small ways.  
> #jmtcw #fwiw
>
> -Mike
> P.S. You could also use JavaScript 
> <https://prasanthmj.github.io/go/javascript-parser-in-go/> instead of 
> Lua, and most people are likely more familiar with that. I chose not to use 
> a JavaScript package as I wanted something significantly lighter weight 
> than JS.  OTOH, I am seriously considering switching out Lua and moving to 
> github.com/antonmedv/expr for my use-case as it is even lighter weight 
> still.
>
> On Saturday, October 28, 2023 at 8:50:54 AM UTC-4 alex-coder wrote:
>
>> Hi all.
>>
>> Of course, in case if anyone is in interest to write  plugins for Go.
>> I found another option for writing plugins by use Lua.
>> I haven't touched the example yet, but I'm giving out the link.
>> https://github.com/yuin/gopher-lua/
>>
>> Thank you.
>>
>> четверг, 3 августа 2023 г. в 15:47:26 UTC+3, alex-coder: 
>>
>>> Hi All,
>>> Currently I walk through the next book about native go development and 
>>> find out that it is possible to use the plugin, 
>>> but with limitations, so it became interesting what alternatives there 
>>> are.
>>>
>>> Thank you.
>>>
>>> четверг, 3 августа 2023 г. в 12:09:21 UTC+3, Christoph Berger: 
>>>
>>>> WebAssembly comes to mind - see, for example, https://wazero.io/
>>>>
>>>> A plugin would then be a .wasm binary that can be compiled in any 
>>>> language that supports WebAssembly as target.
>>>>
>>>> Disclaimer: I have not yet tried this approach.
>>>>
>>>> On Wednesday, August 2, 2023 at 12:14:15 PM UTC+2 alex-coder wrote:
>>>>
>>>> Hi All !
>>>> Plug-in package is very interesting, but in case the development under 
>>>> windows it does not work,
>>>> So, any hint to use some option instead will be highly appreciated.
>>>>
>>>> Thank you.
>>>>
>>>>

-- 
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/b396f51f-1f2f-4fbc-b1ce-a24bab3043bdn%40googlegroups.com.

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

[Mike Schinkel]

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 performant 
like Go, not type-safe like Go, debugging embedded Lua code is difficult 
compared to working with Delve and Go, and you will have to ship plugin 
source code, or embed and write to a possibly hidden directory.

For real-world plugins I'd say stick with Hashicorp's go-plugin 
 or similar as others have 
recommended, and then only fall back to Lua when you want to allow 
end-users who are not Go developers to extend your app in small ways.  
#jmtcw #fwiw

-Mike
P.S. You could also use JavaScript 
 instead of Lua, 
and most people are likely more familiar with that. I chose not to use a 
JavaScript package as I wanted something significantly lighter weight than 
JS.  OTOH, I am seriously considering switching out Lua and moving to 
github.com/antonmedv/expr for my use-case as it is even lighter weight 
still.

On Saturday, October 28, 2023 at 8:50:54 AM UTC-4 alex-coder wrote:

> Hi all.
>
> Of course, in case if anyone is in interest to write  plugins for Go.
> I found another option for writing plugins by use Lua.
> I haven't touched the example yet, but I'm giving out the link.
> https://github.com/yuin/gopher-lua/
>
> Thank you.
>
> четверг, 3 августа 2023 г. в 15:47:26 UTC+3, alex-coder: 
>
>> Hi All,
>> Currently I walk through the next book about native go development and 
>> find out that it is possible to use the plugin, 
>> but with limitations, so it became interesting what alternatives there 
>> are.
>>
>> Thank you.
>>
>> четверг, 3 августа 2023 г. в 12:09:21 UTC+3, Christoph Berger: 
>>
>>> WebAssembly comes to mind - see, for example, https://wazero.io/
>>>
>>> A plugin would then be a .wasm binary that can be compiled in any 
>>> language that supports WebAssembly as target.
>>>
>>> Disclaimer: I have not yet tried this approach.
>>>
>>> On Wednesday, August 2, 2023 at 12:14:15 PM UTC+2 alex-coder wrote:
>>>
>>> Hi All !
>>> Plug-in package is very interesting, but in case the development under 
>>> windows it does not work,
>>> So, any hint to use some option instead will be highly appreciated.
>>>
>>> Thank you.
>>>
>>>

-- 
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/71ab878f-2ce6-4c73-9e85-e9d29e61d718n%40googlegroups.com.

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

[Mike Schinkel]

Absolutely, some times generics are not needed.  

I actually don't find a need to use them that often which is probably why 
when I came across a use-case that really needed them I was so stumped as 
to how make it work.  Kudos again to Axel for helping me recognize my 
blindspot.

-Mike
P.S. BTW, regarding your *"I mean this... 
<https://goplay.tools/snippet/GCxBeHMfipf>"* link, I already addressed 
<https://groups.google.com/g/golang-nuts/c/eD7207kM8zA/m/IZSZNPwnAQAJ> why 
that was not sufficient for the use-case earlier in the thread. #justfyi

On Monday, October 23, 2023 at 2:20:28 PM UTC-4 Victor Giordano wrote:

> Very interesting case.
>
> As Alex says, if you "help" the compiler writing  the actual type 
> parameter like `Append[Suiter](slice, suiter)` it works. I have seen this 
> before in Java when generics comes into town... I guess with time golang 
> team with time will improve the type inference engine... this also happens 
> with typescript... perhaps is a common trait in evolution of language 
> compilers.
>
> Now if you allow me, I do appreciate that not using generics and using 
> interfaces in your Append method things will work... I mean this 
> <https://goplay.tools/snippet/GCxBeHMfipf>... 
> I know... probably it won't fit to your coding issues... but what I feel 
> sometimes is that generics aren't necessary and we tend to make use. I 
> don't know.. forgive me if I'm wrong... just an opinion.
>
>
> El lunes, 23 de octubre de 2023 a las 0:01:47 UTC-3, tapi...@gmail.com 
> escribió:
>
>> 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:55 PM UTC+8 Mike Schinkel wrote:
>>
>> 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 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/c62243c1-d6af-41c1-b64d-be7d59063576n%40googlegroups.com.

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

[Mike Schinkel]

Yes, I was surprised too.  It actually took me the better part of a day 
trying to get this to work before finally posting to the list.

It turns out that this limit was actually documented by Ian Lance Taylor 
back in February 2023:

https://github.com/golang/go/issues/58650

Look for the section entitled *"Inferring based on interfaces."*

Again, it sure would be nice it this were possible, if for no other reason 
than to keep others being as time-inefficient as I was while trying to 
figure it out. 

-Mike
On Sunday, October 22, 2023 at 11:01:47 PM UTC-4 tapi...@gmail.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:55 PM UTC+8 Mike Schinkel wrote:
>
> 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 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/d4b59845-bd40-4c24-9838-8b1210dfc205n%40googlegroups.com.

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

[Mike Schinkel]

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 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/58122205-88a4-4a84-bddf-06a5a2c44197n%40googlegroups.com.

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

[Mike Schinkel]

@Axel Wagner — 

Thank you for adding clarity to this.

Yes, it would be nice if we could get this to be handled with better type 
inference. 

But unless and until then, we have our workarounds.

On Saturday, October 21, 2023 at 4:01:05 PM UTC-4 Axel Wagner wrote:

> This is purely a type-inference problem. If you explicitly instantiate 
> `Append`, it works: https://goplay.tools/snippet/15RFAPFPl3y
> Type inference is still relatively limited. It might become possible to at 
> some point omit the instantiation. I think this might be "Inferring based 
> on interfaces" 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.  
>>
>> For my use-case I need to be able to use other types besides []Suiter such 
>> as []int, e.g.:
>>
>> var n []int
>> n = Append(n, 1)
>> n = Append(n, 2)
>> n = Append(n, 3)
>> n = Append(n, 4)
>> for _, i := range n {
>> fmt.Printf("Int: %d\n", i)
>> }
>>
>> 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 
>>> > 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 T 
>>> > 
>>> > My code is complex so I wrote the simplest example for this email and 
>>> > here is part of that code: 
>>> > 
>>> > type Suiter interface { 
>>> > Suit() 
>>> > } 
>>> > func Append[T any](s []T, i T) []T { 
>>> > return append(s, i) 
>>> > } 
>>> > func main() { 
>>> > var s []Suiter 
>>> > 
>>> > //CAN GENERICS SUPPORT THIS? 
>>> > //s = Append(s, Clubs{}) 
>>> > //s = Append(s, Hearts{}) 
>>> > //s = Append(s, Diamonds{}) 
>>> > //s = Append(s, Spades{}) 
>>> > 
>>> > //VERSUS HAVING TO DO THIS? 
>>> > s = Append(s, Suiter(Clubs{})) 
>>> > s = Append(s, Suiter(Hearts{})) 
>>> > s = Append(s, Suiter(Diamonds{})) 
>>> > s = Append(s, Suiter(Spades{})) 
>>> > 
>>> > for _, suit := range s { 
>>> > fmt.Printf("Suit: %s\n", suitName(suit)) 
>>> > } 
>>> > } 
>>> > The full code is here in a playground. 
>>> > 
>>> > Note: My example func Append() makes no sense in real use, I only use 
>>> > it as it should be an easily understood example to show the syntax I 
>>> > am trying to illustrate. 
>>> > 
>>> > Question: Is there a way to write Append() such that I can call 
>>> > Append(s, Clubs{}) instead of having to write Append(s, 
>>> > Suiter(Clubs{}))? 
>>> > 
>>> > And if no, is there a chance that in the future Go generics will be 
>>> > able to support that level of type inference? 
>>> > 
>>>
>>> The pre-generics language handles this case: 
>>> https://go.dev/play/p/jaJF7LTSVYe 
>>>
>>> Is there something about your real case that makes this not acceptable? 
>>>
>>> -- 
>> 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/805dbd4a-e2a0-426e-b61f-45b9333803f5n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/805dbd4a-e2a0-426e-b61f-45b9333803f5n%40googlegroups.com?utm_medium=email_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/adfe6f16-92a5-4195-bcda-2412506c2410n%40googlegroups.com.

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

[Mike Schinkel]

No, that pre-generics case is not sufficient for my use-case.  

For my use-case I need to be able to use other types besides []Suiter such 
as []int, e.g.:

var n []int
n = Append(n, 1)
n = Append(n, 2)
n = Append(n, 3)
n = Append(n, 4)
for _, i := range n {
fmt.Printf("Int: %d\n", i)
}

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
> > 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 T
> > 
> > My code is complex so I wrote the simplest example for this email and
> > here is part of that code:
> > 
> > type Suiter interface {
> > Suit()
> > }
> > func Append[T any](s []T, i T) []T {
> > return append(s, i)
> > }
> > func main() {
> > var s []Suiter
> > 
> > //CAN GENERICS SUPPORT THIS?
> > //s = Append(s, Clubs{})
> > //s = Append(s, Hearts{})
> > //s = Append(s, Diamonds{})
> > //s = Append(s, Spades{})
> > 
> > //VERSUS HAVING TO DO THIS?
> > s = Append(s, Suiter(Clubs{}))
> > s = Append(s, Suiter(Hearts{}))
> > s = Append(s, Suiter(Diamonds{}))
> > s = Append(s, Suiter(Spades{}))
> > 
> > for _, suit := range s {
> > fmt.Printf("Suit: %s\n", suitName(suit))
> > }
> > }
> > The full code is here in a playground.
> > 
> > Note: My example func Append() makes no sense in real use, I only use
> > it as it should be an easily understood example to show the syntax I
> > am trying to illustrate.
> > 
> > Question: Is there a way to write Append() such that I can call
> > Append(s, Clubs{}) instead of having to write Append(s,
> > Suiter(Clubs{}))?
> > 
> > And if no, is there a chance that in the future Go generics will be
> > able to support that level of type inference?
> > 
>
> The pre-generics language handles this case:
> https://go.dev/play/p/jaJF7LTSVYe
>
> Is there something about your real case that makes this not acceptable?
>
>

-- 
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/805dbd4a-e2a0-426e-b61f-45b9333803f5n%40googlegroups.com.

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

[Mike Schinkel]

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 T

My code is complex so I wrote the simplest example for this email and here 
is part of that code:

type Suiter interface {
Suit()
}
func Append[T any](s []T, i T) []T {
return append(s, i)
}
func main() {
var s []Suiter

//CAN GENERICS SUPPORT THIS?
//s = Append(s, Clubs{})
//s = Append(s, Hearts{})
//s = Append(s, Diamonds{})
//s = Append(s, Spades{})

//VERSUS HAVING TO DO THIS?
s = Append(s, Suiter(Clubs{}))
s = Append(s, Suiter(Hearts{}))
s = Append(s, Suiter(Diamonds{}))
s = Append(s, Suiter(Spades{}))

for _, suit := range s {
fmt.Printf("Suit: %s\n", suitName(suit))
}
}
The full code is here  in a 
playground.

*Note: *My example func Append() makes no sense in real use, I only use it 
as it should be an easily understood example to show the syntax I am trying 
to illustrate.

*Question:* Is there a way to write Append() such that I can call Append(s, 
Clubs{}) instead of having to write Append(s, Suiter(Clubs{}))?

And if no, is there a chance that in the future Go generics will be able to 
support that level of type inference?

-- 
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/1b01e1d8-0814-4a77-a67a-399f52da1ff4n%40googlegroups.com.

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

[Mike Schinkel]

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 know what is required 
to *"install"* the libraries so that might be your sticking point that 
embed would not address. But if building on the user's machine is the real 
problem and you can distribute pre-build binaries then this might work for 
you.  

Basically Go reads a `//go:embed` comment, converts your files into Go 
source code, compiles that code, and then provides a package that allows 
you to write those files to disk from an your Go app before you need to 
load the libraries.

Maybe this will work for you?  If yes, would love to hear back how it 
worked out.

-Mike
On Monday, October 16, 2023 at 8:40:54 AM UTC-4 Bruno Albuquerque wrote:

> I guess you switched things here. Shared libraries (.so) need to be 
> available at engine. Static libraries (.a) are bagged into the binary.
>
> -Bruno
>
>
> On Sun, Oct 15, 2023, 3:55 PM Jan  wrote:
>
>> Thanks Tamas, this is useful information. 
>>
>> One of my libraries is using a `.a` library -- as opposed to `.so`, which 
>> is another level of complexity, since the library has to be available in 
>> runtime, not only in compile time -- and I'm going to follow your 
>> "incantation" suggestion.
>>
>>
>> On Sunday, October 15, 2023 at 7:55:55 AM UTC+2 Tamás Gulácsi wrote:
>>
>>> Neither I see a convenient way.
>>> BUT if you add a .go file into the directories where your precompiled 
>>> libraries live,
>>> then "go get" will download them too (and only those dirs that have .go 
>>> files in it).
>>>
>>> So your next mission is to prepare the right #cgo CFLAGS LDFLAGS 
>>> incantations to use those libraries.
>>>
>>> Jan a következőt írta (2023. október 14., szombat, 8:37:48 UTC+2):
>>>
 Thanks Tamás, I may not be understanding correctly, but after taking a 
 look at github.com/godror/godror, and the odpi subdirectory,
 I see it is including all the `.c` files on the fly 
 .

 A couple of reasons immediately come to mind, that make this not a 
 generically valid option:

 * ODPI library is all C code (see src 
 ) so it works 
 including in Go: my dependencies are C++/Rust code, for which I write a 
 small C wrapper (or for Rust just `extern "C"`). Also architecture 
 dependent compilation is different in C++/C/Rust code ...
 * The C++ libraries I'm including have sub-dependencies of themselves 
 (one of which is llvm). It uses Bazel to organize it, and to manually move 
 all the required C++ files to a directory would be years of work :) Plus 
 would require me to slave to maintain things in sync. 
 * The C++ libraries take hours to compile ... I don't want to impose 
 this to users of my libraries.

 I think the only way to work this out is distributing the pre-compiled 
 C++/Rust libraries, so the Go simply refer to them (and we get the fast 
 compilation times from Go). But then, how to best distribute them in an 
 automatic fashion, so that users don't need to one by one figure out how 
 to 
 install them (and clean up them later if they are no longer using...) ?

 Or maybe there is another convenient way I'm not seeing ?


 On Thursday, October 12, 2023 at 6:39:34 PM UTC+2 Tamás Gulácsi wrote:

> Can't you build (make go build for you) those libraries?
> For example, see github.com/godror/godror just includes the sources 
> of that third party library in an "odpi" subdir, and with
> ```
> /*
> #cgo CFLAGS: -I./odpi/include -I./odpi/src -I./odpi/embed
>
> #include "dpi.c"
>
> */
> import "C"
> ```
> it is compiled automatically.
>
>
> Caveat: for "go get" to download a directory, it must include a sth.go 
> file ("require.go" in the odpi/* subdirs).
> But it may work that your precompiled libs in a subdir, with a mock 
> .go file gets downloaded.
> But how will it found by your lib/app ?
>
> Tamás
>
>
> Jan a következőt írta (2023. október 12., csütörtök, 8:14:41 UTC+2):
>
>> Thanks Richard. Indeed, as you pointed out the downside is the 
>> bloating of the git repo, but it makes sense.
>>
>> But does the user have to manually clone the repository and move the 
>> `.a` file to, let's say, /usr/local/lib, or does a simple `go get` 
>> magically does everything ?
>>
>>
>> On Thursday, October 12, 2023 at 2:29:21 AM UTC+2 Richard Wilkes 
>> wrote:
>>
>>> It isn't a great solution, but I currently include the built library 
>>> files and necessary headers in the git 

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

[Mike Schinkel]

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:

func (m MyHandler) Handle(ctx context.Context, r slog.Record) error {
return m.Handler.Handle(ctx, r)
}

See https://goplay.tools/snippet/qw07m0YflLd

I know about this because just this past weekend I was trying to write a
TeeHandler to output the default to the screen and JSON to a file just this
past weekend and ran into an infinite loop problem with the default handler.

I tried my best to figure out why it needed to be structured the way it was
in that it seems to call itself recursively. I wanted to post a question to
this list to see if there was a workaround, or if not to see if there might
be interest in allowing it to work, but I could not get my head around it so
eventually gave up and just used the TextHandler instead.

Shame though. It would be nice to be able to reuse the default handler but
AFACT it is not possible (though if I am wrong I would love for someone to
show me how to get it to work.)

-Mike

On Monday, August 28, 2023 at 12:50:50 PM UTC-4 Tamás Gulácsi wrote:

slog.SetDefault(slog.New(myHandler{Handler:slog.Default().Handler}))

vl...@mailbox.org a következőt írta (2023. augusztus 28., hétfő, 15:06:37 
UTC+2):

Hi, 

When reading trough the log/slog documentation, it seems one can create 
a logger with a different handler, which is either NewTextHandler or 
NewJSONHandler. 

Why can't I configure the defaultHandler? Let's say I want my logger to 
behave exactly like the defaultHandler, but output to a logfile or 
Stdout instead. 

The defaultHandler's output is different compared to the NewTextHandler: 

slog.Info("ok"), gives me: 

INFO ok 

The NextTextHandler gives me: 

level=INFO msg="ok" 


Regards, 

-- 
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/f35b9d1a-86bf-446b-a0c7-54cb197b0116n%40googlegroups.com.

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

[Mike Schinkel]

Hi Kurtis,

> Is the code after the "end" label ever going to be more complicated than a 
> simple "return err"? If not then I don't see the point of the goto statements.

Yes, very often. 

I could show examples but don't want to trigger bike shedding.

If you want to see some I'll be happy to send off-list. 

> Also, since you named the return value you can simply do "return" rather than 
> "return err" (personally I'm not a fan of bare returns that implicitly return 
> the named return parameters).

I started using this pattern to avoid multiple return statements which can be 
problematic when you want the debugger to stop before a function returns. If 
you miss breakpointing a return you can waste time chasing your tail.

Most recommend against naked returns so I prefer one set of return values 
instead of many repeating ones.

I have also found other beneficial reasons to use the pattern than just the 
debugging concern, which I can discuss off-list if you like.

> That function can be ten lines (25%) shorter

Length is one useful metric, but there are other metrics I consider too.

> I would argue would be clearer since the reader doesn't have to look at what 
> follows the "end" label.


The pattern has an `end:` label always at or near the only return in the func, 
and (almost) never any other labels so a reader need not look for it 
after recognizing the pattern.
 

-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 interested in exploring, 
> unfortunately.
> 
> Let me instead present some real code from my current project, specifically 
> the variable declarations on the lines 35-36 of the `Process()` method of 
> `*FileProcessor` where the variables declared at the top are not referenced 
> after the label:
> 
> https://github.com/newclarity/wpfr/blob/88d1289a90646f59ec4233eed0e421f1eae36332/pkg/wpfr.go#L34-L75
>  
> <https://github.com/newclarity/wpfr/blob/88d1289a90646f59ec4233eed0e421f1eae36332/pkg/wpfr.go#L34-L75>
> 
> Is the code after the "end" label ever going to be more complicated than a 
> simple "return err"? If not then I don't see the point of the goto 
> statements. Also, since you named the return value you can simply do "return" 
> rather than "return err" (personally I'm not a fan of bare returns that 
> implicitly return the named return parameters). That function can be ten 
> lines (25%) shorter and I would argue would be clearer since the reader 
> doesn't have to look at what follows the "end" label.
> 
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank

-- 
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/3495CCD1-6509-4027-9F2B-082B205E1568%40newclarity.net.

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

[Mike Schinkel]

Hi Ian,

Thank you for the explanation. That makes perfect sense.

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, 
unfortunately.

Let me instead present some real code from my current project, specifically the 
variable declarations on the lines 35-36 of the `Process()` method of 
`*FileProcessor` where the variables declared at the top are not referenced 
after the label:

https://github.com/newclarity/wpfr/blob/88d1289a90646f59ec4233eed0e421f1eae36332/pkg/wpfr.go#L34-L75

However, your links to https://go.dev/issue/27165 and 
https://go.dev/issue/26058 <https://go.dev/issue/26058> seems to be addressing 
exactly the concern, so I will follow up with use-cases on those tickets after 
spending enough time with them to determine which one addresses my use-cases 
better.

Again, thank 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 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 made with 
>> the Go compiler.
>> 
>> 
>> Question. Was it:
>> 
>> 
>> 1. Somehow logically required by the compiler, and if so can you elaborate 
>> why?
>> 
>> 2. A design decision made, and if so what what the rationale for the design 
>> decision?
>> 
>> 3. A limitation place on GoLang for some other reason, and if so, what and 
>> why?
>> 
>> 
>> I have prepared an example showing use of `goto` that compiles and one that 
>> does not at this playground URL:
>> 
>> 
>> https://goplay.tools/snippet/tSAbWhmiCZK
>> 
>> 
>> Hoping to hear from someone who actually knows why the decision was made as 
>> opposed to someone who might just be guessing at the reason.
> 
> Consider a function like
> 
> func F() {
>goto lab
>x := 1
> lab:
>fmt.Println(x)
> }
> 
> This function is forbidden today.  If it were permitted, what should it print?
> 
> If the answer to that question seems obvious, what about a case like
> 
> func F() {
>goto lab
>x := func() int {
>fmt.Println("setting x")
>return 1
>}()
> lab:
>fmt.Println(x)
> }
> 
> Should that print "setting x"?
> 
> Rather than attempt to answer these kinds of questions, Go simply
> forbids cases like this.
> 
> Note that Go is not the only language with this restriction.  This
> similar C++ function is invalid, because the goto crosses the
> initialization of the variable.
> 
> int f() {
>goto lab;
>int x = 1;
> lab:
>std::cout << x;
>return 0;
> }
> 
> If you are interested in this topic you may be interested in
> https://go.dev/issue/27165 and https://go.dev/issue/26058.
> 
> Ian

-- 
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/B066901D-A60A-4F08-A1BF-D2C307910548%40newclarity.net.

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

[Mike Schinkel]

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 made with the Go 
compiler.

Question. Was it:

1. Somehow logically required by the compiler, and if so can you elaborate why?

2. A design decision made, and if so what what the rationale for the design 
decision?

3. A limitation place on GoLang for some other reason, and if so, what and why?

I have prepared an example showing use of `goto` that compiles and one that 
does not at this playground URL: 

https://goplay.tools/snippet/tSAbWhmiCZK

Hoping to hear from someone who actually knows why the decision was made as 
opposed to someone who might just be guessing at the reason.

Thank you in advance.

-Mike

-- 
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/B6B94DDC-323C-4C4C-9292-903421EC7103%40newclarity.net.

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

[Mike Schinkel]

If I understand what you are asking then JetBrains GoLand does. 

I do not know if there is a way to use the keyboard, but it does provides 
links you can click when it displays the call stack on panic.

-Mike

On Saturday, August 26, 2023 at 8:33:08 AM UTC-4 Jason E. Aten wrote:

> Is there any IDE that allows you to jump through a stack trace like emacs 
> does?
>
> e.g. If I have a panic on a run, with two keystrokes I can jump to the 
> origin
> of the panic, and then their caller, and then the parent caller, and then 
> up to
> the grandparent on the call stack... instantly. I've never found this 
> essential
> functionality elsewhere, but maybe I'm just not familiar... A friend of 
> mine tried
> to add it to Visual Studio and gave up... it was just too hard for VS. But 
> maybe JetBrains has it??
>
> I'd love to try an 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.  
>>
>> Generally, ALM addresses concerns broader than individual concerns 
>> whereas IDEs are more focused on individual productivity.
>>
>> Just my opinion, but I would expect you'd be better off finding an ALM 
>> solution and then an IDE that integrates with that ALM, or vice versa, i.e. 
>> find an IDE that integrates with an ALM and then use that ALM.
>>
>> #fwiw
>>
>> -Mike
>> On Wednesday, August 23, 2023 at 7:21:46 AM UTC-4 alex-coder wrote:
>>
>>> Hi All !
>>>
>>> Considering that IBM's punch cards were bearing at least twice, I would 
>>> vote for them. :-)
>>>
>>> Of cource I do agree with them who wrote that to feel comfortable "under 
>>> fingers" is great !
>>>
>>> So, the tasks to code - they are different. 
>>> Sometimes it is possible to keep all the details regards to the task in 
>>> a head or several.
>>> Sometimes it is nesessary to write say a hard copy of them(details) on a 
>>> paper with a different size.
>>>
>>> But in case the task from the area of the "poorly formalized". You spend 
>>> paper quickly. :-)
>>>
>>> The Luke Crook points to:
>>> https://en.wikipedia.org/wiki/Application_lifecycle_management
>>>
>>> I will simplify the task somewhat and take from ALM for example even 
>>> less than SDLC, namely:
>>> requirements, design, implementation, testing, deployment.
>>>
>>> 1. Requirements must be described somewhere.
>>> 2. Design artifacts should reflect requirements.
>>> 3. Design decisions refer to objects and messages that
>>> implemented in the form of classes and operations.
>>> 4. Each operation must pass at least one test.
>>> All tests must be passed successfully.
>>> 5. The application 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 Schinkel: 
>>>
>>>> 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 nicely.
>>>>
>>>> Can you elaborate on the specific dependencies you are trying to 
>>>> manage?  In specific, vs generalities.
>>>>
>>>> -Mike  
>>>>
>>>

-- 
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/c8b2e710-240b-4f4a-ae80-3142578673d3n%40googlegroups.com.

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

[Mike Schinkel]

Yes, as Luke Crook mentioned I think those requirements are more ALM 
functionality than IDE functionality.  

Generally, ALM addresses concerns broader than individual concerns whereas 
IDEs are more focused on individual productivity.

Just my opinion, but I would expect you'd be better off finding an ALM 
solution and then an IDE that integrates with that ALM, or vice versa, i.e. 
find an IDE that integrates with an ALM and then use that ALM.

#fwiw

-Mike
On Wednesday, August 23, 2023 at 7:21:46 AM UTC-4 alex-coder wrote:

> Hi All !
>
> Considering that IBM's punch cards were bearing at least twice, I would 
> vote for them. :-)
>
> Of cource I do agree with them who wrote that to feel comfortable "under 
> fingers" is great !
>
> So, the tasks to code - they are different. 
> Sometimes it is possible to keep all the details regards to the task in a 
> head or several.
> Sometimes it is nesessary to write say a hard copy of them(details) on a 
> paper with a different size.
>
> But in case the task from the area of the "poorly formalized". You spend 
> paper quickly. :-)
>
> The Luke Crook points to:
> https://en.wikipedia.org/wiki/Application_lifecycle_management
>
> I will simplify the task somewhat and take from ALM for example even less 
> than SDLC, namely:
> requirements, design, implementation, testing, deployment.
>
> 1. Requirements must be described somewhere.
> 2. Design artifacts should reflect requirements.
> 3. Design decisions refer to objects and messages that
> implemented in the form of classes and operations.
> 4. Each operation must pass at least one test.
> All tests must be passed successfully.
> 5. The application 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 Schinkel: 
>
>> 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 nicely.
>>
>> Can you elaborate on the specific dependencies you are trying to manage?  
>> In specific, vs generalities.
>>
>> -Mike  
>>
>

-- 
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/bd651903-e4ff-41c9-b1df-260d1d0937ban%40googlegroups.com.

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

[Mike Schinkel]

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 nicely.

Can you elaborate on the specific dependencies you are trying to manage?  
In specific, vs generalities.

-Mike  

-- 
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/b36b1c63-53bb-4200-95c4-80152faf9c9fn%40googlegroups.com.

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

[Mike Schinkel]

Hi Henry,

For clarity, my comments were not intended to call out any lack of 
motivation — which you keyed on — but instead focus on the fact no silver 
bullet is likely to exist that addresses error handling without new 
language features, and that many Go developers want error handling 
addressed. 

In hindsight I would remove the mention of motivation if I could so as not 
to be misinterpreted. #justfyi  #fwiw

-Mike

On Monday, July 3, 2023 at 2:03:00 AM UTC-4 Henry wrote:

> I don't think it has anything to do with motivation, Mike. The problem I 
> see is that there is no good enough solution that offers a substantial 
> benefit over the current approach. Many error handling proposals involve 
> rearranging the code with a few line savings, and sometimes at the cost of 
> readability. Note that there is no perfect solution to error handling to 
> date. Even 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 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 people ask for new language features it is possible to 
>> simulate what is being requested via some combination of convention and/or 
>> reusable package(s).
>>
>> But sadly, at least in my experience, most teams are only motivated to 
>> continue the approach they chose initially and not interested in changing 
>> to a new non-standard approach, and this is the case for almost anything 
>> proposed as *"something we can do today"* unless it has already 
>> established itself as a defacto-standard way to approach the problem.
>>
>> Although some conventions and some packages come close to achieving 
>> defacto-standard status — Cobra for CLI is the closest one I can think of 
>> for Go even though it is far from defacto — the use of most conventions 
>> and/or packages required a motivated team or at least a motivated 
>> individual. 
>>
>> The simple fact is even if the core Go team adds a new feature for error 
>> handling, many will still not embrace it, at least not for a while.  But if 
>> there is any chance a motivated individual has to get an unmotivated team 
>> to adopt a new approach, it almost has to be an approach advocated for by 
>> the core Go team, and with new features that make that approach possible.
>>
>> So while it may be great for motivated individuals and the rarer 
>> motivated teams to hear about how we can do things today without the new 
>> language features we are requesting — and the developer of the package that 
>> enables it is certainly motivated — there is little chance a *"can do 
>> today"* approach will address the reason people ask for a new language 
>> feature.  And especially for error handling improvements, which is near the 
>> top of the things people want to see improved in Go, per the Q1 2023 Go 
>> Developer Survey[1]. 
>>
>> #fwiw
>>
>> -Mike
>>
>>  [1] Go Developer Survey 2023 Q1 Results - The Go Programming Language 
>> (golang.org) <https://tip.golang.org/blog/survey2023-q1-results>
>>
>

-- 
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/9cfdf812-f9fa-4baa-9402-0e60bc03ef00n%40googlegroups.com.

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

[Mike Schinkel]

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 people ask for new language features it is possible to 
simulate what is being requested via some combination of convention and/or 
reusable package(s).

But sadly, at least in my experience, most teams are only motivated to 
continue the approach they chose initially and not interested in changing 
to a new non-standard approach, and this is the case for almost anything 
proposed as *"something we can do today"* unless it has already established 
itself as a defacto-standard way to approach the problem.

Although some conventions and some packages come close to achieving 
defacto-standard status — Cobra for CLI is the closest one I can think of 
for Go even though it is far from defacto — the use of most conventions 
and/or packages required a motivated team or at least a motivated 
individual. 

The simple fact is even if the core Go team adds a new feature for error 
handling, many will still not embrace it, at least not for a while.  But if 
there is any chance a motivated individual has to get an unmotivated team 
to adopt a new approach, it almost has to be an approach advocated for by 
the core Go team, and with new features that make that approach possible.

So while it may be great for motivated individuals and the rarer motivated 
teams to hear about how we can do things today without the new language 
features we are requesting — and the developer of the package that enables 
it is certainly motivated — there is little chance a *"can do today"* approach 
will address the reason people ask for a new language feature.  And 
especially for error handling improvements, which is near the top of the 
things people want to see improved in Go, per the Q1 2023 Go Developer 
Survey[1]. 

#fwiw

-Mike

 [1] Go Developer Survey 2023 Q1 Results - The Go Programming Language 
(golang.org) 

-- 
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/8dad58af-3c67-4db8-9495-094b6fcbfb70n%40googlegroups.com.

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

[Mike Schinkel]

Hi Sven,

> *What is the difference to if err != nil { goto  } ?*

Thanks you for asking.

If you run *go fmt*  on a file that contains the formatting you ask about 
the line will be expanded to the 3 lines, which brings us back to status 
quo:

*if *

*err != nil { goto  } *Of course *go fmt* could be modified, but 
allowing that formatting strikes me as even more *non*-Go idiomatic than 
added a *when* command.
That said, I am not personally advocating for a *when* command, I was just 
comparing *when err != nil goto * with the OP and proposer's *when 
err handle *. #fwiw -Mike P.S. I think there is a approach similar to 
that proposed that simplify error handling even more as it would not 
require any code where this proposal requires *when* — a proposal that 
could also kill another bird with the one stone — but as the tendency of 
online programming communities is to shoot 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. Juni 2023 um 07:04:

*when err!=nil goto  *


What is the difference to `if err != nil { goto  }` ?

Go is awesome, because it does _not_ more and more syntax, especially with 
subtle nuances that one has to remember.

-- 
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/daa56174-b570-4d73-91b8-f6bfa5ec1693n%40googlegroups.com.

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

[Mike Schinkel]

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 having to jump back much harder to reason about than 
   jumping forward to find the error handler.
   2. Does not require handling the error in a closure or other *func* as 
   the former adds a lot of visual noise and the latter complicates by 
   creating a different variable scope. 


It is in many ways similar to a proposal I have been planning on preparing 
but have no found the right opportunity. Possibly this is the right 
opportunity and maybe taking aspects of this and aspects of mine we could 
find a solution beneficial enough that Ian Lance Taylor would consider it a 
big enough improvement. I'll try to follow up on that soon.

As for the specifics of this proposal:

1. I think *when err handle * is a bit too much magic.  I think it 
would be more Go-like if it were instead:

   *when err!=nil handle *

I know this makes for more repeated syntax, but within the scope of this 
proposal I do not think you can avoid it without it adding magic.  I do 
think that could be addressed, and what I have in mind addresses that. But 
I wanted to first comment on your proposal, not introduce mine.

2. As for *check* as you have proposed it — handling zero return values — 
it seems to add more magic, and that it would only work in selected 
use-cases so it might be best to omit this from the proposal?

3. I do like the concept of labels that do not fall through to the code in 
the next label.  However, it is not exactly clear how they should work.  Do 
your handlers always have to have a *return* themselves?

   
*func foo()error {*
* ...*
* when err != nil handle cleanup*
* ...*
* return nil*

   :*cleanup:*
 *doCleanup()*
* return err*
   *}*

4. When you are in a handler, is there any way to correct the problem and 
*resume* or *retry* the code where you left off without resorting to using 
*goto* and labels?

5. I do not think you need the new keyword *handle*, i.e. I think this 
would be sufficient to use *goto* instead since the syntax of your handler 
label with the preceding colon should be sufficient to distinguish between 
the two:

   
*when err!=nil goto *
6. If you use *goto* instead of *handle* then you actually have two 
orthogonal features, the latter one being labels that do not fall through 
that can be used without when. Those could be proposed as a feature in 
their own right.

7. How would your proposal handle shared cleanup?  As we can see from the 
following example I have to call *db.Rollback()* for every error case, and 
I would really rather only have to call it in one place in the case.  Does 
your proposal have a solution for this that I missed?

   
*func (db *Database) Transfer(from, to Account, amount int) (err error) {*  
   
*err = db.Begin()* *when err != nil **goto noTrans*
 *if **from*
*.Balance() >= amount {* 
* goto noFunds* *}*
 *err = **from*
*.Withdraw(amount)* *when err != nil **goto **noWithdraw*
 
*err = to.Deposit(amount)* *when err != nil **goto **no**Deposit*
 
*err = db.Commit()* *when err != nil **goto **no**Commit*
 
*return nil* 
*:noCommit:*   
*db.Rollback()*   
*return fmt.Errorf("cannot commit; %w", err)* 
*:noDeposit:*   
*db.Rollback()*   
*return fmt.Errorf("cannot deposit; %w", err)* 
*:noWithdraw:*   
*db.Rollback()*   
*return fmt.Errorf("cannot withdraw; %w", err)* 
*:noTrans:*   
*db.Rollback()*   
*return fmt.Errorf("cannot begin transaction; %w", err)* 
*:noFunds:*   
*db.Rollback()*   *return errors.New("no funds")*
 *} *8. Using the example above, is there not a way to also annotate 
the error in a shared manner vs. having to have all the different handle 
labels and duplicated code?

-Mike

-- 
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/5e180c59-9761-40e7-8fdf-10fb5fc1492en%40googlegroups.com.

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

[Mike Schinkel]

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 that doesn't count MacBooks or iMacs.) They are an excellent 
machine for someone who can't afford a new Mac to buy and needs to set up 
as a home server for macOS-related work.

There are numerous videos on YouTube about using 2010 and 2011 Mac Minis 
(and even more about using mid 2012):

https://youtu.be/gTqlVdSfGK0
https://youtu.be/iqn2xGt3sos
https://youtu.be/9yFewmhDymc

Anyway, if GoLang stops supporting this hardware then these would no longer 
viable for testing and/or running newer Go code on macOS, albeit an earlier 
O/S version.

Anyway, I know that a lot has to be taken into consideration but I wanted 
to add more details about how much hardware like this is available and what 
people might be using it for.

-Mike
P.S. I'll follow up over on the ticket, too.
On Friday, February 3, 2023 at 1:36:03 PM UTC-5 Ian Lance Taylor wrote:

> On Fri, Feb 3, 2023 at 9:42 AM Jason E. Aten  wrote:
> >
> > Primarily the argument is that High Sierra is the most stable version of 
> OSX,
> > and thus preferred by those who highly value stability and reliability. 
> It is also the only
> > version supported on older hardware, such as my 2015 mac book pro. These 
> mac books
> > have superior keyboards and better access to USB ports and HDMI ports. 
> They are readily available on
> > the used market for testing purposes. Just last week I bought my wife 
> one for only $320.
> > There are tens if not hundreds of listings on ebay.
>
> Thanks. Required for older hardware seems like a valid reason to me.
>
> Please comment on https://go.dev/issue/57125, which is the proposal
> for dropping High Sierra support.
>
> Ian
>
>
> > On Fri, Feb 3, 2023 at 12:34 PM Ian Lance Taylor  
> wrote:
> >>
> >> On Fri, Feb 3, 2023 at 8:34 AM Jason E. Aten  wrote:
> >> >
> >> > The Go 1.20 release notes say:
> >> >
> >> > > Go 1.20 is the last release that will run on macOS 10.13 High 
> Sierra or 10.14 Mojave. Go 1.21 will require macOS 10.15 Catalina or later.
> >> >
> >> > This is sad to hear, since High Sierra is the preferred (most stable) 
> available mac operating system.
> >> >
> >> > Please consider continuing to support High Sierra in future Go 
> versions.
> >>
> >> Our general guideline is that we stop supporting an operating system
> >> when that operating system is itself no longer supported. According
> >> to Wikipedia, Apple stopped supporting High Sierra in 2020, so
> >> presumably people should be moving off it. It's also going to be
> >> steadily harder for us to test it. What's the argument for us
> >> continuing to support it?
> >>
> >> Ian
>

-- 
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/a3e67455-c433-49bc-8130-0cec5c87b502n%40googlegroups.com.

Re: [go-nuts] Help Bootstrapping to ESXi

[Mike Schinkel]

> 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 server installed on. If it's x86 or 
> any other architecture that the Go toolchain already supports you don't have 
> to make a bootstrap version for yourself. If it's not one of those, then it 
> might be easier to compile your binaries on a different machine with the GOOS 
> and GOARCH flags to specify your target OS (in this case Linux) and whatever 
> architecture you are trying to build for.
> 
> Just to be sure, I just wrote a simple "Hello" binary in Go on Ubuntu. Did a 
> simple 'go build' so that it would target my host OS and architecture then 
> SCP'd it to an ESXi host I have available for testing also on x86. I was able 
> to run this binary without issue within the shell of the ESXi server.

That is quite surprising. 

Brett sent me an off-list email and so I explored compiling and running Go on 
my VMware ESXi 7.3 server but ran into problems.

I SSHed into the ESXi server, used wget to pull down the Golang tarball, used 
tar to extract it from within the ESXi shell, and then used `go run hello.go` 
in the ESXi shell and got a runtime error of "epollwait on fd 4 failed with 
38."  

That error is basically the same error from this ticket for an unsupported 
older version of CentOS: https://github.com/golang/go/issues/24980 


>From there I realized it was beyond my skills to pursue and so I dropped it.

I wonder if anyone on the list can speak to the difference between what you 
(Anthony) did and what I did, and Anthony's worked and mine didn't?  

Further, I wonder if other runtime errors are waiting as soon as other packages 
are pulled in that need greater access to the O/S?

Finally, I wonder if someone on the list would be able to help me get around 
that error and continue exploring the compilation and execution of Go programs 
on an ESXi server from within the ESXi SSH shell?

Thanks in advance for any insight into this.

-Mike

> 
> Hopefully that provides some insight.
> 
> On Monday, January 9, 2023 at 3:20:15 PM UTC-6 brett@gmail.com wrote:
> Good afternoon, hoping to get a little help.
> 
> I am trying to build a bootstrap candidate that allows me to build and run go 
> programs on an ESXi server.
> 
> I am following this 
> 
>  blog, and the issue is that my bootstrap candidate doesn't contain the go 
> binary in the bin directory that is required when running all.bash.
> 
> Any help would be greatly appreciated.
> 
> -- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "golang-nuts" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/golang-nuts/u2hKqDg24R4/unsubscribe 
> .
> To unsubscribe from this group and all its topics, 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/05acc8d9-fe55-49fc-bf97-2b51e4d6c5e2n%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/26712CF9-A5A6-47D5-B533-CF69FC9EA458%40newclarity.net.

[go-nuts] Re: Help Bootstrapping to ESXi

[Mike Schinkel]

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 bootstrap candidate that allows me to build and run 
> go programs on an ESXi server.
>
> I am following this 
> 
>  blog, and the issue is that my bootstrap candidate doesn't contain the 
> go binary in the bin directory that is required when running all.bash.
>
> Any help would be greatly appreciated.
>

-- 
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/9fc7173f-fc01-4fcf-8ce4-a329011cdf75n%40googlegroups.com.

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

[Mike Schinkel]

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 an error 
occurs the *only thing* I would want to do is an immediate return, which I 
*almost 
never* do. 

Instead I almost always annotate errors with context to help when debugging 
logs, and often do some analysis to potentially resolve the error — such as 
a retry, or ignoring when not relevant — and the current structure of Go 
error handling, while I am sure it could be improved somehow, currently 
works extremely well for this.

Also, I don't really like the idea of having to create a different function 
located a distance away in terms of code location from where the error 
occurs in order to be able to handle an error.  I much better how Go 
optimizes my ability to address an error exactly at the point in which I 
recognize that an error occurred.

As an aside, I would rather see Go make it easier to annotate errors with 
context in a way that does not require so much duplication of effort 
throughout the code than make it easier to just return early.

So from a concerned-for-my-own-interests perspective if something that 
makes it easier to do an immediate return on `err!=nil` were added to Go 
and it were to be used ubiquitously it would make it much harder to me to 
stick with Go moving forward. #fwiw

-Mike

On Wednesday, November 9, 2022 at 4:42:55 PM UTC-5 paurea wrote:

> On Wed, Nov 9, 2022, 20:47 Ian Lance Taylor  wrote:
>
>> On Wed, Nov 9, 2022 at 10:40 AM Gorka Guardiola  wrote:
>>
>> Seems related to https://go.dev/issue/54361, although due to inject it
>> is not the same.
>>
>
> I hadn't seen that proposal.
>
>>
> It is similar in the sense that it is a more powerful return, but this is 
> much more limited and restricted (1 call level explicitly annotated in the 
> function call vs. returning N levels to a label/function name). In that 
> sense it is a subset of what can be done with that change but more 
> structured. I feel it could be easier to reason about.
>
> The changes to the language, runtime, compiler... are also quite more 
> limited. The bad part is the need for two new reserved words.
>
> G.
>
>
>

-- 
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/de56e687-9db7-476c-b042-eade94d4f00fn%40googlegroups.com.

Re: [go-nuts] Preemptive interfaces in Go

[Mike Schinkel]

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*™ 
> 
>  
> -- (likely from the scripts in this repo 
> ) which goes a long way 
> towards explaining why so much of the code looks like Java written in Go 
> syntax.
>
 
Sounds like your new shop is programming in GWAIJ[1].  

Yeah, I have run into that in my current shop, too.

On Tuesday, August 9, 2022 at 3:35:48 PM UTC-4 rog wrote:
> One significant argument against preemptive interfaces is that you can't 
add a method to an interface type without breaking compatibility.

Exactly.  Which is why single method (or at least only a few method) 
interfaces are preferred in Go vs. large, monolithic interfaces.

I do see the value in having an interface with methods used as a contract 
for an extension — like a database driver  — but those need to be very 
carefully considered with all efforts made up front for them to be as 
complete as possible upon publishing. Otherwise when modifying those 
interfaces later to add requirements that were not previously understood 
all the client code that uses them break or you need to version your 
interfaces, e.g. DBDriver, DBDriver2, etc,  which I have not seen done 
(much?) in Go. 

But I am sure I am preaching to the choir on this broader point.


On Wednesday, August 10, 2022 at 4:17:21 AM UTC-4 Henry wrote:
> Someone also mentioned that you cannot add methods to an interface 
without breaking compatibility. The only case that this is true is when you 
have no control over the implementation. If you have control over the 
implementation, I don't see why you can't add methods to an interface and 
change its implementation in the same way you would to a struct if you are 
to return a struct. 

In my experience having control over the implementation is not a 
black-and-white thing, unless you are the sole developer on a project. 

What I have found is a desire to limit changes in code reviews that could 
affect other parts of the code and a desire to keep commits small to make 
reviewing code easier.  While I don't always agree with my colleagues on 
that rationale in all cases, these are still organizational pressures that 
developers can face. Changing an interface can cause large ripples in a 
tested and approve codebase requiring many different files to be updated, 
and again in my experience those are often frowned on.  

Which, the moral of the story is: strive not to change interfaces once 
published and in use when and if you can avoid it.

-Mike
[1] Go Written As If Java

-- 
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/c632a282-21b3-4f3c-8594-0d3f8fa3a884n%40googlegroups.com.

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

[Mike Schinkel]

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 you Sebastian Binet, I need to check more gonum project.
>
> You are right drv drv that Python is not true culprit here. Problem is 
> that it seems a bad written code. Maybe after a while I will change my mind 
> about it, but it looks bad right now.
>
> Here you have list of dependencies that came with this code.
> attrs==21.2.0
> azure-functions==1.7.2
> certifi==2021.5.30
> charset-normalizer==2.0.4
> graphviz==0.18
> idna==3.2
> jmespath==0.10.0
> jsonschema==4.1.2
> Pillow==8.4.0
> pyrsistent==0.18.0
> raven==6.10.0
> requests==2.26.0
> svg.path==4.1
> urllib3==1.26.6
>
> I have a bunch of problem with it. I normal use Python 3.6, because it is 
> standard Python on Ubuntu OS and I'm fine with that. But, jsonschema v. 
> 4.1.2 wasn't available on Python 3.6. After installing new version of 
> Python I now have a problem with Pillow. I still don't know what to do with 
> that, so they told me to switch to Windows. And I just begin with it.
>
> Best,
> Kamil
>
> sobota, 5 lutego 2022 o 16:43:46 UTC+1 drv drv napisał(a):
>
>> I don't know the background of this Python code but *" It seems 
>> underdeveloped, buggy and running it first time is a pain, because of 
>> dependencies. "* is not a language problem.
>> I cannot imagine any dependencies in this kind of program.
>> JSON "equals" dictionaries in case of Python and it supports natively so 
>> it is quite fast and can be write very simple and elegant code.
>> It is true that GO is faster (in this case I guess 2x on single core) but 
>> if you cannot take advance of goroutines (and multicore) use Python.
>>
>> On Thursday, 3 February 2022 at 23:26:14 UTC+1 kziem...@gmail.com wrote:
>>
>>> Hello,
>>>
>>> I was handed proof-of-concept app written in Python. It seems 
>>> underdeveloped, buggy and running it first time is a pain, because of 
>>> dependencies. Basically it need to read some graphs stored in JSON files 
>>> and manipulated them accordingly and write them to JSON files again.
>>>
>>> It seems that porting it now to more suitable language is worth a gain 
>>> at this stage and I wonder if Go is a good choice? I read and watch many 
>>> Ian Lance Taylor presentations about generics, so I know that only that 
>>> generic graph (tree) data structure is something that can be a pain,  but 
>>> in this case it would be were small issue. It seems that we have only few 
>>> data types to be stored in graph, mostly strings and ints.
>>>
>>> I'm not true gopher, so I don't know if Go is proper choice for this 
>>> task. I don't believe that Python is any better, but maybe I should check 
>>> another language.
>>>
>>> Also, if someone know better thing to sore graphs than JSON, I would 
>>> appreciate it any suggestion.
>>>
>>> I don't write anymore about this app, since I don't know if company 
>>> allows for it.
>>>
>>> Best regards,
>>> Kamil
>>>
>>

-- 
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/264afa9b-1acf-4695-b0b8-14dc25e3e254n%40googlegroups.com.

Re: [go-nuts] Generics and parentheses

[Mike Schinkel]

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 — but perhaps those can be addressed in the 
future?

All in all, I think the team has come up with a really good approach to 
generics, much better than the prior proposals.

-Mike

P.S. If there is one thing that piqued my interest about this thread it 
was Geoff Speicher's suggestion of a "generic" keyword, assuming type 
inference could be addressed. That approach would be even easier to reason 
about than the current proposal, I think.  That said, the current proposal 
is very good if type inference can not be addressed in Geoff Speicher's 
suggestion.

On Wednesday, July 22, 2020 at 8:02:55 PM UTC-4 Russ Cox wrote:

> So it sounds like everyone is in favor of the entire generics proposal and 
> all the semantics, and all we have left to hammer out is the bracket 
> characters? Do I have that right?
>
> Best,
> Russ
>
>
>
>

-- 
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/56865922-75d0-43c6-8a4e-6777c39fce25n%40googlegroups.com.

[go-nuts] Re: Generics and parentheses

[Mike Schinkel]

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, good choice.

Just one person's opinion, FWIW.

On Tuesday, July 14, 2020 at 5:56:01 PM UTC-4 gri wrote:

> We have received a variety of feedback on the generics draft design 
> 
>  
> (blog ). Thanks to everyone 
> who took the time to read it, play with generics code in the playground 
> , file issues, and send us their thoughts.
>
> Not unexpectedly, many people raised concerns about the syntax, 
> specifically the choice of parentheses for type parameter declarations and 
> generic type and function instantiations.
>
> A typical computer keyboard provides four easily accessible pairs of 
> single-character symmetrical "brackets": parentheses ( and ), square 
> brackets [ and ], curly braces { and }, and angle brackets < and >. Go uses 
> curly braces to delineate code blocks, composite literals, and some 
> composite types, making it virtually impossible to use them for generics 
> without severe syntactic problems. Angle brackets require unbounded parser 
> look-ahead or type information in certain situations (see the end of this 
> e-mail for an example). This leaves us with parentheses and square 
> brackets. Unadorned square brackets cause ambiguities in type declarations 
> of arrays and slices, and to a lesser extent when parsing index 
> expressions. Thus, early on in the design, we settled on parentheses as 
> they seemed to provide a Go-like feel and appeared to have the fewest 
> problems.
>
> As it turned out, to make parentheses work well and for 
> backward-compatibility, we had to introduce the type keyword in type 
> parameter lists. Eventually, we found additional parsing ambiguities in 
> parameter lists, composite literals, and embedded types which required more 
> parentheses to resolve them. Still, we decided to proceed with parentheses 
> in order to focus on the bigger design issues.
>
> The time has come to revisit this early decision. If square brackets alone 
> are used to declare type parameters, the array declaration
>
> type A [N]E
>
> cannot be distinguished from the generic type declaration
>
> type A[N] E
>
> But if we are comfortable with the extra type keyword, the ambiguity 
> disappears:
>
> type A[type N] E
>
> (When we originally dismissed square brackets, the type keyword was not 
> yet on the table.)
>
> Furthermore, the ambiguities that arise with parentheses appear not to 
> arise with square brackets. Here are some examples where extra parentheses 
> are not needed with square brackets:
>
> using () using []
>
> func f((T(int))  func f(T[int])
>
> struct{ (T(int)) }   struct{ T[int] }
>
> interface{ (T(int)) }interface{ T[int] }
>
> [](T(int)){} []T[int]{}
>
> To test this better understanding, and to get a feel for this alternative 
> notation, we will begin to make changes to our prototype implementation 
> such that it accepts either parentheses or square brackets (only one or the 
> other) in a generic Go package. Those changes will first appear as commits 
> to the dev.go2go branch 
> , and eventually 
> in the playground .
>
> If square brackets don't lead to unforeseen issues, we have another fully 
> explored notation to choose from, which will allow us to make a more 
> informed decision.
>
> - gri, iant
>
> PS: For ambiguities with angle brackets consider the assignment
>
> a, b = w < x, y > (z)
>
> Without type information, it is impossible to decide whether the 
> right-hand side of the assignment is a pair of expressions
>
> (w < x), (y > (z))
>
> or whether it is a generic function invocation that returns two result 
> values
>
> (w)(z)
>
> In Go, type information is not available at compile time. For instance, in 
> this case, any of the identifiers may be declared in another file that has 
> not even been parsed yet.
>
>

-- 
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/ebe9a1ff-5539-4c85-998f-4dec143e3f24n%40googlegroups.com.

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

[Mike Schinkel]

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

-- 
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/eca35b41-df62-4c03-81b5-af55d113361a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Mike Schinkel]

> 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 that code 
> transpiles it back into Gopher++ to make a change.

That appears to be more of a bug than a feature to me, and a nightmare of 
incompatible source code. Imagine everyone on a team having their source code 
in their own flavor of a language? And I have yet to see a transpiler maintain 
100% compatibility in both directions.

Sounds like pure hell to me.

IMO transpilers are a hack that come with lots of downsides. Also IMO 
developers use transpilers because those controlling the evolution of a 
language have not been responsive to the needs of their developers (I am mainly 
looking at CSS here, not Go.)

I for one pine for a day that will likely never come when transpilers are no 
longer needed for development (I am not referring to go generate here, but 
tools to input one language and output another.)

JMTCW.

-Mike

-- 
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://groups.google.com/d/optout.

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

[Mike Schinkel]

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:
>>> 
>>> 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.
> 
> In what sense is that an issue?  If you are concerned about
> performance, note that the compiler can eliminate the initial
> assignment in the value == nil case if it is costly.
> 
> Ian

-- 
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://groups.google.com/d/optout.

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

[Mike Schinkel]

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


Having it be a statement instead would not address what everyone wants, but it 
would solve the excessive verbosity of referencing “result” three times and 
having to explicitly declare its type, or having to assign to it only to have 
its value immediately overwritten:

var result string
if temperature > 80 {
   result = "red"
} else {
   result = "green"
}

And it would do those things without the downsides mentioned thus far in this 
thread. 

-Mike

P.S. And for me personally, it would help reduce the carpel-tunnel flareups I 
get from having to type so damn many shift-brace keystrokes.  :-)

-- 
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://groups.google.com/d/optout.

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

[Mike Schinkel]

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 have no easy way to search 
> for that, and a random symbol me nothing about what it does. Go 
> specifically tries to stick to keywords because even if you've never 
> seen them before it's generally easier to figure out what they do (or to 
> search for them if you're not sure). 
>

Given that, I am curious what your thoughts would be if this were possible 
in Go instead?
 
   color := if temperature > 80 then “red” else “green” 

And especially if this formatting were valid:

   color := if temperature > 80 
  then “red” 
  else “green” 

-- 
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://groups.google.com/d/optout.

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

[Mike Schinkel]

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 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://groups.google.com/d/optout.

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

[Mike Schinkel]

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

Yes! Exactly.  Would be very interested in that.


> On Mar 30, 2019, at 12:16 AM, Brad  wrote:
> 
> 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 wrote:
> 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 wrote:
> Now that WebAssembly is available as an (experimental) compilation target, it 
> raises the question of how feasible is it to make a quality UI library. Vue 
> (my personal fav) and React, while they have their issues, do have many ideas 
> which are good and seem like they may translate well over to WebAssembly.
> 
> Here's a working experimental Vue-like UI library with tools to write UI 
> components in .vugu files (similar in concept to .vue files): 
> https://github.com/vugu/vugu <https://github.com/vugu/vugu>; Getting Started 
> page: http://www.vugu.org/doc/start <http://www.vugu.org/doc/start>
> 
> HTML with logic in it gets code generated to .go files.  In-browser rendering 
> in wasm  with DOM sync as well as static HTML output are implemented.
> 
> And this is my cheesy bullet-pointed list that makes it sound a lot more 
> mature than it is:
> 
> * Runs in-browser using WebAssembly
> * Single-file components
> * Vue-like markup syntax
> * Write idiomatic Go code
> * Rapid prototyping
> * ~3 minute setup
> * Standard Go build tools
> 
> I'm curious what people think of the approach and ideas for improvement.
> 
> --brad
> 
> 
> -- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "golang-nuts" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/golang-nuts/kpMrXLZ38So/unsubscribe 
> <https://groups.google.com/d/topic/golang-nuts/kpMrXLZ38So/unsubscribe>.
> To unsubscribe from this group and all its topics, send an email to 
> golang-nuts+unsubscr...@googlegroups.com 
> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
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://groups.google.com/d/optout.

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

[Mike Schinkel]

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 it?  I would be really interested if it could 
become a commercial product so that I could have better confidence of it 
being supported.

-Mike

On Friday, March 29, 2019 at 12:39:42 AM UTC-4, Brad wrote:
>
> Now that WebAssembly is available as an (experimental) compilation target, 
> it raises the question of how feasible is it to make a quality UI library. 
> Vue (my personal fav) and React, while they have their issues, do have many 
> ideas which are good and seem like they may translate well over to 
> WebAssembly.
>
> Here's a working experimental Vue-like UI library with tools to write UI 
> components in .vugu files (similar in concept to .vue files): 
> https://github.com/vugu/vugu; Getting Started page: 
> http://www.vugu.org/doc/start
>
> HTML with logic in it gets code generated to .go files.  In-browser 
> rendering in wasm  with DOM sync as well as static HTML output are 
> implemented.
>
> And this is my cheesy bullet-pointed list that makes it sound a lot more 
> mature than it is:
>
> * Runs in-browser using WebAssembly
> * Single-file components
> * Vue-like markup syntax
> * Write idiomatic Go code
> * Rapid prototyping
> * ~3 minute setup
> * Standard Go build tools
>
> I'm curious what people think of the approach and ideas for improvement.
>
> --brad
>
>

-- 
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://groups.google.com/d/optout.

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

[Mike Schinkel]

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 wrote:
>
> Now that WebAssembly is available as an (experimental) compilation target, 
> it raises the question of how feasible is it to make a quality UI library. 
> Vue (my personal fav) and React, while they have their issues, do have many 
> ideas which are good and seem like they may translate well over to 
> WebAssembly.
>
> Here's a working experimental Vue-like UI library with tools to write UI 
> components in .vugu files (similar in concept to .vue files): 
> https://github.com/vugu/vugu; Getting Started page: 
> http://www.vugu.org/doc/start
>
> HTML with logic in it gets code generated to .go files.  In-browser 
> rendering in wasm  with DOM sync as well as static HTML output are 
> implemented.
>
> And this is my cheesy bullet-pointed list that makes it sound a lot more 
> mature than it is:
>
> * Runs in-browser using WebAssembly
> * Single-file components
> * Vue-like markup syntax
> * Write idiomatic Go code
> * Rapid prototyping
> * ~3 minute setup
> * Standard Go build tools
>
> I'm curious what people think of the approach and ideas for improvement.
>
> --brad
>
>

-- 
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://groups.google.com/d/optout.