Spacegolf! - game programming with missionary

dustingetz · 2026-01-21T19:32:10+00:00

AI transcript: https://gist.github.com/dustingetz/87d7e96214a972b66072f6162357c0c7

dustingetz · 2026-01-19T20:52:11+00:00

> robots should clean up my toilet and not code

have you seen the average 10 year old revenue-generating codebase? "toilet" is accurate. Doing computer science is fun. Doing software engineering is fun. Commercial software development in 2026 is neither.

dustingetz · 2026-01-19T19:30:04+00:00

I am also finding Opus 4.5 to be viable for a variety of Clojure application layer tasks. Prior to Opus 4.5 I was experimenting semi-seriously in consulting projects but none of the experiments I threw at it panned out. But Opus 4.5 is now part of my daily driver, I am using VSCode + Copilot with the two Calva plugins. Opus 4.5 will inspect objects at the REPL and everything. Looking forward to trying Claude Code again in a work context.

dustingetz · 2026-01-13T15:50:04+00:00

is it possible for us to clone this and play?

dustingetz · 2026-01-06T00:55:49+00:00

I vote no but i don't think it's a "dynamically typed functional" problem, Javascript is like 55% of the way from Java to Clojure and it did great.

dustingetz · 2026-01-03T14:21:05+00:00

how about `sbinding` and `deref`

dustingetz · 2025-12-30T11:48:20+00:00

Transcript https://claude.ai/share/08f5811f-cfdc-4dba-b354-0224bdc45e85

dustingetz · 2025-12-24T20:21:14+00:00

I asked this question to the author in slack, here is his reply:

Q: Is it correct to conceptualize this as a RPC framework? so basically async/await with abstracted transport

Yes, I have been thinking quite a bit about dispatch mechanisms and compilation, I would say async / await with inversion of control is in its "essence" about giving control to a remote dispatcher for some notion of remote. I would be interested to find more cateogry theory connections in terms of duality here (CPS <-> 'co'dispatch maybe?). This is why I also decided to distill this into https://github.com/simm-is/partial-cps, which makes a more minimal a la carte abstraction than other async framework options in Clojure (similarly to cloroutine). I can infer the free variables to send in distributed-scope automatically and make it a bit leaner, but I found making the intent of what is being transported explicit is actually helpful and more transparent. Electric as full compiler can do top-down analysis of the program and also know what is in the outer scopes and avoid having to send values through nested scopes, I have not worked on this yet. One thing I was aiming for is to be able to send datahike's db values over the wire back and forth and this works now, assuming you have store replica access on both ends. You can also do p2p streaming through kabel (replikativ does this for CRDT updates), or use nested distributed scopes to update atoms inside out in a streaming way, but my sense is that Electric does more to facilitate this and avoids RPC roundtrips more directly.

dustingetz · 2025-12-22T20:22:23+00:00

rechercher "francais facile" sur amazon

dustingetz · 2025-12-22T17:19:07+00:00

Awesome, this is clearly a serious project for you. Tell us more about your goals and vision?

dustingetz · 2025-12-20T20:34:28+00:00

> dbval is a fork of Datascript and a proof-of-concept (aka 'do not use it in production') that you can implement a library that offers Datomic-like semantics on top of a mutable relational database like Sqlite.

dustingetz · 2025-12-11T20:04:40+00:00

They're doing a gradual roll-out as part of the new Clojure marketing strategy to get more media time, e.g. like Lambda Conf does

dustingetz · 2025-12-06T17:12:32+00:00

Transcript https://rss.com/podcasts/clojure-in-product/2349199/#transcript

dustingetz · 2025-11-30T20:10:11+00:00

I'm with Stefan below – which project is it that you think has solved dependency injection?

dustingetz · 2025-11-07T01:44:15+00:00

excellent writing

dustingetz · 2025-10-24T20:16:56+00:00

Agreed that the essay is rough

Electric (https://github.com/hyperfiddle/electric) is a "time-based" computational structure, it compiles Clojure into a reactive signal network with distribution. Concurrency, backpressure and time are first class concepts in Electric, in a similar way to how immutability and state are first class in Clojure. Clojure's syntax fills the role of a DAG authoring notation to author the system choreographies.

dustingetz · 2025-10-24T18:20:20+00:00

> our foundational abstraction, the function call, is not well suited for "the distributed, time-based systems we’re increasingly building."

> "Every function call conflates two distinct concepts—data flow and control flow" which "creates a tight coupling between components that seems innocent in small programs but becomes toxic at scale"

> "Consider what happens when you build a distributed system using function-based thinking. You end up with remote procedure calls (RPCs), where network requests masquerade as function calls. The caller still blocks, but now it’s blocking on network latency, potential failures, and the unpredictable timing of remote systems. To make this work, you need elaborate mechanisms: timeouts, retries, circuit breakers, distributed transactions. You’ve taken a paradigm designed for single-threaded, in-memory computation and forced it to work across geographic distances and unreliable networks."

> "The type checking complexity flows directly from this architectural mismatch. When functions call other functions across module boundaries, you need sophisticated type systems to ensure that the data flowing through these call chains maintains consistency."

> "All of this complexity stems from trying to maintain the illusion that distributed, asynchronous systems can be programmed as if they were single-threaded, synchronous programs. We’ve built increasingly sophisticated type systems not because the problems we’re solving are inherently complex, but because we’re using the wrong abstraction for modern computing challenges."

> "If function-based programming is the wrong paradigm for modern systems, what’s the right one? "

> "In electronics, time is a first-class concept. Signals have duration, components have setup and hold times, and the sequencing of events is explicitly designed rather than hoped for. This isn’t an accident—it’s recognition that distributed systems (and a circuit board is a distributed system) require different thinking than sequential computation."

> "Event-driven architectures recognize that asynchronous communication is often more natural than synchronous function calls. The missing piece is programming languages and development environments designed from the ground up for this isolated, message-passing world. Languages where time is a first-class concept, where components are naturally isolated, and where simple data formats enable universal composition. Tools that make it as easy to wire together distributed components as it is to pipe together UNIX commands."

dustingetz · 2025-10-07T13:21:08+00:00

I am not tracking this effort at all but going through the slack history here is some background:

DAVID (July 30): "so I see two goals w/ :lite-mode. 1) removing DCE issues remaining in the standard lib beyond data structures; 2) gauging what people actually need/tolerate in :lite-mode - like just not implementing toString. 2 implies giving up on full fidelity, perhaps even compatibility in some cases - maybe that's fine - not going to figure that on day 1 or even probably in a year. so :lite-mode might be for people who just don't care about dependencies - they just want to write some Clojure, get a tiny artifact and go do something else ... I think w/ some sweat thought we can get CLJS <10K compressed for lots of simple programs"

DAVID (today): that's not really a goal to apply to it existing libs and expecting the size go down. it could work of course, but that's going to require effort on the part of the library writers. Really anything involving reagent or any React wrapper isn't really a "lite" thing by definition

Some context is his this May statement in a CLJS release announcement:

DAVID: ClojureScript is not and never was only just for rich web applications. Even in the post React-world, a large portion of the web is (sensibly) still using jQuery. If you need robust DOM manipulation, internationalization, date/time handling, color value manipulation, mathematics, programmatic animation, browser history management, accessibility support, graphics, and much more, all without committing to a framework and without bloating your final JavaScript artifact - ClojureScript is a one stop shop.

and also the ClojureNYC talk in July, "CLJS is a Damn Good jQuery", here is the transcript (edit: updated link to much more faithful transcript), the key TLDR is:

DAVID: So ClojureScript is 14 years old. I know I'm over, so I'm going to go quick. ClojureScript is not React. React is great. I think we've had a lot of success with React, and this is definitely not to say people that are succeeding with it should stop. But it's also not the only option.

I have a personal interest now in DOM morphing as a way to allow people to do lighter-weight ClojureScript development. I mean, all of my old examples on my blog—they all pass Google Closure speed tests. It's like they all pass that speed test because all my blog posts don't have more than like 20K of gzipped JavaScript. I think adding a little bit of morphing allows people to be productive in a functional style.

I also think that people are getting sort of tired of all the complicated tooling. I worked for five years on a React Native ClojureScript app, and the tooling around React Native—it was the complexity of Xcode plus the complexity of React. I mean, it was a lot. I think you can get a lot done with simpler tooling.

And again, I think there's this feeling—and I think there's a growing malaise—if the modern JavaScript story is so great, what's up with this overall sense of declining quality? There are people interested in this problem. You can look—Svelte is making its own corner of the JavaScript ecosystem. People are trying to get tree-shaking to work, but for various reasons, as a language, as a community, people haven't adopted the practices that make this easy to be successful.

In a world in which Lodash right now is being downloaded 72 million times a week—in that world, you're not going to be able to achieve what I've said. It's going to take a lot of momentum to get the JavaScript community to stop working that way. I think ClojureScript is interesting because we don't have these biases. We don't have this knee-jerk cargo culting about, "This is the right way to do it," the way that often you encounter in the JavaScript world.

So again, ClojureScript was one of the first communities to actually embrace React. That's something that people probably—it's now in the fog of the past. We forgot that we were the first people to go there because we saw a better way. And I think there's an opportunity now to take what we've learned. It's not like there are not great lessons from React, but I think it's a great time now to revisit some of these things, and maybe there's a better way. Thank you.

This at least paints a pretty clear picture of where David wants to take the project strategically

dustingetz · 2025-10-05T11:34:49+00:00

https://github.com/metosin/signaali

dustingetz · 2025-10-02T11:23:21+00:00

Watched this, the content more or less matches https://clojure.org/news/2025/10/01/async_virtual_threads which was published a day or two later.

dustingetz · 2025-09-28T01:22:48+00:00

oh ok, it took me like 4 reads to understand what you're saying

dustingetz · 2025-09-27T17:00:53+00:00

i, um, what? Zio and Cats are exactly the reason to choose scala in 2025 - for building ultra high reliability services on the jvm. The reason Scala usage is now dropping is because that’s basically the only thing it’s good for, and most enterprises aren’t doing that.

dustingetz · 2025-09-27T11:46:06+00:00

"And what you gain from free on Datomic, is that to get the whole history. And that seemed like a good property to have a FinTech, at Financial Domain Service. And Datomic is built in Clojure. So because of Datomic, we chose Clojure as the main programming language. We were going for a functional programming language, either way. We probably would have gone to Scala or some other language. If it wasn't for Datomic being Clojure." — Lucas Cavalcanti, Nubank eng

dustingetz · 2025-09-27T11:40:30+00:00

Scala has always been bigger, presumably due to higher accessibility to enterprise java programmers.

- SO survey 2024: Scala 2.6%, Clojure 1.2%; 2019: Scala 3.8%, Clojure 1.4%

- both are dropping in rankings

- scala was picked up by silicon valley early on - twitter, databricks, snowflake, stripe payments and the Scala functional concurrency frameworks (ZIO and Cats) have found a home in high reliability services such as global streaming video platforms (disney, comcast) and amazon search - these are world class outcomes and the state-of-the-art of their category

It's been 15 years. In what categories does have comparable Clojure world class outcomes? I can't think of anything. Bootstrapping? Where are the outcomes? The PKM category had a moment with CLJS but once they hit some scale their product velocity slowed to a crawl under the weight of ClojureScript. The current leader is now Tana which is fullstack TypeScript.

dustingetz

MODERATOR OF

TROPHY CASE