Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust vs. Haskell

serokell.io

Post reply on HN
Print view View original

61–70 of 189 posts

Re: Rust vs. Haskell

#61

Post by erk__ »

IshKebab wrote: post #50
thedataangel wrote: post #9

Earlier quoted context omitted.

Quite a few of Rust's features were borrowed from or inspired by ones in Haskell - albeit often modified to be more suitable for systems programming (and systems programmers!). Most Haskellers I know are quite fond of Rust :)

I think Rust's features were actually inspired by OCaml rather than Haskell. Rust was originally written in OCaml, and OCaml feels a lot more similar to Rust than Haskell does. Of course Haskell is heavily influenced by ML so it also has a lot of the same features.

There does exist at least one sml implementation that computes the memory allocations at compile time a bit similar to how Rust does it.

Re: Rust vs. Haskell

#62

Post by marcosdumay »

lvass wrote: post #24

Can someone explain why/whether a language like Rust requires mutability? Wouldn't it be better if we could just have the compiler guarantee that functions marked as such are doing TCO, so algorithms would look better and had the full benefit of persistent data structures?

You mean mutability annotations or allowing mutability at all?

Because you can't simply disallow mutability in an imperative language.

But about annotations, you annotate your code to let the compiler know what you meant to do. If just looking at what you do was enough, C would be a safe language. You improve it by giving more information to the compiler, so it can check if you are doing what you meant to.

(But I don't know what relation you saw with TCO. It's not a related concept.)

Re: Rust vs. Haskell

#63

Post by platz »

pjmlp wrote: post #38
amelius wrote: post #21

Earlier quoted context omitted.

I think painting Rust and Haskell as similar languages is very misleading. Haskell has a garbage collector for a reason. You can't program naturally with closures unless you have a garbage collector, because closures introduce cyclic references. Also, Haskell has a type inference system that allows e.g. the IO monad to work seamlessly with the rest of the language. EDIT: and laziness of course.

Also Haskell is getting linear types, which gets us the best of both worlds, GC productivity and low level performance when needed.

Every talk I've seen on Haskell linear types is that at best they can do some specific compuatations more efficiently (especially with arrays) but are not a good fit in Haskell to significantly elide GC.

Re: Rust vs. Haskell

#64

Post by surement »

ianpurton wrote: post #42

> As a result, both languages have steep learning curves compared with other languages. Well yes and no. In a way the features such as immutability and algebraic data types are things you should know about as a software developer even if your current language means you can't use them at the moment. My 16 year old son has learned Rust coming from a python at school background and is now writing small games in the bevy…

> yes and no

Having to understand monad transformers or another kind of effect system to get anything working is a heavy load that's unnecessary in other languages.

Re: Rust vs. Haskell

#65

Post by ghostwriter »

platz wrote: post #63
pjmlp wrote: post #38

Earlier quoted context omitted.

Also Haskell is getting linear types, which gets us the best of both worlds, GC productivity and low level performance when needed.

Every talk I've seen on Haskell linear types is that at best they can do some specific compuatations more efficiently (especially with arrays) but are not a good fit in Haskell to significantly elide GC.

What would be an example of significant elision in this context?

Re: Rust vs. Haskell

#66

Post by ilovecaching »

Ericson2314 wrote: post #58
ilovecaching wrote: post #48

As a systems programmer any mention of the word Haskell next to the word Rust sends shivers down my spine. Haskell is the king of yak shaving abstractions and is almost the polar opposite in all the ways that made C the most practically successful language on the earth. I do not want abstractions where they aren't needed. I want control, simplicity, a clear correspondence between what I'm writing and what logical ass…

I've helped write some very abstract combinator-y Rust that compiled down to an embedded program that runs with only 4K RAM. Get over it. > and what logical assembly I'll be generating The problem with Rust and C is not worrying about what assembly I'll get, it is that one has very little control over the layout of the stack. It's the last implicit data structure and that's a PITA for highly resource constrained prog…

With all due respect, writing one program with a small memory footprint doesn't disprove my point. I'm referring to writing very large, complex programs that interact directly with hardware - kernels, boot loaders, firmware, all of which must be as clear as possible. And I say this with many years of experience dealing with other companies badly written device drivers and firmware.

I absolutely need to worry about what assembly I get. I am often checking my assembly or looking for optimizations in my assembly. And I'm doing this across multiple architectures.

Re: Rust vs. Haskell

#67

Post by ilovecaching »

kilgnad wrote: post #60
ilovecaching wrote: post #48

As a systems programmer any mention of the word Haskell next to the word Rust sends shivers down my spine. Haskell is the king of yak shaving abstractions and is almost the polar opposite in all the ways that made C the most practically successful language on the earth. I do not want abstractions where they aren't needed. I want control, simplicity, a clear correspondence between what I'm writing and what logical ass…

Rust is the bastard child of C++ and Haskell. So it doesn't have the simplicity of C, it tries to give you as many abstractions as possible while still maintaining the zero cost philosophy. I would say Rust is easier then C++ and easier haskell.

Being easier than C++ or Haskell isn't really saying much at all. Neither of them have improved code readability and are notorious for their learning curve.

Re: Rust vs. Haskell

#68

Post by cosmic_quanta »

surement wrote: post #64
ianpurton wrote: post #42

> As a result, both languages have steep learning curves compared with other languages. Well yes and no. In a way the features such as immutability and algebraic data types are things you should know about as a software developer even if your current language means you can't use them at the moment. My 16 year old son has learned Rust coming from a python at school background and is now writing small games in the bevy…

> yes and no Having to understand monad transformers or another kind of effect system to get anything working is a heavy load that's unnecessary in other languages.

You need to use the IO monad to get anything working, true. Monad transformers? Not at all.

I'd say knowing how to use monad transformers is the barrier between intermediate and expert Haskell programmers.

Re: Rust vs. Haskell

#69

Post by pjmlp »

platz wrote: post #63
pjmlp wrote: post #38

Earlier quoted context omitted.

Also Haskell is getting linear types, which gets us the best of both worlds, GC productivity and low level performance when needed.

Every talk I've seen on Haskell linear types is that at best they can do some specific compuatations more efficiently (especially with arrays) but are not a good fit in Haskell to significantly elide GC.

They are on the early days of integrating them, so how could we expect them to refactor GHC all the way already?

Re: Rust vs. Haskell

#70

Post by jeremyjh »

cosmic_quanta wrote: post #68
surement wrote: post #64

Earlier quoted context omitted.

> yes and no Having to understand monad transformers or another kind of effect system to get anything working is a heavy load that's unnecessary in other languages.

You need to use the IO monad to get anything working, true. Monad transformers? Not at all. I'd say knowing how to use monad transformers is the barrier between intermediate and expert Haskell programmers.

I'd say using transformers are more the barrier between beginner and intermediate. Its not impossible to do serious work without them but I'm not sure its worth doing.
Post reply on HN