Commercial Haskell should go after Python / Julia, not Rust

72

This is not a correct story.

I was the person who made Juspay a successful Haskell company from the technological point of view.

When I came to Juspay in mid 2017, there was some experimental PureScript code that didn’t do anything useful. There was an obvious problem: the lack of overall architecture and design of the Haskell-like project. I, being the author of my Hierarchical Free Monads architecture, and the author of Functional Design and Architecture book, proposed my design to achieve their goals:

  • allow for less competent developers to write business logic in PureScript
  • this should not be difficult even for managers to participate in development (and they did!)
  • connect the logic to the other infrastructure in JS and do this conveniently for the business logic writers
  • make the business logic testable
  • …

This is how the Presto.Core Free monadic framework for mobile apps has been born. I designed it using my ideas from the book, and folks from Juspay implemented the connectors to the mobile ui code they had.

Then Presto.Backend was introduced (I participated a lot). It is a PureScript reincarnation of Presto.Core for backends, also uses my architecture.

Then, I and my team created EulerHS for Juspay, a Haskell port of Presto.Backend.

Folks from Juspay were mostly working on the business logic with the tools and project structure we provided them with the frameworks.

This definitely wasn’t “just looked for phrasebooks”, and “just modified code samples”, and “somehow the project worked”.

There were definite challenges that could easily become a stopper for Juspay on the early PureScript ages if not me and my book.

5 Likes
73

Ah, the Erlang gambit.

3 Likes
74

I am doing the very same for my containerized Haskell programs. But it’s a completely different story when you need to bind to glibc, which is typically what you’d expect from a programming language like Haskell with good system programming potential, or simply to write a CLI. If you need to bind to glibc, Haskell suddenly becomes strictly inferior to Go or Rust.

75

You mean you want partial static linking? Or you want full static linking against glibc (I think that’s problematic)?

76

If you statically link against glibc, some function calls will still try to dynamically load certain libraries (for example, things around localisation or domain name resolution), which in turn will try and dynamically load glibc (making it rather pointless to statically link glibc if you know this is going to occur). There are other libcs (like muslc) which don’t have this problem.

1 Like
77

The latter, of course. Imagine trying to ship a fully statically linked program that the (Linux, macOS) user wants to just install and run from their machine (i.e. a CLI). I’ve been there. I think it took me more time to build than it took me to write the actual thing.

1 Like
78

That doesn’t work very well to begin with: c++ - Why is statically linking glibc discouraged? - Stack Overflow

2 Likes
79

Thanks for the correction! That must have just been rumor then; but I swear there’s some firm that picked up Purescript from the “know-nothing” angle.

And while I do know you’re eristic and controversial, thank you for bringing Juspay into the Haskell community!