Live data from Hacker News

Yehuda Katz and Steve Klabnik Are Joining the Rust Core Team

blog.rust-lang.org

71–80 of 135 posts

Re: Yehuda Katz and Steve Klabnik Are Joining the Rust Core Team

#71

Earlier quoted context omitted.

> (2) The Haskell code is nowhere near idiomatic This isn't meant as a personal attack firstly. Secondly, I've heard this said more than a few times lately and am generally curious: Do you know which Haskell examples are idiomatic, which aren't, and why? I feel like in the case of some it's just parroting someone elses argument.

Just in the first two examples on that page, you'll find allocaArray, mallocByteString, writeAlu, unsafeUseAsCString, unsafeIndex, withForeignPtr, unsafeDrop, and more. You really don't have to know Haskell very well (and I'm not claiming to be an expert by any stretch) to understand that this is far from idiomatic in a lazily evaluated, pure functional language. No parroting required.

You should know it at least a tiny bit though, or else you lump perfectly "idiomatic" functions in with low level functions that aren't often used and pretend they're a problem. How is a indexing an array without a bounds check somehow counter to lazy evaluation or functional programming? It is the exact same thing as indexing it normally, just without checking the length.

Re: Yehuda Katz and Steve Klabnik Are Joining the Rust Core Team

#72
post #69

Earlier quoted context omitted.

I didn't see an import for unsafe or foreign in: fannkuch-redux pidigits binary-trees

fannkuch-redux heavily utilizes unsafe operations on a mutable vector. binary-trees uses artificial strictness for the sake of the benchmark. Nine of the ten Haskell implementations are demonstrations of writing C in Haskell (without reaching C's performance).

>fannkuch-redux heavily utilizes unsafe operations on a mutable vector.

They are just not bounds checked. That is not "writing C in Haskell".

>binary-trees uses artificial strictness for the sake of the benchmark

What on earth is "artificial strictness"? Forcing evaluation when you need something to be evaluated immediately is not artificial, not unidiomatic, and not "writing C in Haskell".

>Nine of the ten Haskell implementations are demonstrations of writing C in Haskell

And end up shorter than rust? The idea that writing lower level code is "writing C in haskell" is nonsense, the ability to write more verbose but faster code is not harmful, it is useful. But the fact that lower level haskell is still shorter than rust and yet you want to act like it is some sort of horrible thing makes it hard to believe that you are really concerned about the horrors of writing slightly more verbose code.

Re: Yehuda Katz and Steve Klabnik Are Joining the Rust Core Team

#73
post #69

Earlier quoted context omitted.

fannkuch-redux heavily utilizes unsafe operations on a mutable vector. binary-trees uses artificial strictness for the sake of the benchmark. Nine of the ten Haskell implementations are demonstrations of writing C in Haskell (without reaching C's performance).

>fannkuch-redux heavily utilizes unsafe operations on a mutable vector. They are just not bounds checked. That is not "writing C in Haskell". >binary-trees uses artificial strictness for the sake of the benchmark What on earth is "artificial strictness"? Forcing evaluation when you need something to be evaluated immediately is not artificial, not unidiomatic, and not "writing C in Haskell". >Nine of the ten Haskell i…

The Rust code is both safer and faster at the cost of more keystrokes.

I'm not certain the point of writing unsafe code in Haskell when there are better tools for the job. Haskell is fast enough as is and using it to hammer screws just reeks of wrong tool for the job.

Re: Yehuda Katz and Steve Klabnik Are Joining the Rust Core Team

#74

Earlier quoted context omitted.

> (2) The Haskell code is nowhere near idiomatic This isn't meant as a personal attack firstly. Secondly, I've heard this said more than a few times lately and am generally curious: Do you know which Haskell examples are idiomatic, which aren't, and why? I feel like in the case of some it's just parroting someone elses argument.

>I feel like in the case of some it's just parroting someone elses argument. It usually is. The reality is that like most memes like this, there's a grain of truth at the center, but most of the people repeating it don't know where the truth ends and the exaggeration begins. Regex-dna is using low level ByteString operations to squeeze out a bit of extra performance. This makes it quite a bit longer and would rarely…

Ok, so perhaps I grant you the fact that unsafe indexing is idiomatic. The Rust code is still safer and more robust against buffer overflows in the long term. Also, isn't regex-dna using libpcre? That's a C library, no? Rust's regex library is pure Rust, with no unsafe code.

I love Haskell, but I still don't think it occupies the same space as Rust.

Re: Yehuda Katz and Steve Klabnik Are Joining the Rust Core Team

#75

Earlier quoted context omitted.

Just in the first two examples on that page, you'll find allocaArray, mallocByteString, writeAlu, unsafeUseAsCString, unsafeIndex, withForeignPtr, unsafeDrop, and more. You really don't have to know Haskell very well (and I'm not claiming to be an expert by any stretch) to understand that this is far from idiomatic in a lazily evaluated, pure functional language. No parroting required.

You should know it at least a tiny bit though, or else you lump perfectly "idiomatic" functions in with low level functions that aren't often used and pretend they're a problem. How is a indexing an array without a bounds check somehow counter to lazy evaluation or functional programming? It is the exact same thing as indexing it normally, just without checking the length.

The point is that is unsafe. You don't need to do that in idiomatic Rust code, because the bounds-check-free indexing is encapsulated inside the iterator library. So to re-frame it: fast, idiomatic Rust code is safer and easier to write than fast, idiomatic Haskell code.

Re: Yehuda Katz and Steve Klabnik Are Joining the Rust Core Team

#76
post #60

Earlier quoted context omitted.

Do you have an opinion on how Rust compares to Go?

Rust and Go do not overlap much other than they are both natively compiled, have curly braces and are backed by 'web' companies. Go was designed for building server software and for encouraging standardized, easy to maintain software. Rust on the other hand is generally targeted at the same areas where C and C++ are used for today.

The main similarity is that Go was called a systems language for some reason, and the idea is now cached in people's minds.

Re: Yehuda Katz and Steve Klabnik Are Joining the Rust Core Team

#77
post #69

Earlier quoted context omitted.

I didn't see an import for unsafe or foreign in: fannkuch-redux pidigits binary-trees

fannkuch-redux heavily utilizes unsafe operations on a mutable vector. binary-trees uses artificial strictness for the sake of the benchmark. Nine of the ten Haskell implementations are demonstrations of writing C in Haskell (without reaching C's performance).

> binary-trees uses artificial strictness for the sake of the benchmark

Using strict evaluation when appropriate is most certainly idiomatic Haskell code.

> Nine of the ten Haskell implementations are demonstrations of writing C in Haskell (without reaching C's performance).

This (C in Haskell accusation) is debatable, though I'm not sure there's much to be gained even given a totally successful discussion where we both communicate our points 100% effectively.

Re: Yehuda Katz and Steve Klabnik Are Joining the Rust Core Team

#78
post #69

Earlier quoted context omitted.

fannkuch-redux heavily utilizes unsafe operations on a mutable vector. binary-trees uses artificial strictness for the sake of the benchmark. Nine of the ten Haskell implementations are demonstrations of writing C in Haskell (without reaching C's performance).

> binary-trees uses artificial strictness for the sake of the benchmark Using strict evaluation when appropriate is most certainly idiomatic Haskell code. > Nine of the ten Haskell implementations are demonstrations of writing C in Haskell (without reaching C's performance). This (C in Haskell accusation) is debatable, though I'm not sure there's much to be gained even given a totally successful discussion where we b…

There probably isn't a point to it, as we're likely trying to argue different points.

I posit that using Haskell in such a way is a disservice to the language. If you want to code in such a way, why use Haskell?

Haskell is plenty fast as is and doesn't need to resort to unsafe code. What's the point?

Re: Yehuda Katz and Steve Klabnik Are Joining the Rust Core Team

#79
post #74

Earlier quoted context omitted.

>I feel like in the case of some it's just parroting someone elses argument. It usually is. The reality is that like most memes like this, there's a grain of truth at the center, but most of the people repeating it don't know where the truth ends and the exaggeration begins. Regex-dna is using low level ByteString operations to squeeze out a bit of extra performance. This makes it quite a bit longer and would rarely…

Ok, so perhaps I grant you the fact that unsafe indexing is idiomatic. The Rust code is still safer and more robust against buffer overflows in the long term. Also, isn't regex-dna using libpcre? That's a C library, no? Rust's regex library is pure Rust, with no unsafe code. I love Haskell, but I still don't think it occupies the same space as Rust.

> I love Haskell, but I still don't think it occupies the same space as Rust.

My opinion is that Haskell can overlap, but something that occupies the same space as rust would be Ivory[0] or ATS[1].

0: http://hackage.haskell.org/package/ivory 1: http://www.ats-lang.org/

Re: Yehuda Katz and Steve Klabnik Are Joining the Rust Core Team

#80
post #73

Earlier quoted context omitted.

>fannkuch-redux heavily utilizes unsafe operations on a mutable vector. They are just not bounds checked. That is not "writing C in Haskell". >binary-trees uses artificial strictness for the sake of the benchmark What on earth is "artificial strictness"? Forcing evaluation when you need something to be evaluated immediately is not artificial, not unidiomatic, and not "writing C in Haskell". >Nine of the ten Haskell i…

The Rust code is both safer and faster at the cost of more keystrokes. I'm not certain the point of writing unsafe code in Haskell when there are better tools for the job. Haskell is fast enough as is and using it to hammer screws just reeks of wrong tool for the job.

Your comment says absolutely nothing, and that appears to be the goal. What is the point of writing any code in any language? It is a benchmark, the point of it is to write the fastest code you can. You aren't obligated to write lower level code in haskell, nobody has a gun to your head. So why do you pretend it is a problem, and claim other languages are "better tools" for that job despite haskell clearly being very good at that job?
Post reply on HN