A quick check with release build on macOS shows the component demo has a non-zero energy impact in the background (per activity monitor), but the input example has zero energy impact while in the background. This is already better than many new from-scratch UI libraries. The foreground impact is harder to measure.
It relies on `pw-record` for recording audio and `ydotool` for triggering keyboard input. These are Linux specific. I don't know about Windows, but on my Mac I have a not-yet-public Swift + whisper + CoreAudio + Accessibility based solution that provides similar functionality.
Just for fun. I like both languages. I thought Rust would be better fit on account of interop with whisper.cpp, but turns out the use of cgo was straight forward in this case. I like that the Go version has minimal 3rd party dependencies compared to the Rust version.
I wanted speech-to-text in arbitrary applications on my Linux laptop, and I realized that loading the model was one of the slowest parts. So a daemon process, which triggers recording on/off using SIGUSR2, records using `pw-record` and passes the data to a loaded whisper model, which finally types the text using `ydotool` turned out to be a relatively simple application to build. ~200 lines in Go, or ~150 in Rust (check history for Rust version).
Mostly using Wipr 2. Brave works very well but Safari seemed maybe slightly snappier (I know the browser engine is the same). Tried this but seems like it blocked less than Wipr 2 in a quick spot check.
Ah, I remember seeing this a long time ago. It seemed like something CL fans would enjoy, but to me it felt verbose. I guess this is my Clojure preference showing.
Regarding runtime macro-expansion - since Dak is written in JavaScript, it comes for free.
Nice! My goal in Dak is to reach a point where macros can allow transforming hiccup like syntax to hyperapp or React like function calls, or original hiccup style optimized string concat, or lit-html style template string generation. I know I could use all these for different use cases.
My fear taking this path is around performance. I've not done any profiling yet, and I'm hoping I don't regret taking this path when I get around to it.
I'm a huge fan of Clojure and have had a lot of fun building things with it. CLJS on the other hand has felt heavy to me, from a browser performance and dev tooling perspective. Clojure startup time always affected me more so with CLJS projects. I hope these two projects alter the landscape for the better!
Besides those aspects, Dak is different than these two specifically in that it tries to provide something closer to a minimal 1-to-1 language feature mapping to JavaScript as the base, with a goal of having essentially no runtime.
The clean room implementation has downsides - Squint and Cherry can reuse Clojure tooling like clj-kondo etc, which Dak cannot. On the other hand Dak is small, the transpiler is under 2k lines as I write this. It can run on virtually any modern JavaScript runtime (all browsers, node, deno, bun etc).
Safety for me is confidence to use the thing. For me in my own code, but also others on my team that may work on this code.
I mostly have experience building things in GC languages. But with Rust I managed to safely use [1]:
- stack references in threads
- kept mmap references alive until threads finish work
- zero copy xml parsing (from mmaped data!)
- SSE/AVX enabled searching
The Rust language empowered me to do these things with a high degree of confidence. Not one segfault or core dump, just lots of compiler errors.
I played with Zig. Admittedly, the small ecosystem aspect is something all languages go thru, and it would be a better experience with a Zig specific libraries. But Zig doesn't empower library authors to make a large category of bugs impossible, and leaves it to documentation. This is like C, I don't have enough confidence in myself to use it.
Brilliant people are building powerful, safe-ish, reusable libraries in Rust. For mere mortals like me, this is Awesome.