3 ms·

Rust and Go are often thought of as C++ replacements, which dcauses them to be compared, however the reality is more subtle. C++ is quite flexible, and so it fi

Rust and Go are often thought of as C++ replacements, which dcauses them to be compared, however the reality is more subtle. C++ is quite flexible, and so it finds itself in many niches where there were no languages to fit. Rust and Go are targeting two of these niches, and have the ability to compete with C++ in them. Go is designed to take advantage of large amounts of concurrency, while still providing good performance (think cloud). Rust allows low-level control while giving the OOP structure required for large programs, like web browsers, or even game engines. Go was also (mistakenly) referred to a systems language at one point, which didn't help the issue.

bad_user 12y ago
> Go is designed to take advantage of large amounts of concurrency, while still providing good performance (think cloud). Java/JVM and C#/.NET fall in that space as well and are doing a very good job, while at the same time exposing a managed runtime that can be used as a target for other languages, thus lowering the friction for bootstrapping such new languages. Because of this, in a sense, Java/.NET are better replacements for C, which has also been used for building portable libraries freely usable across multiple languages. I'm still getting thrills when using well tested, mature Java libraries from Scala, Clojure or JRuby. Where Java/.NET really suck is for building real-time or soft real-time systems, because they are managed and thus heap allocation must be managed by a garbage collector. Go has precisely the same limitation by design, with the difference that because it's younger, it doesn't have pauseless garbage collectors available for it - like say, the one from Azul Systems. Go GC is even less good than the garbage collectors available in the reference Java/.NET implementation - the one in version 1.0 at least wasn't even precise, let alone concurrent. And this is not about performance per se, btw. This is about dealing with real-time constraints. In certain contexts speaking of the "cloud", it's not enough if your server is able to respond to tens of thousands of requests per second in under 100ms per request, if you can't guarantee that kind of delivery for more than 99.99% of requests. For video decompression, another industry dominated by C/C++, the average throughput doesn't matter if you can't guarantee a consistent frame rate per second - how annoying would it be if when watching a video, the playback would suffer short freezes every couple of seconds? To make matters worse, if the GC stops the world, it can act like a global lock (GIL) and then you become aquatinted with Amdahl's law, as it severely limits vertical scaling, even if your logic is embarrassingly parallelizable. Go was referred to as a systems language, but I don't think that was a mistake on their part. If Go wouldn't have been referred as a systems language, then that would've meant admission that the real competition for Go is actually the JVM with all its languages running on top of it.

bad_user 12y ago

> Go is designed to take advantage of large amounts of concurrency, while still providing good performance (think cloud). Java/JVM and C#/.NET fall in that space as well and are doing a very good job, while at the same time exposing a managed runtime that can be used as a target for other languages, thus lowering the friction for bootstrapping such new languages. Because of this, in a sense, Java/.NET are better replacements for C, which has also been used for building portable libraries freely usable across multiple languages. I'm still getting thrills when using well tested, mature Java libraries from Scala, Clojure or JRuby. Where Java/.NET really suck is for building real-time or soft real-time systems, because they are managed and thus heap allocation must be managed by a garbage collector. Go has precisely the same limitation by design, with the difference that because it's younger, it doesn't have pauseless garbage collectors available for it - like say, the one from Azul Systems. Go GC is even less good than the garbage collectors available in the reference Java/.NET implementation - the one in version 1.0 at least wasn't even precise, let alone concurrent. And this is not about performance per se, btw. This is about dealing with real-time constraints. In certain contexts speaking of the "cloud", it's not enough if your server is able to respond to tens of thousands of requests per second in under 100ms per request, if you can't guarantee that kind of delivery for more than 99.99% of requests. For video decompression, another industry dominated by C/C++, the average throughput doesn't matter if you can't guarantee a consistent frame rate per second - how annoying would it be if when watching a video, the playback would suffer short freezes every couple of seconds? To make matters worse, if the GC stops the world, it can act like a global lock (GIL) and then you become aquatinted with Amdahl's law, as it severely limits vertical scaling, even if your logic is embarrassingly parallelizable. Go was referred to as a systems language, but I don't think that was a mistake on their part. If Go wouldn't have been referred as a systems language, then that would've meant admission that the real competition for Go is actually the JVM with all its languages running on top of it.