Hacker News new | past | comments | ask | show | jobs | submit login

I wouldn't call a "mutability first" language which relies mostly on side-effects "functional".



Rust’s type system is very close to Haskell’s and takes a lot of inspiration from functional programming.

I’m not sure I’d call Rust mutable-first either. As for side-effects, I suspect the next leap in PL development will be an efficient algebraic-effects system with a good dev experience (or at least a trade-off so appealing it overcomes the necessary friction).


> Rust’s type system is very close to Haskell’s and takes a lot of inspiration from functional programming.

Well… No.

It misses some landmark features like HKTs, and it likely never won't get them.

Inspiration? Sure. But what lang today doesn't take that?

> I’m not sure I’d call Rust mutable-first either.

So what do the affine types track? ;-)

> As for side-effects, I suspect the next leap in PL development will be an efficient algebraic-effects system with a good dev experience (or at least a trade-off so appealing it overcomes the necessary friction).

Let's make "some effect system" out of it and I'm with you.

But it likely won't be Rust getting such features in the near or midterm future (no clue about such a possibility in the far future, though).

Other languages are almost there on the other hand side. Scala for example will get "ability tracking" real soon™ now.

Rust may seem a little bit like a FP lang at frist if you're coming form one. But after writing some code you going to realize that Rust's philosophy is quite different form a FP lang: Rust embraces mutability and side-effects at its core! It "just" tries to make that more safe.


Thing is, the constraints that make mutability and side effects "safe" are pretty much indistinguishable from functional programming. You can opt out of those in Rust via "internal mutability", but that comes with a corresponding increase in complexity.


I don't think Rust can enforce referential transparency, nor does it have any focus on doing this manually. But I would say referential transparency is one the most important properties in functional programming, if not even the most distinguishing property.

Referential transparency is the one feature that makes reasoning about a program easy. You can think about referential transparent programs purely in the substitution model. You can move referential transparent expressions freely around as you please.

You can't think of a Rust program this way. It's inherently procedural.

Rust gets a lot of things quite right! But it's not a FP language. It's a better C. It's about shoveling bits and bytes around, as safely and efficient as possible.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: