looks like Haskell [LWN.net]

looks like Haskell

Posted Apr 17, 2013 23:47 UTC (Wed) by ncm (guest, #165) [Link] (4 responses)

It takes ideas from many languages. A type-safe Erlang, a scrubbed-up C++, a not-stupidly-weak Go, a fast Haskell, a fast ML, a history-sanitized Lisp; it's a real hodgepodge, and that's no criticism. Equally important are those it doesn't take anything from. One of very few languages with a real destructor and a pledge not to rely on GC in the standard library, it could turn out to be useful, someday, for writing programs that heretofore could only have been in C++.

looks like Haskell

Posted Apr 18, 2013 5:52 UTC (Thu) by nevyn (guest, #33129) [Link]

> One of very few languages with a real destructor and a pledge not to rely on GC in the standard library

So the "managed" allocated data using reference counts and thus. having RAII like properties is guaranteed to continue to exist?

looks like Haskell

Posted Apr 19, 2013 8:21 UTC (Fri) by k8to (guest, #15413) [Link] (1 responses)

Nitpick: ML is already fast, if you use the ocaml implementation. It's already competitive with C++ or C, and has been for like 8 years.

looks like Haskell

Posted Apr 24, 2013 20:36 UTC (Wed) by Tuna-Fish (guest, #61751) [Link]

There are many different kinds of speed. OCaml is very fast in *throughput*, but the differences in memory management strategies guarantee that Rust should always be able to promise less worst-case latency. In fact, Rust seems to sacrifice quite a bit of throughput to provide those better latency guarantees (among other things, the language promotes copying in many places where OCaml would be fine sharing), so I would expect OCaml to win most throughput benchmarks. However, if what you want is to guarantee that no task can take longer than 8ms to complete (fe. you want smooth 120Hz frame rates in a game), Rust should be better.

It's a tradeoff. Fundamentally, if a language or system wants to be really good on one metric, it has to sacrifice some of the other. OCaml and Rust choose different points, and there is nothing wrong with the choice of either. However, this does mean that there are some tasks where Rust is better suited.

looks like Haskell

Posted Apr 22, 2013 1:33 UTC (Mon) by zooko (guest, #2589) [Link]

I think that's why it is called "Rust"! Because it was originally envisioned to be made up entirely of hoary old ideas that had already been proven out in other languages.

looks like Haskell

Posted Apr 17, 2013 23:55 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Not really Haskell. It's more like Erlang - Rust emphasizes thread-local data with explicit object passing between threads.

Looks like something good

Posted Apr 18, 2013 3:47 UTC (Thu) by ofranja (guest, #11084) [Link]

It looks like OCaml, enhanced with Erlang concurrency model, and Cyclone type tagging for different memory management models.

Nice to hear about the language, it seems that they did a good research for gluing good things together, instead of implementing just more of the same old stuff. I'll keep an eye on it.

looks like Haskell

Posted Apr 17, 2013 23:57 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (11 responses)

Yeah, I'd like Haskell to become a popular language rather than Rust if only because Haskell already has a large pool of libraries and community. However, if people are that adverse to Haskell's more mathy take on things (such as using terms from category theory directly instead of naming them with more "friendly" terms) and how to handle laziness, I think Rust might be good enough.

looks like Haskell

Posted Apr 18, 2013 0:56 UTC (Thu) by droundy (subscriber, #4559) [Link] (10 responses)

The problem with Haskell that strongly distinguishes it from rust is that Haskell is designed in a way that makes it very hard to write fast code, and very hard to write a compiler that generates fast code. Laziness is a cool idea, but has huge implications for efficiency. Rust looks like it should be possible to have a compiler giving C-like efficiency (with a caveat for array bounds checking).

I love Haskell, but so far as I can tell, it's not playing the same game that rust is, which is creating a fast, safe, low-overhead language.

looks like Haskell

Posted Apr 18, 2013 1:58 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (2 responses)

I think one thing that I'd likely miss with Rust is Haskell's 'do' notation. Having a sequence of operations fail if any of them fail is nice to have. The biggest problem with the laziness that I've found is that I/O is lazy. I've been bitten a number of times forgetting a strictness marker on results of file reading and such.

That said, there is a lot of research going into making GHC generate good and fast code. There are certainly some very nice examples of GHC producing very fast code from fairly idiomatic Haskell. However, once you get past that cliff, things tend to get pretty hairy quickly.

looks like Haskell

Posted Apr 18, 2013 10:15 UTC (Thu) by Auders (guest, #53318) [Link] (1 responses)

Lazy I/O is on the way out, with iteratee I/O (pipes, conduit...) replacing it.

looks like Haskell

Posted Apr 19, 2013 17:36 UTC (Fri) by b7j0c (guest, #27559) [Link]

right, but like String -> Text, laziness is another major legacy problem for haskell. how much of hackage has been built with the older thinking? how much of hackage is now merely replicated attempts to get mindshare for the latest Iteratee variant?

you'll never purge Strings or laziness (or bang annotations etc) from hackage, most of those packages aren't that well maintained. rust is the reboot haskell needs.

looks like Haskell

Posted Apr 18, 2013 2:46 UTC (Thu) by rsidd (subscriber, #2582) [Link] (6 responses)

There are also important algorithms (eg dynamic programming, any kind of linear algebra) that are ill-suited to a purely functional language like Haskell. It can be done but hoops need to be jumped through and the results are (to me) unreadable. Sometimes it is clearer and more efficient to have a mutable array or matrix where operations are done in-place. And recursion instead of looping is a nice idea until you try to make it tail-recursive for efficiency and find it is ugly or just impossible. I prefer the approach of OCaml and (apparently) Rust where one is allowed to declare variables mutable, write for-loops, etc.

looks like Haskell

Posted Apr 19, 2013 9:24 UTC (Fri) by peter-b (subscriber, #66996) [Link] (4 responses)

Given that every loop has an isomorphic tail recursive form, I suspect that you are running up against "ugly" much more often than "impossible"!

looks like Haskell

Posted Apr 19, 2013 9:39 UTC (Fri) by rsidd (subscriber, #2582) [Link] (3 responses)

Read "impossible" as "impossible for me to get my mind around" :) I'm thinking of nested loops in particular. Also things like the Fibonacci function where a naive implementation

fib 0 = 0
fib 1 = 0
fib n = fib (n-1) + fib (n-2)

is not just non-tail-recursive but incredibly inefficient. And every "functional" efficient version that I've seen is just too hard to understand (for me) by reading the code. And that's for a trivial beginner-level example.

looks like Haskell

Posted Apr 19, 2013 9:54 UTC (Fri) by neilbrown (subscriber, #359) [Link] (2 responses)

How about something like:

fib 0 = (1,1)
fib n = (a+b, a) where (a,b) = fib (n-1)

That's reasonably efficient - not sure how easy it is to make it tail recursive.

looks like Haskell

Posted Apr 19, 2013 10:19 UTC (Fri) by rsidd (subscriber, #2582) [Link]

Yes, thanks, that's efficient though I'm not sure how easy it is to make it tail-recursive either. When it's more complicated stuff like matrix multiplication or Needleman-Wunsch, it's just too hard for me -- and, I suspect, for most "normal" people. Haskell has clearly proved that it is very useful for some people and some tasks, but I suspect that's the maximum for pure functional programming.

looks like Haskell

Posted Apr 21, 2013 15:12 UTC (Sun) by ballombe (subscriber, #9523) [Link]

Converting your code to tail-recursion give:

fib n = fibr n 1 1 where
fibr 0 a b = (a,b)
fibr n a b = fibr (n-1) (a+b) a

(thought there are much faster algorithms to compute this)

looks like Haskell

Posted Apr 19, 2013 17:38 UTC (Fri) by b7j0c (guest, #27559) [Link]

graphs have also been a problem for pure functional languages