Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Electric Clojure v3: Differential Dataflow for UI [video]

hyperfiddle-docs.notion.site

Post reply on HN
Print view View original

41–50 of 53 posts

Re: Electric Clojure v3: Differential Dataflow for UI [video]

#41

Post by jmkr »

mgdev wrote: post #34

I hate stuff like this. It's so incredibly brilliant that it spoils me for mainstream tech, but it's never actually "done enough" for mgmt to feel comfortable adopting it in any capacity. (See also: Unison https://www.unison-lang.org/ ) Or, you can get them to adopt, but then you hit hiring limitations. I say this as someone who built a large team of Clojure developers in a Fortune 100 company, and lived to regret it…

Clojure and Common Lisp has spoiled /me/.

Things really are, and can be that simple. Rich has some talks that should be required viewing for all programmers.

Turns out that I miss all the conveniences whenever I'm not using a lisp-like.

Re: Electric Clojure v3: Differential Dataflow for UI [video]

#42

Post by dustingetz »

isker wrote: post #37
dustingetz wrote: post #17

Earlier quoted context omitted.

The site macros (e/client & e/server) let the programmer declare what site an effect must run on. The network is not explicit, only implied. For example, platform calls like (query-database) or (.createTextNode js/document) or (check-password) are inherently sited. Siting is essential complexity (arguably the essence of a distributed system), and consequently we as programmers are hyper-aware of where (at which site)…

How does this implicit, "bottom up" definition of the network boundary between client and server cope with version incompatibilities? You, as the developer, control what version of your code is running on the server, but you don't have direct control over what version is running in the browser. In approaches with an explicit API, you can explicitly maintain backward compatibility for a period of time until you believ…

Haven't personally encountered this yet – it seems keeping some stale servers around and routing to them would be sufficient? Long term, over-the-air upgrades (hot migrating connected clients) seems within reach, if a bit researchy - but the durable workflows projects seem to be making headway on the problem

Re: Electric Clojure v3: Differential Dataflow for UI [video]

#43

Post by JackMorgan »

dustingetz wrote: post #40
JackMorgan wrote: post #38

A short story from the pre-development of Electric/Hyperfiddle. I was sitting at a table with Rich and Dustin after Conj in Philly. Dustin was trying to explain some of these (still hypothetical) ideas to Rich, and Rich was just too tired from the keynote to really follow along. He wasn't dismissive, but just didn't seem to get the Big Idea. Many people would have taken that as a sign and possibly dropped the idea. N…

ha nooo i think he said: “i am looking for something more flexible” than the immutable REST payload POC we were playing with at the time (this was 8 years ago). He was right!

Ah excellent extra detail! Eight years. I wager you've put in a remarkable amount of hammock driven development in that time.

Re: Electric Clojure v3: Differential Dataflow for UI [video]

#44

Post by yayitswei »

mgdev wrote: post #34

I hate stuff like this. It's so incredibly brilliant that it spoils me for mainstream tech, but it's never actually "done enough" for mgmt to feel comfortable adopting it in any capacity. (See also: Unison https://www.unison-lang.org/ ) Or, you can get them to adopt, but then you hit hiring limitations. I say this as someone who built a large team of Clojure developers in a Fortune 100 company, and lived to regret it…

Or you could start a startup that codes circles around its competitors (see Nubank, which became large enough to acquire Rich Hickey's team). There's a growing list of Clojure unicorns, most of whom have a tech-forward culture.

Agree with the challenges you mentioned using new tech at a more mainstream company.

Re: Electric Clojure v3: Differential Dataflow for UI [video]

#46

Post by Jianghong94 »

I work in a finance company and basically what our product is in terms of tech is a lot of client-server spreadsheets, with a huge $ amount per cell. So when I saw the demo and the use case I got extremely hooked! Unfortunately due to the hiring conditions and tech competence, there's almost 0 chance of adopting something like this, but still, I'm impressed.

I haven't got enough time to finish the video today, but I'd like to throw out some of our major technical domain problems and see how people familiar with electric would try to solve them:

1. How does it handle multiple different functionality servers? And potentially server-server networking? e.g. if I need to get some data from server A and some other data from server B, and combine them into the UI, is that doable in electric? Also what if I want to save the combined data onto the database on server C? Now for simplicity, let's just assume we're talking about less than 20 servers here and there's no problem with the port, so each one of them can keep 1 websocket per each other server open up. 2. How does it handle listening to a stream of events and triggering if the event meets a certain criteria? e.g. like if the price of GOOG is lower than a certain price then trigger a popup or something like that. This may not be the intended scope of electric Clojure but it is what we do day to day, so I'm curious. 3. How does it handle interop with existing Java apps? Is it just a normal java-clj interop?

Overall I really like the concept of being network transparent, or shall I say that devs would be better served by spending more time on business data and function, but not on coming up with derived request/response obj, API route, etc. Also, if this type of library ends up in some sort of more mainstream programming language, I would vouch for adoption in a heartbeat.

Re: Electric Clojure v3: Differential Dataflow for UI [video]

#47

Post by bobnamob »

mx5 wrote: post #45

is this liveview for clojure?

Not quite

LiveView does serverside rendering and “streams” dom diffs afaik

Whereas electric is doing full client side rendering and sending data/code diffs “only”

Writing client side code seems lower friction in electric at the cost of the macro/client magic being a little more magic

Re: Electric Clojure v3: Differential Dataflow for UI [video]

#48

Post by cultofmetatron »

jraines wrote: post #14
BaculumMeumEst wrote: post #8

Earlier quoted context omitted.

I've seen that the author of Electric Clojure is pretty involved in the startup scene and I was curious about how those folks perceive the changing world.

It’s honestly top of mind question for someone like me, who loves Clojure but doesn’t want to be disadvantaged for this reason. Like I wonder if the “Blub paradox” is still real or if we’re in a world where “if Blub isn’t the answer you aren’t using enough of it (spat from an LLM)”. Like try finding YC job posting without TS and/or Python in the requirements :-/

if you like working in a certain language, just do it and the opportunities will come along. I really love elixir and I started 5 years ago when it wasn't so popular. nevertheless, I found a niche building MVPs for people. eventually I met my cofounders and we built our entire startup on elixir. today I work on elixir all day and we recently hired an elixir engineer.

Re: Electric Clojure v3: Differential Dataflow for UI [video]

#49

Post by dustingetz »

Jianghong94 wrote: post #46

I work in a finance company and basically what our product is in terms of tech is a lot of client-server spreadsheets, with a huge $ amount per cell. So when I saw the demo and the use case I got extremely hooked! Unfortunately due to the hiring conditions and tech competence, there's almost 0 chance of adopting something like this, but still, I'm impressed. I haven't got enough time to finish the video today, but I'…

3- yes, Electric Clojure is a Clojure library (macro) so the interop story is identical to Clojure’s

2- Electric vars are reactive signals and stock prices are signals, so: (if (1- we can support microservice topologies (N sites) in principle though the work requires a corporate design partner to make sure we get it right.

This is an important capability for the Hyperfiddle layer - a Universal UI is only as valuable as the data it reaches; i.e., as far as RAD platforms go, service connectivity is the only thing that matters. Today, connecting a service to a UI requires immeasurable amounts of glue code (constantly shifting, breaking, requiring ongoing maintenance) at the cost of ~$100k+ per year per service connection, and costs grow superlinearly with complexity of the service! Electric collapses to zero the cost of service connectivity.

Re: Electric Clojure v3: Differential Dataflow for UI [video]

#50

Post by dustingetz »

JackMorgan wrote: post #43
dustingetz wrote: post #40

Earlier quoted context omitted.

ha nooo i think he said: “i am looking for something more flexible” than the immutable REST payload POC we were playing with at the time (this was 8 years ago). He was right!

Ah excellent extra detail! Eight years. I wager you've put in a remarkable amount of hammock driven development in that time.

I think every clojure programmer has; thinking alone can only get one so far. Electric is the result of contributions of multiple 4-sigma engineers who I have worked closely with over the years. Projects like this are larger than any individual; genuine progress requires collaboration.
Post reply on HN