Tooling is such a huge factor. I'd love a functional language that had build tools as nice as rustup and cargo.
Indeed I'd place Rust as an example of a language that got it right. Sure, Rust isn't functional, but it's confusing on first usage, so close enough :D
In all seriousness, the big issue that functional languages have to get over is that most programmers are not great mathematicians, so declarative programming feels very weird and confusing. With Rust the big issue is all the rules about memory. How did Rust solve it?
For one, they made the language as familiar as possible. Rust's syntax is extremely close to C/C++, even if the semantics aren't. As much as PL people claim syntax doesn't matter, it does. ReasonML is a project with a similar philosophy.
Next, they put a lot of work into documentation and explanations, especially at the compiler level. Rust's compiler messages are fantastic and often anticipate beginner mistakes. I'd love a functional language that detects when the code looks kinda imperative and gently guides you towards the functional option.
And finally, they had a killer app like Wadler mentions. Performant memory safety is pretty hard to argue against. Even a manager could see the potential upsides. I wonder what sort of killer app one could create for functional languages? Reason with ReasonReact could have robust UI as one, but that's still not as good of a sell as performant memory safety.
Performant memory safety is not that big of a feature. GCs are fast enough unless you have real time constraints.
If have real time constraints, you probably do not care about memory safety that much, unless your system is safety critical.
If your system is safety critical, you are using lots of tooling for validation beyond memory safety - and probably some form of model based code generation. That tooling just does not exist for newcomer languages.
Where do you have real time constraints but don't care about things blowing up?
I guess there's lots of places that have soft real time constraints like in games and other entertainment? But hard real time usually means you do care about not blowing up.
GCs like ZGC can handle tiny heaps with no pauses, pretty minimal heap wastage and a ~10% throughput hit vs a more middle of the road GC. You're thinking of the Go GC and assuming they must be all like that.
I'll be very happy once claims about improved GC performance turn into actual reality for my workloads.
What is "pretty minimal heap wastage"?
As far as I can see, ZGC (which is currently marked as experimental) doesn't give any specific performance guarantees. It'll be interesting to try.
"How much headroom is needed very much depends on the allocation rate and the live-set size of the application. In general, the more memory you give to ZGC the better."
I don't think the CPU overhead is that significant. The memory storage overhead is significant, but that's "solved" by just requiring more memory. I guess we can all thank Java for keeping the DRAM business in good shape.
I'm not talking about what's optimal or efficient, I'm talking about what's evidently "good enough" in the real world.
All GC overheads obviously depend a lot of the specific workload, but if I'm provisioning for a varied workload I would assume 20% CPU overhead and 100% extra memory.
Whether or not that's good enough depends on the task as well as on your margins, business model and competition.
The cost of hosting grows roughly in proportion with memory capacity (Yes I know it's more complex and nuanced than that).
If you deploy on user provisioned hardware (such as on mobile devices or existing/aging PCs), using half as much memory and significantly less CPU/battery than your competitors may give you a competitive edge.
> I'd love a functional language that had build tools as nice as rustup and cargo.
For what it's worth, speaking from experience on Ubuntu, stack for Haskell has worked just as flawlessly for me as cargo has for Rust. (I might get some flack for this, but I'd encourage one to ignore the existence of cabal as much as possible for Haskell in 2020 and beyond.)
I'm quite happy for people to acknowledge the existence of stack, but I think it's worth pointing out that Cabal has worked flawlessly for me since version 3.
Indeed I'd place Rust as an example of a language that got it right. Sure, Rust isn't functional, but it's confusing on first usage, so close enough :D
In all seriousness, the big issue that functional languages have to get over is that most programmers are not great mathematicians, so declarative programming feels very weird and confusing. With Rust the big issue is all the rules about memory. How did Rust solve it?
For one, they made the language as familiar as possible. Rust's syntax is extremely close to C/C++, even if the semantics aren't. As much as PL people claim syntax doesn't matter, it does. ReasonML is a project with a similar philosophy.
Next, they put a lot of work into documentation and explanations, especially at the compiler level. Rust's compiler messages are fantastic and often anticipate beginner mistakes. I'd love a functional language that detects when the code looks kinda imperative and gently guides you towards the functional option.
And finally, they had a killer app like Wadler mentions. Performant memory safety is pretty hard to argue against. Even a manager could see the potential upsides. I wonder what sort of killer app one could create for functional languages? Reason with ReasonReact could have robust UI as one, but that's still not as good of a sell as performant memory safety.