huge fan of elixir. and definitely have some dumb questions.
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?
Beam only promises soft realtime. When switching processes, runnable high priority tasks will be chosen before runnable normal or low priority tasks, and within each queue all (runnable) tasks run before a task runs again. But beam isn't really preemptive; a normal or low priority task that is running when a high priority task becomes runable won't be paused; the normal task will continue until it hits its reduction cap or blocks. There's also a chance that maybe you hit some operation that is time consuming and doesn't have yield points; most of ERTS has yield points in time consuming operations, but maybe you find one or maybe you have a misbehaving NIF.
Without real preemption, consistently meeting strict timing requirements probably isn't going to happen. You might possibly run multiple beams and use OS preemption?
I spoke with Peer (the creator of Grisp) about this at Elixirconf earlier in the year, and I'm not an expert here so I hope I don't misrepresent his comments:
Grisp puts enough controls on the runtime that soft-realtime becomes hard-realtime for all intents and purposes, outside of problems that also cause errors in hard-realtime systems.
(Also, thanks Peer for being tremendously patient with a new embedded developer! That kind of friendly open chat is a huge draw to the Elixir community)
I did the same workshop some years ago with him also, very nice and patient guy, I can recommend attending if anyone is curious how microelectronics actually work :}
We try to hit the cache as much as possible, and all fetching is done in parallel with Remix. We try to make heavy use of their defer function to only block on the most important data, and await the other data. Remix has the option to merge all parallel requests into a single fetch, but it didn't work for us because we use a hybrid strategy for hosting (where the most common pages are served from v8 edge functions and the less common stuff is served by node functions). The reason we don't put everything (basically) into the edge runtime is because vercel only gives you 2MB of code in the edge runtime before you have to pay HUGE money. But I've definitely put a lot of thought into the performance, so I hope it's great.
founder here. i often advise people to use excel (or some web-based). it's excellent software, and often the simplest way to solve a problem. it just gets untenable as the company gets bigger.
imo, these (supabase, trigger, upstash, novu) are the best hosted solutions in the world, but they are all self-hostable/apache/MIT.
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!
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
Interesting, since the past two manufacturers I have worked for in the last 16 years both have Sage as their primary ERP...BUT that directly resulted in them needing a bunch of other software strapped to the side of it to get things done, which sounds exactly like the problem Carbon was made to solve.
I had even taken it upon myself to develop a (very rudimentary, but functional) piece of software to manage the Service Department of my current employer, since RMAs/Repairs were still being handled with paper and email when I arrived a few years ago, Sage apparently lacking a suitable module as well as the looming shadow of "that's the way we've always done it" thinking.
Carbon looks like it would trim a lot of the thorns my current employer gets hung up on, but it would take some serious convincing to migrate over given the entrenchment of old and comfortable habits, inefficient though they may be.
Anyway, thanks for the response, I know you folks are busy.
i appreciate you talking through it with me! i only have my limited experiences, and the term ERP is pretty fuzzy -- a CFO's view is a lot different than a head of production.
these are all excellent questions! i think, interestingly, the answer to all of them is basically -- there's an off the shelf version that's opinionated and good. and if you want to take it a step further, you'd want to just modify the source code.
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.
I currently work in an ERP adjacent industry serving M&D. I don’t think this is as beneficial as you think it is.
Your value prop lands really well with the Software Architect in me. That part of my skill set loves the idea of creativity, flexibility, etc.
The Director in me does not want that. That sounds like a money pit, never done, management nightmare. What kind of dev do I hire? Do I need a Product Manager for that? How long will it take? Sounds too hard to get a win as a senior leader.
Most of the software in the adjacent space (and ERPs) have “prescriptions” or an ecosystem to get customizations done. Code may get deployed in a special assembly, a special SDK exists, etc
A prescriptive way to get the job done is much more preferred for predictability, even if it is not as loved by the developers.
I think Carbon is a neat and ambitious offering - happy to chat more with you if desired.
The problem with forking is that updating becomes a nightmare. Most ERPs provide a stable-ish API and heavily recommend customers to stick with it, because then automatic updates just work.
I think that's going to be a very hard sell in nearly every scenario. In addition to vendor lock-in you'll then also have people on payroll only to keep your vendor lock-in functional.
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.
ahh, it does -- but there's a slight hair to split.
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.
i don't know a ton about ERPNext's manufacturing capabilities, but i think there are really great for these reasons:
- 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.
