[go-nuts] Re: Mocking requests in Go

[Roman Kuprov]

Hah! I just had a question about this come up at a job interview! The 
Baader-Meinhoff is strong with this one!

On Friday, November 5, 2021 at 11:17:23 AM UTC-6 Amnon wrote:

> Nice post. Good advice.
>
> On Friday, 5 November 2021 at 17:08:25 UTC bke...@zushealth.com wrote:
>
>> Sharing an interesting post by Zus  technologist 
>> Sonya Huang on mocking requests in Go:
>>
>> https://www.linkedin.com/feed/update/urn:li:activity:6862376852103798784/
>>
>

-- 
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/2f46f100-0101-4afd-b86f-b1996365ecean%40googlegroups.com.

[go-nuts] Re: Unable to return multiple values only the first or the last

[Roman Kuprov]

You're returning right after ranging through the first value, thus 
ending/exiting the function. 

Try: https://play.golang.org/p/0n1g8HXxobI

On Friday, November 12, 2021 at 10:20:10 AM UTC-7 bishwajits...@gmail.com 
wrote:

> HI, need help in understanding what i am making mistake of not able to 
> return all the values. Below is the sample code from Playground.
> https://play.golang.org/p/EMN830T0Lvr
>

-- 
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/807fb817-5294-434c-8d99-3be09cb90d50n%40googlegroups.com.

Re: [go-nuts] Re: Why not tuples?

[Roman Kuprov]

I might be missing something, but you can just iterate over your list of 
structs and delete/set-to-default-value the offending field before shipping 
it to your client. Same as tuples afaic.

On Monday, December 5, 2022 at 8:39:17 PM UTC-7 diogo...@gmail.com wrote:

> Hi folks,
>
> Thanks for all the inputs, I really appreciate the effort and help :-)
>
> Regardless of the whole discussion of whether or not tuples are a good or 
> bad data structure, they exist out there in the wild, and we have to deal 
> with them in many situations - of course, in our own code we can opt by 
> continuing to use them or not, depending on the language we're using. It 
> would be nice if Go could support them as first-class citizens - I know 
> it's not the only language that doesn't, though, Java for example doesn't 
> support them either (BTW there's a nice Java library, javatuples, which 
> gives nice names like Pair, Triplet, Quartet etc, to n-sized "tuples" - I 
> find that enjoyable).
>
> Anyways, thanks for the discussion, that helps me get a better grasp of 
> the language!
>
> Cheers!
>
> On Sunday, December 4, 2022 at 11:39:41 PM UTC-3 Kevin Chowski wrote:
>
>> If you really need anonymous tuple types that support decoding that sort 
>> of JSON, it isn't too hard to write one: 
>> https://go.dev/play/p/Fn_wUXh2drs
>>
>> Go's generics don't support varargs types (...yet? who knows) so there'd 
>> be a little copypasta if you needed many different tuple lengths, but Java 
>> has been doing that for years ;)
>>
>> (IMO, using these anonymous tuple types across a whole codebase is not 
>> great: data should be labeled with useful names as it is passed around a 
>> program. But if you really are just using this to make json parsing code 
>> easier, that seems reasonable to me.)
>>
>> On Saturday, December 3, 2022 at 8:47:03 PM UTC-7 diogo...@gmail.com 
>> wrote:
>>
>>> Hi there, sorry for weighting in so late in the game, but I just started 
>>> again to learn Go and was thinking why the language still doesn't have a 
>>> tuple type.
>>>
>>> Now, imagine this scenario: I have a web application which has to access 
>>> a webservice that responds with JSON payloads; These payloads are a list of 
>>> values, where each value is a smaller list like '[20220101, 1.234, "New 
>>> York"]'. And these smaller lists follow the same type sequence: int64, 
>>> float64, string. Suppose that I want to filter those values and send a 
>>> response to the client, with the data structure unchanged (same format and 
>>> types). Today, it doesn't seem to be possible to do that in Go, unless I do 
>>> some dirty hack like decoding to '[]any' and then cast to the other types, 
>>> and then hack again to put these values in the response to the client.
>>>
>>> I totally understand the reasoning for preferring the usage of structs 
>>> for heterogeneous data (and I myself do prefer them, they're much more 
>>> powerful in general), but there's real world data that's available like in 
>>> the example above, and we just can't go on changing them at their sources. 
>>> I might be mistaken (please let me know if it's the case), but it seems 
>>> like Go is missing an opportunity to interoperate with what's a fundamental 
>>> data structure in many other languages (Python, Rust etc). I'm having a lot 
>>> of fun learning to use the language, and would be happy to see this feature 
>>> being implemented at the core.
>>>
>>> (Maybe what I said above is total BS, I acknowledge that since I'm an 
>>> almost complete ignorant in the language)
>>>
>>> Cheers!
>>>
>>> On Thursday, April 19, 2018 at 1:03:55 PM UTC-3 Louki Sumirniy wrote:
>>>
 Multiple return values. They do kinda exist in a declarative form of 
 sorts, in the type signature, this sets the number and sequence and types 
 of return values. You could even make functions accept them as also input 
 values, I think, but I don't think it works exactly like this. I'm not a 
 fan of these things because of how you have to nominate variables or _ and 
 type inference will make these new variables, if you  := into whatever the 
 return was.

 I'm not sure what the correct word is for them. Untyped in the same way 
 that literals can be multiple types (especially integers) but singular in 
 their literal form.


 On Thursday, 19 April 2018 16:06:42 UTC+3, Jan Mercl wrote:
>
> On Thu, Apr 19, 2018 at 2:51 PM Louki Sumirniy <
> louki.sumir...@gmail.com> wrote:
>
> > Sorry for the self-promotion but it was relevant in that I was 
> working on how to tidy up the readability of my code and needed multiple 
> returns and simple untyped tuples were really not nearly as convenient as 
> using a type struct.
>
> I have no idea what you mean by 'untyped tuples' because Go does not 
> have tuples, or at least not as a well defined thing. I can only guess if 
> you're trying to implement tuples in Go with an

Re: [go-nuts] Avoiding resource leaks with racing channels

[Roman Kuprov]

Would the Context package not work for this issue?
(kinda new gopher here)

On Wednesday, July 10, 2019 at 1:08:38 PM UTC-6, Dan Eloff wrote:
>
> Yeah, agreed. I've been deep into concurrent programming for a long time 
> now, and into lock-free programming as well which is the most fraught kind 
> of programming I've ever done. Parallel is the future, it has been that way 
> for a long time, but it's only getting more and more obvious.
>
> I think in this specific case, the timeout should have been handled on the 
> sending side in a select,  almost identically to the receiver code I 
> posted. If the timer channel triggers, then close the channel to indicate 
> to the receiver that it can wake up and it has timed out. Then the sender 
> can go ahead and clean up the resource which it still owns. Doing it on the 
> receiver side is fraught with problems.
>
> I solved it with a dedicated go routine that scans for timed out waiters 
> and expires them by closing the channel, but that meant the sender now 
> needs to handle the rare panic if it sends on a closed channel - not the 
> end of the world, but not as clean.
>
> On Wed, Jul 10, 2019 at 10:14 AM Jesper Louis Andersen <
> jesper.lo...@gmail.com > wrote:
>
>> On Wed, Jul 10, 2019 at 6:45 PM Dan Eloff > > wrote:
>>
>>> On Wed, Jul 10, 2019 at 7:54 AM Michael Jones >> > wrote:
>>>
 unbuffered means nothing is sent until is is simultaneously received, 
 so there is no limbo or race or uncertainty. one sender "wins" the select 
 and the others remain blocked waiting.

>>>
>>> So I'm correct then: "Now one of two things must happen, either the 
>>> sender blocks forever because nobody read the sent value"
>>>
>>>
>> If the sender is written as
>>
>> channel <- fd
>>
>> as you propose, then indeed, the sender will block forever. However, this 
>> is easily fixed via a select on the sender side as well with a timeout, or 
>> a context.Context that can cancel. If the send on the channel is _not_ 
>> selected, you still own the resource and have to clean up.
>>
>> More advanced event systems, such as Concurrent ML, has a withNACK guard 
>> for this case. If a given event is not selected, its withNACK thunk is run, 
>> allowing for cleanup. But in your case and Go, you can just have a variable 
>> or such to handle the case and clean up properly.
>>
>> You are right that a lot of concurrent programming is hard, especially in 
>> the presence of errors and faults. Hence, simple strategies first. And then 
>> you need to have a sketch of a proof present for more complicated 
>> interactions, or a model in TLA+ if you want it to be water-tight. However, 
>> given what AMD just launched, there is little hope for MIMD style operation 
>> now. SIMD style can still be done with a sequential but parallel program.
>>
>>
>> -- 
>> J.
>>
>

-- 
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/7a3021d7-3637-46f2-84a2-58b4b338ffa2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.