Re: [go-nuts] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

[T L]

On Saturday, May 13, 2017 at 1:26:31 PM UTC+8, Tamás Gulácsi wrote:
>
> Reference counting does not come without unforseen stalls - dereference a 
> huge structure with millions of objects!


Programmers can choose use ARC pointers or not.
 

-- 
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] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

[Tamás Gulácsi]

Reference counting does not come without unforseen stalls - dereference a huge 
structure with millions of objects!

-- 
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] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

[T L]

On Saturday, May 13, 2017 at 12:02:39 AM UTC+8, JuciÊ Andrade wrote:
>
> Any memory management strategy costs time. Reference counting is not 
> cheap. Incrementing and decrementing millions of reference counters costs 
> time. Please consider caching issues as well.
>
> Go GC, as it currently stands, is very effective, as other people in this 
> forum can confirm to you. Several Gigs of data and the only way to perceive 
> any performance impact is by generating a profile chart! 
>

In fact, the need to ARC is not efficiency, it is predictability and 
consistency instead.
And I don't expect ARC to be the main memory collect way, but I think it 
can be a supplement.
For example, maybe two types, sync.Pointer and sync.WeakPointer can be 
added.
 

>
> Only a practical test, tailored to your case, could tell if Go GC could 
> degrade your fps. If by any chance you find a challenging situation I am 
> sure the Go Team would be very eager to investigate, because it is 
> increasingly difficult to find new challenges to the GC.
>
>
> On Friday, May 12, 2017 at 11:55:36 AM UTC-3, T L wrote:
>>
>>
>>
>> On Thursday, May 11, 2017 at 8:48:05 PM UTC+8, JuciÊ Andrade wrote:
>>>
>>> Maybe a 100µs GC would be fast enough for you to be at easy with your 
>>> game FPS.
>>>
>>>
>>> https://groups.google.com/forum/#!searchin/golang-dev/garbage$20collector$20microseconds%7Csort:relevance/golang-dev/Ab1sFeoZg_8/_DaL0E8fAwAJ
>>>
>>>
>> The 100µs is STW duration. I mean the fps may decrease some during the 
>> period of GC running.
>>  
>>
>>> On Friday, May 5, 2017 at 12:10:01 AM UTC-3, T L wrote:

 ARC would be a better option for game apps than GC, to keep the fps 
 stable.

>>>

-- 
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: Reading stdlib for education about go?

[Scott Pakin]

On Friday, May 12, 2017 at 4:39:54 AM UTC-6, Steve Mynott wrote:
>
> What parts of the go stdlib are particularly useful for self education 
> in general go? 
>

It's been a while since I looked, but I recall image/png 
 (or any of its file-format siblings) 
and its dependencies, image  and image/color 
, being helpfui for understanding when 
to use interfaces and when to use concrete types when implementing a set of 
interrelated abstractions (in this case, various image formats that can be 
encoded, decoded, and manipulated with most of the implementation details 
hidden).

― Scott

-- 
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: map[X]Y or map[X]*Y ?

[jmontgomery]

In addition to the god points that others have made, there is a difference 
in the way that memory will be allocated. See 
https://play.golang.org/p/l6d4lODiDx and pay attention to the "delta" 
lines. In this particular example, using a map to a pointer does a Malloc 
for every map item, whereas using a map to value does not. For 10,000 items:

pointer delta : Alloc: 401248, TotalAlloc: 401248, Mallocs: 10543
value   delta : Alloc: 369512, TotalAlloc: 369512, Mallocs: 623


Of course, other uses could behave differently.

On Friday, May 12, 2017 at 8:00:00 AM UTC-4, aktungmak wrote:
>
> Setting aside the receiver types of methods for the moment, if we consider 
> the following declaration:
>
> type Y struct {
> //some fields
> }
>
> Which of the following would be "better" (from a speed and storage usage 
> viewpoint)?
>
> map[X]Y
> map[X]*Y
>
> If we consider that this map could be handed between different functions. 
> Does it make any difference to use a pointer? Or does it make no 
> difference, since the map is already a reference type and functions are 
> receiving a copy of the pointer to the map and not a copy of the map value?
>
> Thanks!
>

-- 
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] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

[ojucie]

Any memory management strategy costs time. Reference counting is not cheap. 
Incrementing and decrementing millions of reference counters costs time. 
Please consider caching issues as well.

Go GC, as it currently stands, is very effective, as other people in this 
forum can confirm to you. Several Gigs of data and the only way to perceive 
any performance impact is by generating a profile chart! 

Only a practical test, tailored to your case, could tell if Go GC could 
degrade your fps. If by any chance you find a challenging situation I am 
sure the Go Team would be very eager to investigate, because it is 
increasingly difficult to find new challenges to the GC.


On Friday, May 12, 2017 at 11:55:36 AM UTC-3, T L wrote:
>
>
>
> On Thursday, May 11, 2017 at 8:48:05 PM UTC+8, JuciÊ Andrade wrote:
>>
>> Maybe a 100µs GC would be fast enough for you to be at easy with your 
>> game FPS.
>>
>>
>> https://groups.google.com/forum/#!searchin/golang-dev/garbage$20collector$20microseconds%7Csort:relevance/golang-dev/Ab1sFeoZg_8/_DaL0E8fAwAJ
>>
>>
> The 100µs is STW duration. I mean the fps may decrease some during the 
> period of GC running.
>  
>
>> On Friday, May 5, 2017 at 12:10:01 AM UTC-3, T L wrote:
>>>
>>> ARC would be a better option for game apps than GC, to keep the fps 
>>> stable.
>>>
>>

-- 
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: would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

[T L]

On Friday, May 12, 2017 at 10:42:24 PM UTC+8, feilengcui008 wrote:
>
> If there are ARCs like shared_ptr in C++, I think there must be some kind 
> of raw pointers not managed by gc, this means bringing more "unsafe". 
>

Yes. But "unsafe" != "not safe"
 

>
> 在 2017年5月5日星期五 UTC+8上午12:00:18，T L写道：
>>
>> sometimes, I really want to some memory blocks be collected when they 
>> become unreferenced immediately..
>>
>

-- 
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] would it be good a go runtime support both GC (garbage collection) and ARC (automatic reference counting)?

[T L]

On Thursday, May 11, 2017 at 8:48:05 PM UTC+8, JuciÊ Andrade wrote:
>
> Maybe a 100µs GC would be fast enough for you to be at easy with your game 
> FPS.
>
>
> https://groups.google.com/forum/#!searchin/golang-dev/garbage$20collector$20microseconds%7Csort:relevance/golang-dev/Ab1sFeoZg_8/_DaL0E8fAwAJ
>
>
The 100µs is STW duration. I mean the fps may decrease some during the 
period of GC running.
 

> On Friday, May 5, 2017 at 12:10:01 AM UTC-3, T L wrote:
>>
>> ARC would be a better option for game apps than GC, to keep the fps 
>> stable.
>>
>

-- 
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: adding context.Context to new code

[Henrik Johansson]

With the whole "Reactive" movement thread locals have started to vanish at
least in the Java ecosystem.
I agree with Sameer that, while convenient, it comes with a whole set of
obscure bugs.

On Fri, May 12, 2017, 14:57 Sameer Ajmani  wrote:

> Hmm, I'm not finding good open-source examples of ThreadLocal context
> propagation in C++ and Java.  My experience with this is based on what
> Google uses internally.  Perhaps someone more familiar with context use
> (tracing?) outside Google can chime in? +Jaana Burcu Dogan
> 
>
> On Thu, May 11, 2017 at 7:02 AM  wrote:
>
>> thanks,
>>
>> ..integrating Context into the runtime..
>>
>>
>> 50% runtime, 50% syntax with explicit contextualization.
>>
>> ..The flow of request processing in Go may include multiple goroutines
>> and may move across channels;
>>
>>
>> yes big ? mark here. might the 50% of an handy and explicit syntax help
>> with it?
>>
>>
>> C++ and Java use thread-local Contexts, and while this is convenient, it
>> is often a source of mysterious bugs.
>>
>> thanks! I don't know them,
>>
>> I quickly checked according to this
>> https://dzone.com/articles/painless-introduction-javas-threadlocal-storage
>> I may have totally wrong, the syntax does not look like, not even from a
>> 100km,
>> to how i represent go contexts in my head.
>>
>> This is more like the actor pattern dave cheney talks about in
>> https://dave.cheney.net/2016/11/13/do-not-fear-first-class-functions
>> (search for  Let’s talk about actors)
>>
>> Is the dzone link correctly describe
>> what you mentioned as being go context equivalent in java ?
>>
>> sorry my questions are so basic.
>>
>>
>> On Thursday, May 11, 2017 at 12:29:11 PM UTC+2, Sameer Ajmani wrote:
>>
>>> I think you are asking whether we considered integrating Context into
>>> the runtime, so that it does not need to be passed explicitly. Yes, we
>>> discussed this, but decided against it. The flow of request processing in
>>> Go may include multiple goroutines and may move across channels; we decided
>>> an explicit Context made this much easier to get right. C++ and Java use
>>> thread-local Contexts, and while this is convenient, it is often a source
>>> of mysterious bugs.
>>>
>> On Thu, May 11, 2017 at 4:08 AM  wrote:
>>>
 Thanks a lot!

 Might i guess and try to generalize your explanations into
 "we tried to write a plumber for all cases possible"

 Which matters a lot, in my humble opinion.

 At least for the various reasons you put there,
 simply put,
 because it seems not technically achievable.

 Still i m happy you gave me those details, they are of interest indeed.

 I rather intent to solve the problem on a smaller surface
 with more predictability, less impossible solution to find.
 I hope so.
 And if it saves 90% of the time, that s already a win, imho.

 May i ask another question,
 have you considered to create the plumbing
 at runtime rather than statically ?
 With some intents from the syntax, necessarily
 (and yeah go 1 compat will be a problem, let s forget it for 1 minute).

 I suspect in some aspects in might be handier,
 because it might be all about chained func calls and not type system
 handling,
 and it might be easier to interleave the ctx.check in the flaw of ops,
 I don t know enough to realize for sure.



 On Wednesday, May 10, 2017 at 11:40:27 PM UTC+2, Sameer Ajmani wrote:

> Our approach was to identify function calls that consume a Context
> (indicated by a call to context.TODO in the function body) and function
> calls that provide a Context (such as RPC and HTTP handlers). Then we use
> the guru callgraph tool to find all call paths from context providers to
> context consumers. These are the call paths that need to have a context
> plumbed through them.
>
> Starting from a context consumer, we can work upward to the context
> provider, adding a context parameter to reach intervening function
> signature. Replace context.TODO in the consumer function body with the new
> ctx parameter, then update all the places that call the consumer to pass
> context.TODO. Now we have a new set of context consumers. Repeat until you
> reach the context providers (if you reach main or a Test function, pass
> context.Background instead).
>
> This works OK for static function calls but gets messy for dynamic
> calls. If you need to add a context parameter to an interface method, now
> you have to update all implementations of that method, too (guru can find
> these for you). And if that interface is outside your control (like
> io.Writer), you cannot change its signature, so you have to pass the
> context some other way (such as via the method receiver).
>
> This gets yet more complicated if you cannot 

Re: [go-nuts] Reading stdlib for education about go?

[Wojciech S. Czarnecki]

Dnia 2017-05-12, o godz. 11:39:40
Steve Mynott  napisał(a):

> What parts of the go stdlib are particularly useful for self education
> in general go?

Ones that you got deep understanding in other languages you use.

If you thought about general understanding of go just from stdlib
reading you IMO err. While usually clear and concise stdlib code
tends to be dense and sometimes 'hacky'. I personally would start
with a big complete product, or popular 3rd party library. Eg.
Hugo, Caddy, and gorilla if you're into web backend.

Hope this helps,

-- 
Wojciech S. Czarnecki
   ^oo^ OHIR-RIPE

-- 
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] Reading stdlib for education about go?

[Michael Jones]

The file IO routines are good examples of go factoring/structuring. In
particular, the blend of real and direct actions and the
abstracted/indirect use of readers/writers makes for a good IO feature set
with high reuse, efficiency, natural extensibility, and testability. On the
downside, it grew with Go and might be done slightly differently now, so as
always look for broad themes not minutiae.

The fmt package has the same set of virtues and layers above the former.
For example, thinking of C as version 0, it is clear that printf and
sprintf have almost everything in common, yet, one builds a string and one
writes to a file. How this is implemented is important for code simplicity,
understandability, efficiency, and extensibility. I find it pretty in just
these ways. Also educational, if you know the C/C++ meaning of all the fmt
functions, is to look at how the API and meanings (formatting directives,
argument structure) have been changed. For example, fmt.Printf complains if
you have mismatches in type or count between verbs ("%") and arguments.
This is a nice defensive posture and bears consideration vs lint-like
analysis.

On Fri, May 12, 2017 at 5:50 AM Steve Mynott  wrote:

> Perhaps not the most informative reply ever and implying go is like
> the Curate's egg? :-)
>
> I'd imagine that perhaps "unsafe" isn't what I want and there other
> more suitable packages to start studying?
>
> Which do people think the "good parts" (for this task) are?
>
>
>
> On 12 May 2017 at 11:48, Aram Hăvărneanu  wrote:
> > The good parts.
> >
> > --
> > Aram Hăvărneanu
>
>
>
> --
> 4096R/EA75174B Steve Mynott 
>
> --
> 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.
>
-- 
Michael T. Jones
michael.jo...@gmail.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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: adding context.Context to new code

[Sameer Ajmani]

Hmm, I'm not finding good open-source examples of ThreadLocal context
propagation in C++ and Java.  My experience with this is based on what
Google uses internally.  Perhaps someone more familiar with context use
(tracing?) outside Google can chime in? +Jaana Burcu Dogan 

On Thu, May 11, 2017 at 7:02 AM  wrote:

> thanks,
>
> ..integrating Context into the runtime..
>
>
> 50% runtime, 50% syntax with explicit contextualization.
>
> ..The flow of request processing in Go may include multiple goroutines and
> may move across channels;
>
>
> yes big ? mark here. might the 50% of an handy and explicit syntax help
> with it?
>
>
> C++ and Java use thread-local Contexts, and while this is convenient, it
> is often a source of mysterious bugs.
>
> thanks! I don't know them,
>
> I quickly checked according to this
> https://dzone.com/articles/painless-introduction-javas-threadlocal-storage
> I may have totally wrong, the syntax does not look like, not even from a
> 100km,
> to how i represent go contexts in my head.
>
> This is more like the actor pattern dave cheney talks about in
> https://dave.cheney.net/2016/11/13/do-not-fear-first-class-functions
> (search for  Let’s talk about actors)
>
> Is the dzone link correctly describe
> what you mentioned as being go context equivalent in java ?
>
> sorry my questions are so basic.
>
>
> On Thursday, May 11, 2017 at 12:29:11 PM UTC+2, Sameer Ajmani wrote:
>
>> I think you are asking whether we considered integrating Context into the
>> runtime, so that it does not need to be passed explicitly. Yes, we
>> discussed this, but decided against it. The flow of request processing in
>> Go may include multiple goroutines and may move across channels; we decided
>> an explicit Context made this much easier to get right. C++ and Java use
>> thread-local Contexts, and while this is convenient, it is often a source
>> of mysterious bugs.
>>
> On Thu, May 11, 2017 at 4:08 AM  wrote:
>>
>>> Thanks a lot!
>>>
>>> Might i guess and try to generalize your explanations into
>>> "we tried to write a plumber for all cases possible"
>>>
>>> Which matters a lot, in my humble opinion.
>>>
>>> At least for the various reasons you put there,
>>> simply put,
>>> because it seems not technically achievable.
>>>
>>> Still i m happy you gave me those details, they are of interest indeed.
>>>
>>> I rather intent to solve the problem on a smaller surface
>>> with more predictability, less impossible solution to find.
>>> I hope so.
>>> And if it saves 90% of the time, that s already a win, imho.
>>>
>>> May i ask another question,
>>> have you considered to create the plumbing
>>> at runtime rather than statically ?
>>> With some intents from the syntax, necessarily
>>> (and yeah go 1 compat will be a problem, let s forget it for 1 minute).
>>>
>>> I suspect in some aspects in might be handier,
>>> because it might be all about chained func calls and not type system
>>> handling,
>>> and it might be easier to interleave the ctx.check in the flaw of ops,
>>> I don t know enough to realize for sure.
>>>
>>>
>>>
>>> On Wednesday, May 10, 2017 at 11:40:27 PM UTC+2, Sameer Ajmani wrote:
>>>
 Our approach was to identify function calls that consume a Context
 (indicated by a call to context.TODO in the function body) and function
 calls that provide a Context (such as RPC and HTTP handlers). Then we use
 the guru callgraph tool to find all call paths from context providers to
 context consumers. These are the call paths that need to have a context
 plumbed through them.

 Starting from a context consumer, we can work upward to the context
 provider, adding a context parameter to reach intervening function
 signature. Replace context.TODO in the consumer function body with the new
 ctx parameter, then update all the places that call the consumer to pass
 context.TODO. Now we have a new set of context consumers. Repeat until you
 reach the context providers (if you reach main or a Test function, pass
 context.Background instead).

 This works OK for static function calls but gets messy for dynamic
 calls. If you need to add a context parameter to an interface method, now
 you have to update all implementations of that method, too (guru can find
 these for you). And if that interface is outside your control (like
 io.Writer), you cannot change its signature, so you have to pass the
 context some other way (such as via the method receiver).

 This gets yet more complicated if you cannot make atomic changes to all
 callers of your functions, because callers may be in other repositories. In
 this case, you must do an incremental refactoring in multiple steps: each
 change to a function signature involves adding a new function that has the
 context parameter, then changing all existing calls to use the new
 function, while preventing new calls 

[go-nuts] Re: map[X]Y or map[X]*Y ?

[howardcshaw]

>
> type Y struct {
> //some fields
> }
>
> This rather depends on what those some fields ARE, and whether type Y is 
conceptually mutable or immutable.

For example, I might make a lightweight struct just to group a pair of 
values; X/Y coordinates, or Latitude and Longitude:

type LatLon struct {
  Latitude, Longitude float64
}

or the like, and in that case, I might treat it as immutable, and just make 
a new one if I needed changes, in which case doing a map[string]LatLon 
would be fine. 

If the struct is larger or is mutable, then a pointer makes more sense.

BUT! There is one *critical* case to consider.

type Something struct {
   guard sync.Mutex
   ... guarded things
}

This one MUST be done as a pointer, otherwise you are copying the mutex 
when you assign to the map, or assign from the map to a variable. As the 
docs say, "A Mutex must not be copied after first use."

So if you have mutexes or mutable values in the struct, best to use *. 
"Only use the non-pointer map when your structs are simple, small, and 
immutable" is probably a reasonable rule of thumb.

-- 
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] Reading stdlib for education about go?

[Steve Mynott]

Perhaps not the most informative reply ever and implying go is like
the Curate's egg? :-)

I'd imagine that perhaps "unsafe" isn't what I want and there other
more suitable packages to start studying?

Which do people think the "good parts" (for this task) are?



On 12 May 2017 at 11:48, Aram Hăvărneanu  wrote:
> The good parts.
>
> --
> Aram Hăvărneanu



-- 
4096R/EA75174B Steve Mynott 

-- 
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] map[X]Y or map[X]*Y ?

['Axel Wagner' via golang-nuts]

There is a difference, given that in the former, values stored in the map
are not addressable, so if you need to modify them, you need to read,
modify, write them, whereas in the latter, you can simply do
someMap[k].doSomeThings. As you noted, there is also the issue that you
can't call methods on pointer receivers on an index expression in the
former case.

If those semantic differences don't matter, it depends on Y (and your use
cases). Storing a pointer means less copying, when you access or store
something in the map; storing a value means less pointer indirection and
cache misses, as it's stored packed in the bucket. Whats cheaper depends on
your specific use case.

A priori I don't believe that the performance difference is material. Thus
I personally usually opt for the latter, because I find the semantics more
convenient and appropriate for what I need.

On Fri, May 12, 2017 at 2:00 PM, aktungmak  wrote:

> Setting aside the receiver types of methods for the moment, if we consider
> the following declaration:
>
> type Y struct {
> //some fields
> }
>
> Which of the following would be "better" (from a speed and storage usage
> viewpoint)?
>
> map[X]Y
> map[X]*Y
>
> If we consider that this map could be handed between different functions.
> Does it make any difference to use a pointer? Or does it make no
> difference, since the map is already a reference type and functions are
> receiving a copy of the pointer to the map and not a copy of the map value?
>
> Thanks!
>
> --
> 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.
>

-- 
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: Delve v1.0.0-rc.1 release

[Ged Wed]

Derek,

can the RR be used with golang on AMD64 and ARM ?
If so this is pretty huge

ged

On Monday, 8 May 2017 20:42:43 UTC+2, Derek Parker wrote:
>
> Hey all,
>
> Just wanted to make some noise about the latest Delve 
>  release, v1.0.0-rc.1 
> 
> .
>
> This is a particularly big release for us, and includes a bunch of fixes, 
> improvements and new features. I'll break down the new features shortly, 
> but just wanted to call out this is an exciting milestone for the project, 
> and we're excited to be driving towards a 1.0.0 release. What does that 
> mean to you as a user? Well, not much should change, the project has been 
> pretty stable, we have had API compatibility guarantees for a while now, 
> etc, so this release is mostly symbolic. It does not mean the project is 
> feature complete, we will be working hard to continue to add new features, 
> support for more systems, and overall improvements as usual.
>
>  For a full list of changes, please check out the changelog 
> ,
>  
> but I wanted to highlight some interesting features:
>
> Ability to swap low-level back ends. This means you can select either the 
> native Delve back end, gdbserver, lldb-server, or Mozilla RR. The most 
> exciting of this, in my opinion, is the ability to use the Mozilla RR (
> http://rr-project.org/) project as a back end. This allows for record & 
> replay deterministic debugging, and allows you to combine the power of 
> Delve and RR into a very useful debugging tool for Go.
>
> Lastly, would just like to say thanks to the community overall for the 
> support of the project and for all the patches, bug reports submitted 
> editor integrations, etc, and co-maintainer Alessandro 
>  for all the help, fixes, improvements, 
> reviews and so on.
>
> Please check out this release, file bugs, and look out for the v1.0.0 
> release within the coming weeks!
>

-- 
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] map[X]Y or map[X]*Y ?

[aktungmak]

Setting aside the receiver types of methods for the moment, if we consider 
the following declaration:

type Y struct {
//some fields
}

Which of the following would be "better" (from a speed and storage usage 
viewpoint)?

map[X]Y
map[X]*Y

If we consider that this map could be handed between different functions. 
Does it make any difference to use a pointer? Or does it make no 
difference, since the map is already a reference type and functions are 
receiving a copy of the pointer to the map and not a copy of the map value?

Thanks!

-- 
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] Reading stdlib for education about go?

[Aram Hăvărneanu]

The good parts.

-- 
Aram Hăvărneanu

-- 
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] Reading stdlib for education about go?

[Steve Mynott]

I've often seen advice that a good way of increasing language
understanding is to read parts of the stdlib written in that language.

What parts of the go stdlib are particularly useful for self education
in general go?

-- 
4096R/EA75174B Steve Mynott 

-- 
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] Java to Golang converter

[Simon Ritchie]

I think the problem is testing.  If you use a tool to convert one language to 
another, you have to check that the result works, which involves a lot of 
testing, possibly as much as you had to do to get the original working in the 
first place.  So it's expensive.

It will usually be cheaper to leave your original Java in place, writie new 
functionality in Go and integrate the two together.   You can do that using web 
services, gRPC, a Service Bus or whatever.

This is pretty much the way that Java replaced COBOL.  A common trick in the 
beginning was to put a layer of Java in front of a COBOL solution to provide a 
web interface.  Extra functionality could then be written in Java.  Some of 
those COBOL solutions are still running, hiding behind a Java app.

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