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

51–60 of 283 posts

Re: Rust: Not So Great For Codec Implementing

#51

Post by vvanders »

jeeyoungk wrote: post #46
myusernameisok wrote: post #36

Earlier quoted context omitted.

> The only legitimate complaint there is that it's tough in Rust to get two arbitrary mutable slices into the same array. Rust wants to be sure they're disjoint, to prevent aliasing. For some matrix manipulation, this is inconvenient. I've only looked into Rust briefly, but I thought this was the point of unsafe blocks? You can roll your own multi-dimensional array data structure using unsafe blocks if you're certain…

Unsafe allows you to dereference raw pointers and foreign-function calls, but you cannot go around the borrow checker, which is what's causing annoyance. That said, you can create raw and dereference raw pointers, which lets you to do the above.

If you take a ref into a pointer that lets you work around the borrow checker(and I've bitten myself just about every time I've done it now that I'm used to the borrow checker).

Re: Rust: Not So Great For Codec Implementing

#52

Post by dbaupp »

myusernameisok wrote: post #36
Animats wrote: post #32

The only legitimate complaint there is that it's tough in Rust to get two arbitrary mutable slices into the same array. Rust wants to be sure they're disjoint, to prevent aliasing. For some matrix manipulation, this is inconvenient. It would be easier if Rust had real multidimensional arrays. If the compiler knows about multidimensional arrays, some additional optimizations are possible. For example, if you want to b…

> The only legitimate complaint there is that it's tough in Rust to get two arbitrary mutable slices into the same array. Rust wants to be sure they're disjoint, to prevent aliasing. For some matrix manipulation, this is inconvenient. I've only looked into Rust briefly, but I thought this was the point of unsafe blocks? You can roll your own multi-dimensional array data structure using unsafe blocks if you're certain…

Yes, unsafe blocks one way in which the Rust doesn't privilege built-ins and the standard library (much) over external code: people can write high performance a abstractions without them needing to be baked into the language. This is exactly what has occurred with multidimensional arrays with external libraries like ndarray.

Re: Rust: Not So Great For Codec Implementing

#53

Post by tatterdemalion »

valarauca1 wrote: post #38
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.

I agree with the author. Bytes is basically just C++'s `std::string` (kind of don't bite my head off people who've memorized the C++17 standard). Its an ARC backed array [1]. This suggests it should be a fairly fundamental abstraction. Edit: ^^^My C++ is wrong sorry :( Really I disagree with its purpose. In its immutable, non-threaded safe form you can create the same structure by just borrowing a value. This ofc req…

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.

Re: Rust: Not So Great For Codec Implementing

#54

Post by kllrnohj »

mcguire wrote: post #23
kllrnohj wrote: post #9

Earlier quoted context omitted.

> Clojure, incidentally has great benchmarking due to being on the JVM. Eh? Benchmarking on the JVM is notoriously difficult bordering on impossible. There's things like Google Caliper but test runs take forever due to attempting to force JIT warmup and doing GCs after every run. And the project's own wiki tells you the results are basically meaningless for a variety of reasons. Benchmarking things like C++ or Rust a…

Benchmarking is pretty meaningfree in the best cases. The JVM isn't any worse in this regard. The JVM is slow in many regimes due to things like JIT warmup. Rather than accepting that many JVM people are hypersensitive: thou must only benchmark in the JVM's best case scenario.

> Benchmarking is pretty meaningfree in the best cases.

That's completely false. Benchmarking is a core staple of building & evaluating performance-sensitive libraries or other routines. It doesn't work (well) in non-deterministic languages which reduces its usefulness scope, but in things like C++ it's highly useful and reliable for evaluation of libraries and monitoring for regressions.

> The JVM is slow in many regimes due to things like JIT warmup. Rather than accepting that many JVM people are hypersensitive: thou must only benchmark in the JVM's best case scenario.

Well it's not just the JIT that's a problem. It's also things like GC passes. Does that get included in the results or not? Do you force GC passes between runs? How about finalizers? The answers to those questions depends on the state of the rest of the system and the expected workload, it's not something you can just trivially answer or even accommodate in a framework since most of the behavior is up to the particular implementation, which can then further vary based off of command line flags.

Re: Rust: Not So Great For Codec Implementing

#55

Post by Manishearth »

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…

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

Re: Rust: Not So Great For Codec Implementing

#56

Post by mrec »

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…

What would baking them into the language add that a library solution couldn't? I'm not keeping track of Rust very closely these days, but it supports arithmetic operator overloading and the Copy trait. What's missing?

I agree that this needs to be standardized for vector-ey crates to be able to talk to each other seamlessly. Otherwise we'll end up with a rerun of the C++ strings fiasco, with char* and wchar_t* and std::string and std::wstring and BSTR and _bstr_t and CString and CComBSTR and QString and GString and...

Re: Rust: Not So Great For Codec Implementing

#57

Post by kbenson »

icebraining wrote: post #41
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…

Good comment; shame about that gibe in the middle, it'd be better without making it personal.

Normally I would agree, but I think it makes an important point. The author is not at the same level in both languages. The author is actually new enough to Rust that they've missed the existence a common feature and used it's absence as evidence. This may or may not color how you assess the rest of the points being made by the author.

Re: Rust: Not So Great For Codec Implementing

#58

Post by davemp »

> 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 than C (or any PL) can reasonably provide.

C doesn't "let you do what you mean", it has no knowledge of special registers, interrupts, timers, DMA, etc. Companies have coped with a slew of macros that are just ugly to write with and make testing much more difficult than need be. If the language had actual support for embedded you'd see support for architecture strictly as libraries (which may be possible in C but certainly not ergonomic or supported by the culture around the language). Library architectures would make writing simulators and embedded unit tests __MUCH__ simpler.

Not to mention the minefield that is the undefined sections of the C spec. A lot of people "mean" for an integer to rollover, but that's undefined and the C spec doesn't care about what you "mean". [1]

Just today I meant for a constant lookup table not to be overwritten by the stack (I had plenty of unused RAM), but unfortunately C doesn't care what I meant. I had to dig around and find an odd macro to jam that data into program space--effectively hiring some muscle (gcc) to break the spec so it behaved the way I wanted. [2] I run into this sort of thing all the time. I know the C spec. I know my hardware. C doesn't care and needs to be beaten up. The only real benefit of C in these situations is that it's a huge sissy and people are really good at beating the piss out of it now.

I'm not very familiar with rust, but if it makes an honest effort to be ergonomic for embedded (might need to be forked). It will eventually crush C.

[1]: https://blog.regehr.org/archives/213 [2]: https://gcc.gnu.org/onlinedocs/gcc-4.8.5/gcc/Named-Address-S...

Re: Rust: Not So Great For Codec Implementing

#59

Post by ekidd »

Personally, I've been happy with Rust for writing an MPEG-2 subtitle decoder. I posted about this earlier here: https://news.ycombinator.com/item?id=14753201

For me, the biggest advantages over C/C++ were:

1. Rust's compile-time checks, run-time checks and fuzzing tools make it much easier to write secure code. Since decoders are a notorious source of bad security bugs, this is a big plus in my book.

2. Rust's dependency management makes it rather pleasant to rely on 3rd-party libraries. The combination of an immutable package repository and semver makes it easy to trust that things won't break. And in my experience, the number of 3rd-party libraries is relatively small compared to more popular languages, but the quality tends to be fairly high (especially relative to npm).

3. The tooling is surprisingly nice for a young language. cargo has solid defaults, Visual Studio Code provides auto-completion and tool tips, and there are good libraries for basic logging, argument parsing, etc.

4. Rust makes it relatively easy to write fast code, as long as you use references and slices when appropriate.

Downsides include the learning curve (about a week or two for a C++ programmer to start feeling semi-comfortable), and slower compile times for large modules or ones using lots of parameterized types. My coworkers will write Rust, but they tend to say things like, "Rust is intense."

Re: Rust: Not So Great For Codec Implementing

#60

Post by pcwalton »

cwyers wrote: post #30
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". Who's fault is that? Rust seems like an attempt to take a lot of foreign concepts to C/C++ programmers and dress them up in ALGOLy syntax. If you look at Rust's influences page[1], there's stuff from ML, Haskell, Erlang... and yet Rust code examples I've seen all look like "slightly weird C++." I…

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.
Post reply on HN