How much do you think a better interpreted mode for Haskell would work? GHCI isn’t the best, and it doesn’t optimize well, but if you want to compete with Go in terms of build speed, the best way to get around Haskell’s poor compile times is to have a strong interpreted mode; i.e, load the project into GHCI, then go hack in interpreted mode to get around the crappy compile times.
I use GHCi in -fobject-mode and it’s pretty fast. In interpreted mode it will take several minutes to fire up GHCi, in objec mode it’s only a few seconds.
20mn to compile the full project, but that’s once in while.
The novelty budget is better translated as ROI. Haskell may be a nice dainty language for people to play around with, but it has not shown a proven ability to deliver business promises at a higher ROI. Using Haskell means you get longer onboarding times, more time spent on R&D, more time spent vetting libraries, more time spent refactoring, more risks with ecosystem and tooling churn, but does all of that really lead to faster delivered features and lowered development costs ala the lisp/python/ruby/go effect?
Unfortunately for companies betting on haskell, its not apparent that this is happening, and the cost spent to even breakeven is already prohibitive for most smaller companies unless they stick to a tight discipline of using Simple Haskell or some variant.
2 Likes
does all of that really lead to faster delivered features and lowered development costs…?
In my employer’s experience, definitely. We do cultivate a Haskell dialect, but not down to strict Haskell98 or Simple Haskell or any other specific initiative. We allow things like lens-within-reason and use generic-lens with -XOverloadedLabels to make records much nicer, but we often avoid heavily GADT-based or typelevel solutions if they seem too complicated.
The reliability of software we write in Haskell has been much better for us compared to equivalent code written in Ruby, and even basic features like completeness checking of patterns or liberal use of newtype help a lot. Many services don’t need maintenance beyond a quick recompile to get the latest dependencies, and then they just keep on working. On the library vetting front, we found that Ruby or JS libraries actually need more thorough vetting than the Haskell equivalent. A Ruby library that hasn’t been touched for six months could be dangerously outdated, while a Haskell library that has been untouched for three years could well be complete.
As for ecosystem and tooling churn? Hasn’t been a problem for us. Besides, the JS ecosystem is famous for its rate of library releases, and I’d worry more about Python inventing new build tools.
Yes, sometimes we have to write our own web service bindings, but that’s generally been fast enough when we had to do it (thank you, servant-client), and in other languages we’d sometimes find ourselves doing that anyway because we couldn’t trust the existing libraries.
9 Likes
I concur with @jackdk ; in my experience (I wrote about it here), we were able to calculate the cost of dynamical typing / non-null-safety and found it to be very expensive. Using Haskell (as we’ve started doing) will objectively pay for itself. This may not be applicable to all industries, though.
4 Likes
Being the advocate of the devil, cost is much more than just developper cost and bug cost/lost.
You’ve got hiring costs, wages cost. What happend if in n years the main Haskell devs leaves or threaten to do it unless they get a significant pay rise ? How fast can you replace a team, what happen in the mean time. How does that scale (develope wise) etc …
There are long term costs which you can’t predict until you actually survived a few years. I’ve heard that 90% close within 5 years.
If you are a small company and manage to survive, chances are that you’ll get bought buy a bigger one and they rewrite everything in another language …
What I mean is yes in theory Haskell should pay off, but the proof is in the pudding and if Haskell was a silver bullet every big company (which are aware of Haskell) would be using Haskell more than they do.
Don’t get me wrong, I’m the boss of a company and we use Haskell and it pays off, but that doesn’t mean it can be generalized.
4 Likes
Re: hiring, fungibility; I think this is probably because this has not been a focus of the Production Haskell community.
In general, Haskell is seen as hard to learn, and a way to get a hold of highly experienced and talented Haskellers, then maybe make them write Rust ;).
However, what would happen if we tried to focus on quickly training Haskellers?
Serokell’s certification program actually presents a fairly good opportunity; i.e, if people were to experiment with speedrun-training on Serokell’s Proficient level, what’s the shortest we can get the time without completely throwing “Avoid Success At All Costs” out the window? 2 weeks seems to be the minimum thus far, possibly involving talented programmers and reduced idioms, but what happens if we can get it down to 1-2 weeks?
That makes Haskell developer fungibility much better; you will still need senior Haskell developers who know what they are doing, but if the request is to give them cats to herd, you can just hire an “ordinary intelligent developer” and push them through your training program.
1 Like
I don’t think speed is what matters here. And the reason Haskellers are popular in industry (even for non-Haskell positions) is because they’re deemed self-driven, excited and knowledgeable engineers.
We need better education material. But I don’t think we should optimize it for “learn Haskell in 2 weeks”.
6 Likes
Speed does matter because, one, firms that adopt Haskell do not want to take 6 months to retrain their staff or hire a new development team.
Moreover, the current Haskell brand image and recruiting base is great, but as with the Rust vs Haskell thread, we need to locate demand for new or otherwise overlooked use cases. The old use cases saw limited success and got a bit stale.
I agree, however, that a book titled “Learn Haskell in 2 Weeks” would be harmful, as creating a competent Haskeller from that would be impossible, and bad Haskell code is bad for the brand. There are already similar books, aimed at people who are trying to pass a Haskell class, like Haskell From The Very Beginning.
What is needed isn’t a book targeted at learners, but rather teachers: “Teach Haskell in 1-4 Weeks” is a lot more useful since firms want rapid onboarding, and lacuna and misunderstandings can be handled through pair programming and code review over time greater than the 1-4 weeks promised.
3 Likes
Haskell brand image … is great
Unfortunately outside of Haskell blogs I’m seeing the opposite.
When I’ve asked tech leaders – people who choose platforms – about Haskell’s reputation, its branding is bad: Bloated, academic, impossibly complex, not worth the pain.
So there does appear to be a branding issue, at least among some tech leaders.
Related topic arose around the Haskell survey, it needs to look beyond the immediate fan community.
9 Likes
I’m not sure that feedback carries a lot of value.
There’s really not much Haskell can offer to people who just need an ok general purpose programming language. It would indeed be an odd choice.
And I’m being fairly diplomatic here with my wording.
4 Likes
It’s important to not lose “avoid (success at all costs)” in these discussions.
There are a lot of reason tEcH lEaDeRs don’t like Haskell that are core values to the language. I hope we never compromise them and create some bleh language. Tech leaders aren’t gods they’re just people who honestly make dumb decisions all the time lol. I guess years in the industry inevitably erodes the respect 
5 Likes
I think my industry experience matches yours.
6 Likes
I like to be cynical too, but for a community has gotten this large this attitude can really prompt the existential question. Or are we all okay with being industrial renegades?
I wish this thread dies out but I am contradicting and adding fuels…
Could someone just close it with a hopeful tone?
2 Likes
Question: If Hasura was instead switching to the likes of e.g. Agda, Idris or Epigram…would this thread even exist?
as far as my math goes: if false all true
I use to think the same until I set up my own company. At the end of the day, a company is black box with money getting in and money getting out. The goal is to make the outs bigger that the ins and it’s hard.
So what ever one thinks of its management, the simple fact the the company exists and is able to pay its developpers, means that somenone in the chain of commands is doing it right.
Even though it involvesd hiring a crap teach leader, chosing the “wrong” language etc … If the company is making money, they made the right decision (for them). If they made the wrong decisions, well, there will be no developpers moaning about anything.
3 Likes
You’re aware most tech companies don’t make any money (profit) for years, but burn investments?
Even Grab, one of the major tech company players in SEA, is still not profitable.
So the fact that you’re working at a company that pays their engineers and doesn’t go bankrupt usually has very little to do with their tech decisions, but whether they still attract investors.
Those bad decisions often don’t show significant effect during chaotic startup phase, but manifest much later.
Note: I’m not advocating for companies to use Haskell. I’m questioning whether the average tech lead decision has any meaningful feedback value for us. You could as well ask the average programmer what they think about Haskell and most of them will either say they never heard of it or it’s some academic nonsense.
So yes, surveys that target existing or previous Haskell users have more value.
1 Like
I would be interested in what is actually the percentage of dev working for “tech” companies.
All the companies I worked for where not tech companies and where actually making profit.
In fact, I actually don’t know personnaly anybody working for a company burning investements.