So, to summarise:<p>- It is an accomplishment if you get your basic project setupped in 2 weeks<p>- It is very hard to make popular libraries work together<p>- 1/3 of the popular libraries are not well maintained, there are no docs and maintainers do not reply to PRs<p>- It is hard to use latest GHC versions because of the previous problem<p>- It is hard to get additional devs<p>- Compile times are ok-ayish but can be a pain<p>- There is no good IDE and refactoring<p>But it is still somehow "the best general purpose language"?<p>And don't get me wrong, Haskell is on top of my list of purely functional languages that I would like to learn.<p>BUT, if I want to build an actual app and try to earn money from it I would just use something that is very popular, well maintained, easy to push features, easy to deploy and find additional devs for. For me it is ReactJS on the frontend and Kotlin on the backend. OR it is a jackpot if I could just make it in something like NextJS. Haskell can wait for when I earn enough money with other languages so that I can just play with it and satisfy my own engineering itch without any production expectations I have from other languages.
What scares me about Haskell is that it seems even people who used it extensively for a while call themselves "intermediate", and still find themselves in Haskell-shaped holes.<p>If something breaks and I need to fix it <i>now</i>, I don't want to be fighting with a language that says, "no-o, no shortcuts, use a proper monad", or takes years to master to that level.<p>Maybe I'm just missing the point.
> So after about 8 months of work I was ready to start getting users.<p>I caution readers looking for advise on building a start up. Early on, this reads as a post celebrating the joy of programming. Which is great! Working on something you enjoy can be personally fulfilling, but that doesn't mean that it's a start up.<p>At the end of the day, a start up is a business, and a business needs to make money. The ultimate validation is finding users willing to pay for your service. Waiting 8 months before finding users is a huge risk, and signals that this is is a fun personal project that may generate profit if it happens to find product/market fit.<p>The author's closing remarks address the idea, but I think they're a little late for a post about building startups.<p>> Have I spent too much time geeking out on Haskell and not enough time thinking about the idea? I guess we will see .
Tooling is so critical to the uptake of a language it surprises me that more effort isn't expanded in that area for more niche languages that want to see their popularity increase.<p>I guess it's a 'chicken-and-egg' problem. Popular languages get tooling investment because they are popular.
Deadpendency sounds nice, and may be profitable, but it's less a "startup" in the sense of a growth business, and more an indie lifestyle business. It's a GitHub app, like people who sell Word Macros to lawyers.
There's a good a
chance it would be obsoleted by a small open source project next year.
> (...) making my types strict by default with the StrictData extension. Additionally, Haskell has lazy linked lists as the default list type. Instead I used a strict list type.<p>Is this the norm for production-ready Haskell codebase - basically throw away laziness?
I learned Haskell for a year and went into various books. After that I tried to contribute to a relatively simple open source projects and I realized the real world Haskell is so different than books, then I got discouraged and stop. These days I wanted to pick up Haskell back again, is there any updated resource you can recommend for doing real world Haskell?
What if the project became popular, scaled up and the original developer needed help with it? As Haskell is a niche language, wouldn't it be harder to find Haskell developers to come on board?
I was curious how Haskell helped with the peculiar challenges of building a startup. Did it make it easier to validate business ideas and pivot over time towards profit compared to other languages?
GitHub offered something called Dependabot -- and the point I want to make here is that I've see SOOOOO many semi-active projects (like, dozens of stars and some downstream users) which just ignore the PRs opened by Dependabot.<p>These maintainers don't even switch off Dependabot, not to say merge the PRs that updates dependencies with potential security risk. And it bothers me a lot....
Except for the pyramid of doom (which you can avoid with good architecture) this reads more like "why to use go over haskell" (at least for me as someone familiar with go).<p>I started writing go at the same time i started to work on production with it. In 2 weeks time i had a working service and learned the language, instead of the setup.<p>Interestingly enough the main problem was the pyramid of doom though (due to various http middlewares)!<p>Nowadays i don't have issues with the pyramid of doom.<p>Still it seems that in the long run the benefits are similiar, except for the time it took to build it, so if it was fun i think it was worth it.