Nice one, great to see this addition to the Rust ecosystem!
Reading through the README, this piqued my curiosity:
> Small or fast transactions may share the same WAL position.
I don't think that's true; each data change and each commit (whether explicit or not) has its own dedicated LSN.
> LSNs should be treated as monotonic but not dense.
That's not correct; commit LSNs are monotonically increasing, and within a transaction, event LSNs are monotonically increasing. I.e. the tuple commit-LSN/event-LSN is monotonically increasing, but not LSNs per se. You can run multiple concurrent transactions to observe this.
It's a non-issue with GraalVM native binaries. See https://news.ycombinator.com/item?id=46445989 for an example: this CLI tools starts in ms, fast enough you can launch it during tab completions and have it invoke a REST API without any noticeable delay whatsoever.
But also when running on the JVM, things have improved dramatically over the last few years, e.g. due to things such as AOT class loading and linking. For instance, a single node Kafka broker starts in ~300 ms.
graalvm is literally 500x more overhead than a statically linked dash script.
Maybe not an issue for terminal UIs, but the article mentions both TUIs and CLI tools. A lot of people use CLI tools with a shell. As soon as you do `for file in *.c; do tool "$file"; done` (as a simple example), pure overhead on the order of even 10s of ms becomes noticeable. This is not theoretical. I recently had this trouble with python3, but I didn't want to rewrite all my f-strings into python2. So, it does arise in practice. (At least in the practice of some.)
Assuming JVM installation is not required (to which I agree, it shouldn't be), why would you care which language a CLI tool is written in? I mean, do you even know whether a given binary is implemented in Go, Rust, etc.? I don't see how it makes any meaningful difference from a user perspective.
> Pkl, which is at least built using Graal Native Image, but (IMO) would _still_ have better adoption if it was written in something else.
It makes a difference in size, in how arguments tend to be handled, and so forth.
As for why Pkl was in Java: it was originally built to configure apps written in Java, and heavily uses Truffle. Pkl is a name chosen for open sourcing, it had a different name internally to Apple before that which made the choices a little more obvious.
As a practical example for a Java-based CLI tool in the wild, here's kcctl, a command line client for Kafka Connect: https://github.com/kcctl/kcctl/. It's a native binary (via GraalVM), starting up in a few ms, so that it actually be invoked during tab completions and do a round-trip to the Kafka Connect REST API without any noticeable delay whatsoever.
Installation is via brew, so same experience as for all the other CLI tools you're using. The binary size is on the higher end (52 MB), but I don't think this makes any relevant difference for practical purposes. Build times with GraalVM are still not ideal (though getting better). Cross compilation is another sore point, I'm managing it via platform-specific GitHub Action runners. From a user perspective, non of this matters, I'd bet most users don't know that kcctl is written in Java.
I'm not sure I'd go so far as to claim it was definitely written by AI (after all, LLMs tend to write the way they do because it reflects their training material), but it does have a large number of suspicious constructions that suggest it could have been:
- "Look, I’m going to say something that might sound crazy...."
- But here’s the thing: there’s nothing stopping us...
- Emdashes. I don't believe that alone they are a tell for AI any more than they are a tell for the cultured, but in combination with other things, maybe.
To me it fundamentally does not make sense to publish texts generated by an LLM. These tools are available to everyone, so readers can just use the LLM directly. When I'm writing a blog post, it's to share my own perspective, ideas, experiences, and that's something which an LLM can't do.
That's not to say I don't use LLMs at all; I don't use them for original writing though, but rather as a copy editor, helping with improving expressions, getting language and grammar right, etc.
I have publicly documented my usage of AI for writing on my blog: https://www.morling.dev/ai/. I wished more folks would do that, as I think transparency is key here, every reader should always know whether they'rea reading a text written by a human or by a machine.
This approach can work for experienced speakers, in particular if you have spoken about the given topic before, but I'd strongly advise against not rehearsing for folks a bit newer into their speaking career. So often I have seen talks where folks either were time after half of their time slot, or they ran out of time towards the end. Or they lost track of the plot, went off on a tangent for way too long, etc.
All this is not great for the audience (who have "invested" into your session, by paying for the ticket, spending time away from work and family, not attending other concurrent sessions, etc.), and it can so easily be avoided by rehearsing.
The most common reason I have seen for folks skipping to rehearse is the awkward feeling you might have when speaking loud all by yourself. If that's the issue, it can help to do a dry run in front of colleagues. In any case, "winging it" is best reserved for later on, after having gathered quite a bit of speaking experience and having spoken about the same, or very similar, topics before.
I'd also recommend to avoid reading from slides during a talk as much as possible, it's also not a great experience for the audience. There shouldn't be much text on slides to begin with, as folks will either read that, or listen to what you say, but typically have a hard time doing both at once.
(All this is a general recommendation, not a comment on your talks which I have not seen)
After I finished my "industrial year" at university, we were all asked to give a short presentation on what we had done "in industry".
Returning to university after my industrial year, I took a very dim view of the academic environment and resented being asked to do this task that was worth no credit towards my degree.
So I didn't rehearse or even make any slides, I just stood up and talked about what I had been up to.
And although I was by any measure an extremely inexperienced speaker, it was the best talk I had ever given. It was the first time I stood in front of a room of people and felt present in the environment while giving my talk, rather than monotonously reciting the rehearsed material.
So obviously different people have different experiences, but I learnt that day that rehearsing your talk isn't always helpful.
It helped that I really enjoyed my industrial year and had loads of interesting stuff to talk about. So maybe the more important thing is to be interested in the topic.
I have to agree, if it's clear the talk is just someone mindlessly rambling about a topic, it leaves me feeling like my time isn't being valued and I don't know why I'm spending it listening to this person.
> This is why we have indexes in databases, which, if you squint a little, are just another kind of materialized view, at least in their covering form.
Reading through the README, this piqued my curiosity:
> Small or fast transactions may share the same WAL position.
I don't think that's true; each data change and each commit (whether explicit or not) has its own dedicated LSN.
> LSNs should be treated as monotonic but not dense.
That's not correct; commit LSNs are monotonically increasing, and within a transaction, event LSNs are monotonically increasing. I.e. the tuple commit-LSN/event-LSN is monotonically increasing, but not LSNs per se. You can run multiple concurrent transactions to observe this.
reply