> To be frank I find the point about developer speed in Rust to be a bit exaggerated, it's pretty high level and the tooling is pretty great.

Rust has a long learning curve that most people won’t make it through. For them, they might feel the language is slow to developenin because they haven’t gotten to the point where they are “thinking” in Rust.

As a Haskeller, you are well suited to learn Rust; due to their similar ML lineage (the original Rust compiler was written in OCaml), Rust and Haskell make some similar design considerations. I’d say one thing Rust does right is take a lot of the things that make Haskell safe and make them fit in an imperative language.

That's an interesting take on Rust. Given that I have written a lot of code in Standard ML, I might give Rust a try after all.

GP's statement "If you care about security, correctness and performance but don't care about developer speed, use Rust." threw me a little off here. Because, Standard ML is very quick and easy to develop in. So should Rust not inherit that property?

It's very easy and simple to write Rust in Rust. Compiler is your friend and helps you all the time.

It's possible to write C++ or Java or Haskell in Rust but then compiler becomes your enemy and you fight it at every turn.

Yes, I think Rust does get there. The thing of it is, I think people are measuring "time of development" differently. To some, the time developing a thing is the time spent writing it, and then getting it out the door. They often don't include things like fixing bugs that are discovered down the line and handled maybe by a completely different team. There's a difference between writing something and writing something right.

The Rust compiler and specifically the borrow checker help you write code that works the first time, which is a property Haskell famously exhibits. In order to get there, sometimes an involved conversation with the borrow checker or type checker is needed. What this means is sometimes you might spend a good long while figuring out a particular lifetime and ownership annotation in order to satisfy the borrow rules. Another implication is that sometimes the way you've architected your code is just plain wrong as far as the borrow checker is concerned. Sometimes it's hard to tell when you just need to add a particular annotation to your code to make it work, or if you actually need to rethink everything entirely. For example, if you go writing a doubly linked list in Rust thinking you'll use pointers, that's just the wrong way to go about it in Rust world, so rather than trying to force that style of code, doing things the Rust way (using Rc<RefCell<T>>>) will yield better results.

But once you get your code to compile, things generally work in a sense that the code will never fall victim to a whole class of bugs that frequent code written in other languages (segmentation faults, use after free, memory leaks, dangling pointers, etc.) You just won't see these things in safe, idiomatic Rust code.

And that leads me to developer speed. Once you and the borrow checker are on the same page, it's like night turned to day. Early when I first started writing Rust, I would spend most of my time dealing with borrow checker errors. Now that I know what the borrow checker expects, and I've internalized all the strange syntax and edge cases, the borrow checker fades into the background and I can code in Rust just about as fast as I can in TypeScript.

As a Haskeller, I expect you might approach writing Rust code in a functional style, and I think this would serve you well. The general approach that newbies take in Rust and which finds strong resistance by the Rust compiler is copious use of passing references for mutation, and creating a rat's nest of pointer references. This style of coding doesn't go over well in Rust, and unfortunately a lot of coders practice this because it's permitted by their native language.

Instead, it's better to lean into type checking and actually use the type checker to save you from having to write a lot of code. Take advantage of immutability and referentially transparent function. Make heavy use of pattern matching and Maybe monads cough I mean Option<T>. We don't use that word in Rust. Haskellers get all of this.

I also don't use the m-word! Maybe Rust is for me after all.

I am currently using Swift, and I like it a lot. But you are kind of siloed into the Apple ecosystem. So I am looking for an alternative.

I am thinking TypeScript might give the biggest bang for the buck: * You have the widest possible reach via web apps & Electron * You have an eval/Function object for compiling code on the fly * You can embed low-level code via WebAssembly (and here Rust might be relevant for producing that WebAssembly) * If you need access to your TypeScript libraries on mobile, you can still do that via embedding a hidden WebView.