I'd love to be able to write my DSP code in cleaner, simpler language but for now I'm happy that I have a tool that lets me build the software I care about.
I'd love to be able to write my DSP code in cleaner, simpler language but for now I'm happy that I have a tool that lets me build the software I care about.
Although, I will say that Vala plus GTK+ is amazing for desktop development on Linux, especially with elementary OS's Granite library. The thing is, it's really just a nice language on top of C plus GObject as a transpiler!
I do wish that some other languages were as nice to use as various scripting languages, but with the performance and pure utility of C/C++. Maybe one day.
Much more info about the compatibility and differences for anyone interested on wikipedia[1].
[1] http://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B
I just think that their names, common syntax and saying things like 'C++ is a [sort of] superset of C' make people unfamiliar with them think that they are more related than they are. That's why I brought up Python and Ruby - two languages that are different in syntax and many details but in the same conceptual space, whereas C and C++ look more similar, sound like almost the same thing but are, conceptually, on different planets.
Oracle's Project Graal plans to replace the C++ JIT by a Java one. This is based on the work of the Maxime VM.
The developers of MRI are focused on developing an interesting and useful language first and everything else second. The developers of JRuby are focused on replicating that language on the JVM. They benefit from a sophisticated JIT and GC and in later JVMs some direct help, none of which diminishes their own efforts to improve performance.
Sure you can write slow code in anything but I don't see how that's in any way related to 'your JRuby/CRuby' comparison.
By that logic, any mention of any difference between any language, runtime or its implementation can simply be dismissed by 'well, they ARE all Turing equivalent!'
I just wanted to point out on your previous comment - it is not surprise that only choosing some particular language doesn't mean a guaranteed performance.
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.
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.
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.
What about languages like Erlang and Rust where each actor/object/process has its own heap, GCed individually?
Rust should work. It's the right approach I think. I haven't used it yet, but I really hope it gains popularity and becomes a real alternative to C++.
Nice omission of pauseless GC algorithms there.
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.
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.
Yes, that is my main point.
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.
I think that would be much easy to add than C++esque `smart pointers as library`.
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.
Regarding Rust, Rust has lightweight green threads just like Go does. (Go's scheduler is currently more mature though.)
It seems like Rust never ceases to impress.
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.
The problem is not how much but when - you never know when GC fires and interrupts your running code. That is a nondeterminism.
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.
You never know when GC fires - starts harvesting for memory locations that need to be freed and frees them.
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.
Here are some more details if you're interested:
http://en.wikipedia.org/wiki/Garbage_collection_(computer_sc...
https://news.ycombinator.com/item?id=5503066
HN is small ;)
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.