Earlier quoted context omitted.
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 t…
Writing a JPEG Decoder in Rust – Part 2: Implementation I
51–60 of 86 posts
Re: Writing a JPEG Decoder in Rust – Part 2: Implementation I
#52Earlier quoted context omitted.
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 t…
For me, type inference, strong typing, and ADTs with pattern matching puts a language into the ML family quite easily.
Re: Writing a JPEG Decoder in Rust – Part 2: Implementation I
#53That's not to say you could just throw this into the back-end of a public-facing website. It's still going to panic (abort) if someone unexpected happens, and it's still going to chew indeterminate amounts of CPU, memory or storage unless sandboxed (maybe even just ulimit). And there's still the danger one of the Rust standard library functions has a flaw in it. But this is the kind of starting point you wouldn't get with the plain C equivalent.
Re: Writing a JPEG Decoder in Rust – Part 2: Implementation I
#54Earlier quoted context omitted.
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 t…
A module functor is nothing more than a higher order module...one that takes as a parameter some data structure that conforms to an interface (signature). Rust may not have constructs called module functors, but it definitely has constructs that are capably equivalent, as well as some that are even more powerful (a claim that applies to Scala as well) For me, type inference, strong typing, and ADTs with pattern match…
Re: Writing a JPEG Decoder in Rust – Part 2: Implementation I
#55I 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
Since Rust people are reading this. I find myself wanting to walk an iterator pairwise regularly for stuff like this and I'm using: for (cur, next) in (& vec).iter().zip(vec.iter().skip(1)) { encoded_data.push(cur); if cur == 0xff && next == 0x00 { // ... } } Is there a better way to write this? What I'd really like is the equivalent to Clojure's partition[1]. I know that the stdlib has windows `(partition n (dec n)…
Re: Writing a JPEG Decoder in Rust – Part 2: Implementation I
#56[0] - http://www.briancbecker.com/blog/2010/analysis-of-jpeg-decod...
Re: Writing a JPEG Decoder in Rust – Part 2: Implementation I
#57Earlier 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.
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…
let codes: Vec = data_table.iter()
.zip(&code_lengths)
.zip(&code_table)
.map(|((&value, &length), &code)| {
HuffmanCode {
length: length,
code: code,
value: value,
}
})
.collect();Re: Writing a JPEG Decoder in Rust – Part 2: Implementation I
#58Re: Writing a JPEG Decoder in Rust – Part 2: Implementation I
#59Earlier quoted context omitted.
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.
https://doc.rust-lang.org/std/panic/fn.catch_unwind.html
Does anybody know if the standard library allocator aborts the process or throws a catchable exception? When they added catch_unwind they officially split panics into two types: abort panics and unwind panics. Code can choose one or the other when panic'ing. Also, programs can be built in such a way that all panics become aborts. That kind of sucks but it's probably one of the compromises needed to assuage those Rust developers who don't believe it's practical to handle OOM conditions.Re: Writing a JPEG Decoder in Rust – Part 2: Implementation I
#60Earlier quoted context omitted.
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.