Rust: Not So Great For Codec Implementing • Hacker News Board

Re: Rust: Not So Great For Codec Implementing

#61

Post by pcwalton » Tue, Aug 01, 2017, 5:36 PM UTC

ajross wrote: post #14

simias wrote: post #5

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…

> 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!).

Hold on. We aren't talking about modifying the codec itself, or how it's implemented at the machine level. If it weren't straightforward to generate machine code that matches how the codec is designed to be implemented, that would be an issue with Rust—but that isn't what this thread is about. We're only talking about the particular language idioms used to create that implementation.

Re: Rust: Not So Great For Codec Implementing

#62

Post by nwmcsween » Tue, Aug 01, 2017, 5:37 PM UTC

phkahler wrote: post #39

mrec wrote: post #22

Earlier quoted context omitted.

If anyone's interested, this is the (epic!) discussion thread for "Getting explicit SIMD on stable Rust": https://internals.rust-lang.org/t/getting-explicit-simd-on-s... It still wouldn't compete with really good hand-tuned asm, but it might help reduce the perf/usability tradeoff a bit.

I'd just like to see 2,3, and 4 element vectors as a first class citizen in C, C++, or Rust. These are incredibly common for so many things it's hard for me to understand this omission. I want to be able to pass them by value and as return values from function. I want to do operations like a=b+c with vectors without creating classes or overloading operators. For a lot of people the SIMD instructions are about paralle…

It doesn't really make sense in C as any modern optimizing compiler will turn it into SIMD. IIRC rust needs explicit SIMD due to bounds checking.

Re: Rust: Not So Great For Codec Implementing

#63

Post by zanny » Tue, Aug 01, 2017, 5:41 PM UTC

ditonal wrote: post #43

zanny wrote: post #27

Earlier quoted context omitted.

There is a real change in mentality you have to go through if you transition from a fairly strict C/C++/ even Java background to trying out Rust. In the former languages, adding dependencies rapidly becomes a painful experience, whereas Rust does much better dependency management and automatic building than even Python (where you need a requirements file or something similar to go pull down all the deps). With Rust,…

> even Python Off topic, but it shouldn't be better than "even Python", because Python has a really, really broken dependency system. Far more so than Java, which has Maven/Gradle which are both infinitely better than the pip/virtualenv disaster. People complain about things like shading in Maven being complicated. What they might not realize is that pip doesn't even try to address conflicting dependencies, it will j…

My language development went from C -> C++ -> Java -> Python. So when I got there and figured out pip was a thing (or easy_install back in the day) it was a major innovation at the time.

Additionally, for anyone coming from almost all compiled native languages, a native environment like Rust with better dependency management than Python (which, as you say, and in retrospect, is pretty broken) is a bit of a mind screw.

Re: Rust: Not So Great For Codec Implementing

#64

Post by pcwalton » Tue, Aug 01, 2017, 5:42 PM UTC

binarycrusader wrote: post #44

Sean1708 wrote: post #11

> And don’t tell me about Bytes crate—it should not be a separate crate 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.

A little copying is better than a little dependency. https://go-proverbs.github.io/ As a developer at a large software company, every dependency that is not part of the language runtime itself is a pain because legal paperwork and evaluation has to be done for each individual component before I can use it / ship it. NOTE: I am not referring to copying I would be doing, but to the crates thats have little dependencies…

> A little copying is better than a little dependency. https://go-proverbs.github.io/

I really disagree with that quote. Copying is how you get bugs sticking around in software for all time (for example, doing binary searches in a way that avoids overflow is surprisingly tricky, and the endless copying of naive binary search code is why this bug is so difficult to eradicate). Honestly, that quote is just an excuse to avoid the hard work of making the language ecosystem handle dependencies properly.

> As a developer at a large software company, every dependency that is not part of the language runtime itself is a pain because legal paperwork and evaluation has to be done for each individual component before I can use it / ship it.

How is copying better than dependencies in this regard? You presumably need legal signoff either way.

> Additionally, I personally despise have many, small dependencies because it means I have more to think about and manage. Instead of just being able to think about the version of the compiler/standard library I'm using, I have to consider every individual crate.

This is what the "Rust platform" is designed to address. It is nice to be able to refer to a specific version of the Rust platform, but that doesn't mean you have to give up on the massive ergonomic benefit of the Cargo ecosystem relative to copying and pasting code.

Re: Rust: Not So Great For Codec Implementing

#65

Post by zanny » Tue, Aug 01, 2017, 5:44 PM UTC

nolok wrote: post #45

zanny wrote: post #27

Earlier quoted context omitted.

There is a real change in mentality you have to go through if you transition from a fairly strict C/C++/ even Java background to trying out Rust. In the former languages, adding dependencies rapidly becomes a painful experience, whereas Rust does much better dependency management and automatic building than even Python (where you need a requirements file or something similar to go pull down all the deps). With Rust,…

Haven't used Rust yet, is it kind of similar to Go where any file can simply import and then Go knows how to fetch and build when needed ? And then when you remove the calls (eg during a refactor) the compiler force you to remove the imports too, stopping the infinite bloat caused by "no one really knows if we still need this" that can be common in other language. I really liked that "dependancy as part of the langua…

Its kind of the reverse. You declare versioned dependencies in the toml file, and (soon) Cargo will add them to rustc so they just show up for your source files. Right now you declare them twice, once in the toml and once in the crate root - ie, you add url = 1.5 in toml, and extern crate url in src/main.rs. There is an RFC coming that will make the extern crate part optional.

Re: Rust: Not So Great For Codec Implementing

#66

Post by kbenson » Tue, Aug 01, 2017, 5:44 PM UTC

jcelerier wrote: post #17

simias wrote: post #5

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…

> Okay, but what are you comparing it against? Neither C or C++ have builtin benchmarking or even tests. 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…

> On my computer I will always choose speed over security... especially for video processing & stuff like this.

What's the worst that could happen? It's not like video, image and audio codec implementations get exploited much, right?

In case that sarcasm was too subtle, I think you would be hard pressed to find a popular implementation of common media format (h.264, mp3, JPEG, GIF, etc) that hasn't had an exploit at some time.

It's your choice what to run, but I can't help but be somewhat annoyed at the professed position because it doesn't just affect you when it goes wrong.

Re: Rust: Not So Great For Codec Implementing

#67

Post by steveklabnik » Tue, Aug 01, 2017, 5:44 PM UTC

nwmcsween wrote: post #62

phkahler wrote: post #39

Earlier quoted context omitted.

I'd just like to see 2,3, and 4 element vectors as a first class citizen in C, C++, or Rust. These are incredibly common for so many things it's hard for me to understand this omission. I want to be able to pass them by value and as return values from function. I want to do operations like a=b+c with vectors without creating classes or overloading operators. For a lot of people the SIMD instructions are about paralle…

It doesn't really make sense in C as any modern optimizing compiler will turn it into SIMD. IIRC rust needs explicit SIMD due to bounds checking.

> IIRC rust needs explicit SIMD due to bounds checking.

Bounds checks can be eliminated and code can be vectorized if the optimizer can prove it; explicit SIMD is useful for the cases where it can't.

Re: Rust: Not So Great For Codec Implementing

#68

Post by [deleted] » Tue, Aug 01, 2017, 5:45 PM UTC

phkahler wrote: post #39

mrec wrote: post #22

Earlier quoted context omitted.

If anyone's interested, this is the (epic!) discussion thread for "Getting explicit SIMD on stable Rust": https://internals.rust-lang.org/t/getting-explicit-simd-on-s... It still wouldn't compete with really good hand-tuned asm, but it might help reduce the perf/usability tradeoff a bit.

I'd just like to see 2,3, and 4 element vectors as a first class citizen in C, C++, or Rust. These are incredibly common for so many things it's hard for me to understand this omission. I want to be able to pass them by value and as return values from function. I want to do operations like a=b+c with vectors without creating classes or overloading operators. For a lot of people the SIMD instructions are about paralle…

[deleted]

Re: Rust: Not So Great For Codec Implementing

#69

Post by jstewartmobile » Tue, Aug 01, 2017, 5:45 PM UTC

davemp wrote: post #58

> And that’s why C is still the best language for systems programming—it still lets you to do what you mean (the problem is that most programmers don’t really know what they mean) Honestly after a ~1yr of embedded C co-op/intership experience, I'm familiar enough but not too entrenched to say that C is not that great for embedded/systems. When you're dealing at the hardware architecture level you need more detail tha…

It sounds like you're looking for Forth. It doesn't have everything on your wish list, but it's a good bit more predictable when you have to get down into the weeds.

Re: Rust: Not So Great For Codec Implementing

#70

Post by blt » Tue, Aug 01, 2017, 5:45 PM UTC

nwmcsween wrote: post #62

phkahler wrote: post #39

Earlier quoted context omitted.

I'd just like to see 2,3, and 4 element vectors as a first class citizen in C, C++, or Rust. These are incredibly common for so many things it's hard for me to understand this omission. I want to be able to pass them by value and as return values from function. I want to do operations like a=b+c with vectors without creating classes or overloading operators. For a lot of people the SIMD instructions are about paralle…

It doesn't really make sense in C as any modern optimizing compiler will turn it into SIMD. IIRC rust needs explicit SIMD due to bounds checking.

Optimizing compilers are rarely successful at turning non trivial code into simd.