Re: [go-nuts] Language idea: Improved support for method-like functions

['Axel Wagner' via golang-nuts]

On Tue, Dec 20, 2022 at 6:05 PM Red Daly  wrote:

> Thanks for the links. Note that while 56283 was declined citing lack of
> emoji support
> , a
> comment in issue 49085
>  has 35
> thumbs up and no thumbs down for essentially the same proposal.
>

I don't think the two are the same proposal. They have overlap, but they
differ significantly. For example, the comment you link suggests that they
should still be *methods* and thus inherently namespaced differently, while
UFCS is about making *functions* callable using method syntax.
Both come with their own unique set of disadvantages and IMO UFCS has a
significantly worse tradeoff.

That being said, we don't know how to implement parameterized methods
either, so the point seems moot.


>
> I suppose it makes sense to decide on this at the same time as deciding
> whether/how to support type parameters for methods.
>
>
>>
>>
>>>
>>> This feature would be useful for defining these pseudo-methods on types
>>> within a package or on types from other packages. Using a pseudo-receiver
>>> type that's defined in another package raises some questions about how to
>>> use the pseudo-method without surprising/confusing readers. Most
>>> prominently for writing method-like generic functions.
>>>
>>> --
>>> 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/e8685cd7-4691-4b74-8c9a-b4a8992dbd20n%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/CAEkBMfHSn7RtgcFP70QTP%2BpjVgYd955kzUrBDjRXTgV06Ktnpw%40mail.gmail.com.

Re: [go-nuts] Re: App Engine hasn't upgraded beyond Go 1.16, which is now out of security window

[ga...@zenbunker.ch]

Any updates on App Engine Flexible? It's still stuck on 1.15 and a pull 
request for 1.16 has been ignored for over a year 
https://github.com/GoogleCloudPlatform/golang-docker

Is App Engine Flexible being abandoned by Google? Where should I migrate 
our Go applications?

Best,
Gabor

On Tuesday, December 20, 2022 at 3:39:22 AM UTC+1 seana...@gmail.com wrote:

> Thanks, folks! I just upgraded my app to the 119 runtime too, and it went 
> very smoothly!
>
> On Mon, Dec 19, 2022 at 11:40 AM 'drc...@google.com' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
>> I just checked with my personal app engine project ("gcloud app deploy", 
>> that's app engine, I think), and with 1.19 specified in go.mod and 
>> "runtime: 119" in app.yaml, the app reported runtime.Version() of 1.19.3.  
>> My understanding is this is a recent change.
>>
>> On Thursday, December 15, 2022 at 11:33:41 AM UTC-5 Olivier Favre wrote:
>>
>>> Hi,
>>>
>>> I think App Engine is not getting as much development efforts as Cloud 
>>> Run does.
>>> I foresee it the same fate as Legacy Networks versus VPC.
>>>
>>> That said, it looks like they were unconfortable with this situation as 
>>> they released Go 1.18 and 1.19 (NB: not 1.17) a few days ago:
>>>
>>> https://cloud.google.com/appengine/docs/standard/go/release-notes#December_07_2022
>>>
>>> Cheers,
>>> --
>>> Olivier Favre
>>>
>>> On Monday, September 12, 2022 at 11:33:09 AM UTC+2 Rusco wrote:
>>>
 Googles own language on Googles own cloud lags behind several version,  
 I don't understand this :-( 

 Microsoft seems to be more eager to keep things up to date: 
 .NET 7 comes to Azure Functions & Visual Studio 2022 - .NET Blog 
 (microsoft.com) 
 

 On Monday, 12 September 2022 at 02:33:18 UTC+1 seana...@gmail.com 
 wrote:

> I'm hoping a member of the Go team will take pity on me and prod the 
> App Engine Go team about this. The most recent upgrade to AE's Go 
> environment was in Nov 2021, when they started supporting Go 1.16 (see 
> release notes below). Now that Go 1.19 is out, Go 1.16 won't be getting 
> security fixes anymore, and App Engine Go users are in a frustrating 
> place.
>
> If this is App Engine's way of telling me to move to Cloud Run 
> (-->Dockerizing), it'd be nice if they'd just tell us that :). Otherwise, 
> could a Googler please help us AE users out and poke AE into getting up 
> to 
> 1.17, 1.18, or 1.19? I don't know where to file a bug straight against 
> AE, 
> and I figure the Go team should be very interested in this, due to 
> aforementioned security implications.
>
> https://cloud.google.com/appengine/docs/standard/go/release-notes
>
> Thanks,
> Sean
>
 -- 
>> 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/OspOyUz7CBQ/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> golang-nuts...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/5844eecc-9315-41a7-957e-39c6bd46a0bcn%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
> Sean Abraham
> seana...@gmail.com
> Cell: 720-278-8211 <(720)%20278-8211>
>

-- 
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/d14b0188-be19-4dc8-9ea4-b21b64f31270n%40googlegroups.com.

[go-nuts] In App Engine Flexible, how do I use a Go version beyond 1.15?

[Gabor Lenard]

Hello everyone

I would like to use the latest available Go version in Google App Engine 
Flexible. However, the latest supported Go version seems to be 1.15, see 
https://cloud.google.com/appengine/docs/flexible/go/runtime The responsible 
repository was not updated since 2020, and relevant pull requests are ignored 
for unknown reasons, see https://github.com/GoogleCloudPlatform/golang-docker 

I know it’s not fully relevant in this group but who else could help?

Best,
Gabor

-- 
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/54ED6940-AA80-48FD-B85F-63E698D9E154%40zenbunker.ch.

[go-nuts] Create a XML signature my XML DATA

[Reeturaj Sahoo]

Hello Golang Team,

I want to implement Signed XML to my XML Data . 
If anyone have reference  document .Kindly share

-- 
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/0c91f4a8-ccc2-428c-ab80-b81f269b64dan%40googlegroups.com.

Re: [go-nuts] Language idea: Improved support for method-like functions

[Red Daly]

On Mon, Dec 19, 2022 at 12:25 PM Axel Wagner 
wrote:

>
>
> On Mon, Dec 19, 2022 at 8:31 PM Red Daly  wrote:
>
>> Methods cannot take type arguments, so I find myself writing `func Foo(o
>> Object) {...}` instead of `func (o Object) Foo()` in cases where Foo needs
>> a type parameter.
>>
>> I would like some type of pseudo-method in Go similar to Kotlin's
>> extension methods. Made up syntax:
>>
>> ```go
>> package foo
>>
>> func (o Object) #Foo[T any]() { /* ... */ } // Foo is a pseudo method of
>> Object
>>
>> func main() {
>>   obj := Object{}
>>   obj#Foo() // use # to differentiate from regular methods, or use .
>> }
>> ```
>> or something more clever.
>>
>> I expect a lot of the time people use methods for syntactic reasons, not
>> so those methods can be used to implement an interface. Methods appear in
>> godoc along with the type, get better tab completion than functions, etc.
>> I'm not proposing these pseudo-methods be used in any way to implement
>> interfaces.
>>
>> This may have already been discussed. There have been rejected proposals
>> for adding methods to types defined elsewhere (
>> https://github.com/golang/go/issues/37742 and
>> https://github.com/golang/go/issues/21401). However, I can't find a
>> proposal that proposes the Kotlin approach to "extension methods," which is
>> largely syntax sugar that allows `fun koo(k Kobject): void` to be called
>> like `k.koo()` by the programmer (rather than `koo(k)`) so long as `koo` is
>> statically resolved where such `k.koo` calls appear. Is there such a
>> proposal?
>>
>
> There are (at least) two:
> https://github.com/golang/go/issues/56283
> https://github.com/golang/go/issues/56242
> It's not *exactly* what you describe, but I believe it's close enough.
>

Thanks for the links. Note that while 56283 was declined citing lack of
emoji support
, a
comment in issue 49085
 has 35
thumbs up and no thumbs down for essentially the same proposal.

I suppose it makes sense to decide on this at the same time as deciding
whether/how to support type parameters for methods.


>
>
>>
>> This feature would be useful for defining these pseudo-methods on types
>> within a package or on types from other packages. Using a pseudo-receiver
>> type that's defined in another package raises some questions about how to
>> use the pseudo-method without surprising/confusing readers. Most
>> prominently for writing method-like generic functions.
>>
>> --
>> 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/e8685cd7-4691-4b74-8c9a-b4a8992dbd20n%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/CA%2BjYSA__GwbLrUhhub47Bo2CT7txcVQ%3DryQC62J274WU4s%2B6Hg%40mail.gmail.com.

Re: [go-nuts] Re: Context cancellation: Is it sufficient to make long-running things interruptible?

[Jason E. Aten]

Nonsense.

Closing channels is a generic means of broadcasting to all listeners a
state change.

To say that only one goroutine should ever initiate such a change is a
needless and pointless restriction.


On Tue, Dec 20, 2022 at 2:40 AM Jan Mercl <0xj...@gmail.com> wrote:

> On Tue, Dec 20, 2022 at 9:21 AM Jason E. Aten  wrote:
>
> > Shutting down goroutines quickly was needed so often that I wrote a
> package to help me with it. it is called idem, short for idempotent.
> >
> > It uses the idea of an idempotent Close of a channel to signal that the
> goroutine should stop. This is because Go will panic if
> > close a channel more than once (i.e. you wish to stop a goroutine from
> more than one place).  This is a design flaw in channels,
> > but we can work around it by using a mutex.
>
> I disagree with it being a design flaw. Quite the opposite, IMO.
> Closing a channel more than once reveals a design flaw in the
> respective program and panicking is about the only safe thing to do in
> that situation.
>
> Working around this safety feature should be discouraged.
>

-- 
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/CAPNEFAbwQM51gmN8Pq%3D4hOs4cdKv%3DHzHhUAjeG-YOgs5fcmbAw%40mail.gmail.com.

Re: [go-nuts] Re: Context cancellation: Is it sufficient to make long-running things interruptible?

[Jan Mercl]

On Tue, Dec 20, 2022 at 9:21 AM Jason E. Aten  wrote:

> Shutting down goroutines quickly was needed so often that I wrote a package 
> to help me with it. it is called idem, short for idempotent.
>
> It uses the idea of an idempotent Close of a channel to signal that the 
> goroutine should stop. This is because Go will panic if
> close a channel more than once (i.e. you wish to stop a goroutine from more 
> than one place).  This is a design flaw in channels,
> but we can work around it by using a mutex.

I disagree with it being a design flaw. Quite the opposite, IMO.
Closing a channel more than once reveals a design flaw in the
respective program and panicking is about the only safe thing to do in
that situation.

Working around this safety feature should be discouraged.

-- 
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/CAA40n-UxSkA6ATXsmXyE9NZtXiOLBFpV8FMRK8y9t829Hu02dQ%40mail.gmail.com.

[go-nuts] Re: Context cancellation: Is it sufficient to make long-running things interruptible?

[Jason E. Aten]

Shutting down goroutines quickly was needed so often that I wrote a package 
to help me with it. it is called idem, short for idempotent.

It uses the idea of an idempotent Close of a channel to signal that the 
goroutine should stop. This is because Go will panic if
close a channel more than once (i.e. you wish to stop a goroutine from more 
than one place).  This is a design flaw in channels, 
but we can work around it by using a mutex.

Since the goroutine that wants the other goroutine to shutdown typically 
needs to wait until that is done, there is a reciprocal
closing of another channel to indicate that the message has been received 
and will be acted on.

https://github.com/glycerine/idem/blob/master/halter_test.go#L43

-- 
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/c5debfad-8dbc-4ae3-9b88-d4b9933d1f1en%40googlegroups.com.