I don't know rust, but what happens if you get a 0xff as the last byte here, wouldn't i+1 go out of array bounds? while i
Ooops :(
One of many minor bugs, I suppose.
Writing a JPEG Decoder in Rust – Part 2: Implementation I
41–50 of 86 posts
Re: Writing a JPEG Decoder in Rust – Part 2: Implementation I
#42Original thread: https://news.ycombinator.com/item?id=12319557
Oh well - not getting karma on HN isn't the worst thing that could've happend :)
Re: Writing a JPEG Decoder in Rust – Part 2: Implementation I
#43Rust code looks very similar to ES6 or Typescript. The great CS language convergence has begun!
Yes: now we all forget how to correctly manage memory. Rust: where resources are unlimited and aborting when you run out of them is okay
The vast majority of programs that you run on a day to day basis will abort when they run out of memory. On a default Linux system, there's not even any way to prevent that - you need to faff with the config to make it actually return errors when allocating memory.
Re: Writing a JPEG Decoder in Rust – Part 2: Implementation I
#44Earlier quoted context omitted.
The biggest difference between Scala and Rust here is ".iter()", which is necessary mainly because you need to specify whether the iterator iterates over references (".iter()") or passes results by value (".into_iter()"). Because Java doesn't have value types and has no concept of move semantics, it has no need for the distinction, while Rust does. In effect, the "elegance" of Scala here is really the product of its…
Wouldn't the type guarantees provided by rusts type system allow for different implementations based on whether it was called on value types vs reference types? I thought there was an auto specialization feature created a while ago that did something like that.
I think the into iterator version borrows the references (did I say that right?
Re: Writing a JPEG Decoder in Rust – Part 2: Implementation I
#45I feel like i'm missing something. In the "Why" section he claims that Rust is a performant language with a low-level feel. In this part, he claims that decoding a tiny JPG image took 2 seconds with his code. How is that "performant" by any definition?
Author here. I am having some trouble reproducing the 2 seconds number, but with optimizations I'm getting around 1.5 seconds (without, I'm up to 5!), and as balducien mentions, /u/DroidLogician pointed out a _huge_ performance flaw in the file reading code. Writing bad code is easy in any language (as I just showed :) - writing _super_ performant code is only possible in some. EDIT: I made a pretty bad mistake while…
Ah, ok. From the Reddit thread it sounds like you were using a 20MB file for the 2s result?
From the article it sounds like the 2s result was for the 90Kb file, which would have been rather odd.
Re: Writing a JPEG Decoder in Rust – Part 2: Implementation I
#46Earlier quoted context omitted.
The biggest difference between Scala and Rust here is ".iter()", which is necessary mainly because you need to specify whether the iterator iterates over references (".iter()") or passes results by value (".into_iter()"). Because Java doesn't have value types and has no concept of move semantics, it has no need for the distinction, while Rust does. In effect, the "elegance" of Scala here is really the product of its…
Wouldn't the type guarantees provided by rusts type system allow for different implementations based on whether it was called on value types vs reference types? I thought there was an auto specialization feature created a while ago that did something like that.
It allows changing implementation depending on what you pass it, but it cannot change how you pass things. The issue is that if you just call zip(code_lengths), then ownership of code_lengths is passed into the function and it ceases to work in it's parent.
Re: Writing a JPEG Decoder in Rust – Part 2: Implementation I
#47Earlier quoted context omitted.
> (except the obvious `:Vec ` type that is not required) It is required, otherwise, `collect()` doesn't know what type of collection to collect into. > It may be possible to implement `.zipped` on tuples though. This is impossible without varargs, no?
Haskell just brute force implements zipWith3, zipWith4 etc Not elegant, but it works.
The un brute force way is to use the Applicative instance of ZipList.
Re: Writing a JPEG Decoder in Rust – Part 2: Implementation I
#48Earlier quoted context omitted.
It's not, but they're both ML-family languages. I had hoped that Rust would be able to offer a similar level of elegance to Scala.
It's a bit of a stretch to call Scala and Rust "ML-family languages".
Not at all -- there's a lot of commonality in the language designs.
Core language features: both have algebraic datatypes like ML ("case classes" in Scala, enums in Rust), and a 'match' statement that makes working with them easy. Both have pervasive destructuring that works with match arms, 'let' bindings, etc.
Data structures and mutation: both encourage a pragmatic version of immutability -- use values and provide functional interfaces primarily, but support mutation where needed. In Rust there are 'Cell' and 'RefCell' types, just like ML's cell-based interior mutability.
Library idioms: all three have the standard set of functional-style higher-order transformation functions ('map', 'filter', etc. -- Rust in particular has a very rich Iterator trait API), and it's idiomatic to use these.
FWIW, Rust's first/bootstrap compiler was written in OCaml and there's a lot of obvious influence.
Re: Writing a JPEG Decoder in Rust – Part 2: Implementation I
#49this is a really elegant way to take parallel arrays and put them into a table: let codes: Vec = data_table.iter() .zip(code_lengths.iter()) .zip(code_table.iter()) .map(|((&value, &length), &code)| { HuffmanCode { length: length, code: code, value: value, } }) .collect(); Nice!
Yeah though there's something a bit sad to the lack of variable-arity zip/map as you'd find in dynamically typed languages e.g. in Clojure: (mapv HuffmanCode. code_lengths code_table data_table) I don't know if even dependent types would allow for that, given the (variable number of) arguments are all different types.
It's straightforward with dependent types, unless the language treats multiple arguments (or functions of multiple arguments) specially. In my Scala example in the sibling thread the ().zipped is sort-of-language-level, but one could easily implement the same thing using a HList instead of a tuple; turning the function into a function that accepts a HList requires language-level support or a (standardized) macro but it wouldn't in a Haskell-like language where a function of multiple arguments is curried by default.
Re: Writing a JPEG Decoder in Rust – Part 2: Implementation I
#50Earlier quoted context omitted.
It's a bit of a stretch to call Scala and Rust "ML-family languages".
Not at all -- there's a lot of commonality in the language designs. Core language features: both have algebraic datatypes like ML ("case classes" in Scala, enums in Rust), and a 'match' statement that makes working with them easy. Both have pervasive destructuring that works with match arms, 'let' bindings, etc. Data structures and mutation: both encourage a pragmatic version of immutability -- use values and provide…
I'm aware that Rust's bootstrap compiler was written in Ocaml. And yes, there are lots of ML inspirations in the language -- but not enough to make an ML language. Where are the module functors, for example? Many would consider that an essential element of an ML language, and it is a stretch to call a language an ML family member without them.
I don't want this to devolve into a No True Scotsman debate, I just feel that the parent post -- which decried a lack of similarity between Rust and Scala because they were both in the ML family -- was founded on a weak premise.