Clojurians Log v2

whoaaaa

now i want to rebuild that based on bb

i wonder if there’s a way to do interop between a graal native binary and rust

i’d want to write the job control in rust and the business logic in clojure

Maybe? https://github.com/babashka/sci/blob/master/doc/libsci.md#using-libsci-from-rust

yesss beautiful

i wonder if i could build something like flower for shells, where you can plug in the language syntax without having to recompile the core library

hm i don't think data readers would work here because they require the syntax tree to be a valid clojure form

maybe it could dispatch based off the subshell operator, so (+ 1 2) is clojure and py(1 + 2) is a python interpreter, something like that

Maybe @kloud (author of closh) is still interested in this idea

Re: Closh: At the time I had some proof-of-concept graal native binary support based on SCI (interpreter from babashka). Nowadays, one could probably make it hosted on babashka directly, create pods for rebel-readline/jline, there is already pod for sqlite (for civilized storage of history), etc. I am also contemplating Closh 2. If Jank matures and is able to deliver on the promise I think it could be possible to implement a proper shell on top of it (using interop for low-level syscalls for proper process groups, setting up pipes and descriptors, without worrying about clashing with JVM internals).

Regarding the article it inspired me and got me thinking. I can see multiple angles of attack: 1. What shell interaction ala Clojure REPL could look like? Basically considering what Clojure REPL is to typing code into interpreters on CLI (primitive REPLs like python, irb). Imagining what REPL-based shell sending commands to eval from editor could be compared to primitive typing commands into shell process in terminal. I will probably try some experiments in Neovim. 2. If we have REPL-based shell interaction, what if we upgrade it to REBL (read-eval-browse loop). I am a fan of Portal implementation of the REBL paradigm. What if we could have a natural workflow to eval a command and send the output as data to Portal window for browsing/visualization? 3. Building on the idea of Closh 2 on Jank, once libghostty comes out (the rendering engine of the Ghostty terminal packaged as a library, we could use it via interop), we could flip the terminal-shell paradigm around. Instead of a shell process running inside a terminal, we could have a single process with both shell (process management) and terminal (rendering) responsibilities. For rendering the VT100 component would be just one viewer for legacy CLIs/TUIs among different kinds of viewers for other kinds of data. For inspiration https://terminal.click/ has shown that it is viable for a terminal to take on shell responsibilities. We could try something similar, but with a lisp/clojure goodness at the core.

I've done a lot with Clojure->Rust and uniffi, probably the same with graal

It works great but we're all scared of it https://mozilla.github.io/uniffi-rs/latest/ Uses JNA You could probably use the new FFM API but I haven't tried yet, since some of our internal users are still using java8

We also have rust calling back into clojure the same, you can do JVM foreign impls of rust traits

Looks like JNA just works? https://github.com/phronmophobic/jna-native-image/blob/main/src/com/phronemophobic/native_image/jna.clj

If you want to try uniffi and not use their built-in kotlin code generator, you can probably use this: https://crates.io/crates/uniffi-bindgen-java

I don't think I could have learned enough JNI in any reasonable amount of time to make it work without breaking and have confidence in shipping rust to other teams' JVMs. Uniffi just works.

This allowed me to ship a multi-arch jar from one CI run: https://github.com/rust-cross/cargo-zigbuild

We even have rust logging to telemere, but I haven't gone as far as hooking up rust tracing to the java otel SDK. Seems possible ?.

I don't quite understand why this problem needs a JVM to fix it, except we like sci here? I like it, too.

you could do dataflow tracking with something like this in rust: https://github.com/salsa-rs/salsa or https://github.com/janestreet/incremental in ocaml

I'm not sure I get it. I think Nix covers initial state, DBs cover incremental updates with transactional semantics, and you'd have to start fresh to unify all the things, and somehow account for I/O with the rest of the world.

Eg, unikernels are a kind of limited immutable OS state, and I'm not sure there's any value in building those up from imperative operations?

well the value is that people can transition incrementally instead of all-at-once

it's much easier to convince people to run a CLI tool than to install an experimental OS

https://doc.cat-v.org/bell_labs/utah2000/utah2000.html

this is kinda related to https://becca.ooo/blog/vertical-integration/, like yes of course things are easier if you control the whole stack, but this is open source, so we don't

doomed to rewrite the same primitives over and over unless someone finds a way to expose a composable general-purpose API

reminds me of jane st's thing https://blog.janestreet.com/putting-the-i-back-in-ide-towards-a-github-explorer/

yeah

vertical integration is nice actually!

they picked a stack to control for sure

lol

> We no longer release the code of Iron, and do not expect that will change. It was never possible to run outside of Jane Street, and is not plausible that it ever will, due to dependencies on many aspects of our internal environment.

I'm not sure this idea is compatible with open-source reality

yeah

> integrations between a code forge, build system, deploy system, CI, and code editor. oof, I worked at a startup that used Phabricator, which was one really motivated php dev, and it fizzled out

well, you have to be clever

your integration can't be "we spend a bunch of engineer labor on each forge we support"

the whole thing i'm trying to do in these posts is talk about how to avoid spending that labor

The problem is a real vertically-integrated solution needs to be easy enough for people just starting out, or it won't get used. That means it needs to be familiar and simple.

eg, python taking over the world

i actually don't care if it's familiar and simple

i care much more if it's easy to adopt incrementally

jj does this really well

jj is unfamiliar and not particularly simple, but you can use it for a single one-off command, so there's a low switching cost

if people don't want to try jj because they don't want to spend time on devtools, that's fine, but i don't see that as a fault in the tool

is git good enough? There was a time before git existing when everything else was really terrible.

i think you're pointing at a worse-is-better thing, git works "well enough" so people don't switch? i don't know what to tell you, a bunch of my friends are switching to jj

people worked around the rough edges and it got a little better and took over the world

it's not mainstream yet and that's fine

git is actually an interesting case because when it breaks people are afraid to try things and ask for help

for most devtools people just put up with things being broken, so you never hear about the brokenness

Yeah, I don't know how to beat 'worse it better', but maybe someone does 😄

i think jj is doing a good job!

it doesn't need to take over the world to be a success

that's a feature, not a bug

It looks like a nice design, but I got good enough with git 10 years ago, and as long as magit stays viable I'm not sure it's easy to beat.

i am not trying to convince you personally to switch to jj 😄 just to point to it as a model of the kind of adoption model i think works well

sure, just saying there has to be incremental value for different kinds of users and I don't quite see it for my case

I like this and wish everyone else I work with would do it, maybe that's valuable: https://github.com/jj-vcs/jj?tab=readme-ov-file#automatic-rebase

specifically I mean using git without merge commits, squashing and rebasing, and stacked diffs is a good thing, in my opinion. If the tool makes it easier, then it doesn't have to be just my opinion.

so, the thing i'm trying to point to is that jj is designed so that you don't have to care if the other people at your work use it

it uses a normal git repo as the data layer

that's what i mean by "incremental adoption"

Yeah, I understand the interop piece.

I also used git-svn back in the day

git could track renames, and svn couldn't, and that was useful for what I was trying to do

'embrace, extend, extinguish'

heh

kinda, yeah

that but for PTYs

funny how your proposed solution is basically nrepl for the terminal, but with transactional semantics

it's a compelling idea

yes!

and even more than that, i want to treat repl sessions as data

i want asciicinema, but i can edit and transform it at runtime, i want a pluggable terminal frontend

like ... imagine if you could hook up the equivalent of https://github.com/bhauman/rebel-readline to your terminal

you can write a bunch of plugins that work on the line editing, that aren't tied to the shell

omg omg omg someone built the transactional semantics already https://patrick.sirref.org/shelter/index.xml

that's sick

powershell did the right thing to deal with objects, not strings, but that's never caught on

nushell picked up on it!

i don't think i've shared https://jyn.dev/you-are-in-a-box/ yet

i had no idea nushell did that, that's cool

For related work in clojure there is also this discontinued project https://github.com/dundalek/closh it was initiated before babashka saw the light. it was a crossover between a terminal and a repl