Did you know that we use Haskell in production at Tesla for some critical tasks? We're currently looking for an intern for the fall session (roughly Sept to Dec 2025). If you're interested and graduating in December 2026 or before, please apply on the careers page here: https://www.tesla.com/careers/search/job/internship-haskell-software-developer-vehicle-firmware-fall-2025-240953

Hello you all.

I watched a video by Alexis king about laziness but I don’t have patience for videos so didn’t finish it.

Can you please give me an idea of what benefits laziness brings to Haskell? And can you share of a paper or a good blog post that talks about this? Thanks

I've only really heard people complaining about Cabal. Surely we could all agree to use (and develop if necessary) some other tool? Why keep using Cabal? What should we use instead?

Edit: or just work to improve Cabal! That's probably the best option (yes, I know there are people working on it right now, but perhaps be more radical)

Edit 2: a lot of people seem upset about the title of this post! I can't change it, but I apologize. Not everybody hates Cabal - in fact it looks like the majority is okay with it. Honestly, this post wasn't intended to be a jab at Cabal, but to explore what its problems are, and possible solutions for those problems.

I come from C++/C/Verilog/JS/Shell/SQL background, doing work designing AI software and hardware. Looking at Haskell it seems like it's a quite hard to learn language because every term is described in a very abstract way (type constructors/data constructors/etc). It also seems like the resulting binary programs would be much slower and much larger than in C++, and I value performance a lot because I am in an HPC industry.

Is there a class of problems that would be hard to solve in C++ and easy to solve in Haskell?

Why do people like Haskell? (I assume some people do.) What are the "selling points" of this language? What Haskell example should I look at to fully appreciate the language? (Like: Wow! This is so easy in Haskell and would be such a hassle in C++.)

Like, is Haskell particularly more Math than programming in general? If so, then how so? Like, what the fuck does Math have to do with class Monad, really? Can't someone read those words without their Math phobia going off? I just don't get it.

Python is 100 MB, Chocolatey needs 362 MB for msys64 but bootstrap-haskell-1.0.1 needs for msys64 2.51 GB and the code in GHC is more difficult to patch and add features than re-write tools. Haskell lost its logical appeal with its simplicity long time ago but the speed of GHC continuos growth is on colission with logic.

I used to feel that Yesod had a lot of promise. But it has really failed to deliver. Major failings:

• still no blog system, after years of discussion about it. Never mind things like CRUD screens. Shouldn't these be derivable from the Persistent model?

• highly, highly opinionated at the core level. This wouldn't be so bad, but it's also wrong very often. I know this is just my opinion. But I also know that when I make opinionated choices in my libraries, I do them in type classes and provide a way to override my choice. Yesod abandoned that principle a long time ago.

• Highly inconsistent and type un-safe interfaces. This is especially scary in the Auth system. A "Creds master" is a text token and list of text key-values. The semantics of the key-value pairs depends on the Auth plugin that sets the Creds master. Really? String typing? In 2014? In a strongly typed language? There are a lot of examples like this, especially in the Auth system. The bizarre thing is, Yesod already uses TypeFamilies all over the place, so there is literally no reason to pass around a blob of texts.

• type safe URLs are over-hyped. Especially for a "RESTful" framework. Type safe URLs just aren't useful when your hrefs are dynamically generated by JavaScript.

• Having a "Foundation" module splits your project in two -- the stuff that imports Foundation, and the stuff Foundation imports. This division is really painful. Moving code from one side of the Foundation to the other very often breaks code, just because the Import.hs module doesn't work.

• Actually, the whole Import idea is misguided. I end up having to import parts of Prelude constantly, especially on the framework side of the Foundation boundary.

• There are like 5 different ways to load a widget. The pro's and con's are not explained anywhere, including the source code.

• The documentation is actually really really bad. Consider:

  -- | Determine the ID associated with the set of credentials.

  getAuthId :: Creds master -> HandlerT master IO (Maybe (AuthId master))

  -- | Retrieves user credentials, if user is authenticated.

  By default, this calls defaultMaybeAuthId to get the user ID from the session. This can be overridden to allow authentication via other means, such as checking for a special token in a request header. This is especially useful for creating an API to be accessed via some means other than a browser.

  maybeAuthId :: HandlerT master IO (Maybe (AuthId master))

Notice that maybeAuthId does not return a Creds master. Notice that 'getAuthId' determines the ID associated with a set of credentials. Notice that this means having to read the spaghetti code to figure out what is actually going on. This is even worse, since the semantics for credentials aren't even defined in Yesod.Auth. They're defined by plugins.

• The documentation is even worse than that. If you Google for Yesod function names, Google ends up pointing you toward old versions. Especially since a lot of the functions have become private in newer versions (so they don't get documented on Hackage). Fair enough, but Yesod was always a bit on the spaghetti side, and this just pours on thick, inky squid sauce. In other words, obscure.

• Multitudes of special cases. Why is whamlet a widget quasiquoter, but not julius?

• The community is not very good. It's the weakest community I've seen from a "major" Haskell project.

Strengths:

• Hamlet is sweet. I actually do like type safe URLs. And the templating language is nice.

• Persistent: I can take it or leave it, honestly. But it's decent enough to count as a strength.

• esqueleto: an "associated" project.

I'm 100% sure there are other strengths. And that I am feeling uncharitable this evening.

Is Yesod a viable platform? Will it ever be one? Or is it just a vehicle for Michael Snoyman to write a book?

EDIT: Vibe coded, not bragging about the code, just sharing the tool.

husk - A lightweight interpreted Haskell implementation compiled to Chez Scheme

The size of software packages I needed to install in order to use Haskell for daily scripts bothered me many times, especially when all I wanted was to solve a problem without the need for advanced features, or when learning the language.
At the time the only practical option was GHC because the others were obsolete or incompatible with the learning materials.

Now that AI is here I tried to make my wish come true, and I think I succeeded in making (vibe coding) something that is useful for me, and maybe for others.
Introducing husk, a new implementation that tries to be small and compatible with learning materials, and doesn't try to implement all Haskell features or be compatible with existing popular libraries.

If you have serious work use GHC.

The point of husk is to be small enough to run everywhere Chez Scheme runs and be there for you to study with, or write daily scripts.

Now I'm not advocating for vibe coding, nor am I sure that it's very good (I'm not a Haskell expert so it's hard for me to judge though I ran many automated tests). All I'm saying is that it's small (1.3MB) and runs all LYAH and a few other popular learning materials exercises.

Easy to install on Arch Linux: AUR

Haskell gets good marks in this person's test.

Based off the Zen of Python

Beautiful is better than ugly
Declarative is better than imperative
Minimal is better than redundant
Redundant is better than incomplete
Folds are better than recursion
Lazy is usually better than strict
Clear types count
Special cases aren't special enough to unsafePerfomIO
Because practicality rarely beats purity
Errors should never pass as _|_
Use Maybe instead
In the face of ambiguity, improve your types
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're a category theorist.
Now is better than never.
Although never is often better than *right* now.
If the monad is hard to explain, it's a bad idea.
If the monad is easy to explain, it may be a good idea.
Dependent types are one honking great idea - let's do more of those!

Any changes you would suggest (some lines I had trouble with).

EDIT: Based on suggestions, I have a couple of alternate lines that could be used.

There should be one-- and preferably only one --obvious way to do it.
Although it might not be obvious what counts as one way (optional: unless you can know when diagrams commute)

Because practicality is gained from purity

Yeah, if you could just, go ahead and release GHC 7.8.1, that'd be great!

So i have been researching Cardano for a few months and was curious about the haskell programming that it uses for Dapps.

What do you think about Cardano using haskell programming?

What do you think about Cardano the project itself?

Any intresting projects you working on?

Thanks for the read!

Reasons.

Some people like to say that Haskell, in addition to being a function programming language, is the worlds best (or finest) imperative programming language. The link above are some reasons it's not. I'd love to hear what other Haskellers think about these reasons that it's not. Did I miss something?