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 m...@mjmworks.co.uk ---- 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 <kato...@freaknet.org> 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@lists.dyne.org >> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng >_______________________________________________ >Dng mailing list >Dng@lists.dyne.org >https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
