in some of the realtime architectures i've seen, certain processes get priority, or run at certain Hz. but i've never seen this with the beam. afaik, it "just works" which is great most of the time. i guess you can do: Process.flag(:priority, :high) but i'm not sure if that's good enough?

Comments URL: https://news.ycombinator.com/item?id=44801830

Points: 3

# Comments: 0

a sage integration is actually at the top of our roadmap: https://github.com/orgs/crbnos/projects/1/views/1

I'm surprised the carousel is slow, it's just framer motion. https://github.com/crbnos/www/blob/24d2b59150fc21e6b9c9df3b4...

the easiest one to replace is upstash -- the @io/redis is super easy to switch out -- i think the APIs are the same. but the others encapsulate an insane amount of complexity. my thinking is, if i -- as a fairly competent software engineer -- don't have the bandwidth to sysadmin 10 services -- how is someone whose running a manufacturing going to have the bandwidth.

the setup does suck, but imo it's the best solution for bang-for-the-buck long-term. interested to hear your thoughts!

here's a little bit about me, and why i decided to build this: https://carbon.ms/#memo

re: sage, i'd say that sage is well-known as being a great general purpose accounting software for multi-location, and multi-entity businesses. but i don't know of many manufacturers running on sage.

re: erpnext, also great. i love their open source model, their developer ecosystem, and great documentation. i'd say the major difference is the data model and the UI that it begets. in erpnext, i think everything is a "doctype" where with carbon things are more bespoke. each ui has it's own specific tables, and specific ui

re: erp

i think open-source gives consultatnts and integrators super powers that they may not be used to -- everything currently has to be done through abstractions on abstractions. if you can just modify the source code, it becomes a little simpler i think.

take the PDFs for example. just make them how you want them in your instance of the software using the most popular tools on the planet (i don't mean crystal reports): https://github.com/crbnos/carbon/tree/main/packages/document...

we've started trying to work through adding agents like this: https://x.com/barbinbrad/status/1903047303180464586

the trouble is that there are 1000s of possible mutations -- and the quality of an agent tends to diminsh with the amount of "tools" you give it. i need to figure out the right abstraction for this.

on sales, carbon supports quoting, sales orders, invoicing, configurator, etc -- but it does not attempt to create a website for you where you can list your products and their configurations. the idea is that you have a site, the site sends info to carbon through the API (whether it's a quote or an order), and then things begin from there.

similarly with production except that the shop floor is pulling intstead of pushing. carbon manages the schedule, the jobs, the capacity planning, etc. and provides a UI for guys on the shop floor to record their time and materials. but if you want to interface with a machine, you'd be pulling information out of carbon through the API, and relaying it to the machine.

the way i see it, the sales side should be bespoke -- because everyone has a different product, and way of selling/configuring, and the factory-floor side should be bespoke -- because of all the different types of equipment. but the middle layer (purchasing, bill of materials, invoices, sales orders, scheduling, processes, work centers) can be standardized.

for me that's why it's important that the middle layer is open source. so that the bespoke layers can tie into it.

- free to try - open source - well-documented - great developer community

one big difference is in the data model. in ERPNext, everything is a doctype, and there's some standard hooks.

in carbon, there are hundreds of different tables. each ui is it's own set of react components, so it's a lot more manufacturing-specific and a little more opinionated.