ElectricSQL has made massive strides towards solving this fwiw. Write sqllite in client, guarantee sync to postgres.
503 karma · joined July 6, 2021
How else are you going to know which of these GPTs are garbage or not without wasting all kinds of time and energy on them otherwise?
Personally, more than happy to use anyone else's GPT to support them if it's good and clear that they've put good effort into it. OpenAI should create an interface like Github that lets folks collaborate on prompts instead of this derivative black-box concept.
Three years of building with it (plus constant re-evaluation of that decision) has supports our conclusion that it is far more concise and easier to manage (esp for less technical folks who need to sign off on the business logic/domain) than anything we'd have done in JS.
With that said, we're building a product that requires much more interactivity than most, and we're performing a lot of typical "back-end" logic in the client - that might color our evaluation.
To be sure, it hasn't been without tradeoffs, but we haven't found those tradeoffs to be at the language level.
* Elmish (F#) repo - https://github.com/elmish/elmish
* The Elmish Book (... remarkably good) - https://zaid-ajaj.github.io/the-elmish-book/#/
* Fable compiler - https://fable.io/
The F# community is very friendly (sub-communities as well), and there are plenty of good opportunities to contribute OSS work across any skill level.
Phosphor isn't hiring right now, but we will begin a search for FE/interface engineers soon. oliver@phosphor.co for anyone interested.
We've been building a very technical product in F# + Rust for the last three years or so (think R lang + R Studio or Replit but for DSLs we built for finance and contracts).
While most folks tend to see F# as a .NET-oriented/back-end kind of language, they'd be missing some incredibly unique web technologies such as the Fable compiler (F# -> JS, Python, Dart, etc) and Elmish (Elm, but for F# with a JS target via Fable). It boggles my mind that more of the web dev community haven't discovered these tools.
These "communities" fall completely outside of MSFT's umbrella, but are transformative for how you think about architecting applications: Elm as an architecture (rather than as a language) enables a large amount of optionality in terms of what technologies one might use as a "reactivity layer" (e.g. can swap out React for SolidJS or even non-JS targets like Avalonia quite easily if it made sense to).
Our bet is that it enables us to future proof things in a number of unique ways as better WASM-based solutions come online as well that hopefully won't require shipping the whole .NET runtime (e.g. Bolero). The approach is also v helpful in managing state across an otherwise very complex application.
We use F# on the front end (instead of TS), and thanks to the Fable compiler (which transpiles F# to JS, Python, Dart, PHP and Rust), most of the benefits of an Elm-style model in the UI can be ported to all sorts of different outputs languages. The rust target is in beta, but its promising because the WASM bundle size stands to be dramatically reduced compared to Blazor.
While the default is reactivity library for Elmish is React, you can swap in Avalonia/FuncUI (https://github.com/fsprojects/Avalonia.FuncUI) with just a little work as well.
How has your experience been using Lexical? Would love to get a sense of where you've run into limitations/etc as we're exploring it (albeit, for a very different use case).
We didnt find anyone else who was tackling the tie between client-side SQLite, an open source CRDT/sync layer, and Postgres. We found a few who were attempting to manage this in a closed source way, but it didn't make sense to give up control of the server/auth, and every other fully open source solution was SQLite -> SQLite, not Postgres.
Great stuff from some killer engineers.
They're syncing client-side SQLite to server-side Postgres on backend via an Erlang service that enables bi-directional active-active replication. They have a little more work to go until they solve the RLS concerns, but its been an incredible project to follow.
Still not sold that it'll fly in finance without that sort of observable, intermediate representation.
It's remarkable how much more clearly logic is when semantic flourish (and associated ambiguity) from the English language is thoughtfully constrained away, and it's always seemed interesting to see how computer engineers see natural language as the target.
phosphor.co/20x if you'd like to see how this works in contract law and finance :).