So the refrain goes. Making that statement itself can be a political act, an attempt to gather support to one’s cause. From my point of view I don’t see how that line of thinking is beneficial to the Haskell community, however.
4 Likes
Rust certainly has its allure, and I tried to like it enough to drop Haskell, but for myself it represents a lateral step rather than a step forwards. The tooling is awesome and package ecosystem is large, but then other things are worse, like the lack of exceptions, concurrency and garbage collection. All of which are outstandingly ergonomic in Haskell. In Rust, async/await, errors, and borrowing are all awkward and leave their grubby mark all over otherwise simple code. For all its warts, which are well-described in that post, I haven’t yet found something I like better than Haskell.
12 Likes
I meant to reply to the original post, but clearly the discussion digressed so far away that my answer would be offtopic at this point. Could we all be mindful that linear threading model is not friendly to tangential discussions and create separate topics for them?
6 Likes
Please post your thoughts. I for one would like to read them, and I can’t think of a better way of keeping comments sections on-topic than by posting on-topic comments.
5 Likes
I have PM’d OP when he first posted, pointing out to him that his (interesting!) column was prone to develop into a discussion on the larger Haskell ecosystem. I have asked him whether that was fine or if he preferred a somewhat stricter moderation for tangential replies.
He said he was fine with a more general discussion, and as long as he is fine with it, I am prone to have a hands-off approach.
If you feel some messages stray from “tangent but relevant” into off-topic land, flag them so moderators can act on those.
5 Likes
As I mentioned earlier, modularization cannot be perfect - this is part of why manufacturing is complicated, after all. Further, each application running on an OS already provides good enough modularization, where each production department (or entire company) would focus on one program. You do not need this strict modularization inside the department.
Personally I dislike OOP quite a lot, and I prefer FP if anything. What I said was more of an observation. A modified version of OOP seems to be thriving, which does exclude inheritance but keeps the overloading and polymorphism. Recent success of Go signifies that, with Python expanding further. I cannot spot any glimpse of OOP fading away anytime soon, other than handful of opinionated blog posts like that.
…just like Rust, Haskell and (I think) Idris - no notion of object-based inheritance, only overloading and polymorphism. But based on your prior posts, including those about Haskell and Rust:
I received tons of feedback on my OCaml vs Haskell blog post! Thanks a lot to all who read and shared their thoughts 
Using the feedback, I improved my post by:
- Changing the most triggering exponentiation example to a different one
- Added links to all discussions of my blog post all around the Internet
- Changed feature from Laziness by default to Composable laziness
- Added
topiaryas an OCaml formatter - Changed the suggested TOML library from
To.mltootoml - Changed the suggested AWS library from
ocaml-awstoawsm
As always, I’d appreciate your feedback!
@Bodigrim I’d be happy to read your and anyone else’s thoughts on my blog post!
If not here, you can all reach out to me in other places to share what you think 
In the Haskell community, I often had the impression many people have a lot to tell but rarely feel heard. I’m glad to see that the discussion around my blog post gives people an opportunity to share their feelings. Reflecting on your experience is important too! In the end, that’s what I did in my blog post 
10 Likes
- Work hard to knock down obstacles to using Haskell in mission-critical applications.
I’m optimistic that the Haskell community can make this happen.
With the renewed focus on stability of the language, compiler, and base-library, the community has shown that it is listening to its users. What might help with momentum and actionable goals is to measure the impact of these initiatives. Perhaps, as an example, querying Hackage or Git on how “fresh” the packages are and how often they are updated for GHC compatibility reasons can give some insights as to the burden package maintainers face and whether the situation is improving or not.
From what I gathered, the next big piece of obstacle is addressing the incidental complexities of using Haskell due to it being such a deep and feature rich language. As a newcomer myself, I think the most prominent issue here is there’s no de facto, agreed upon best practice among the community, so it’s been a dazzling and confusing journey for myself. Seasoned individuals and organizations have their own list of do’s and don’ts, but for increased adoption, it’s very helpful to have an authoritative source where newcomers can learn about best practices (or at the very least, safe practices), so we don’t shoot ourselves (and likely, others in the foot), and can produce libraries that are easy to maintain and easily consumed by others (e.g., not forcing the users to use a specific effect system, which could conflict with other libraries used).
Best practice topics like, which extensions are safe/recommended to use, when to use type-classes, when to use type-level programming and what are its associated costs, which parsing library is a safe/conservative default to start out with, what effect system to use; library design best practices like what constitutes a good functional API design, when should you expose fancy Haskell features to end users … etc., can guide newcomers in a direction that both enriches the ecosystem and build momentum in a newcomer’s journey to proficiency.
In summary:
- [Code] Measurable decrease in the overhead of maintaining Haskell packages
- [Documentation] Best practices on the following topics from a unifying and authoritative source:
- Language features
- Library selection (better distinction between experimental and production stable packages)
- Sensible library/API design, especially when it pertains to Haskell/GHC’s ecosystem.
These are the areas that I feel can help drive adoption and allow Haskell to be selected in more mission-critical applications.
8 Likes
…I thought that problem was already solved in 2015:
That it was a relatively simple and compact change to GHC (only 20 files affected) would have to be one of the more salient examples of Haskell’s efficacy. In comparison, it would be interesting to see what would be required to add either of -flazy or -fnonstrict to the likes of Standard ML, OCaml, Go or Rust - perhaps the implementors of Lazy Racket can be of assistance…
1 Like
Conspicuous failure to die, and actually some significant and sustained improvement of long-standing weaknesses.
There’s another reason why Haskell won’t be dying any time soon:
- MONAD[CLASS]
If Haskell did disappear, designers and implementors of new languages would have to provide their own explanations of the monadic interface, and possibly their own monad tutorials! (unless someone remembered to do some archiving ;-)
That’d be a very unfair comparison given that Strict doesn’t make Haskell a strict language in any reasonable sense (see this example), it just adds bangs to new definitions, i.e. it’s basically syntax sugar. Also going from lazy to strict is generally much easier than the other way around.
That’d be a very unfair comparison […]
You mean like the ones I’ve responded to here:
-
https://discourse.haskell.org/t/one-billion-row-challenge-in-hs/8946/199 -
https://discourse.haskell.org/t/pre-hftp-ghc-should-offer-low-level-logging-infrastructure/9159/27 -
https://discourse.haskell.org/t/since-haskell-has-linear-types-so-we-can-track-resources-why-cant-we-disable-the-gc-like-in-ats/7951/8
where:
-
Haskell is being compared to some ol’ warhorse,
-
or Haskell should have some (more) of its “features” *
…amongst others? Yeah, this Discourse seems to have a great many unfair comparisons.
* …apart from it’s style of records, apparently.