Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A couple million lines of Haskell: Production engineering at Mercury

blog.haskell.org

Post reply on HN
Print view View original

51–60 of 249 posts

Re: A couple million lines of Haskell: Production engineering at Mercury

#51

Post by sras-me »

alchemist1e9 wrote: post #40
sillysaurusx wrote: post #30

I just wanted to leave a glowing comment about Mercury itself, since this is one of the few times I’ll be able to. I’ve been using Mercury for 5 years. In that time, I’ve been able to wire transfer money without having to worry it might disappear (functionally impossible at certain other banks), created hundreds of virtual debit cards each with their own limit and pulling from different accounts, created dozens of ac…

> I’m convinced the only reason people don’t use Mercury is that they don’t know what they’re missing. Very well could be true because I had no idea who or what they are. Do they have strong low level automation support for the customer programmatically even for personal accounts? I use ledger for plaintext accounting for both personal and business and sync of data is slightly annoying, perhaps Mercury’s products sol…

> I use ledger for plaintext accounting for both personal and business and sync of data is slightly annoying..

I made this to solve it https://sras.me/accounts/

Feel free to use it as it stores data on your browser's local storage only. For syncing between devices, you would be able to use Google firebase's free tier and export your accounts (after compressing and encrypting) there and import from another device. Let me know if you want to try it..

Re: A couple million lines of Haskell: Production engineering at Mercury

#52

Post by qsera »

django77 wrote: post #49
xedrac wrote: post #47

I loved working in Haskell for a few years. I wasn't actively looking it, but the opportunity just sort of landed in my lap. It was exciting and mentally stimulating. But the unfortunate fact is, I am easily twice as productive in Rust as I am Haskell, even after 3 years of nothing but Haskell. There are more pitfalls in Haskell that you have to just know how to avoid. It can be very difficult to digest as the langua…

Is the productivity 2x all across the board, or are there some parts that are less productive with Rust? Also, what do you mean by write-only?

>what do you mean by write-only?

I think they meant that in Haskell it is very easy to write externally unreadable code..

Re: A couple million lines of Haskell: Production engineering at Mercury

#54

Post by sillysaurusx »

alchemist1e9 wrote: post #40
sillysaurusx wrote: post #30

I just wanted to leave a glowing comment about Mercury itself, since this is one of the few times I’ll be able to. I’ve been using Mercury for 5 years. In that time, I’ve been able to wire transfer money without having to worry it might disappear (functionally impossible at certain other banks), created hundreds of virtual debit cards each with their own limit and pulling from different accounts, created dozens of ac…

> I’m convinced the only reason people don’t use Mercury is that they don’t know what they’re missing. Very well could be true because I had no idea who or what they are. Do they have strong low level automation support for the customer programmatically even for personal accounts? I use ledger for plaintext accounting for both personal and business and sync of data is slightly annoying, perhaps Mercury’s products sol…

They sure do!

API: https://docs.mercury.com/docs/welcome

MCP: https://docs.mercury.com/docs/what-is-mercury-mcp

Re: A couple million lines of Haskell: Production engineering at Mercury

#55

Post by dirkt »

bri3d wrote: post #7

> Haskell gives you tools to encode these incantations in types so they cannot be forgotten. This is, for my money, the single most valuable thing the language offers a production engineering organization. Haskell is admittedly, probably the most powerful widely (or even somewhat widely) used language for doing this, but this general pattern works really well in Rust and TypeScript too and is one of my very favorite…

> works really well in Rust and TypeScript too

And of course Rust and TypeScript were heavily influenced by Haskell... they just don't mention it and call things differently, to avoid the "monads are scary, I need to write a tutorial" effect. Though it's less about monads and more about things like type classes.

Imitation is the sincerest form of flattery.

Re: A couple million lines of Haskell: Production engineering at Mercury

#56

Post by SOLAR_FIELDS »

alchemist1e9 wrote: post #40
sillysaurusx wrote: post #30

I just wanted to leave a glowing comment about Mercury itself, since this is one of the few times I’ll be able to. I’ve been using Mercury for 5 years. In that time, I’ve been able to wire transfer money without having to worry it might disappear (functionally impossible at certain other banks), created hundreds of virtual debit cards each with their own limit and pulling from different accounts, created dozens of ac…

> I’m convinced the only reason people don’t use Mercury is that they don’t know what they’re missing. Very well could be true because I had no idea who or what they are. Do they have strong low level automation support for the customer programmatically even for personal accounts? I use ledger for plaintext accounting for both personal and business and sync of data is slightly annoying, perhaps Mercury’s products sol…

I run a small business books using mercury and beancount. The API supports enough operations in the free tier to do so with ease, though mostly I’m just fetching transactions. I do pay the ~35USD / mo for the extended API to get invoicing, though that’s not something a personal user would need

Re: A couple million lines of Haskell: Production engineering at Mercury

#57

Post by myst »

wyager wrote: post #34
miki123211 wrote: post #22

Earlier quoted context omitted.

This isn't specific to Rust or Typescript. You can do this in basically any language. Imagine you have to distinguish between unescaped and escaped strings for security purposes. Even with a dynamically typed language, you can keep escaped strings as an Escaped class, with escape(str)->Escaped and dangerouslyAssumeEscaped(str)->Escaped functions (or static methods). There's a performance cost to this, so that's a tra…

> You can do this in basically any language. You can do it in Assembly. That doesn't mean it's cost effective.

Costs are a skill issue ;-)

Re: A couple million lines of Haskell: Production engineering at Mercury

#59

Post by cubefox »

django77 wrote: post #48
cubefox wrote: post #43

Earlier quoted context omitted.

No that's not right. If you were calling a function which might return null (String | Null), you will already have null handling at the call site, but if you now change that function such that it never returns null (String), you still have the (now unnecessary) null handling, but this doesn't hurt and you don't have to change anything at the call site. Likewise, if you were passing a String to a function that doesn't…

I agree that this can be nice when done right (Clojure), but null is a high price to pay for this convenience. I must admit I’ve never had this problem in application development. In fact, I do want to change my callers because strengthening the contract is an opportunity to simplify the callsites - they no longer have to handle the optionality. The change might carry some semantic meaning too, why are you getting x…

> I agree that this can be nice when done right (Clojure),

I don't think Clojure has untagged union types like TypeScript or Scala.

> but null is a high price to pay for this convenience.

Why would it be? Untagged unions prevent null pointer errors just as much as option types do, only they don't have the discussed disadvantages of option types.

Re: A couple million lines of Haskell: Production engineering at Mercury

#60

Post by bonesss »

wyager wrote: post #34
miki123211 wrote: post #22

Earlier quoted context omitted.

This isn't specific to Rust or Typescript. You can do this in basically any language. Imagine you have to distinguish between unescaped and escaped strings for security purposes. Even with a dynamically typed language, you can keep escaped strings as an Escaped class, with escape(str)->Escaped and dangerouslyAssumeEscaped(str)->Escaped functions (or static methods). There's a performance cost to this, so that's a tra…

> You can do this in basically any language. You can do it in Assembly. That doesn't mean it's cost effective.

And categorically: the issue isn’t what “I’d” do, my habits often match my habits, it’s what other project members will be doing (including future degenerate versions of myself assumed to be some combination of busy, tired, stressed and drunk).

The Confucian philosophy that people act like water coming down a mountain, seeking the path of least resistance comes to play.

Haskell, OCaml, F#, and their ilk can yield beautiful natural domain languages where using the types wrong is cost prohibitive. In languages without those guarantees every developer needs discipline to avoid shortcuts, and review needs increase, and time-pressure discussions rehashed.

Post reply on HN