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 <javascript:> wrote: > > What about #vlang ? https://vlang.io/ > > On Sunday, 17 June 2012 22:40:30 UTC+2, nsf wrote: >> >> On Sun, 17 Jun 2012 11:48:53 -0700 (PDT) >> ⚛ <0xe2.0...@gmail.com> wrote: >> >> > > You can't have Go syntax without a garbage collector. >> > > >> > >> > I wouldn't be so sure about it. >> > >> >> Let me rephrase myself. When someone says "I want Go without garbage >> collection" it means a person wants a feel he has with Go, but at the >> same time without garbage collection. At least that's my case. I wanted >> exactly that. And you can't have that. You can build a language similar >> to Go without GC, but you won't get a feel of Go. At least, I couldn't >> do it. And maybe it's kind of obvious, but when there is a need to >> manage memory, that factor alone creates a different programmer mindset. >> And in my opinion what Go does so well for a programmer is establishing >> its own mindset that gives a very nice and smooth development process. >> What we call "a feel of Go". >> >> That's actually very same mistake that leads to talks like "where is my >> feature X? I want feature X in your language". And the problem here is >> that a language is not just a collection of features, it's a >> composition of features. You can't just stick something in and make it >> better (see C++) and you can't throw something out. Every feature >> addition/removal affects the language as a whole, mutating it to a >> different state. And in my opinion GC is a critical feature that allows >> you to have memory safety and (well, let's put it that way) memory >> safety is one of the major features in Go. >> >> So.. think about it. "I want Go with templates" and "I want Go without >> garbage collection" are very similar things. Both hide the desire of >> improving/changing something without realization that this will affect >> other areas dramatically. >> >> And to make a summary: I tried that, I did that mistake thinking you >> can build something out of Go just by taking parts you like and mixing >> them in some weird way. I was stupid (to make it clear, I'm not >> implying that anyone is). Hopefully what I said makes some sense. >> >> >> Offtopic: >> >> Btw. Thanks for your work on GC precision, I really hope those patches >> will get into Go. One of the areas where I want to apply Go is desktop >> applications. And for these you need a precise GC, because some desktop >> apps have uptime measured in days or weeks (especially on geek's linux >> machines) and you clearly don't want to get mozilla's firefox fame for >> eating all the memory. >> > > -- > 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 <javascript:>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/165ebe92-362d-44f0-9ddb-2e152276b6fc%40googlegroups.com > > <https://groups.google.com/d/msgid/golang-nuts/165ebe92-362d-44f0-9ddb-2e152276b6fc%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/c03420c5-d1b0-4c73-8a61-f4fa131018f9%40googlegroups.com.
