11–20 of 283 posts
I'd be interested to hear the author's reasoning behind this, if it does what they want then why not use it? It's small and well written, so I don't think vetting it should be a problem.
The rest of the article seems quite sensible, that comment just strikes me as a little odd.
Whilst unrelated to the article, my complaint about codecs in Rust is that they seem to be slow. Whilst the reason for this might be the immaturity of the libraries that I've used, but they've always been slower than their C counter-parts. The native JPEG decoder spins up 4 threads to decode the same amount of frames at 3x the time as the libjpeg-turbo does. There's a similar story for the FLAC decoder. I don't think…
Some of the complaints are perfectly fair (compile time, powerful but unwieldy macros). Other complaints seem a bit odder to me: > While overall built-in testing capabilities in Rust are good (file it under good things too), the fact that benchmarking is available only for limbo nightly Rust is annoying; Okay, but what are you comparing it against? Neither C or C++ have builtin benchmarking or even tests. > If you ca…
> I don't understand this one at all. What's wrong with "as"? That it silently overflows. > And if you need a checked conversion just write a small wrapper function? A better suggestion would be to wait for TryFrom/TryInto which IIRC should be stabilised soon-ish. > So unless I'm missing something something like: Assignment ( https://doc.rust-lang.org/reference/expressions.html#assignm... ) not declaration ( https://…
Ditto with the tuple thing, C doesn't have tuples and won't let you destructure anything.
I guess my overall point is that these complaints seems to pit Rust against some other high level languages like Common Lisp or Haskell but his conclusion is basically "C rulez, Rust droolz".
Some of the complaints are perfectly fair (compile time, powerful but unwieldy macros). Other complaints seem a bit odder to me: > While overall built-in testing capabilities in Rust are good (file it under good things too), the fact that benchmarking is available only for limbo nightly Rust is annoying; Okay, but what are you comparing it against? Neither C or C++ have builtin benchmarking or even tests. > If you ca…
A media codec is a very well understood, highly optimized thing with established idioms that are already well-matched to the capabilities of the hardware (and in many cases are taking advantage of hardware features explicitly designed for the codec being implemented!). Demanding that we start writing codecs differently isn't the same thing as telling a app UI developer they need to get used to traits instead of inheritance.
If rust can't handle the existing idioms for this problem area, that may need to be seen as a problem with rust, not the programmer.
Not a Rust expert, but some thoughts on the negatives. > Compilation time is too large Can you try compiling incrementally? https://blog.rust-lang.org/2016/09/08/incremental.html . Might still only be on nightly. > And, on the similar note, benchmarks. I agree, profiling as well isn't as full featured as in more mature languages. Clojure, incidentally has great benchmarking due to being on the JVM. > Also the tuple a…
Not that this isn't super valuable feedback, but the title is misleading.
Some of the complaints are perfectly fair (compile time, powerful but unwieldy macros). Other complaints seem a bit odder to me: > While overall built-in testing capabilities in Rust are good (file it under good things too), the fact that benchmarking is available only for limbo nightly Rust is annoying; Okay, but what are you comparing it against? Neither C or C++ have builtin benchmarking or even tests. > If you ca…
If you use CMake, you do get tests for free at least.
> Maybe it's worth the hassle of making array manipulation slightly less convenient for the sake of security?
On my computer I will always choose speed over security... especially for video processing & stuff like this. Wasting CPU cycles has a direct effect on my energy bill. Other people may do other tradeoffs.
Earlier quoted context omitted.
> I don't understand this one at all. What's wrong with "as"? That it silently overflows. > And if you need a checked conversion just write a small wrapper function? A better suggestion would be to wait for TryFrom/TryInto which IIRC should be stabilised soon-ish. > So unless I'm missing something something like: Assignment ( https://doc.rust-lang.org/reference/expressions.html#assignm... ) not declaration ( https://…
It's true that a "checked_as" would come handy from time to time and seems to be in line with the "Rust spirit". But again, since the author seems to be arguing in favor of C it seems like an odd complaint. C even makes it tricky to check for integer overflow while Rust has the checked_ family of functions. In C if you get it wrong it's undefined behavior territory baby. Ditto with the tuple thing, C doesn't have tup…
Whilst unrelated to the article, my complaint about codecs in Rust is that they seem to be slow. Whilst the reason for this might be the immaturity of the libraries that I've used, but they've always been slower than their C counter-parts. The native JPEG decoder spins up 4 threads to decode the same amount of frames at 3x the time as the libjpeg-turbo does. There's a similar story for the FLAC decoder. I don't think…
Some of the complaints are perfectly fair (compile time, powerful but unwieldy macros). Other complaints seem a bit odder to me: > While overall built-in testing capabilities in Rust are good (file it under good things too), the fact that benchmarking is available only for limbo nightly Rust is annoying; Okay, but what are you comparing it against? Neither C or C++ have builtin benchmarking or even tests. > If you ca…
> Now this whole section feels a lot like "I'm trying to code in Rust like in C and it doesn't work and it frustrates me". A media codec is a very well understood, highly optimized thing with established idioms that are already well-matched to the capabilities of the hardware (and in many cases are taking advantage of hardware features explicitly designed for the codec being implemented!). Demanding that we start wri…
I'm sure whatever the original code is doing could be copied directly, including calling raw assembly code (which optimized codecs often end up doing to micro-optimize as much as possible). You'll just need copious amounts of unsafe code.
But then what's the point? You might as well keep your existing code. I guess it would make sense if you wanted to standardize your cobebase and move everything to Rust, but I doubt that's much of a use case nowadays.
Now if you write a brand new codec it might be interesting to start in safe Rust and once you're ready incrementally add unsafe code where it matters to improve performance while limiting the unsafe code as much as possible. Rust gives you the choice, C is just unsafe by default.
Coders have to write things differently if they want a different result, as should be expected. If the only metric is performance at all costs then assembly beats everything else.