Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust: Not So Great For Codec Implementing

codecs.multimedia.cx

Post reply on HN
Print view View original

131–140 of 283 posts

Re: Rust: Not So Great For Codec Implementing

#131

Post by davemp »

legulere wrote: post #118
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…

Just a tiny nitpick: Only signed integer overflow is undefined, unsigned integer overflow follows modulo arithmetics. It's pretty much impossible to remember all those details.

Yup. You'd probably like the first footnote if you haven't already read it.

Re: Rust: Not So Great For Codec Implementing

#132

Post by pcwalton »

cwyers wrote: post #94
pcwalton wrote: post #60

Earlier quoted context omitted.

Well, like it or not, one of the primary audiences of Rust is C and C++ programmers. They're the people who write low-level code. There's not much we can do about that; we might as well serve our customers as well as we can.

> we might as well serve our customers as well as we can. Sure, but what part of serving them involves dragging them on Hacker News when they try and write C-like code in Rust?

I don't think we should be upset with people for their legitimate frustrations. But I do think we should be honest with the basic limitations of what we set out to do. A safe language that has dynamic allocation without GC simply has to have a borrow checker, and as far as we know that borrow checker has to have some limitations. Those limitations prevent some kind of code from being written in the same way it was written in C.

Re: Rust: Not So Great For Codec Implementing

#133

Post by jeffdavis »

eptcyka wrote: post #10

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…

How can they allow jumping around the call stack while also destructing/freeing objects?

Re: Rust: Not So Great For Codec Implementing

#134

Post by kbenson »

pcwalton wrote: post #130
kbenson wrote: post #106

Earlier quoted context omitted.

I think this is where reality meets theory. In reality, the developers are probably just taking the code as if they had written it, and the people that may know, such as immediate supervisors, don't care to point it out for the same reason the developers are stealing it, it's much easier than the alternative. The code vetting team is just left in the dark. Employees take shortcuts around bureaucracy all the time. Som…

I'm not going to endorse copying over package managers on the grounds that copying makes it easy to get away with violating big companies' legal procedures on the use of third-party code.

I wasn't endorsing, just providing an explanation of why while in theory copying and package inclusion are the same from a license standpoint, they likely often aren't in reality. That doesn't mean it's a good thing.

Your argument is the correct moral and legal one. Unfortunately that doesn't always matter. For another example, see the cognitive dissonance many express regarding ad blocking (not to come down entirely on one side of that issue, it's complicated).

Re: Rust: Not So Great For Codec Implementing

#135

Post by killercup »

greenhouse_gas wrote: post #125
Manishearth wrote: post #55

Earlier quoted context omitted.

> is it kind of similar to Go where any file can simply import You declare your crate dependencies in a Cargo.toml file. Rust does proper versioning of dependencies so having a separate manifest is desirable. Within your code you declare the existence of a crate via `extern crate` and then you can use it wherever. > the compiler force you to remove the imports too it warns.

Do you know if there are plans for rustfmt to auto-import like gofmt does? In the sense that if a crate is available (in the .toml file) and you reference it, rustfmt will automatically insert the required "import" and "use".

If the compiler gives you an error with a suggestion "You probably need to add `extern crate foo;`" (and it already does in some cases), RLS (i.e., your editor plugin) will be able to automatically add it for you (soon™).

Re: Rust: Not So Great For Codec Implementing

#136

Post by dbaupp »

kbenson wrote: post #123
dbaupp wrote: post #117

Earlier quoted context omitted.

That's true: it probably does make some (probably common) things easier because you get to disjoint slices with simpler indexing conditions, but the problems are equally hard in the general case: the type checker/borrow checker has to understand arithmetic rules like `a != a+1`, and be flow sensitive for things like `if a != b { ... }` and other ways to imply the inequality. (And, it's only a subset of the cases when…

> the type checker/borrow checker has to understand arithmetic rules like `a != a+1` I was actually thinking of this when I wrote, but the opposite case. A lot of compilers already know about that, and exploit it to their benefit (and sometimes the programmers dismay[1]). Overflow semantics matter here. That said, it's looks like an interesting area for Rust. I'm sure it's already been discussed to death somewhere in…

Optimisers reason about this, yes, but they don't define the user-facing language model. They take valid code and transform it in to (hopefully) faster valid code[1] and don't generally emit diagnostics or fail compilation, this means that they can do much more guess work and heuristics rather than having to have predictable, reliable or definable behaviour, all of which are useful for humans writing code (having a predictable optimiser is useful too, but difficulty writing any code at all is worse than difficulty optimising the spots where the optimiser isn't hitting performance targets).

Integrating this sort of thing into the type system "properly" (as in, actually part of the language and doing all of what I think Animats wants) basically means going a long way towards full dependent typing.

[1]: behaviour on invalid code, such as C relying on signed integer overflow, is unspecified/undefined. Languages like, say, Rust and Haskell generally try to guarantee the optimiser never gets invalid code by flagging such instances at compile time, unlike most/all C and C++ compilers.

Re: Rust: Not So Great For Codec Implementing

#137

Post by tatterdemalion »

valarauca1 wrote: post #92
tatterdemalion wrote: post #53

Earlier quoted context omitted.

Bytes is intended for use with the tokio ecoystem where you cna't use references often because borrowing across a yield point in a future would be a lifetime error.

Can't `Vec ` serve the same purpose?

Then you have to do a deep clone every time. Arc> is also not sufficient, because Bytes lets you share a reference count among slices to different offset into the buffer.

Re: Rust: Not So Great For Codec Implementing

#138

Post by wott »

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…

> C doesn't "let you do what you mean", it has no knowledge of special registers, interrupts, timers, DMA, etc.

Special registers are just slots at specific memory addresses.

As far as the rest is concerned, not a single language in the world will provide you with primitives for that and make them portable across a thousand architectures with a million different peripherals. That's the role of libraries and OSes with their drivers.

Re: Rust: Not So Great For Codec Implementing

#139

Post by mook »

steveklabnik wrote: post #2

A lot of good comments on Reddit, with answers/solutions/discussion of the points brought up here: https://www.reddit.com/r/rust/comments/6qv2s5/rust_not_so_gr... These kinds of experience reports are so valuable. (I've been following the whole series and they're very interesting.) Even if solutions to these issues do exist, if people can't find them, well that's a problem too.

Seems like (from that Reddit thread) a lot of the things are in progress in the nightlies. I wonder if that means the nightlies are holding Rust back (because it relieves the pressure to actually ship features for use by normal developers).
Post reply on HN