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

21–30 of 86 posts

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

#21

Post by steveklabnik »

nercury wrote: post #18
lmm wrote: post #16

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

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.

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

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

#22

Post by pcwalton »

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.

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 heavy GC dependence. So the comparison isn't as meaningful as it might seem.

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

#23

Post by pcwalton »

steveklabnik wrote: post #21
nercury wrote: post #18

Earlier quoted context omitted.

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.

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

> This is impossible without varargs, no?

Nah, you'd just implement it as an impl over and over on tuples of reasonable size (up to 16 or so).

It wouldn't be elegant, but it'd work in practice.

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

#24

Post by steveklabnik »

pcwalton wrote: post #23
steveklabnik wrote: post #21

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

> This is impossible without varargs, no? Nah, you'd just implement it as an impl over and over on tuples of reasonable size (up to 16 or so). It wouldn't be elegant, but it'd work in practice.

Oh right, I see now.

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

#25

Post by epidemian »

nercury wrote: post #18
lmm wrote: post #16

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

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.

Yep, but it's still an unfortunately big difference in expressiveness between the two languages, where one might think that they would be more or less on par, given the languages' similarities (both are more or less contemporary in their design, statically typed, with similarly powerful type systems, etc).

My question is then: is there something fundamentally preventing Rust from achieving similar levels of expressiveness to this Scala example without incurring in unnecessary runtime overhead? Given that both languages are statically typed, my inclination would be to say no: the information is there, the compiler should be able to figure it out. But, alas, i know very little about these things, hence my question :)

Update: pcwalton gave some nice insight on why Rust needs some of these constructs on an uncle comment.

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

#26

Post by nercury »

steveklabnik wrote: post #21
nercury wrote: post #18

Earlier quoted context omitted.

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.

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

> `collect()` doesn't know what type of collection to collect into.

Yes, unless there is some other mention of Vec, i.e. it is returned from the function.

> This is impossible without varargs, no?

Varargs would definitely help, and would allow Rust to borrow more ideas without workarounds. But one can do it manually for each tuple variant.

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

#27

Post by nimish »

steveklabnik wrote: post #21
nercury wrote: post #18

Earlier quoted context omitted.

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.

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

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

#30

Post by pcwalton »

Artlav wrote: post #29

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

Many language implementations generate code with good performance. That does not mean that all programs written in those languages will exhibit good performance.
Post reply on HN