Phosphor | NYC | Full Time | Founding Engineer (HCI focus) | $175-225k + Equity
Phosphor enables the development of the built world (e.g. from real estate to energy projects) to be managed agentically by building programming languages and observability primitives (like version control) on top of a hypergraph.
Our primary technical bet is that if you capture annotated "diffs" of user information with the appropriate annotation, you can create path-dependence to train AI models in an AlphaGo like context. By doing so, we achieve agentic experiences for markets that have never even had an opportunity to imagine what life would be like with basic observability.
Our product is similar a combination of Linear and Wolfram, with components and objects that enable advanced financial modeling, legal/regulatory analysis, and geospatial analysis of infrastructure development opportunities.
We're in stealth, but recently venture-backed by one of the best deeptech funds in the market. We're hiring for a few roles at the senior/staff levels:
1. HCI Engineer - You're a prosemirror wizard who probably follows Ink & Switch or the UCSB HCI lab on Twitter; front-end/rich-text/typescript focused; lots of architectural/sync engine work
2. Systems/Compiler Engineer - We design and build dev tools for languages we create that compile into various graph representations. These range from financial modeling calcs (which need to go very fast to support a seamless UX), to computable representations of legal agreements. Extra points if you've worked with hypergraphs. This in Rust but we're exploring a few other languages.
Email resume/linkedin/twitter to oliver@phosphor.co if you might fit somewhere in here, or if you've taken a credible attempt at building end-user programming tools.
We're probably one of the first to make a real tech bet on Loro. We inched our way into it, and plus or minus some edge cases, it is going very well so far.
Even on the edge cases, most of it just relates to what primitives are exposed in the API, and we've found the library's author to be highly engaged in creating solutions.
We've found it to be an incredibly well designed library.
Congratulations to the team!! I've been following for some time and love a good DX story.
I'd love to get some commentary from any active users on tradeoffs re: adopting tech like LiveView vs the community size and scale of JS land.
For example, JS land benefits massively from libraries like ProseMirror or even any of the more advanced CRDT libraries like Loro or Automerge. How about the AI story?
Is there a clear path to adopting this JS-based tech? Is it not needed? Would love to get a better understanding of the tradeoffs from folks who live in both worlds.
It's tough because LiveView is really just the dessert at the Elixir dining hall-- you can't live off of dessert. It's (at least) an order of magnitude smaller an ecosystem than React and the like, and while average library quality is very high, you won't find ready-made solutions to all your use cases like you do in those big front end ecosystems. JS and LiveView do interoperate surprisingly well, so ProseMirror isn't off the table, but I still think there are important benefits in the big front-end ecosystems.
Nevermind front end though, the main course is Erlang/Elixir's concise, functional, concurrency paradigm that feels more discovered than invented. The default structures they provide for thinking about message-passing actors are so much easier than tangled webs of async functions. This means CRDTs, calling out to APIs, running jobs in other languages, realtime coms, all go very well in Elixir.
I think Actors are a paradigm shift somewhat akin to garbage collection. Increasingly complex programs demanded we abstract away memory management to stay sane, knowing we'd drop down to memory manage when needed. In this web-heavy world, we abstract into tiny statefull services (actors) to stay sane, knowing we'll drop down to sequential languages when needed.
Cons: you do not have access to the extensive scale of the JS ecosystem.
Pros: you do not need access to the extensive scale of the JS ecosystem. And you will not need to write as much JS, if at all.
If you do not have Stockholm Syndrome for Javascript, just switch to Liveview. And Erlang/Elixir is just a comfy yet secure platform to build serious apps.
Automerge wise, there's a ton of effort behind ElectricSQL which is written in Elixir and can also be run as part of an Elixir app, so you can get a lot of the same benefits of local first clients, afaict.
There's a langchain implementation that's fairly mature and definitely in production use (I saw the authors handle above actually :D ). Langgraph-style libraries exist (there's one called Magus that I've used) but I think that's where there could be some more efforts. Although it's important to note that building something comparable to langgraph isn't too hard in Elixir with its process model, and most Elixir devs could probably do it, but unfortunately that's not obvious to your average person searching "langgraph implementation in Elixir".
There's no langsmith integration but the telemetry implementation in Erlang and Elixir is really nice so once some patterns around running chains and graphs emerge publicly (there's a few companies that I'd bet have private repos implementing their own equivalents of langgraph) I imagine integrating to langsmith would go pretty quick
So you can have local-first sync in a Phoenix app using Electric. And you can use Electric to sync data into a LiveView using Phoenix.Streams, which is a very natural fit.
We have a couple of example apps showing things in action:
Worth nothing that the former lead dev of ReScript left to create a WASM-first language call Moonbit (https://www.moonbitlang.com/). The language design is awesome and corrects a lot of the corners that they just couldn't get around in OCAML. A touch early, but really well done.
Well, I made a large, multi-year company/technology bet on top of F# with Phosphor.
After over a year of trying to make it work, we completely rewrote the application in Typescript and Rust. The product we're building is an end-user programming tool where the traditional lines between front-end and back-end work blur, and the .NET ecosystem really didn't lend itself well to this.
Our hope was that we'd be able to use the Fable library to maintain type safety across a variety of technologies while being able to interop and in and out as needed: Fable compiles F# code to JS, Rust, .NET, etc. The reality was that the interop story between the various libraries we'd use was much harder to achieve than initially expected, and managing and updating multiple dependencies and their bindings was an absolute PITA.
The assumption that F# makes for beautiful, efficient code is still a safe one, I think. But the ecosystem and the way that it was designed makes it (in my view) applicable only for applications and software that have very traditional frontend/backend lines. F# would be used for the back-end only in that case.
Today, two of the technologies I'm most excited by (and which we're using internally) are the Effect library, whose Schema library fills in a lot of the gaps in TS's type system, and Moonbit, which is what I imagine a modern version of F# would like, free of the MS/.NET dependencies. Moonbit is really, really well designed (designed by the creator of OCAML's version of Fable, ReScript), and it compiles directly to highly optimized JS, WASM or Native output. We're using Effect in production, and not yet Moonbit, but the promise Moonbit holds as a language built for an AI-first world is pretty fantastic.
I’ve had a good experience exposing F# code that compiles to Typescript modules. The approach was to write the core business logic and validators in F# and the rest of the front-end application in Typescript and the back-end in C#. That is, core business logic and validators in F# and all of the IO in TS and C#.
Is your company related to Darklang by any chance? I recall they were a product similar to yours, written in F# as well, but I haven't kept up with them recently.
Effect is pretty nice, I wish it existed in other languages than TypeScript too. Regarding MoonBit, it seems like its own proprietary programming language so I'd hesitate to move to that over something well known, what are your thoughts on that aspect?
We bet quite early on AG-Grid and it got us very far. We’ve probably built one of the most customised AG-Grid tables out there.
I haven’t checked out Tanstack table much but given that it’s such a core component of the product I would like to build our own eventually. Doing that when you start out is probably not worth it though.
Not op but having been in a situation where I was facing the choice between ag-grid and Tanstack Table, I'd say, without hesitation : Tanstack Table. What you may "lose" in advanced features, you gain in flexibility!
Curious to hear about other people's experience with Tanstack. I built a complex app [1] around AG-Grid and here are my thoughts:
I would recommend AG-Grid for most data apps until a well supported alternative comes out. My understanding is that Tanstack Table is aimed at generic apps that happen to have a table. Perspective's [2] table component is most likely more capable than AG-Grids, but it needs significantly more documentation and examples.
AG-Grid has a particular way of building things that seems to map to well to pulling data from a database or basic webservice. AG-Grid works very well for this use case. The AG-Grid enterprise features are built around this type of data model too.
If your data is small enough to fit into memory (less than 50 MB), it works very well. AG-Grid doesn't have a connector to arrow or parquet (I will eventually write my own). For larger datasets JSON generation and parsing performance bottlenecks. Additionally Parquet/Arrow offers much better types.
Configuring AG-Grid is tricky, especially when you want config to be declarative. If you want to define your own custom rendering components, getting them to work properly per column when you want different renderers for pinned rows is tricky (my solution [3])
Support for the community version of AG-Grid is practically non-existent. I understand that they have an enterprise business model that charges for support. They don't seem to be interested in answering community bug reports or comments, even for generically relevant bugs.
I have a decent amount of trust in AG-Grid's community offering [4], I don't see them cannibalizing community features to put them in their enterprise offering. Their enterprise features are the main development focus of the team, particularly the charts. The charts offering isn't impressive compared to bokeh, plotly, or vega. It would work for line of business apps, but not for a userbase familiar with better analytic platforms.
All that said. AG-Grid has excellent documentation and examples. They examples are swappable between Javascript, Typescript, React, and Angular.
Would Perspective work for a similar use case as Causal's where the data tables have a large amount of interactivity, tree-based information and/or master-detail style UI concerns?
We're building a product that is more oriented around the interactive DAG concept and less about big data. The snappiness of those examples is very impressive.
I've been following the author Sandro Maglione for quite a while and am on his email list, he's great. He wrote fpdart which I've used and now he seems to be all in on Effect, with XState.
That’s just another level. Only in five pages of explanations we come to something that is basically:
await fetch(…)
.catch(e =>
new CustomError(…))
But with a wrapped-promise and flatmap nonsense for “better error handling”.
FP always goes out of the way to avoid using the language it operates in and to criticize the ways of doing something it just imagined. As if it wanted to stay as noble from unwashed peasants as it could, but has to do the same job to keep existing.
how to test () => makePayment()? (from the link)
You don’t. You test constituents like request body generation and response handling. It’s inside. You can’t test your Effect-version of this code neither. It’s a strawman.
Phosphor enables the development of the built world (e.g. from real estate to energy projects) to be managed agentically by building programming languages and observability primitives (like version control) on top of a hypergraph.
Our primary technical bet is that if you capture annotated "diffs" of user information with the appropriate annotation, you can create path-dependence to train AI models in an AlphaGo like context. By doing so, we achieve agentic experiences for markets that have never even had an opportunity to imagine what life would be like with basic observability.
Our product is similar a combination of Linear and Wolfram, with components and objects that enable advanced financial modeling, legal/regulatory analysis, and geospatial analysis of infrastructure development opportunities.
We're in stealth, but recently venture-backed by one of the best deeptech funds in the market. We're hiring for a few roles at the senior/staff levels: 1. HCI Engineer - You're a prosemirror wizard who probably follows Ink & Switch or the UCSB HCI lab on Twitter; front-end/rich-text/typescript focused; lots of architectural/sync engine work 2. Systems/Compiler Engineer - We design and build dev tools for languages we create that compile into various graph representations. These range from financial modeling calcs (which need to go very fast to support a seamless UX), to computable representations of legal agreements. Extra points if you've worked with hypergraphs. This in Rust but we're exploring a few other languages.
Email resume/linkedin/twitter to oliver@phosphor.co if you might fit somewhere in here, or if you've taken a credible attempt at building end-user programming tools.
reply