I think that's true, but it's also sad. I've looked at D and it's criticism seems reasonable to me: it actually seems to have more features than C++.
I really hope Go catches on more and fixes some of the (imho) bad things about it (like lack of generic programming). And then C++ won't be the only option anymore.
Go is nice but it's a replacement for Java or Python not for C++. I'm working on an in-memory analytics engine, something that has only become affordable in recent years because memory prices have fallen so much.
In-memory computing is a very important trend and garbage collected languages just don't work. You can't have the system stall for seconds or even tens of seconds unless it's purely a batch workload.
I have to admit that I haven't really researched what can be done in Go to keep in-memory data off-heap so the garbage collector doesn't see it. I have done that research for Java and it's unworkable. It's either slow or extremely unproductive to work with or both.
Garbage collection pauses are a huge concern with larger heap sizes. Depending on the application it may be OK to make a user wait for a second or two, but not for 30 seconds. Multitasking doesn't cause that kind of lag usually.
It's even more problematic for some types of trading systems or stream processing of sensor data, etc.
All the trends are working against garbage collection right now. Memory sizes are growing and we're moving away from batch processing for many workloads.
Most definitely - on a modern multitasking operating system your "all types of pauses" is generally only synchronous IO issues to disk or network - as long as you've got spare CPU available to your process/threads and you're sensible with your memory allocation.
> garbage collected languages just don't work. You can't have the system stall for seconds or even tens of seconds unless it's purely a batch workload.
What about languages like Erlang and Rust where each actor/object/process has its own heap, GCed individually?
> In-memory computing is a very important trend and garbage collected languages just don't work. You can't have the system stall for seconds or even tens of seconds unless it's purely a batch workload.
As someone who had tried to work with available GCs in Java, GP is spot on; it doesn't matter that algorithms exist - production JVMs still pause (or at least did 2 years ago when I looked into it)
Can you point me to a reasonably mature and efficient implementation of such an algorithm for Go or Java? I only know the Azul one which costs thousands of dollars per server per year.
Irrelevant for what? This was a debate about whether or not Go can replace C++, remember? So the fact that there is no such implementation for Go has to be relevant.
It is also very relevant for me that there is no Java implementation of a pauseless garbage collector that is even remotely viable for my business model or the business model of 99% of all startups out there.
If all you want to say is that it is possible to solve this problem for garbage collected languages, then we can agree. Unfortunately there is no viable solution available right now.
> Irrelevant for what? This was a debate about whether or not Go can replace C++, remember? So the fact that there is no such implementation for Go has to be relevant.
Well, surely with so many top notch brains Google can come up with a way to improve Go's runtime if they care about the issue.
> It is also very relevant for me that there is no Java implementation of a pauseless garbage collector that is even remotely viable for my business model or the business model of 99% of all startups out there.
Do you mean viable, as free of charge?
> If all you want to say is that it is possible to solve this problem for garbage collected languages, then we can agree. Unfortunately there is no viable solution available right now.
No, but it would have to be a fraction not a multiple of my per server profit margin. Azul's target market is clearly hedge funds and the like. They don't even quote a price on their website.
To be not only viable but also beneficial, the Azul license plus the additional DRAM cost of Java itself would have to be less than it costs me to use C++ instead of Java.
That's exactly how I feel, I guess. D seems to have a lot more features (import, public import, and static import?) and I'm no expert but I feel some aren't all that necessary/add enough value. Go has fewer than C++, which I think is really good, except for some few ones that I wish were there. Only generic programming/templates off the top of my head actually.
See I don't know about that. Maybe exceptions was one of the features that was good to be left out. I think maybe the comma ok idiom forces the programmer to more actively check for errors and recover from them, and there is no need to do things like RIIA. Maybe also the code is clearer to read, because you can see "if not ok then do_this()" and know that this is error checking/recovery code, instead of looking up the call stack to see where the exception that was thrown in one place is being handled.
I haven't looked at D in a while, but I recall it having two competing standard libraries.
I'm pinning all my hopes and dreams on Rust, but as a frequent (ab)user of Boost.Coroutine and gevent I certainly wouldn't mind if Go gained a bit more traction.
There isn't anything nondeterministic about garbage collection systems; it is just that it is hard to predict how much time they will take for a call.
However, the same can be said about classical C style memory management. An alloc can be almost immediate or take lots of time because it has to request a fresh memory block from the OS. Similarly, a free can or cannot take time to coalesce blocks.
Yes, the differences are much smaller there, certainly historically, but garbage collectors have improved, and I am not sure that C-style allocators can stay predictable in long-running programs. Let's say you have a terabyte of RAM, and want to run a multi-threaded server in it 'forever'. Chances are that your garbage-collected system will be more stable and use less memory because it can compact memory. A C style allocator would need quite a few heuristics (or maybe, even contain some machine learning code that builds a model of memory allocation patterns) to prevent memory fragmentation. Such features would make their timing less predictable.
Because of that, I think we may at some time see an OS with built-in garbage-collection become mainstream.
If it interrupts your running code, it only can happen at moments when you allocate memory, just like with malloc. You cannot predict when malloc calls brk(), either.
Also, most OS-es are non-deterministic, anyways. You cannot predict whether your code lives in cache/main memory, or on disk. In some systems, your data even might have to be brought in by a tape robot without your code being aware of it. As soon as a garbage collector manages to get its interruptions to be about equal to delays caused by caching and virtual memory, I doubt many people will care.
With Gargage collection, there are ni deallocations.
Also, garbage collection does not "harvest for memory locations that need to be freed and frees them.". Garbage collection does not collect garbage, it collects used space.
Just followed that thread again, and I think we're on the same side :)
I mean, when I say that I prefer deterministic memory management, that includes an automatic reference counting - smart pointers - which are now part of C++11.
On that thread, under my "deterministic", you assumed only "manual" as it seems.
I really hope Go catches on more and fixes some of the (imho) bad things about it (like lack of generic programming). And then C++ won't be the only option anymore.