Hacker News Reader

Comment by 67868018 | Hacker News Reader

> coding for the happy path

It's not that complicated. A relatable example would be writing an API endpoint that receives data and then you do something with that data.

1. Write the endpoint so it works for the expected data.

2. You're done

That's it. You don't need to worry about anyone sending you malformed payloads or fuzzing your API. You can ignore it. They cannot exploit anything, they cannot crash BEAM. It will keep working.

Maybe they'll run you out of memory or CPU or bandwidth, but those are problems solved at other layers (unless you include rate limiting in your application).

Ignore all errors you do not need to explicitly handle. That's the whole point. It's wonderful.

Maybe you can do this in other languages with worker pools and supervisors, but it will be very expensive and high latency due to the cost of OS process forking and you're also wasting a lot of resource on context switches with that design anyway.

View on HN

My 'A-ha' moment with Elixir was exactly your example.

Both me and a friend were building an app that ingests cryptocurrency data and stores it in a database for later analysis. The important part was that we wanted data at regular intervals. I'm not much into all this but this is what was asked of us. He wrote the app in Python; I wrote it in Elixir.

Turns out the API's of the various exchanges are (or were) atrocious. We'd get responses ranging from weird error codes to malformed data to timeouts. API's would randomly change. It was a mess.

My app just chugged along, a process per request per api endpoint. When some of these endpoints 'misbehaved' the others just kept going.

His app kept crashing, restart, and so one misbehaving endpoint would cause trouble for all the other ones. He had to add try...catch statements and fix the problems. I would just look at my logs, update the happy-path code, push it, and recompile() in the REPL.

I also have a bunch of personal projects chugging along on my VPS. They actively handle requests a few times per hour at least, by me, and they're doing fine despite the fact that I was quick about it and only wrote the 'happy path'. There's crashes and errors all over the place, and yet when one part crashes the rest just keeps going. It's been a rare occasion where the entire supervision tree failed and the app gave up.

So, both of you guys talk about API request handling.

How about some computational task where coding only the happy path means accurate calculated results for 80% of the cases?

I think my problem is the marketing hype with Elixir around "happy path" and "self healing" are too broad and resemble hype more than feature description. I'd be happy if those terms weren't used outside of marketing literature, until we have an AGI that can manage complexity on its own :)

I dunno. I'd say it's rather obvious that it's not a magical solution to everything. For one, Elixir is too slow for computation-heavy stuff.

I just gave an example of how happy path programming works in a use case that is pretty common to my day to day. A lot of other stuff I do is similar enough that the same applies, and that's just my experience, not marketing hype.

Some articles might be a little over-excited, but I don't think I've generally read articles that claim Elixir is God's gift to programmers ;). And in situations where Elixir does help, it can be very exciting.

Fair enough. Could you please describe other happy path scenarios? Is there an educational resource (blog post maybe?) that talks in depth about "happy path programming" in the general sense? Same applies to "self healing" I really want to know what the folks who came up with these phrases meant, in both specifics and the bigger picture. Thank you for the enlightenment so far!

FWIW, I wasn't aware that Elixir is not optimal for CPU-bound tasks. I use Go for highly concurrent servers, but it uses goroutines not a process per request, and mutexes and/or persistent channels to synchronize shared memory access.

That is seems to be more about the underlying infra (BEAM) than the language. I thought it was something specific to Elixir. I thought they meant it at the level of program logic, which is why it seemed very confusing.

I guess Lisp is about beauty and poetic justice and it shall remain in that realm.

I'll look into Elixir. Seems to have a healthy and growing ecosystem.

The underlying infra is not decouplable from the language. The beam is first and foremost designed to get stuff done easy and without error, not to be beautiful and poetic. Doesn't mean it can't be beautiful! And programming is fun because it feels like programming with training wheels on.

Reply on news.ycombinator.com