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

91–100 of 283 posts

Re: Rust: Not So Great For Codec Implementing

#91

Post by unrealhoang »

gwbas1c wrote: post #74

I tried Rust for the first time a few months ago. One of the things that really impressed me was that it was very easy to just get started. Even though the language is very different than I'm used to, I was able to "just jump in" without jumping through a lot of hoops. I was working with 3rd party crates very quickly. One thing that I think does need improvement is the error handling. Far too many idiomatic examples…

I was thinking the same as you until I learned about Result>. It’s super quick and not really that far off from the detailed hand-roll solution.

Re: Rust: Not So Great For Codec Implementing

#92

Post by valarauca1 »

tatterdemalion wrote: post #53
valarauca1 wrote: post #38

Earlier quoted context omitted.

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.

Can't `Vec` serve the same purpose?

Re: Rust: Not So Great For Codec Implementing

#93

Post by wuch »

dbaupp wrote: post #73
valarauca1 wrote: post #38

Earlier quoted context omitted.

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…

Being an ARC backed array isn't like std::string, and I don't see why having that copy-on-write behaviour implies it is fundamental. Could you expand?

In pre C++11 it was quite typical for std::string to be implemented with COW semantics. Since C++11 standard it is no longer permitted, though it is not necessarily reflected in all stdlib implementations.

Re: Rust: Not So Great For Codec Implementing

#94

Post by cwyers »

pcwalton wrote: post #60
cwyers wrote: post #30

Earlier quoted context omitted.

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

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

Re: Rust: Not So Great For Codec Implementing

#95

Post by kbenson »

dbaupp wrote: post #35
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…

Multidimensional arrays are... completely orthogonal: if the compiler could determine row indices were different, it could determine that slicing indices were too.

Is that true? Consider variables a=3, b=4, c=7.

With a large single array of 100 elements, but divided into 10 10 element pieces by convention, a slice of elements might be accessed by getting the elements array[10a+b] through array[10a+c]. If we also want a slice from the next segment, that would be array[10(a+1)+b] through array[10(a+1)+c].

With a multidimensional array, of 10 bounds checked segments of 10 elements, we could access by array[a][b] through array[a][c] and array[a+1][b] through array[a+1][c]. If access is bounds checked, or the compiler can prove the values are within the sizes, then the multidimensional version provably has no overlap.

Or am I missing something here?

Re: Rust: Not So Great For Codec Implementing

#96

Post by eridius »

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…

> All languages have reserved keywords, that's strictly in bikeshed territory.

This is true, but it is unfortunate that a relatively common word like "type" has been reserved (whereas you very rarely want to call a variable "struct", and "class" at least has the homophone "klass").

This is actually something that I really like about Swift and miss when I come back to Rust. In Swift, most keywords are contextual keywords, so you can still use them as variables or functions. And for the ones that aren't (or the ones where the usage you want is in the keyword context), there's a syntax using `backticks` that lets you turn it into an identifier anyway (which is useful if the declaration runs afoul of the keyword, but the common usage doesn't, so you can use backticks when declaring and leave them off when using).

Re: Rust: Not So Great For Codec Implementing

#97

Post by geofft »

SilasX wrote: post #34
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…

Is it hard to implement such primitives for distinguishing ownership of subsections of an array? Or to extend Rust to do do that?

It's pretty easy to do it in unsafe code, or to use an existing safe function (implemented internally with unsafe code) like the standard library function split_at_mut to do it.

Here's a doc on how to write such a function yourself, and includes the (actual) source code for split_at_mut:

https://doc.rust-lang.org/nomicon/borrow-splitting.html

As others have mentioned, there's nothing special about the standard library in this regard; you can just write the method yourself and it'll work equally well. (The standard library is moderately special in that it gets to use nightly features because dealing with breaking changes is easy for code that literally lives inside Rust's own source repository, but it's not special in terms of its ability to use unsafe code or anything.)

Re: Rust: Not So Great For Codec Implementing

#98

Post by binarycrusader »

pcwalton wrote: post #64
binarycrusader wrote: post #44

Earlier quoted context omitted.

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…

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

I wasn't referring to copying that I would do myself, but copying that other crates would do.

That is, if a crate only needs a little bit from a little dependency, then copying it into their crate can make everyone else's life easier (obviously taking licensing into consideration when doing so).

In short, the context here was the bytes crate, which is fairly tiny. If rust is going to insist on not including the bytes crate, or a copy of it, in the standard library, then I would hope others that consume it would consider embedding a snapshot of it into their own crate for their own, private use so that I don't have to worry about it.

I'm well aware there's a fine line here, hence my reference to the Go proverb.

Re: Rust: Not So Great For Codec Implementing

#99

Post by pertymcpert »

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 if your target architecture has a different vector width and hence you're using 4 element vectors but wasting 12?

If you want to use vectors explicitly, you can do so using intrinsics for most vector architectures.

Re: Rust: Not So Great For Codec Implementing

#100

Post by steveklabnik »

binarycrusader wrote: post #98
pcwalton wrote: post #64

Earlier quoted context omitted.

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

How is copying better than dependencies in this regard? You presumably need legal signoff either way. I wasn't referring to copying that I would do myself, but copying that other crates would do. That is, if a crate only needs a little bit from a little dependency, then copying it into their crate can make everyone else's life easier (obviously taking licensing into consideration when doing so). In short, the context…

> so that I don't have to worry about it.

What would you be worrying about?

Post reply on HN