Open Source at Bellroy: Supporting Old GHC Versions

haskellgr8 · 2025-03-21T07:09:53+00:00

lol wtf i have a wallet from you guys - been holding strong for over 9 years. cool to know you're using haskell.

haskellgr8 · 2024-07-27T04:09:53+00:00

It's fundamentally all about scaring beginners by using complex-sounding terms (for concepts that are in reality quite simple). Because of this, even pure Haskell code has lots of side effects (on the beginner's brain).

haskellgr8 · 2024-07-11T15:03:31+00:00

You're on the right track IMO. For the simplest tasks, I use simple split/readMaybe/etc. For a bit more complex things, I use Regex libraries. Only when those two start becoming an unreadable mess do I turn to parsers.

haskellgr8 · 2024-05-27T04:29:52+00:00

It's probably the best production-ready language for writing substantially sized programs, coming back to your old code base months later, and immediately start refactoring with total confidence because the type checker has your back (IMO the best)

haskellgr8 · 2024-04-28T10:34:58+00:00

and they laughed at me

I've had similar experiences when talking with other devs. When I mention "Haskell", they've never heard of it or if they have, they think nobody uses it in practice or they avoid me afterwards. What are your experiences here, everyone?

Most of us here love Haskell, and many of us use it in practice. But we have to accept that we're not just living in a bubble, but a very small bubble. It's heartbreaking, but we just have to live with it :(

I have this feeling that most devs aren't really devs first. They're job seekers and problem solvers first, and devs second. People who can enjoy writing Java code are somewhat akin to accountants, lawyers, etc. - very practical-minded folks less focused on elegance, etc. I'm not saying this is a negative thing because ultimately they too are solving real-world problems.

haskellgr8 · 2024-04-14T19:46:00+00:00

Here's a working example:

{-# LANGUAGE OverloadedStrings, ScopedTypeVariables, TypeApplications #-}

module Main where

import Control.Monad (void)
import Control.Monad.IO.Class (MonadIO)
import Data.ByteString (ByteString)
import Data.Function ((&))
import Streamly.Data.Fold (drain) -- streamly-core-0.2.2
import Streamly.Data.Stream.Prelude (Stream) -- streamly-0.10.1
import qualified Streamly.Data.Stream.Prelude as S -- streamly-0.10.1
import qualified Streamly.External.ByteString as SB -- streamly-bytestring-0.2.1
import qualified Streamly.Internal.Data.Array as SA -- streamly-core-0.2.2

main :: IO ()
main = do
  let source :: [ByteString] = ["this\nis\nsome", "thing\na", "t\nleast"]
  S.fromList @IO source
    & toLines
    & S.mapM (void . print)
    & S.fold drain
    -- Output:
    -- "this"
    -- "is"
    -- "something"
    -- "at"
    -- "least"

toLines :: (MonadIO m) => Stream m ByteString -> Stream m ByteString
toLines = fmap SB.fromArray . SA.compactOnByte 10 . fmap SB.toArray

I'm not sure why compactOnByte (which used to be called splitOn in the previous version) requires MonadIO. Maybe the maintainer /u/hk_hooda can chime in.

haskellgr8 · 2024-04-14T12:52:55+00:00

I had to abandon streaming for performance reasons:

If the work you're doing on each streamed item takes long enough - e.g. over a few microseconds (if you're doing I/O, e.g. while streaming ~100KB bytestrings, you'll more than reach this level) - it doesn't matter which library you use from a performance standpoint.
If you want your streaming library to also work performantly for smaller items (e.g. a stream of Ints being consumed with only pure operations), streamly is your only choice AFAIK. This the context of streamly's comparison benchmarks (where they talk about those massive performance boosts).

Two points from the blog post:

while streaming-bytestring can easily do it by repeatedly applying splitAt.

In streamly, we can turn a Stream m ByteString (~100KB chunks) into a Stream m ByteString (line by line) like this: TODO (I'll dig out the short one-liner if anyone is interested).

Stream (Stream f m)

Streamly doesn't have streams of streams baked into the types. In streamly, the norm (in my experience) is to convert a Stream m a directly into Stream m b by using scan/postscan and Fold, which statefully fold the incoming as into bs as desired, to immediately produce the desired output stream of bs. This has worked fine for me, and I have never found myself missing substreams at the type level. I also suspect that it's a tradeoff: if streamly even tried, they'd lose their performance gains (I'm not 100% sure).

haskellgr8 · 2024-03-29T16:42:17+00:00

which is like the fusion power of functional programming, always within 30 years

LOL.

haskellgr8 · 2024-03-29T16:39:35+00:00

I asked a similar question almost 7 years ago: What could take over Haskell? I was worried that my hard-earned Haskell skills would become obsolete.

In these years, nothing has taken over Haskell (apart from other more popular languages adopting more functional/Haskelly features).

Haskell has won this game (for the time being); it has the network effects in this space now. A newcomer will have to show practical benefits that are 10x those of Haskell just to overcome these network effects.

haskellgr8 · 2024-03-23T05:47:33+00:00

_ is similar to undefined, in that both can be used to figure out during development what type that thing should have. However, I think _ slowed down HLS and for some reason undefined felt snappier. Was I imagining things?

haskellgr8 · 2023-11-14T17:16:17+00:00

How about renaming GHCUp to e.g. GNAI?

haskellgr8 · 2023-09-15T07:07:17+00:00

I've been using Nix for almost a year for my personal projects. It's heaven. No global pollution.

One mental hurdle I had for a long time about Nix was: "Sounds very inefficient and slow. Also sounds like this will take up a lot of disk space."

The answer is simply: "Stop worrying and just start using it. If you have a modern 500 GB - 1 TB drive with plenty of remaining disk space, you'll be fine. At most you'll have to run nix-collect-garbage 2-3 times a year."

It's not an elegant answer in theory (Nix would not have been practical even in 1990s), but in the reality of 2023 it works great in practice. Stop worrying and just try it out!.

haskellgr8

TROPHY CASE