Hacker News Reader

Comment by andy_ppp | Hacker News Reader

Elixir + Phoenix is so great at this with contexts and eventually umbrella apps. So easy to make things into apps that receive messages and services with a structure. I’m amazed it isn’t more popular really given it’s great at everything from runtime analysis to RPC/message passing to things like sockets/channels/presence and Live View.

View on HN

I've been picking up Elixir and the Pheonix framework and I'm impressed so far. Pheonix is a very productive framework. Under the hood Elixir is very lisp-like, but the syntax is more palatable for developers who are put off by the syntax of Lisp.

Why isn't it more popular? It's always an uphill battle to introduce a new programming language or framework if BIGNAME doesn't use it.

the elixir shop I was at, folks just repl'd into prod to do work. Batshit insanity to me. Is that the elixir way? Are you able to easily lock down all writes and all side effects and be purely read only? If so, they never embraced that.

> repl'd into prod to do work

Like for debugging production problems and fixing customer data? Or for normal development?

If its the former that's a great use of technology, and if its the latter it sound insane.

It's an order of magnitude harder to debug when you don't have access to prod, but there's a reason to block that access. I think you need to put controls on that fairly early in your project's evolution.

Any good strategies to reduce the pain? My previous employer never solved this.

I always wanted to explore contextual logging - by which I mean, logging is terse by default, but in an error state, the stack is walked for contextual info to make the log entry richer; and also, ideally, previous debug log entries that are suppressed by default are instead written. I guess that implies buffering log entries and writing only a subset at the end of the happy path.

To illustrate what I mean: happy path log:

10:21:04 Authenticated 10:21:05 Scumbulated

Error condition log:

10:21:04 Authenticating id 49234 request DEADBEEF IDP response OK for 49234 request DEADBEEF https://idp.dundermifflin.com Session cookie OK request DEADBEEF Authenticated 10:21:05 Scumbulating flange 7671529 user 49234 request DEADBEEF NullFlangeError flange 7671529 at scum.py:265 Frame vars a=42, password=redacted, flags=0x05

I'm reacting to hard-to-repro bugs at $employer where we chucked logging statements at a dartboard, deployed, waited, didn't capture the issue, repeat several times. At a cadence of 5-10 deploys a week, this is below what I consider acceptable velocity. We often took days to fix major bugs, we'd run degraded for weeks at a time.

It has hot swappable code. For skilled practitioners it's fine.

> For skilled practitioners it's fine

That sounds like something that will not scale because people make mistakes. Our DBA at $prev_gig was very skilled. And also truncated a production database. Mistakes happen. Write access to prod all willy nilly gives me the heebie jeebies

It depends on the situation, if something is broken in a live system and you can login and introspect the real thing this is awesome. Obviously there are trade offs and potentially you might break things further!

I'm used to introspecting live data with read only access. They used write access and were an accidental key stroke from deleting. Writing in prod should take permission escalation

Sometimes auditors won't even ok read-only access. I'd have loved RO access, but we hosted financial institutions etc.

Nice if you can get it.

With great power and all that...

Reply on news.ycombinator.com