Live data from Hacker News

Yehuda Katz and Steve Klabnik Are Joining the Rust Core Team

blog.rust-lang.org

91–100 of 135 posts

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

#91
post #73

Earlier quoted context omitted.

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…

>>It is a benchmark, the point of it is to write the fastest code you can.The point of it is to show the performance differences, but that doesn't exclude a program like --

http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...

-- or like --

http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...

etc

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

#92
post #91

Earlier quoted context omitted.

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…

>>It is a benchmark, the point of it is to write the fastest code you can. The point of it is to show the performance differences, but that doesn't exclude a program like -- http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... -- or like -- http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... etc

It doesn't exclude "idiomatic" versions, but the data is presented so as to make them useless. How do I compare "idiomatic" rust to "idiomatic" haskell? All you can get is "here's the fastest versions from each language". If you want to compare any other version you have to do it on an individual basis, one at a time. So there's absolutely no reason for people to bother adding "idiomatic" versions.

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

#93
post #90

Earlier quoted context omitted.

>Also, isn't regex-dna using libpcre? It is in virtually every language on the shootout. That's one of the reasons the shootout is so terrible. A regex benchmark doesn't tell you much of anything unless the task itself is to write the regex engine. >I love Haskell, but I still don't think it occupies the same space as Rust. Neither do I. I am simply correcting this weird meme that "haskell is really slow and the shoo…

> A regex benchmark doesn't tell you much of anything… And yet, the programs don't all perform the same. One regex task doesn't tell you much of anything because so much can be different with a different task. Then again, people are usually surprised by V8 and Irregexp. The GHC version has been updated so many times since the last programs were contributed, that I hope the code would look better if it was written to…

>And yet, the programs don't all perform the same.

Because they don't all use pcre. Duh?

>The GHC version has been updated so many times since the last programs were contributed, that I hope the code would look better if it was written to use the latest greatest Haskell.

Why on earth would the code change because of a new compiler release? Do people rewrite the C one every time a new GCC is released? And the code looks fine, what "better" do you want?

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

#94
post #63
post #6

Congratulations Yehuda and Steve! We've been using Rust in production for awhile now, specifically because of its combo of native speed and memory safety[1]. This bending of traditional tradeoffs has let us implement features that would have been otherwise impossible. Interfacing with Ruby via its C APIs, we are able to do some pretty crazy stuff, like sample memory allocations in production with imperceptible overhe…

> This bending of traditional tradeoffs has let us implement features that would have been otherwise impossible. Could you talk more about what sort of features these are?

Err, he gave examples, as well as links.

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

#95

Earlier quoted context omitted.

(1) Even in that benchmark, Haskell is over twice as slow as Rust on average. (2) The Haskell code is nowhere near idiomatic. It is still useful to know that Haskell can be quite fast if necessary, but it likely does not reflect what your actual experience using Haskell would be.

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

>Do you know which Haskell examples are idiomatic, which aren't, and why?

Why wouldn't he?

With a little familiarity with programming at large and Haskell syntax can learn to discern the two cases even if you're not a Haskell programmer.

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

#96

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.

How is indexing an array OK with functional programming of the level of purity Haskell strives for (not to mention without bounds checking)?

In "Real World Haskell" they advise you to forgo of arrays, and even has a chapter "Life without arrays", saying "arrays and hash tables are often used as collections indexed by key, and in Haskell we use trees for that purpose".

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

#97

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…

>I'd hardly call it unidiomatic though, you just normally use "read" instead of "unsafeRead", etc.

Isn't "idiomatic" defined by what you "normally" use?

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

#98
post #84

Nice! As a reluctant Go developer, I look at rust with envy and excitement. I am very eager to see this project progress and it seems like they've got some great people on it.

I share your envy and excitement. I'm looking forward to dumping Go in favor of Rust once it's competitive in terms of libraries/stdlib. I've been building some big stuff in Go recently (mostly around financial market simulation) and the language shortcomings have hurt a lot. I've been using Go since January 2013 as my primary language, but everything I've seen of and tried with Rust is amazing.

What are the shortcomings?

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

#99
post #96

Earlier quoted context omitted.

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.

How is indexing an array OK with functional programming of the level of purity Haskell strives for (not to mention without bounds checking)? In "Real World Haskell" they advise you to forgo of arrays, and even has a chapter "Life without arrays", saying "arrays and hash tables are often used as collections indexed by key, and in Haskell we use trees for that purpose".

If you look at the context you can see that they are saying that using immutable arrays has a performance hit compared to mutable ones. That doesn't mean you shouldn't use arrays if they suit your purpose.

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

#100
post #98
post #84

Earlier quoted context omitted.

I share your envy and excitement. I'm looking forward to dumping Go in favor of Rust once it's competitive in terms of libraries/stdlib. I've been building some big stuff in Go recently (mostly around financial market simulation) and the language shortcomings have hurt a lot. I've been using Go since January 2013 as my primary language, but everything I've seen of and tried with Rust is amazing.

What are the shortcomings?

From what I gather, lack of user defined generics is primary reason, followed by the loose typing in interfaces.

I'm not an expert in Go, so feel free to correct me there. Additionally, IIRC Rust wanted to take the same route like GO regarding interfaces and generics, but Niko made an argument that it is wrong turn to make.

Post reply on HN