On Sun, 17 Jun 2012 05:00:10 -0700 (PDT)
Archos <raul...@sent.com> wrote:
> There are many projects where you could need complete control of
> memory so C follows being the tool to use, but it would be nice if we
> would have a "C" with the sintaxis of Go, its concurrency, library and
> fast compilation; its name could be G.
>
> Any language/system developer has thinked in creating a "version" of
> Go without the garbage collector?
Yes. At some point I was thinking this is the right choice and the most
important part of the Go is its syntax. I wrote a prototype compiler
for a C-like language but with Go syntax:
https://github.com/nsf/krawl
http://nosmileface.ru/krawl/krawl_by_example.html
It was working at some point and there was a clang plugin for importing
C stuff and I even wrote a tetris game in it:
https://github.com/nsf/krawl/blob/master/examples/tetris.krl
But then when I started to think about all the Go features (methods,
goroutines, channels, slices, maps, interfaces, select, defer), slowly
I realized that the Go isn't just a syntax and you can't get near Go
experience without GC and its magnificent runtime.
If you try to
implement most of the Go features, you need some form of automatic
memory management.
C approach just doesn't work, believe me and syntax
alone doesn't make much difference.
On Sun, Jun 17, 2012 at 10:00 PM, Archos <raul...@sent.com> wrote:
> There are many projects where you could need complete control of
> memory so C follows being the tool to use, but it would be nice if we
> would have a "C" with the sintaxis of Go, its concurrency, library and
> fast compilation; its name could be G.
>
> Any language/system developer has thinked in creating a "version" of
> Go without the garbage collector?
You can't have Go syntax without a garbage collector.
There are many previous threads of the mailing list explaining why.
+ Line-ending semicolons optional
+ Type conversions must be made explicit
+ go and select control keywords, and channels to support concurrent
programming, if it's possible
+ Built-in types like maps, Unicode strings, array slices
+ Variadic functions
+ Multiple return values
+ Funtions literal and closures ?
+ Error handling
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/165ebe92-362d-44f0-9ddb-2e152276b6fc%40googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to golan...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/c03420c5-d1b0-4c73-8a61-f4fa131018f9%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/6B0E7750-C1CB-4043-80BA-277D7CE08479%40ix.netcom.com.
I found a more recent academic paper that proves my conclusions:
On Feb 12, 2020, at 6:36 AM, Brian Candler <b.ca...@pobox.com> wrote:
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/230ed453-0897-48a7-8662-4807e7774e85%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/EF2B49E6-2A39-4582-9308-84F5D35F91EA%40ix.netcom.com.
On Feb 12, 2020, at 7:24 AM, Henrik Johansson <dahan...@gmail.com> wrote:
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/f388606c-7f52-78bc-f59c-776688114e4f%40gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAKOF695amjn_FvHrh1S2x41knXOQ9Dq-yX2%2Bfh5jDL_dDJenaA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/90A5BFEA-AC78-400D-96D8-D618434A7583%40ix.netcom.com.
On Feb 12, 2020, at 11:50 AM, Marcin Romaszewicz <mar...@gmail.com> wrote:
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAKOF695amjn_FvHrh1S2x41knXOQ9Dq-yX2%2Bfh5jDL_dDJenaA%40mail.gmail.com.
-----Original Message-----
From: Jesper Louis Andersen
Sent: Feb 12, 2020 12:13 PM
To: Henrik Johansson
Cc: Kevin Chadwick , golang-nuts
Subject: Re: [go-nuts] Go without garbage collector
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAGrdgiWTDKpdX3tMAecRf770YWDsFHbvjY%2BTcMAxQ5A3LZMe6w%40mail.gmail.com.
Here is a paper from 2005 https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf that proves otherwise.
GC techniques have radically improved since then, some with hardware support, so much so that it is no longer a contest.To reiterate though, if you don’t have dynamic memory management - which is essentially allocate and forget - that will “probably" be faster (many GC systems have an extra level of indirection).You can write robust systems without dynamic memory, but it is very very difficult - beyond the skills of most developers.So most developers resort to dynamic memory at some point - and once you do that - GC will crush your manual memory management techniques.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/c03420c5-d1b0-4c73-8a61-f4fa131018f9%40googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/465e2109-e0a5-4fdc-9dbf-5670eb73bfef%40googlegroups.com.
What about #vlang ? https://vlang.io/
-----Original Message-----
From: alex.be...@gmail.com
Sent: Feb 12, 2020 3:06 PM
To: golang-nuts
Subject: Re: [go-nuts] Go without garbage collector
I'm very familiar with this paper. It's not the first one that uses oracular memory management for comparison, the earlier one used ML as its langauge.The problem with these papers is that they're using very artificial benchmarks, not really representative of real workloads. They additionally use languages that are very heap-oriented, with very few value objects.GCs also have not radically improved since then, if anything they are worse now in massively-parallel environment than on single-core CPUs of yore.
On Tuesday, February 11, 2020 at 8:54:29 PM UTC-8, robert engels wrote:
Here is a paper from 2005 https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf that proves otherwise.
GC techniques have radically improved since then, some with hardware support, so much so that it is no longer a contest.To reiterate though, if you don’t have dynamic memory management - which is essentially allocate and forget - that will “probably" be faster (many GC systems have an extra level of indirection).You can write robust systems without dynamic memory, but it is very very difficult - beyond the skills of most developers.So most developers resort to dynamic memory at some point - and once you do that - GC will crush your manual memory management techniques.
On Feb 11, 2020, at 10:31 PM, alex.b...@gmail.com wrote:
Actually, it was not proven. And in practice manual memory management seems to be outperforming GC in majority of cases.
On Tuesday, February 11, 2020 at 5:59:26 PM UTC-8, robert engels wrote:
It’s been PROVEN that GC outperforms all manual memory management except in EXTREMELY isolated cases (very non-traditional allocation or deallocation patterns).It’s all about constraints and tolerances.
You design a “system” that takes both into account - if not, you’re not engineering, you're guessing.
On Feb 11, 2020, at 4:29 AM, deat...@gmail.com wrote:
To me it seems the issue of concurrency and dynamic ownership of memory are so deeply connected to Go’s programming methodology that the “no GC” comparison is biased.In particular, coding to do it yourself but as perfectly as the GC across many concurrent routines is hard. Doing it better than the GC is hard. Caution encourages use of the tuned GC.Agree with posts above: preallocation is fastest. Hard real time from the 80s lesson.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/465e2109-e0a5-4fdc-9dbf-5670eb73bfef%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/465e2109-e0a5-4fdc-9dbf-5670eb73bfef%40googlegroups.com.
GCs have radically improved since then - at least in practical implementation.Again, see G1, Metronome, Zing or Shenandoah - none of these were available in 2005.(Or even Go's GC performance progression - but as I mentioned, in this particular test the lack of a generational collector is holding it back).
On Feb 12, 2020, at 8:22 PM, alex.be...@gmail.com wrote:
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/36d34a8b-435d-4dab-b3b7-3d3471ff7428%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/662CB08C-4A92-4C3C-93E8-5C65A53ACAAD%40ix.netcom.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/5162AEA4-E03D-4250-BB93-F661659FC5B1%40ix.netcom.com.
G1GC only went into production with Java 7 in 2011.I don’t think you understand how Zing works. Furthermore, malloc based systems actually have longer pauses especially as things get fragmented.I believe your knowledge of modern GC is way out of date.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/36d34a8b-435d-4dab-b3b7-3d3471ff7428%40googlegroups.com.
for (MaoCFG::NodeMap::iterator bb_iter = CFG_->GetBasicBlocks()->begin();
bb_iter != CFG_->GetBasicBlocks()->end(); ++bb_iter) { }
number[(*bb_iter).second] = kUnvisited;
bb_iter != bb_end; ++bb_iter) { |
number[(*bb_iter).second] = kUnvisited; |
The same kind of rookie mistakes (made by fresh-from college developers?) is all over the place. Honestly, I think that they pessimized the C++ code until they reached the desired outcome. If you want a somewhat more realistic range of benchmarks, look at Debian's Benchmark game: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/java.html |
Here is some pretty indisputable evidence on the advancements of GC/JVM vs C++.See this paper/project https://github.com/hundt98847/multi-language-bench that was done by Google in 2011. If you read the paper, the C++ code was tuned by expert C++ programmers at Google. The java_pro author version refused to optimize further - which he felt would create “esoteric non-idomatic” Java.The paper reports that the C++ code outperformed java_pro by 4x - 12x, and go_pro by 5.5xI re-ran the tests using the latest C++ compiler,Go, and Java 13. The code is unchanged since it was posted. Nothing has been modified (Go needed the directory structure changed to compile). Different hardware. Different OS. Different compilers. Different Java runtime. (same JVM settings - so using a different default GC). All tests run on the same OS/hardware.C++ (-O2) = 16.5 secsC++ (-O3) = 16.5 secsgo_pro = 19 secsjava_pro = 8.4 secsOr Java is almost 2x faster than C++, and Go is nearly the same performance as C++.Run the tests yourself… (easy to do, Makefiles included)JVM/GC has improved DRAMATICALLY in the past 9 years - static compilation/optimization not so much… Stressing again - ZERO CODE CHANGES !Enjoy !
(Or even Go's GC performance progression - but as I mentioned, in this particular test the lack of a generational collector is holding it back).
On Feb 13, 2020, at 1:41 AM, alex.be...@gmail.com wrote:
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/025972ea-042c-4ee9-9f11-8805e8104316%40googlegroups.com.
On Feb 13, 2020, at 8:05 AM, Robert Engels <ren...@ix.netcom.com> wrote:
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/B66CFF58-8163-4E4D-9E67-6FA3737ACE07%40ix.netcom.com.
On Feb 13, 2020, at 8:05 AM, Robert Engels <ren...@ix.netcom.com> wrote:
The code hasn’t been changed. The performance numbers have changed dramatically with no developer intervention. No “hand optimizing” required.
-----Original Message-----
From: ⚛ <0xe2.0x...@gmail.com>
Sent: Feb 13, 2020 9:57 AM
To: golang-nuts
Subject: Re: [go-nuts] Go without garbage collector
On Thursday, February 13, 2020 at 3:05:45 PM UTC+1, Robert Engels wrote:The code hasn’t been changed. The performance numbers have changed dramatically with no developer intervention. No “hand optimizing” required.C++ evolves over time also. Hashmaps have been added to C++ in C++11, which from today's viewpoint invalidates most benchmarks published before year 2011 that translated Java's HashMap to C++'s std::map.
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/f5a4a3cf-e4ce-4fb4-af03-fa5f32a5ce62%40googlegroups.com.
-----Original Message-----
From: Robert Engels
Sent: Feb 13, 2020 11:33 AM
To: ⚛ <0xe2.0x...@gmail.com>, golang-nuts
Subject: Re: [go-nuts] Go without garbage collectorI won't dispute that, but at least this particular case, it requires on-going maintenance by the developer (company). In this case of Java very few performance improvements have required code changes.--Using a different structure entirely (hash map vs. tree map) is a different issue - it touches on the robustness of the stdlib, dynamic runtime class replacement, etc. I can only assume that std::map was used because it made the code easier/portable to write in C++ rather than adding an outside dependency or custom hash map. implementation (In the Java code, they use a custom IntegerSet, IntegerList to avoid boxing...)-----Original Message-----
From: ⚛ <0xe2.0x...@gmail.com>
Sent: Feb 13, 2020 9:57 AM
To: golang-nuts
Subject: Re: [go-nuts] Go without garbage collectorOn Thursday, February 13, 2020 at 3:05:45 PM UTC+1, Robert Engels wrote:--The code hasn’t been changed. The performance numbers have changed dramatically with no developer intervention. No “hand optimizing” required.C++ evolves over time also. Hashmaps have been added to C++ in C++11, which from today's viewpoint invalidates most benchmarks published before year 2011 that translated Java's HashMap to C++'s std::map.
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/f5a4a3cf-e4ce-4fb4-af03-fa5f32a5ce62%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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/1149226989.3184.1581615195727%40wamui-sophie.atl.sa.earthlink.net.
I won't dispute that, but at least this particular case, it requires on-going maintenance by the developer (company). In this case of Java very few performance improvements have required code changes.
Using a different structure entirely (hash map vs. tree map) is a different issue - it touches on the robustness of the stdlib, dynamic runtime class replacement, etc. I can only assume that std::map was used because it made the code easier/portable to write in C++ rather than adding an outside dependency or custom hash map. implementation (In the Java code, they use a custom IntegerSet, IntegerList to avoid boxing...)
-----Original Message-----
From: ⚛ <0xe2.0...@gmail.com>
Sent: Feb 13, 2020 9:57 AM
To: golang-nuts
Subject: Re: [go-nuts] Go without garbage collectorOn Thursday, February 13, 2020 at 3:05:45 PM UTC+1, Robert Engels wrote:--The code hasn’t been changed. The performance numbers have changed dramatically with no developer intervention. No “hand optimizing” required.C++ evolves over time also. Hashmaps have been added to C++ in C++11, which from today's viewpoint invalidates most benchmarks published before year 2011 that translated Java's HashMap to C++'s std::map.
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 golan...@googlegroups.com.
-----Original Message-----
From: Alex Besogonov
Sent: Feb 13, 2020 12:18 PM
To: Robert Engels
Cc: golang-nuts
Subject: Re: [go-nuts] Go without garbage collector
@atom ... I changed the cpp code to use unordered_map (cc and h) and it made the code slower... (iteration over most hash map implementations is slower than sorted maps since often you need to skip the unused key slots).
So I would be very curious to see your code changes where this brought the performance to the level of Java ?
This is not my experience. Did you actually do this?
-----Original Message-----
From: Robert Engels
Sent: Feb 13, 2020 11:33 AM
To: ⚛ <0xe2.0...@gmail.com>, golang-nuts
Subject: Re: [go-nuts] Go without garbage collector
I won't dispute that, but at least this particular case, it requires on-going maintenance by the developer (company). In this case of Java very few performance improvements have required code changes.
Using a different structure entirely (hash map vs. tree map) is a different issue - it touches on the robustness of the stdlib, dynamic runtime class replacement, etc. I can only assume that std::map was used because it made the code easier/portable to write in C++ rather than adding an outside dependency or custom hash map. implementation (In the Java code, they use a custom IntegerSet, IntegerList to avoid boxing...)
-----Original Message-----
From: ⚛ <0xe2.0...@gmail.com>
Sent: Feb 13, 2020 9:57 AM
To: golang-nuts
Subject: Re: [go-nuts] Go without garbage collectorOn Thursday, February 13, 2020 at 3:05:45 PM UTC+1, Robert Engels wrote:--The code hasn’t been changed. The performance numbers have changed dramatically with no developer intervention. No “hand optimizing” required.C++ evolves over time also. Hashmaps have been added to C++ in C++11, which from today's viewpoint invalidates most benchmarks published before year 2011 that translated Java's HashMap to C++'s std::map.
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 golan...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/f5a4a3cf-e4ce-4fb4-af03-fa5f32a5ce62%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 golan...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/b4dadd10-e44c-458c-9d27-fbd3d7e6ba93%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/1087935131.4244.1581625624369%40wamui-sophie.atl.sa.earthlink.net.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/33723531-2ad2-4161-ae3e-14ec375cbb90%40googlegroups.com.
You can clearly see that the vast majority of CPU time was consumed by allocation and de-allocation.
On Feb 14, 2020, at 8:35 AM, ⚛ <0xE2.0x...@gmail.com> wrote:
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/68217d56-e01d-4046-8f25-b773cf38afbb%40googlegroups.com.
If each object exists independently - which it does in this case - you must use a free on each object. So you are going to loop - it just may be hidden from you.
And no, reference counting is NOT a GC.
-----Original Message-----
From: ⚛ <0xe2.0x...@gmail.com>
Sent: Feb 14, 2020 8:52 AM
To: golang-nuts
Subject: Re: [go-nuts] Go without garbage collector
On Friday, February 14, 2020 at 3:43:40 PM UTC+1, Robert Engels wrote:If each object exists independently - which it does in this case - you must use a free on each object. So you are going to loop - it just may be hidden from you.I am sorry, I do not understand your style of reasoning in general.
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/9f980aed-6fd7-4ac5-ab79-c8415302a31c%40googlegroups.com.
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/gPoYIPBGy24/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/1662044109.1005.1581699420223%40wamui-sophie.atl.sa.earthlink.net.
-----Original Message-----
From: Alex Besogonov
-----Original Message-----
From: Robert Engels
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/1282352587.1683.1581701009083%40wamui-fuzz.atl.sa.earthlink.net.
Yes, and when you store value objects in a vector and it is resized, it is very expensive as you need to make copies of "large objects", vs a "pointer to an object".
-----Original Message-----
From: ⚛ <0xe2.0x...@gmail.com>
Sent: Feb 14, 2020 11:37 AM
To: golang-nuts
Subject: Re: [go-nuts] Go without garbage collector
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/bfe34744-2d1e-47bb-8ac5-2b18e42bcdd2%40googlegroups.com.
Yes, and then the access and iteration is slower as it needs indirection to find the correct page. There is no free lunch.The caveats about using mutable objects, sharing, and concurrency still apply.A virtual machine environment has nothing to do with preventing direct memory access. You can do direct memory access in Java. I think what you are referring to is a "managed memory", or "safe memory" environment.Honestly, this stuff is CS 101 (maybe 201), and we've strayed so far off the topic. I didn't write the code. Take it up with those Googlers if you think it's bad. I was using the code as a baseline to demonstrate improvements in JVM/GC technology, nothing more - and for that it was appropriate.
-----Original Message-----
From: ⚛ <0xe2.0x...@gmail.com>
Sent: Feb 14, 2020 11:57 AM
To: golang-nuts
Subject: Re: [go-nuts] Go without garbage collector
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/94a121dc-cdef-4b6a-a6b7-dc0b8f910b1f%40googlegroups.com.
On Mar 3, 2020, at 3:55 PM, ⚛ <0xE2.0x...@gmail.com> wrote:
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/1b451260-96aa-4e19-b432-f47001a32e0c%40googlegroups.com.
On Tuesday, March 3, 2020 at 11:25:22 PM UTC+1, Robert Engels wrote:
A key statement in the link “ The JIT-generated code is significantly faster than the ahead-of-time-generated code for small matrix sizes.”
Which is what you were arguing was not possible... you can’t have it both ways.
-----Original Message-----
From: ⚛ <0xe2.0x...@gmail.com>
Sent: Mar 3, 2020 4:35 PM
To: golang-nuts
Subject: Re: [go-nuts] Go without garbage collector
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/dd32ec49-3d7c-4984-b57b-510746da8f55%40googlegroups.com.