Re: [go-nuts] Modern Garbage Collection Article

[andrey mirtchovski]

My apologies to the original author, but the "state of the art" of
modern garbage collectors is not acceptable if it means this:

"To run dex in process, the Gradle daemon needs a larger heap.
It currently has 1024 MB.
For faster builds, increase the maximum heap size for the Gradle
daemon to at least 1536 MB.
To do this set org.gradle.jvmargs=-Xmx1536M in the project
gradle.properties."

note that this GC information is exposed to me, the end user, through
several layers of abstraction: I'm using a build mechanism to coerce a
Go program to be acceptable as a C native program with Java bindings
in Android's virtual machine.

-- 
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] Modern Garbage Collection Article

[Konstantin Khomoutov]

On Mon, 19 Dec 2016 20:56:39 -0800 (PST)
Tyler Compton  wrote:

> https://medium.com/@octskyward/modern-garbage-collection-911ef4f8bd8e#.c48w4ifa7
> 
> Thoughts? How accurate is this article? If it is, why, historically,
> is the work being done on the GC so concentrated on pause times?
> 
> For more 
> discussion:
> https://www.reddit.com/r/golang/comments/5j7phw/modern_garbage_collection/

The article is a typical case of the "sofa theoretist" write-up: take a
couple of phrases out of several Go announces, do no research, read no
source code, be not familiar with any developer working on the Go's GC,
have not to hear their reasoning, lump together whatever you know about
your pet platform (Java), point at decades of academic research.  Done.

Thanks for the author's point of view, but I personally would trade all
those decades and tuning put into the JVM's GC for tests done by Go
engeneers in the field.  Evidence always trumps any theoretisation. :-)

-- 
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] Modern Garbage Collection Article

[Tyler Compton]

Thank you for your input!

> Throwing more cores at the problem is a sensible approach on modern 
hardware.  Since the cores are no longer getting faster, making your code 
run faster on a single core is not the optimal design for the hardware of 
the near future.

I had not considered increasing core counts as something that could drive 
such important decisions about GC design, but it makes sense. Now that I 
think of it, it falls right in line with Go's general goal of being useful 
on newer, multi-core machines.

Here is Rick Hudson's comment, for those who are 
interested: 
https://medium.com/@rlh_21830/it-is-not-true-that-without-compaction-fragmentation-is-inevitable-e67d111e#.fuuajmdoz

On Monday, December 19, 2016 at 10:31:52 PM UTC-7, Ian Lance Taylor wrote:
>
> On Mon, Dec 19, 2016 at 8:56 PM, Tyler Compton  > wrote: 
> > 
> https://medium.com/@octskyward/modern-garbage-collection-911ef4f8bd8e#.c48w4ifa7
>  
> > 
> > Thoughts? How accurate is this article? If it is, why, historically, is 
> the 
> > work being done on the GC so concentrated on pause times? 
>
> If you click on the comments link near the bottom you will see that 
> Rick has commented on part of the essay. 
>
> I do not work on the GC myself, but these are my personal observations. 
>
> I think the key observation in Go's GC is that modern systems have 
> multiple cores, and are rapidly getting more cores.  Throwing more 
> cores at the problem is a sensible approach on modern hardware.  Since 
> the cores are no longer getting faster, making your code run faster on 
> a single core is not the optimal design for the hardware of the near 
> future. 
>
> For a language like Go, stop-the-world pause times really are the most 
> important thing, because during a pause your server isn't doing 
> anything useful.  The essay suggests that the Go runtime is "willing 
> to slow down your program by almost any amount" in order to reduce 
> pause times; that is clearly hyperbole, and it isn't literally true. 
> The slowdowns in compiled Go code occur when writing pointers into the 
> heap and when allocating new memory.  The compiler works hard to let 
> you store variables on the stack rather than the heap, where no 
> slowdown occurs.  The language is designed to let you control when and 
> how memory is allocated, giving you control over when memory is 
> allocated.  The effect is that in Go you can adjust your program to 
> reduce GC overhead, rather than tuning the GC.  This is far more true 
> in Go than in Java, since Java has no stack variables or structs.  I'm 
> not familiar enough with C# to say anything serious about it. 
>
> That said, it should be obvious that nobody thinks that work on Go's 
> garbage collector has finished. 
>
> The essay mentions the request-oriented collector, which is indeed 
> similar to a generational garbage collector.  If everything works, the 
> request oriented collector can be cheaper than a generational 
> collector because no copying is required.  The essay suggests that it 
> can be simulated by a generational GC "by ensuring the young 
> generation is large enough that all garbage generated by handling a 
> request fits within it" but that is somewhat meaningless if any of 
> your requests can use a lot of memory, since you have to waste a lot 
> of space by allocating that much memory for each goroutine. 
>
> Once the request-oriented collector is working or abandoned, I believe 
> the GC team plans to focus on increasing throughput, since latency is 
> now low enough that it hopefully doesn't matter for non-realtime 
> programs. 
>
> 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.

[go-nuts] Re: Modern Garbage Collection Article

[Dave Cheney]

>  If it is, why, historically, is the work being done on the GC so 
concentrated on pause times?

Predictable latency is good for servers.

On Tuesday, 20 December 2016 15:56:39 UTC+11, Tyler Compton wrote:
>
>
> https://medium.com/@octskyward/modern-garbage-collection-911ef4f8bd8e#.c48w4ifa7
>
> Thoughts? How accurate is this article? If it is, why, historically, is 
> the work being done on the GC so concentrated on pause times?
>
> For more discussion: 
> https://www.reddit.com/r/golang/comments/5j7phw/modern_garbage_collection/
>

-- 
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] Modern Garbage Collection Article

[Ian Lance Taylor]

On Mon, Dec 19, 2016 at 8:56 PM, Tyler Compton  wrote:
> https://medium.com/@octskyward/modern-garbage-collection-911ef4f8bd8e#.c48w4ifa7
>
> Thoughts? How accurate is this article? If it is, why, historically, is the
> work being done on the GC so concentrated on pause times?

If you click on the comments link near the bottom you will see that
Rick has commented on part of the essay.

I do not work on the GC myself, but these are my personal observations.

I think the key observation in Go's GC is that modern systems have
multiple cores, and are rapidly getting more cores.  Throwing more
cores at the problem is a sensible approach on modern hardware.  Since
the cores are no longer getting faster, making your code run faster on
a single core is not the optimal design for the hardware of the near
future.

For a language like Go, stop-the-world pause times really are the most
important thing, because during a pause your server isn't doing
anything useful.  The essay suggests that the Go runtime is "willing
to slow down your program by almost any amount" in order to reduce
pause times; that is clearly hyperbole, and it isn't literally true.
The slowdowns in compiled Go code occur when writing pointers into the
heap and when allocating new memory.  The compiler works hard to let
you store variables on the stack rather than the heap, where no
slowdown occurs.  The language is designed to let you control when and
how memory is allocated, giving you control over when memory is
allocated.  The effect is that in Go you can adjust your program to
reduce GC overhead, rather than tuning the GC.  This is far more true
in Go than in Java, since Java has no stack variables or structs.  I'm
not familiar enough with C# to say anything serious about it.

That said, it should be obvious that nobody thinks that work on Go's
garbage collector has finished.

The essay mentions the request-oriented collector, which is indeed
similar to a generational garbage collector.  If everything works, the
request oriented collector can be cheaper than a generational
collector because no copying is required.  The essay suggests that it
can be simulated by a generational GC "by ensuring the young
generation is large enough that all garbage generated by handling a
request fits within it" but that is somewhat meaningless if any of
your requests can use a lot of memory, since you have to waste a lot
of space by allocating that much memory for each goroutine.

Once the request-oriented collector is working or abandoned, I believe
the GC team plans to focus on increasing throughput, since latency is
now low enough that it hopefully doesn't matter for non-realtime
programs.

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.

[go-nuts] Modern Garbage Collection Article

[Tyler Compton]

https://medium.com/@octskyward/modern-garbage-collection-911ef4f8bd8e#.c48w4ifa7

Thoughts? How accurate is this article? If it is, why, historically, is the 
work being done on the GC so concentrated on pause times?

For more 
discussion: 
https://www.reddit.com/r/golang/comments/5j7phw/modern_garbage_collection/

-- 
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: How has your company adopted Go ?

[Diego Medina]

In our case, our original product was a web app, written in Scala, as our 
data starting growing, we had to move from real time queries to our 
database plus some data manipulation to precalculating/storing the data in 
a ready to server manner.
This worked well for a while, but eventually our backend process was 
consuming large amounts of memory. This was the a good point for us to try 
Go, so we switch part of that processing to Go to see how it goes, worse 
case scenario, a crash wasn't going to affect our main product, we could 
still run the old code. Having a safe fallback was key for adoption.

But before we used Go at work, I personally made sure I was comfortable 
enough with it that I could answer any questions our team had, or at least 
being able to go look for the answer (this mailing list, stackoverflow, 
etc).

The move was great, our incoming data has grown a lot more than what it was 
3 years ago, and I keep improving the go program from time to time. We 
still run our web application in Scala, but a few months ago we also 
started handling a couple of specific pages in Go, again, if those pages 
fail, they are not critical, so it wouldn't be a reason to stop migrating. 
A few weeks ago I got our CTO onboard with Go, which was a big milestone, 
so we'll be writing more and more of the web app in Go in the near/mid 
future.

In short, if your company doesn't like taking risks, you can go slow in 
migrating to Go, have safe guards and know where to go for help.

Thanks

Diego




On Monday, December 19, 2016 at 8:03:43 AM UTC-5, Tieson Molly wrote:
>
> What arguments or factors have contributed to your company adopting Go?
>
> Many businesses see switching to a new language or even using a new 
> language side by side with their existing  language choice as a business 
> risk.
>
>   Best regards,
>
>   Ty
>
>
>

-- 
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] How can i sort array inside struct

[sergien . evgeny]

Thanks a lot!
I've tried pass pointers, but i forgot to pass & in Sort method.

вторник, 20 декабря 2016 г., 0:24:14 UTC+5 пользователь Jan Mercl написал:
>
>
> On Mon, Dec 19, 2016 at 8:16 PM  
> wrote:
>
> > This code does not do anything.
>
> The code does sort the array. It's just the copy of the array passed to 
> sort.Sort that's get sorted. That's because array is a plain old value 
> type. A pointer receiver methods fix it: 
> https://play.golang.org/p/Kgpcm191fo
> -- 
>
> -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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] How can i sort array inside struct

[Jan Mercl]

On Mon, Dec 19, 2016 at 8:16 PM  wrote:

> This code does not do anything.

The code does sort the array. It's just the copy of the array passed to
sort.Sort that's get sorted. That's because array is a plain old value
type. A pointer receiver methods fix it:
https://play.golang.org/p/Kgpcm191fo
-- 

-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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] How can i sort array inside struct

[sergien . evgeny]

This code does not do anything.

package main
import (
 "fmt"
 "sort"
)

type coll struct{
arr [4]int
}

func (c coll) Len() int{
return len(c.arr)
}

func (c coll) Less(i,j int) bool{
return c.arr[i]

Re: [go-nuts] Re: How has your company adopted Go ?

[Justin Israel]

Here are some high level slides I put together, for a demo about the
timeline of my company (Weta Digital) getting introduced to Go

talks.godoc.org/github.com/justinfx/demos/go_at_weta/go_at_weta.slide

It was a slow process, and it wasn't any kind of full switch over. Just
using the right tool for the job, as Gary just said. It seems best to not
try and just cut everything over to it in one move, but to write piece by
piece and let Go naturally prove it's worth and gain confidence and
supporters.

Then again my company is not your company, and the impact of using
different languages, as well as the approach to introduce a new language,
may be quite different.

Justin

On Tue, Dec 20, 2016, 4:28 AM  wrote:

> It should always be 'use the best tool for the job'. If Go seems like a
> good fit for a task, use it. We've used Go for creating web services
> accessed via restful API's and it works great. I've personally used Go to
> create command line utilities to help with development. We've also used it
> to prototype systems before using other languages.
>
> We don't see it as a risk but as a competitive advantage.
>
>
> On Monday, 19 December 2016 13:03:43 UTC, Tieson Molly wrote:
>
> What arguments or factors have contributed to your company adopting Go?
>
> Many businesses see switching to a new language or even using a new
> language side by side with their existing  language choice as a business
> risk.
>
>   Best regards,
>
>   Ty
>
>
> --
> 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.

Re: [go-nuts] Gob encoding of maps is not consistent, should this be fixed?

[Jan Mercl]

On Mon, Dec 19, 2016 at 5:06 PM Tom Payne  wrote:

> Note that consistent encoding of the same value is *not* specified in the
list of goals in https://blog.golang.org/gobs-of-data (in fact it is not
mentioned at all). However, it could be considered a desirable feature :)

Map keys are comparable but not necessarily ordered, so I think it's a
non-starter. If you need a reproducible map gob and the map has ordered
keys, you can always use the GobEncoder interface implementation for that.

-- 

-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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Go on AIX

[matthieu . sarter . external]

I am also working on an AIX port, from another version (GCC 7 on AIX 6.1).

For now, I have been able to complete the build, but lots of tests are 
failing. Some of the changes I made require to be reworked, as I did them 
just to allow the build to progress, to have an idea about the amount of 
changes required, now I will have to make them work properly.

I should be able to share my work soon.

On Friday, December 16, 2016 at 6:46:59 AM UTC+1, scchang wrote:
>
> Not sure if ppl in this thread are still interested. I managed to get 
> gccgo (included in gcc 4.8.4) to work on AIX 5.3. The bulk of the changes 
> are indeed in the xcoff reader as Ian and others had suggested. xcoff 
> writer also has a couple of issues as the default assembler could not 
> understand the generated assembly code as it complained about syntax error.
>
> It also appears that IBM were also trying to get gccgo to work on AIX 
> based on a recent gcc bug they filed. They probably already got it working. 
> Not sure whether and when they would upstream the changes though.
>
> On Thursday, 24 January 2013 14:15:06 UTC-8, minux wrote:
>>
>>
>> On Fri, Jan 25, 2013 at 5:50 AM, Gulácsi Tamás  wrote:
>>
>>> I've stumbled on this: 
>>> https://github.com/mirrors/gcc/commit/2c64b281f32d81eafbf0dce8b103ddbf7398ef2f
>>>
>>> What's next?
>>> What shall I do to have Go on AIX?
>>>
>> OK, so simple object reader is completed. If you have some time, you can 
>> try
>> building gccgo on AIX and fix build problems as they appear.
>>
>> sorry, i can't provide more details because based on my past experiences,
>> different systems have vastly different problems to solve. You can ask on 
>> the
>> mailing list when problem arises. (But please be prepared to upstream your
>> changes if you do want to tackle this)
>>
>

-- 
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] Gob encoding of maps is not consistent, should this be fixed?

[Tom Payne]

This example demonstrates that the Gob encoding of the same map value 
varies:
  https://play.golang.org/p/DZRV9i0uf_

This is because the encoder iterates over the map using a for ... range 
loop and the iteration order for maps is not defined:
  https://github.com/golang/go/blob/master/src/encoding/gob/encode.go#L379

Is this considered a bug and would the Go maintainers consider a patch to 
fix it? Such a patch would sort the keys first and emit the key-value pairs 
in order to provide a consistent encoding. The consistent encoding would 
likely be optional to avoid the performance and memory penalty of sorting 
the keys.

The reason this is a problem is that we generate a data file in Gob format 
as part of our build process. The encoded structure contains many maps and 
so the generated file varies on every run. This makes our build process 
non-repeatable: when using Gob the same inputs do not result in the same 
outputs.

Note that consistent encoding of the same value is *not* specified in the 
list of goals in https://blog.golang.org/gobs-of-data (in fact it is not 
mentioned at all). However, it could be considered a desirable feature :)

Regards,
Tom

-- 
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: How has your company adopted Go ?

[gary . willoughby]

It should always be 'use the best tool for the job'. If Go seems like a 
good fit for a task, use it. We've used Go for creating web services 
accessed via restful API's and it works great. I've personally used Go to 
create command line utilities to help with development. We've also used it 
to prototype systems before using other languages.

We don't see it as a risk but as a competitive advantage.

On Monday, 19 December 2016 13:03:43 UTC, Tieson Molly wrote:
>
> What arguments or factors have contributed to your company adopting Go?
>
> Many businesses see switching to a new language or even using a new 
> language side by side with their existing  language choice as a business 
> risk.
>
>   Best regards,
>
>   Ty
>
>
>

-- 
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] howto: compile template against well-known structure ?

[Andy Balholm]

I don’t know if this will be helpful to you or not, but I’ve made a package 
that is basically a copy/paste of the autoescaping logic from html/template, 
but modified to work at runtime instead of when compiling a template: 
github.com/andybalholm/escaper 

It lets you write your “template” logic in plain Go instead of the special 
template language, without needing to spend a lot of extra effort on escaping. 
The runtime impact would be mixed: you would lose the overhead of reflection, 
but gain the overhead of figuring out HTML contexts at runtime. I don’t know if 
it would be a net performance gain or not.

Anyway, your RenderComponent method would look something like this:

func (b *ButtonRenderer) RenderComponent(wr io.Writer, view 
mgc.ViewComponentRenderer, args ...interface{}) (string, error) {
if button, ok := view.(*components.Button); !ok {
return "", errors.New("wrong type expected components.Button")
} else {
e := escaper.New(w)

tag := "button"
if button.Attr.Has("href") {
if button.Attr.Has("disabled") {
tag = "span"
} else {
tag = "a"
}
}

e.Literal("<"+tag+" ")

for _, v := range button.Attr {
e.Print(v.Name+"='", v.Value, "' ")
}

e.Print("class='", button.Classes.Render(), "' ")

if button.GetValue() != "" {
e.Print("value='", button.GetValue(), "'")
}

e.Print(">", button.GetLabel(),  "")
}
return "", nil
}

The only real thinking about escaping you need to do is deciding whether to use 
a plus or a comma between strings you want to join, to preserve the proper 
alternation between literals and values in the arguments to e.Print.

Andy

-- 
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: are functions garbage collected?

[adonovan via golang-nuts]

On Monday, 19 December 2016 06:52:40 UTC-5, Jason E. Aten wrote:
>
> In the context of having a REPL for Go (and the new plugin support!) where 
> we would generate functions at runtime, I'm curious if the garbage 
> collector could be made to scan (perhaps on cue) some designated sub-space 
> for unreachable functions?  Is my assumption correct that functions are not 
> currently garbage collected?
>

The main obstacle to building a complete Go REPL in Go---one that allows 
users to define new types whose methods satisfy existing interfaces, and 
that uses the host garbage collector to determine variable lifetimes---is a 
mechanism for defining new named types and attaching methods to them.  See 
https://github.com/golang/go/issues/16522.

-- 
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] are functions garbage collected?

[Jan Mercl]

On Mon, Dec 19, 2016 at 2:22 PM Jason E. Aten  wrote:

> 1) there was always https://golang.org/pkg/reflect/#MakeFunc
>
>  2) and now with the 1.8 plugin support:
https://github.com/dragonfax/go_repl_plugin_example

None of the above generates a function (think machine code) at runtime. 1)
creates a new function value (a pointer to machine code in the first
approximation). Values are subject to garbage collection as usual. Note
that pointers to machine code are not interesting to the Go garbage
collector as the machine code is never collected (because it's never
created at runtime by Go runtime). If one would use some other mechanism
that really generates machine code at runtime, there are plenty of such,
then from the garbage collector POV they may be invisible in some mmaped
area or they may be, say a []byte, collected as usual when not reachable
anymore.

-- 

-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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] are functions garbage collected?

[Jason E. Aten]

1) there was always https://golang.org/pkg/reflect/#MakeFunc

2) and now with the 1.8 plugin support:
https://github.com/dragonfax/go_repl_plugin_example

On Mon, Dec 19, 2016 at 6:11 AM, Konstantin Khomoutov <
flatw...@users.sourceforge.net> wrote:

> On Mon, 19 Dec 2016 03:52:40 -0800 (PST)
> "Jason E. Aten"  wrote:
>
> > In the context of having a REPL for Go (and the new plugin support!)
> > where we would generate functions at runtime, I'm curious if the
> > garbage collector could be made to scan (perhaps on cue) some
> > designated sub-space for unreachable functions?  Is my assumption
> > correct that functions are not currently garbage collected?
>
> Could you please provide a simple example of "generating a function at
> runtime" in 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] How has your company adopted Go ?

[Tieson Molly]

What arguments or factors have contributed to your company adopting Go?

Many businesses see switching to a new language or even using a new 
language side by side with their existing  language choice as a business 
risk.

  Best regards,

  Ty


-- 
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] are functions garbage collected?

[Konstantin Khomoutov]

On Mon, 19 Dec 2016 03:52:40 -0800 (PST)
"Jason E. Aten"  wrote:

> In the context of having a REPL for Go (and the new plugin support!)
> where we would generate functions at runtime, I'm curious if the
> garbage collector could be made to scan (perhaps on cue) some
> designated sub-space for unreachable functions?  Is my assumption
> correct that functions are not currently garbage collected?

Could you please provide a simple example of "generating a function at
runtime" in 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] are functions garbage collected?

[Jason E. Aten]

In the context of having a REPL for Go (and the new plugin support!) where 
we would generate functions at runtime, I'm curious if the garbage 
collector could be made to scan (perhaps on cue) some designated sub-space 
for unreachable functions?  Is my assumption correct that functions are not 
currently garbage collected?

-- 
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: howto: compile template against well-known structure ?

[Egon]

On Monday, 19 December 2016 13:04:23 UTC+2, mhh...@gmail.com wrote:
>
> hi, thanks. 
>
> tbh, i m not sure i feel like i want to do php-like dev in go. 
> I m not even certain that the apparent gain in flexibility and speed of 
> development really worth it. 
> Guts tell me this is like giving the wrong tools to the wrong worker to do 
> the wrong job. 
> A front end dev won t really benefit of such powerfull templates, and it 
> could probably 
> give him way more hard time than benefits, a backend dev does not really 
> benefit of such 
> intrusion of his code into the presentation layer, he usually is not so 
> good in design.
> Also, i don t think it helps to solve the general problem of go with 
> templating, 
> express similarities but yet avoid duplication, when you develop a backend 
> you have hundreds of pages very similar to each other, a table of users or 
> a table of blog posts 
> its a table after all, except those little differences in the number and 
> types of column, 
> which go really is not good to manage, because their are totally different 
> according to its type model. 
> Giving more responsibility and power to the presentation, to me, really 
> does not sound to be a way to solve that.
> Recently i worked on a component oriented approach with a clear separation 
> of concerns 
> between the client and server domains, i found it was a good fit between 
> all parameters i identified 
> and felt concerned with.
> yet i guess we agree to say its a waste to loose so much machine resource 
> with the current implementation of templates, even though, 
> and as often with go, there are lots of great and awesome properties in it.
>

Just a note, you can also think of working with a custom DSL, rather than 
working with templates or io.Writer directly... e.g:

type Table struct {
Rows []struct{
Cells []ui.Renderer
}
}

func (table *Table) Render(w ui.Writer) {
defer w.Wrap("table")()
for _, row := range table.Rows {
w.Start("tr")
for _, cell := range row.Cells {
w.Start("td")
cell.Render(w)
w.End("td")
}
w.End("tr")
}
}

type CustomLink struct {
Name  ui.TextContent
IDui.ID
Class ui.ClassList
URL   ui.URL

Disabled bool
}

func (link *CustomLink) Render(w ui.Writer) {
if !link.Disabled {
defer w.Wrap("a")()
link.URL.Render(w)
} else {
defer w.Wrap("span")()
}

link.ID.Render(w)
link.Class.With("my-custom-link").Render(w)
link.Name.Render(w)
}

+ Egon


> On Monday, December 19, 2016 at 8:11:51 AM UTC+1, Aliaksandr Valialkin 
> wrote:
>>
>> Take a look at https://github.com/valyala/quicktemplate . Though it is 
>> incompatible with template/html sytax, it provides static template 
>> compilation, high performance and go-like syntax.
>
>

-- 
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: howto: compile template against well-known structure ?

[mhhcbon]

hi, thanks. 

tbh, i m not sure i feel like i want to do php-like dev in go. 
I m not even certain that the apparent gain in flexibility and speed of 
development really worth it. 
Guts tell me this is like giving the wrong tools to the wrong worker to do 
the wrong job. 
A front end dev won t really benefit of such powerfull templates, and it 
could probably 
give him way more hard time than benefits, a backend dev does not really 
benefit of such 
intrusion of his code into the presentation layer, he usually is not so 
good in design.
Also, i don t think it helps to solve the general problem of go with 
templating, 
express similarities but yet avoid duplication, when you develop a backend 
you have hundreds of pages very similar to each other, a table of users or 
a table of blog posts 
its a table after all, except those little differences in the number and 
types of column, 
which go really is not good to manage, because their are totally different 
according to its type model. 
Giving more responsibility and power to the presentation, to me, really 
does not sound to be a way to solve that.
Recently i worked on a component oriented approach with a clear separation 
of concerns 
between the client and server domains, i found it was a good fit between 
all parameters i identified 
and felt concerned with.
yet i guess we agree to say its a waste to loose so much machine resource 
with the current implementation of templates, even though, 
and as often with go, there are lots of great and awesome properties in it.

On Monday, December 19, 2016 at 8:11:51 AM UTC+1, Aliaksandr Valialkin 
wrote:
>
> Take a look at https://github.com/valyala/quicktemplate . Though it is 
> incompatible with template/html sytax, it provides static template 
> compilation, high performance and go-like syntax.

-- 
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] Packaging Test Utilities in a Project

[Henry]

Thanks. It does work. I suppose I had wrong assumptions on how the 
'internal' package works. I thought it is usable only by its immediate 
parent package. It turns out it is usable by any other packages that share 
the same parent as the internal package. 

Thanks again, everyone! :)

Henry

On Monday, December 19, 2016 at 1:31:03 PM UTC+7, Marian Kopriva wrote:

> What Dave suggested should work, in your example package1, package2, 
> package3 and package4 should be able to import testhelpers with `import 
> "project/internal/testhelpers"`
>
> On Sunday, December 18, 2016 at 2:48:41 PM UTC+1, Henry wrote:
>>
>> Where do you put this internal package in relation to the rest of the 
>> packages? Is it something like this:
>>
>> project/
>>package1/
>>package2/
>>package3/package4/
>>internal/testhelpers/
>>
>> I thought internal package would only be visible to its immediate parent? 
>> I want it to be usable across the packages. 
>>
>> 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.

[go-nuts] Re: What's the -buildid for?

[Dave Cheney]

The build id is a hash of the package's source and tags. It allows the Go 
tool to detect when a package is compiled with different tags or when a 
source file is removed from the source directory.

On Monday, 19 December 2016 18:41:04 UTC+11, sca...@gmail.com wrote:
>
> When I run go build -x, I find that there is -buildid flag in the compile 
> and link command. What is it for?
>

-- 
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: gomobile: support/v7/app vs app

[Elias Naur]

Use a package rename for one of the imports:

import sapp "android.support.v7.app.AppCompatActivity"

And then use "sapp" for the support library app Java package.

- Elias
man. 19. dec. 2016 kl. 06.59 skrev andrey mirtchovski :

> The main activity in the reverse example uses a
> support/v7/app.AppCompatActivity (as it should), however if I want to add
> an app.Service service to the android app gomobile encounters duplicate
> import errors:
>
>gomobile_bind/go_appmain.go:20: app redeclared as imported package name
>
> If I attempt to resolve this by renaming v7/app gomobile still complains:
>
>gomobile_bind/go_appmain.go:31: undefined:
> "Java/android/support/v7/app".Service
>
> (I suspect it doesn't propagate the rename, but I have not yet looked at
> the generated code).
>
> Essentially I have two files (activity.go and service.go) which each
> import something called "app", one from android.support.v7.app, the other
> from android.app... I can successfully refactor the service into a separate
> package but then I'm only allowed to use one package name in the manifest
> and I don't see how I can reference the second package by name.
>
> http://schemas.android.com/apk/res/android;
> package="go.app" >
>  android:label="MyApp"
>  android:name=".MainActivity">   
> 
>
> 
> 
> 
>

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