I would consider myself an intermediate Haskeller, yet I’m more than a little afraid to use Haskell in a commercial setting or for anything bigger than a toy project because my impression is that it is very easy to shoot yourself in the foot by accident with Haskell and wind up with problems that (seem to me) can be very difficult to diagnose. I’m mostly talking about runtime pitfalls stemming from things like lazy IO and memory leaks from piling up unevaluated thunks. Can anybody share their experience of working with a large Haskell codebase without a Haskell expert on hand to catch any pitfalls as they happen or to bail them out if it comes down to trying to understand a memory profile? Am I just overestimating how often these pitfalls come up, or perhaps how difficult it is to diagnose them?
The main reason against using Haskell for mission-critical commercial applications, is the shortage of Haskell programmers generally.
Somebody develops the application then leaves. Now what? I’m in New Zealand: the number of job adverts in the past decade wanting Haskell skills? Zero. So either nobody supporting Haskell apps has left so making a vacancy, or there are no such apps.
I think you are overestimating. I started writing Haskell commercially way before even understanding how do-notation works, and still I do not recall a single case of memory leak from piling up unevaluated thunks. To be extra safe, follow Avoiding space leaks at all costs and you’ll be all right.
With the advent of remote working there is no shortage of Haskell workforce worldwide.
So perhaps I’m old-fashioned, but (as a manager of programming teams) I expect the Analysts/Programmers to front up to the users, and sit with them to understand requirements.
I’ve tried the remote working model. Disaster. Since the programmers wouldn’t leave Thailand, we eventually flew a couple of key users to them. Things improved for a short while. Then resumed the disaster after the users came back.
And the BAs-here-programmers-in-India was also a disaster. The programmers might have been at a cheap hourly rate, but the BAs took 4 x the hours to write the spec in enough detail, and still the programmers took 10 x the hours because of ‘imprecision’ in the spec – which were allegedly all because our users weren’t explicit enough. (No I do not expect to have to pay someone (from an allegedly NZ-based software house) to explain to them how GST works, and why the data model for Sales Tax won’t adapt.)
Memory leaks caused by lazy evaluation are mostly scars from the past, when application routinely operated data amounts exceeding RAM. If you were not careful enough, your app could get out-of-memory and then boom. Today, when most of applications can put entire DB in memory without a sweat, retaining data longer than strictly necessary is rarely a problem as long as it gets garbage collected eventually.
Thanks for the replies! I’m glad to hear that my fears are overexaggerated! I use F# and PureScript mostly at work, so I’m not terribly concerned about the shortage of Haskellers. I’m sure there are far fewer PureScripters than Haskellers in the world.
I am using it on business critical services and never regretted the choice. Type safety gives me some peace of mind.
Also compiler assisted refactoring is Haskell’s killer feature.
The expert is useful for navigating cabal/stack and nix or not, setting up a fast CI process, and knowing which Haskell parts to avoid (such as outlined by snoyman blog articles). I don’t think it’s necessary, you just have to do a little more reading and research alone without an expert.
Depends what you write. It’s impossible to understand performance intricacies for haskell beginners. Even experts struggle.
Reading blog posts about it might help, but in the end it comes down to intuition and understanding how GHC works.
In addition to what @hasufell wrote, I think it’s important to learn how to profile and optimize your applications. I have been coding Haskell professionally for 3 years, and I still struggle sometimes. If you are interested, I compelled some notes and links about profiling here . The good news is that lately, more and more blog posts are being written about it and GHC has improved considerable at outputting such information.
Apart from that, it also depends on the application you are working on. In some applications, you can get away without being proficient in the language, but others may require quite the expertise. GHC can be blazing fast, but it usually requires a lot of time and an expert hand. Sometimes, it is worth considering using another language when dealing with such tasks.
I would suggest to start easy with a non-performance critical service where you can experiment and learn. There is nothing to be scared of!
You seem to equate today’s distributed work with outsourcing to cheap countries. As Bodigrim wrote above companies nowadays have the luxury to hire haskellers worldwide. This however should not mean cheap labour! You get what you pay. I’ve built a high-performing distributed haskell team at work which i’m immensely proud of and i could not have done it without hiring worldwide. In addition your company needs to be set up for distributed work otherwise you can have the best team you’ll still fail. This however is not that difficult in 2022 (covid having been a forcing function for most).