Recent submissions

Comment · 5 months ago
It's very nice updating Elixir, having no breaking changes across my many projects and it then the compiler just finds bugs for free. I'm so spoiled.
Comment · 1 year ago
Solar is great but the bottleneck is on battery capacity to carry those noon hours into evening for peak usage. Last I checked we had plenty of lithium and are mostly held back on refinement.
Comment · 1 year ago
Thanks, I might hit you up when I'm in the weeds of that feature.
Comment · 1 year ago
Any takeaways on using Fly APIs for provisioning isolated environments? I'm looking into doing something similar to Phoenix.new but for a low-code server-less workflow system.
Comment · 1 year ago
Manufactured consensus is everywhere there is enough attention to incentivize such an effort. The worst by far is Reddit.
Comment · 1 year ago
The important thing is to know fundamentally "why" a rule exists and what goal / organizational objective it's existence and constraints provides. Then breaking it can be productive if it meets the same ends. This usually puts the rule breaker at conflict with people in the organization who put adherence to process higher in priority than the actual organizational goals.
Comment · 1 year ago
Main limitation of these kinds of products is that the graph/workflow itself is not very expressive of dataflow options. Eventually you need map, reduce, and state machines and likewise concurrency and durable execution. It's not easy to have a high level declarative tool but also expose powerful programming primitives; at some point technical need-to-knows cross the point where you might as well have the user write code.
Comment · 1 year ago
Most expensive part of the typical web app is the coordination cost between front and backend devs. Thus the rational to have 1 dev implement full stack. But the trade-off for coordination costs are heavy context switching and knowledge costs to know both ends. Neither option is very ideal and most companies have accepted the coordination costs.

But LiveView just ignores these problems and does full stack without the heavy costs. Elixir/Phoenix/LiveView is a tool-set for maximizing how far one dev can go.

You'd think this would be a selling point in many companies: to have less devs ship more features but those heavy SPA stacks let middle managers rationalize hiring bigger teams. LiveView is for shipping - not stalling.

Comment · 2 years ago
Comment · 2 years ago
Comment · 2 years ago
Yeah modern ML is not really at all comparable and they're more complementary than modern approaches replacing rules. All these agent frameworks and platforms cropping up will be using things like rules, workflow DAG models and so on as the execution engine with LLMs embedded as steps and/or to construct a workflow.

Likewise either with knowledge graphs or using LLMs to generate possible predicates and constraints to run against a rule engine or backwards chain through facts is a way to minimize hallucinations of generative models.

Comment · 2 years ago
Comment · 2 years ago
Yeah 100% the root pain is from low agency/trust dynamics of a large org.

Jira is just the tool management chooses because nobody-got-fired-for-buying-jira.

Comment · 2 years ago
It shipped with a slide out that we can't figure out how remove in the AWS console which is already a dumpster fire of a UX.

Every single developer in our org already hates it for just that reason. I'm sure it will be very successful.

Comment · 3 years ago
This is a great resource to map "what library/thing should I use for x situation" which can sometimes be daunting to someone new to an ecosystem.

The "niche" label cast at Elixir and its ecosystem hasn't been relevant for years; it can do what you need it to and with massive reduction in complexity.

If or when you do need to write your own library: you'll find that straightforward as well.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton