I don't think it's really possible to seriously consider Haskell as somehow less "dizzyingly complex" than rust unless you're already a math postgrad. I like haskell, don't get me wrong, but it is not in any way simple to write or read or work with by comparison. And while rust has some heady concepts in its design, for the most part even advanced users don't actually need to understand most of them to use it (I think this is actually rust's biggest innovation).

I do wish rust had borrowed syntactically more from haskell than C++, though.

Haskell is not really that complicated. What it is is capable of hosting dizzying complexity on top of its relatively simple core, which it is capable of hosting precisely because the core is so simple. It is similar to Lisp in that regard.

There's also rather a lot of spazzing out because some very simple concepts like "monad" in Haskell somehow managed to pick up a lot of very bad explanations and an aura of mystique they don't deserve. They're really only complicated if you go in assuming they must be, and that if you have a simple understanding it must be wrong because it has to be complicated. Rust fans may be familiar with the process; I see the borrow checking starting to pick up a bit of a similar mystique with the greater community, though I don't think it'll ever quite reach the same level of fever pitch as "monad" has. And I think there's even a similar process; start with Rust, print out Hello World, then immediately try to jump to writing a custom network application in Tokio and, yeah, the borrow checker is going to look pretty complicated since you're basically trying to swallow it all in one shot. The solution is, don't do that.

I detect some of that mystique in your post. It is a complete myth that you need to be a math postgrad to understand Haskell. It is a complete myth that you must understand group theory to use Haskell. It has even been observed that knowing too much Haskell can make group theory a bit harder to learn, and knowing too much group theory can make Haskell a bit harder to learn, because Haskell has a very programming-language centric view of group theory that means that even though some terminology is shared, everything is just a bit askew from the other. You no more need to be a math postgrad to use Haskell than you do to use a structured programming language, which also used to be a weird math nerd thing. Now it's just how programming languages work.

> I don't think it's really possible to seriously consider Haskell as somehow less "dizzyingly complex" than rust unless you're already a math postgrad.

This seems clearly false to me. Haskell has a higher abstraction ceiling than Rust, but unless you want to contribute to a particularly heavyweight library (`lens` comes to mind) you can get by just fine without going anywhere near it. In practice, most code in both languages maxes out at or below the mathematical sophistication of an introductory algebra class.

Aren't Haskell and Erlang both GC? I don't think anyone is touting Rust as newly immutable. The only differentiator (to my understanding) is Rust's safety without GC.

I don't know that that's really the whole story. I mean, C++ has smart pointers that do reference counting, same as Rust's do.

But C++ can't provide most of the rest of guarantees that Rust can, like that you didn't hold a reference to that argument, or return a pointer to a local variable that's about to go out of scope, or that these threads aren't both touching that thing at the same time.

That's true, a lot of Rust's features do exist in C++. I guess the main difference is that Rust is safe by default and you have to go out of your way to be unsafe. C++ is basically unsafe by default. In C++, the standard syntax for allocating memory gives you a completely unchecked pointer that you can freely use from whatever thread you want.

> or return a pointer to a local variable that's about to go out of scope

I thought of that recently. I wonder about using escape analysis to detect that and simply don't release the stack frame until the reference goes out of scope.

Static analysis/tracing absolutely can do a bunch of that kind of thing, particularly catching trivial cases.

But I think it's still a pretty important upgrade when those things are being checked by the compiler, for free, with guarantees, as part of every build, rather than using some side-tool that may be proprietary, deliver oodles of false positives, and so on.

What I mean is just fix that so it works. If you have split stacks the one for data doesn't have to track function call chains.

The advantage of using analysis tools is you only pay for that once. Not with every compile. And the tools are smarter than Rust. You also don't have safe vs unsafe code like you do with Rust.

You wouldn't just need split stacks for this, you'd need a spaghetti stack with some kind of heap allocation for frames. At which point perf goes out of the window already.

If you are using gcc, clang or vc++, to certain extent that is part of the compiler.

Just like C, following the UNIX principle, had compiler, assembler, linker, makefile, and linter since 1979. But people kept forgetting about the last piece of the puzzle and now it is a pain to bolt into existing code.

"Aren't Haskell and Erlang both GC?"

I answered the question about safety. You can have the safety of Rust without the complexity of Rust. I never promised there are languages that will have every last attribute of Rust but be simpler, and even typing that sentence out should make it clear that that is fairly unlikely to happen. Adding a GC is one way to simplify Rust. All simplifications of Rust are going to come with side effects. The complications are there for a reason; the question is always, does the code you're writing right now require that complexity, or can you use a simpler safe solution? Usually the answer will be the latter, honestly. Only a fraction of programs require that level of control... but it's a very important fraction!

There are some immutable languages inspired by Rust that are trying to have immutability without garbage collection but they're a ways off from practicality, I think.

I wonder too if we might see a world where a lot of application and business-logic code in Rust gets written essentially in the style of Python or Ruby— lots of immutability and copying stuff around because perf doesn't matter at that layer. But then the heavy processing part of the application can call down into vetted crates which do take advantage of Rust's more sophisticated features.

Am thinking here of the relationship between Python and Numpy/Pandas. Lots of companies use Numpy heavily but wouldn't dream of trying to hack on it or build such a thing themselves from scratch.

Similar story with places which do things like ban writing their own template code, but permit the use of std container classes.