Also it assumes that only one program is running on a machine and it's ok to use all the machine's resources. In practice that isn't true - if your web application uses twice as much server memory then you're going to be paying nearly twice as much for your cluster of servers. That makes a big difference.

"The most amazing achievement of the computer software industry is its continuing cancellation of the steady and staggering gains made by the computer hardware industry." (Henry Petroski)

Right! Had we not squandered all those wonderful hardware performance gains on useless stuff like web browsers, searching the entire internet in milliseconds or streaming HD video over the net, we could now play Pac-Man thousands of times faster than in 1983!!!

It's not a limitation, just a tuning knob that can be used to trade off GC cycles against memory usage. If you're in a low-memory environment, tune the knob to use more CPU.

My comment was targeting that particular statement and was not meant to be interpreted as a deficiency in this particular GC design, though if I were to comment about that, I have to say I remain a bit skeptical about how far you can effectively scale it down via this single knob technique; scaling up, I'm more certain about.

Fair enough. It might not scale down that well, especially since on low-memory systems you often worry about CPU usage and power usage as well. But Go uses a lot less memory to begin with, so the default GOGC value of 100% (half of application memory used, half free) will still be less than a similar Java program, even ignoring that Java also needs a heap larger than the allocated size to get good performance.

What if you're in a low-everything environment?

Then don't use Go. Go was pitched as a systems language, but has found its niche as a server language. It's to be expected that the maintainers will make decisions that tune it for servers.

Don't use a language which has GC. Allocate all objects statically.. no memory management needed at runtime.

At some point you can no longer afford the luxury of a garbage collector. As the tech gets better, that point gets lower and lower, but there are still limitations.

Phones have two gigs of RAM and four cores these days. Low what? If you're talking software on an internet connected fridge, then, maybe, but that's a pretty niche area even in today's mostly theoretical and overpriced IOT world.

>smaller, low-power embedded/IoT device

Do you want a GC there anyways?

There's a market for embedded Java. Atego makes a variety of runtimes for real-time use.

http://www.ptc.com/developer-tools/perc

Latency under 1ms per their material.

That's interesting, from a business perspective. How did they arrive at that market via CAD?

What do you mean arrive "via CAD?" What is CAD in this context?

I mean how did PTC go from selling solid modelling software for IRIX to hawking an embedded JVM?

Hell, I didn't even know they were PTC now. On an acquisition or name-changing spree it seems lol. Aonix developed and marketed the Java technology. Got acquired by Atego and now apparently PTC. You will probably find the Wayback Machine's copy more informative with the non-JS links on left leading to PDF's showing its capabilities:

https://web.archive.org/web/20111101211755/http://www.aonix....

They had standard Java support, a better native API, GC pauses down to 100 microseconds, AOT compilation, and so on. I especially liked how they supported separation kernels like INTEGRITY and non-x86 architectures. The ability to use strong, user-mode isolation on the VM plus obfuscation of codebase and processor ISA makes for high resistance to whatever Internet throws at you. ;) Plus, embedded boards can be really cheap w/ Freescale's doing I/O, crypto, and TCP acceleration.

So, I thought it was cool shit that could've benefited mainstream market if they thought of things like this and applied it properly. Could always build, in parallel, a FOSS-based setup in case they pulled out or some other crap that happens with proprietary companies. Can just painlessly move off their stack. Meanwhile, their stack rocked in its domain, still does given numbers I'm seeing in Go etc, and it's worth copying in some ways.

Yes, very much so. GC on powerful servers is a well trodden path. Low power devices much less so.

Isn't it a less troden path because it's sacrificing too much and gaining too little, especially when we have languages coming up like rust with the memory safety of a GC but no gc runtime cost?

I ask because I don't have much low-level/embedded experience, and I'm unaware of why you'd want a gc on such low power systems. If there's a use case though, I'd love to learn about it!

I think the question is easier to answer if we view "garbage collection" as automatic memory management in general, rather than a more specific case of automatic memory management via a runtime task colloquially known as the garbage collector. I believe automatic memory management is a universally desirable property whether you are running on a server or a small device. However, since you brought up Rust, I also think it is valid to debate the value of a runtime GC as opposed to another automatic memory management technique like automatic reference counting. I don't think that question is embedded-specific though: it applies just as much to the server environment.

How is tracing GC vs. pervasive reference counting relevant to Rust?

I merely used automatic reference counting as one alternative automatic memory management technique. Rust, as I understand it, uses a similar alternative, which is, at least on paper, similar to enforcing a max refcount of one on pointers, statically. I'm far from a Rust expert so feel free to correct me if I'm wrong.

I'd say that "reference counting" implies a dynamic/runtime component, which is not how Rust manages memory (unless you're specifically using the `Rc` pointer in the stdlib).

I think it's important to be clear here because Swift and Objective-C rely on a technology known as "Automatic Reference Counting" (ARC), which does imply the usual dynamic cost of reference counting.

I think the go guys are clearly focusing on server applications.

> potentially dangerous worldview

those tools are the same freaks that make Chrome take 150MB-200MB per Tab and ruined my perfectly usable 8GB-RAM system in a matter of 2 years.

You may enjoy this: https://chrome.google.com/webstore/detail/the-great-suspende...

How reliable is this one? Browsers these days are infuriatingly memory hog and Chrome is the champion specially in OSX.

I haven't had any problems with it. As somebody who has ~100 tabs open at any given time, this extension is a godsend.

you know, considering I manage with 300GB / month I don't see why I should need 200MB for each website. Just keep it serialized and compressed until I need it.

it's too late. I have 32GB now

That pretty much validates their motivation.

haha. sigh...