I've been playing with golang recently and although you can't strictly stop it garbage collecting you can compile with a flag which produces the output of the escape analysis. Anything that doesn't escape gets stored on the stack. Things that might are stored in the heap.
I often compile with the flag and see if there is a way to use the stack rather than the heap in what I am doing. In hope that the heap will get hit less. Perhaps the other gc languages have a similar feature that isn't being used as much as it might?

Matthew Melton
mjm@???

---- Gravis wrote ----

>> > Contrary to what most "modern" programmers would like to promote, I
>> > do not believe for one second that mandatorily garbage collected,
>> > bounded languages create better code design.
>>
>> I honestly can't see all this failing around of code written in
>> Python, Perl or Ruby :)
>
>garbage collection is actually a compounding issue, meaning that while
>it may not be a problem for programs that are only active for a few
>minutes before terminating, it is a problem for programs that are high
>intensity or run indefinitely. it's typical (just ask an admin) for
>internally developed server side Java business database applications
>to require they be restarted daily because the devs cant figure out
>why they are "running out" of memory and it's easier just to have it
>restarted. if they were developing in perl, python or any other
>number of GC languages, it would still be an issue. while it /can/ be
>used properly, garbage collection is more of a hassle than it's worth.
>--Gravis
>
>
>On Mon, Mar 2, 2015 at 4:26 AM, KatolaZ <katolaz@???> wrote:
>> On Mon, Mar 02, 2015 at 02:59:40AM -0600, T.J. Duchene wrote:
>>
>> [cut]
>>
>>>
>>> Contrary to what most "modern" programmers would like to promote, I
>>> do not believe for one second that mandatorily garbage collected,
>>> bounded languages create better code design. I would subscribe to
>>> precisely the reverse, actually. If there is a flaw in the
>>> collector or the bound check, you have an extremely hard to fix
>>> problem that affects virtually everything. You are also
>>> continuously wasting resources on overhead for features that can
>>> fail without warning. Even if you set that aside, the reality is
>>> that you are investing in all of that wasted overhead for vanishing
>>> returns. At no time are those features a 100% effective solution to
>>> the problems they were intended to solve, and they create entirely
>>> new ones. So what good are they, really?
>>>
>>> Any code that does not work reliably isn't worth much.
>>>
>>
>> I honestly can't see all this failing around of code written in
>> Python, Perl or Ruby :) Bad code is bad code in C, C++, Perl, Python,
>> LISP, or whatever other language you can think of, and bad code will
>> either get better or die. IMHO the evil is not in any specific
>> language, but in the way you use it.
>>
>> Concerning "performance", well it is not always the most important
>> thing. I personally use C a lot for simulations and scientific
>> calculations, but I would never do data analysis and postprocessing in
>> C, since it would require every time a few days just to have a running
>> thing to be used only once or twice, while I can do the same task in
>> Python with 10 minutes coding and a few minutes more processing. In
>> that case, *my* time and *my* performance is more important than the
>> time it takes to the machine to crunch a few million numbers :)
>>
>> While I totally agree about the necessity to teach "good programming
>> practices" to young coders, I am convinced that there is no such thing
>> as the "perfect" language. It's just a matter of taste. And if you are
>> a good coder you will write good code in asm, C, Perl, Python or
>> Erlang. If you are not, then your code will be crap anyway :)
>>
>> HND
>>
>> KatolaZ
>>
>> --
>> [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
>> [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
>> [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
>> [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
>> _______________________________________________
>> Dng mailing list
>> Dng@???
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>_______________________________________________
>Dng mailing list
>Dng@???
>https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng