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

Writing a JPEG Decoder in Rust – Part 2: Implementation I

mht.technology

Post reply on HN
Print view View original

11–20 of 86 posts

Re: Writing a JPEG Decoder in Rust – Part 2: Implementation I

#11

Post by steveklabnik »

ekidd wrote: post #5
0x0 wrote: post #2

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

IIRC, Rust will panic and halt your program. This is one of a handful of errors that Rust can't catch at compile time, and so it inserts run-time checks. The syntax "vec[i+1]" means "I expect this index to be in bounds, and if it's not, my program is so hopelessly broken it should be shut down immediately." If you're really confident in your code and you need to wring out the last bit of performance, you could also u…

  > and you need to wring out the last bit of performance,
... and if you've already demonstrated that LLVM hasn't removed the bounds checks itself already.

Re: Writing a JPEG Decoder in Rust – Part 2: Implementation I

#12

Post by lmm »

bluejekyll wrote: post #3

this 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!

It seems like a lot of work? In scala this would just be:

    val codes = (data_table, code_lengths, code_table).zipped map HuffmanCode

Re: Writing a JPEG Decoder in Rust – Part 2: Implementation I

#13

Post by mtanski »

lmm wrote: post #12
bluejekyll wrote: post #3

this 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!

It seems like a lot of work? In scala this would just be: val codes = (data_table, code_lengths, code_table).zipped map HuffmanCode

Rust is not Scala

Re: Writing a JPEG Decoder in Rust – Part 2: Implementation I

#14

Post by lmm »

tdb7893 wrote: post #7
daconvergence wrote: post #6

Rust code looks very similar to ES6 or Typescript. The great CS language convergence has begun!

As far as I know languages have broken down into families that look pretty similar to each other for a long time.

I think there is some convergence. E.g. there seems to be broad consensus that at least some level of standardisation of type information is valuable (see Python adding/improving type annotation syntax), and at the same time that having to explicitly specify the type of absolutely everything probably isn't worth it.

Re: Writing a JPEG Decoder in Rust – Part 2: Implementation I

#16

Post by lmm »

mtanski wrote: post #13
lmm wrote: post #12

Earlier quoted context omitted.

It seems like a lot of work? In scala this would just be: val codes = (data_table, code_lengths, code_table).zipped map HuffmanCode

Rust is not Scala

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.

Re: Writing a JPEG Decoder in Rust – Part 2: Implementation I

#17

Post by bluejekyll »

lmm wrote: post #16
mtanski wrote: post #13

Earlier quoted context omitted.

Rust is not Scala

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.

Scala and Rust are not trying to solve problems in the same way though. Rust is a zero-overhead language. Scala has never tried to make that claim.

Re: Writing a JPEG Decoder in Rust – Part 2: Implementation I

#18

Post by nercury »

lmm wrote: post #16
mtanski wrote: post #13

Earlier quoted context omitted.

Rust is not Scala

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.

Looking at the example, I can't find a thing in there that is not required (except the obvious `:Vec` type that is not required). We need `.iter` to tell that iterator is imutable (there is mutable version), we need `.collect` to actually run the iteration. I also don't think objects should have default constructor functions.

It may be possible to implement `.zipped` on tuples though.

Re: Writing a JPEG Decoder in Rust – Part 2: Implementation I

#19

Post by Manishearth »

quotemstr wrote: post #8
daconvergence wrote: post #6

Rust 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

Rust has provided ways to not abort on oom for a while now.

Re: Writing a JPEG Decoder in Rust – Part 2: Implementation I

#20

Post by gmfawcett »

lmm wrote: post #16
mtanski wrote: post #13

Earlier quoted context omitted.

Rust is not Scala

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