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

111–120 of 283 posts

Re: Rust: Not So Great For Codec Implementing

#111

Post by falcolas »

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…

I personally agree with this philosophy - more the "use the standard library" than "copy stackoverflow".

I can't count the number of times we've had problems with the requests library, either because of the huge tree of dependencies (both explicit and implicit) that requests has, and because of some of the assumptions made by requests.

On the other hand, when a bit more time is taken (yes, this means a few lines of boilerplate) and the code uses urllib2, it rarely has to be touched again.

Re: Rust: Not So Great For Codec Implementing

#112

Post by phkahler »

pertymcpert wrote: post #99
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…

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.

The sizes I mentioned are extremely common in 2d and 3d geometry. This is due to the number of dimensions visible in our world. While someone may want to run 11 dimensional calculations in string theory, there are a large number of common real-world applications of the lengths 2,3,4. In C and C++ you can often use intrinsics but the big 3 - ARM, Intel, PPC - all define them differently. I want this common stuff to be part of the language. Sure go ahead and support general vectors via class definitions and such, but give me direct support for the common sizes.

Re: Rust: Not So Great For Codec Implementing

#113

Post by phkahler »

mrec wrote: post #56
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…

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

OOP often involves overhead. If someone defined a really clean vector type/object in a library that let me write expressions the natural way, that could be added to the language I suppose. And that's what I want.

Re: Rust: Not So Great For Codec Implementing

#114

Post by weberc2 »

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…

I'm really glad it doesn't do this. I spend a fair amount of time writing or reading Rust, Python, CoffeeScript, Haskell, OCaml, etc (in no particular order) and I find Rust to be much more readable, largely due to braces, commas, and parens in intuitive places.

Re: Rust: Not So Great For Codec Implementing

#115

Post by phkahler »

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.

I want it to turn it into SIMD instructions. What I don't want is to write classes, functions, or loops that have to be automatically converted to SIMD. I want a simple built-in type for these three size vectors. I also mentioned that they should be passed by value and be able to be returned by value in a (SIMD) register. This is the most efficient way to write and execute vector math.

Re: Rust: Not So Great For Codec Implementing

#116

Post by weberc2 »

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…

CMake--not lack of static analysis--is the primary reason I moved to Rust from C++. Safety is something I came to appreciate later. Building binaries is a solved problem; there's no reason to allocate project time crafting and maintaining a build system for each individual project.

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

Rust allows you to make that tradeoff, ridiculous though it may be.

Re: Rust: Not So Great For Codec Implementing

#117

Post by dbaupp »

kbenson wrote: post #95
dbaupp wrote: post #35

Earlier quoted context omitted.

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[10 a+b] through array[10 a+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 elem…

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 one wants to slice an array multiple times.)

Re: Rust: Not So Great For Codec Implementing

#118

Post by legulere »

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.

Re: Rust: Not So Great For Codec Implementing

#119

Post by kbenson »

phkahler wrote: post #115
nwmcsween wrote: post #62

Earlier quoted context omitted.

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.

I want it to turn it into SIMD instructions. What I don't want is to write classes, functions, or loops that have to be automatically converted to SIMD. I want a simple built-in type for these three size vectors. I also mentioned that they should be passed by value and be able to be returned by value in a (SIMD) register. This is the most efficient way to write and execute vector math.

Can't a library just add that? Make some types, implement some functions and/or overload some ops. If you're defining the special type anyway, I'm not sure why it has to be built in.

Re: Rust: Not So Great For Codec Implementing

#120

Post by geofft »

SilasX wrote: post #104
geofft wrote: post #97

Earlier quoted context omitted.

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

I meant primitives that preserve Rust's (safe) ownership model.

Well, you can use the existing split_at_mut if you're worried about getting your hand-rolled unsafe implementation wrong. It's definitely reasonable if you're splitting on rows; it may or may not be what you want if you're trying to get a slice-like thing that splits on columns.

(There's no reason to avoid safe functions that happen to have unsafe implementations. For instance, the standard-library implementation of indexing a slice, as in b"hello"[3], is just a bounds check plus an unsafe dereference.)

Post reply on HN