daakus

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.

Shameless plug: A brutally minimalist Linux only, whisper.cpp only app: https://github.com/daaku/whispy

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.

I used the prompt included in llama.cpp and it worked for me in English (for fun GK type questions):

MODEL=./models/mistral-7b-v0.1.Q5_K_M.gguf N_THREAD=16 ./examples/chat-13B.sh

I used mistral-7b-v0.1.Q5_K_M.gguf and it responded to basic questions.

It can! TheBloke is to thank for the incredibly quick turnaround.

https://github.com/ggerganov/llama.cpp/pull/3362

https://huggingface.co/TheBloke/Mistral-7B-v0.1-GGUF/tree/ma...

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.

Thanks!

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).

Thanks for the feedback. I'll add some notes comparing it with other attempts like you suggested.

Correct and fair. Updated the code to remove the safety issue.

The bytes are assumed to be utf8 (I was using the safer `from_utf8` prior to confirming the data was utf8).

I brought in `twoway` when I couldn't find a way to `rfind` using `aho-corasick`. I'll switch the use over for consistency.

Thanks for the quick code review!

PS: Thanks for ripgrep too!

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.

[1] https://gist.github.com/daaku/58557e2545612df8f40b13b66b7d3b...

If the default is set to something else, say DuckDuckGo, it'll go there instead right?

Would be great to understand what communication with Google servers can be turned off via setting changes rather than code changes, and what cannot.

Anyone have experience with making this work? I tried starting it on the server I have WireGuard running on and it fails to start because it also wants to bind to the UDP port WireGuard uses (even in server mode).

Additionally http://www.cs.columbia.edu/~lennox/udptunnel/ has a note saying:

UDPTunnel is designed to tunnel RTP-style traffic, in which applications send and receive UDP packets to and from the same port (or pair of ports). It does not support request/response-style traffic, in which a client request is sent from a transient port X to a well-known port Y, and the server's response is returned from port Y to port X.

Which from what I understand is exactly what WireGuard does.

One aspect is that upgrading Go only requires upgrading it on the build infrastructure rather than a deployment of a new JVM. The "next build" will simply be a binary built with a new compiler version.

GitHub pages + Cloudflare.

Largely it just means that it uses the `LISTEN_FDS` environment variable and passes the sockets down starting at fd=3 (more here: https://github.com/facebookgo/grace/blob/master/gracenet/net...). Admittedly our systemd use case is no more and I haven't tested with it recently so I want to clarify I should probably re-test and make sure it still works.

It doesn't find dependencies like /etc/ssl/certs/ca-certificates.crt or /usr/share/zoneinfo.

What does "via Ruby" mean here? Title should probably not include that.

fwiw, i had a similar experience as well. i tried prgmr too, and linode was just much better and more consistent than all the others.

You can get an extra IP for $1/month to solve the SSL problem (or alternatively look at something like Cloudflare).

I built something similar which additionally provides graceful termination of established connections as well as systemd socket activation to (optionally) provide lazy startup of servers: https://github.com/daaku/go.grace

I hope this doesn't kill the current best UX that hides the junk in this industry.

I haven't looked at Rust, but the semi colon looks like a decision to make some common verbose or "ugly" syntax to be less noisy. Admittedly most syntax has quirks, and this seems more like a quirk rather than an instance of "clever design". Ignoring the explanation of the differences between statements and expressions, the rest of the discussion is about the presence of a semicolon.

I'm the Facebooker maintaining this tool. We use it internally and externally and it represents a "platform application". It runs on a separate domain (www.fbrell.com) and is iframed on the linked page on facebook.com.

It's all open source actually: https://github.com/daaku/rell.

Even better, it's written in Go :)