>OK, but doesn't it imply that I do not need Rust at all because I could write 90% of my code in Go and the rest 10% in C? Only silver bullet seekers and airy-fairy (t)he(o)retics will use Rust just for the sake of feeling contented about having 100% of a program written in seemingly one language. Have you actually tried to do that or understand what Rust unsafe code means ? Interfacing between different run-times an…
There's a lot of the "write X% in slowlang and (100-X)% in fastlang" thrown around, but I have to say, I've not seen too many such projects around.
Right, which is why a subset of C or C++ (like MISRA) is used for critical applications.
My day job is currently writing embedded high availability code to a slightly modified version of the JSF coding standard (which is itself a modified version of MISRA for C++). There's a lot of safety that Rust would give us on top of C++ with the coding standard's rules, and we're waiting for Rust to simply mature a little.
To me, it seems like in the future Rust could occupy the same niche as Java + RTSJ does presently. I'm just not clear on how or why Rust would be sufficiently better to overcome the track record of Java + RTSJ.
I get that this is a translation but it's very poorly written even considering that. lots of repetitive conclusion jumping in what I can only assume is an attempt to baffle the reader into uncritically accepting what appears to be a largely unsupported opinion. the only evidence the post seems to offer is that rust is slow because it showed up 5th in a set of microbenchmarks. everything else is rhetorical garbage, fr…
Correction: a set of microbenchmarks whose own documentation emphatically states the difficulty of drawing any conclusions from those results.
Comparing different programming languages is notoriously difficult, particularly since the metric is underdefined. The best programmers might write faster code in language A compared to language B, but if average programmers write code that is no faster, does that mean language A is better than language B?
Regarding speed, I am not sure it really is the bee's knees. The existence of LLVM and the likes, the fact that Javascript got a HUGE speedup in the past 5 years seems to be an indication that it is by essence a factor that can be tuned eventually. I doubt a "slow" language will ever get to be C in that regard, but I also doubt C will ever provide the kind of ease of mind that a more inherently modern and secure lang…
It's a little silly to quibble about speed when the language is still being designed. There is plenty of time to optimize the language; there's not much technical barrier to matching the speed of c/c++, especially when allowing unsafe code. However, something I've noticed from the land of C++ is some peoples' issue with the idea that thread safety is difficult. In fact, they appear to downright bristle at the idea th…
This is an interesting question, but I'm not convinced it is the case. Many people have argued that Java, Ruby, (insert favorite language here) will one day match the speed of C, it just requires more advanced tooling, but that promise has never been fulfilled. Many abstractions come with a cost, just look at the jump between C and C++. Perhaps Rust will match the speed of C, but I don't think it is certain.
Note the translation is done by a company which makes C++ static analyzer for a living. This might be the case of conflict of interest and/or heavy bias.
It also means they know what they're talking about. Many of the points are valid, but it's important to remember Rust is not even released. Java 1, Ruby 1, Perl 1, Python 1 were all pretty terrible compared to their current manifestations.
They know only 1 part of the bridge, but without second part is not the bridge, but shameful biased grunt "oh oh, will we still make money on C++ or we need to learn something new to keep our income?". And question is answered before they company existed. They even dare enough to recommend others don't learn Rust in favor of C++ - so biased recommendation makes whole grunt even more pointless.
Don't get me wrong, I understand difference between constructive criticism and biased grunt of grumpy C++ programmer.
I've made an honest effort with C++ >= C++11. The language has improved -- lots -- but there's just no getting around the fact that: - Most of the improvements hellaciously leverage the hideous template system, and - Actually writing template-leveraging libraries is an exercise in pain, repetition, and insanely slow compile times. C++ won't be a "Rust-killer" (insert any other modern low-level type parameterized syst…
How does Rust's compile times compare with those of C++?
We don't have a whole lot of data, but generally faster. I can't seem to find the blog post now, but someone ported their raytracer from C++ to Rust, and the compile time was... half? I think?
My day job is currently writing embedded high availability code to a slightly modified version of the JSF coding standard (which is itself a modified version of MISRA for C++). There's a lot of safety that Rust would give us on top of C++ with the coding standard's rules, and we're waiting for Rust to simply mature a little.
To me, it seems like in the future Rust could occupy the same niche as Java + RTSJ does presently. I'm just not clear on how or why Rust would be sufficiently better to overcome the track record of Java + RTSJ.
JITs and interpreters suck for realtime, and there's only so many optimizations that an AOT compiler can do to a Java codebase (hence why JITs ar so prevalent for Java). Pushing all of these verifications into compile time significantly reduces the run time requirements.
Honestly I see Rust as (potentially, down the road) being a better, less verbose Ada than a better C++ or Java. You tend to write Rust code much like you would an Ada or VHDL program.
I get that this is a translation but it's very poorly written even considering that. lots of repetitive conclusion jumping in what I can only assume is an attempt to baffle the reader into uncritically accepting what appears to be a largely unsupported opinion. the only evidence the post seems to offer is that rust is slow because it showed up 5th in a set of microbenchmarks. everything else is rhetorical garbage, fr…
This article is difficult to read in original (for native speaker) too. Just raw flow of minds, without any shape.
>OK, but doesn't it imply that I do not need Rust at all because I could write 90% of my code in Go and the rest 10% in C? Only silver bullet seekers and airy-fairy (t)he(o)retics will use Rust just for the sake of feeling contented about having 100% of a program written in seemingly one language. Have you actually tried to do that or understand what Rust unsafe code means ? Interfacing between different run-times an…
There's a lot of the "write X% in slowlang and (100-X)% in fastlang" thrown around, but I have to say, I've not seen too many such projects around.
Skylight.io is one of the first production applications using Rust, and is exactly this.
It's a little silly to quibble about speed when the language is still being designed. There is plenty of time to optimize the language; there's not much technical barrier to matching the speed of c/c++, especially when allowing unsafe code. However, something I've noticed from the land of C++ is some peoples' issue with the idea that thread safety is difficult. In fact, they appear to downright bristle at the idea th…
This is an interesting question, but I'm not convinced it is the case. Many people have argued that Java, Ruby, (insert favorite language here) will one day match the speed of C, it just requires more advanced tooling, but that promise has never been fulfilled. Many abstractions come with a cost, just look at the jump between C and C++. Perhaps Rust will match the speed of C, but I don't think it is certain.
We're already faster than C in some benchmarks, (and slower in others, of course) and since we use LLVM on the backend, we can take advantage of all of the performance work that's put into Clang and friends as well.