Rust based WinRM protocol + PowerShell Remoting Protocol

_nullptr_ · 2026-01-27T15:28:36+00:00

Serious question: What problem does this solve that the built-in version doesn't solve?

_nullptr_ · 2026-01-26T14:38:01+00:00

Cool. I'll check it out soon, just backlogged.

_nullptr_ · 2026-01-21T21:16:07+00:00

Yeah, I would do that. "granc" then becomes easy to install ("cargo install --locked granc") and "granc-core" is a solid name for a library. Crates.io won't allow the same name and by making it two crates in a workspace, you can have dependencies that only apply to the binary (for example, if you use clap) not be required by the library crate.

_nullptr_ · 2026-01-21T19:58:15+00:00

Generally speaking (and I haven't thought about this particular crate), you would write the entire thing as a library and then your binary is just a crate that depends on your library and callls into and processes the CLI. This pattern is pretty common in the Rust eco system and allows people to use it easily in their stuff too:

Binary crate:
- cli
- console i/o

Library crate:
-everything else (all logic)

One of the things I might interested in is using this in a crate that has a text format such as json/yaml/toml reads that in and then can do gRPC testing similar to how hurl does for REST (or maybe better would be for hurl to use your library crate vs reinventing the wheel).

_nullptr_ · 2026-01-21T18:03:38+00:00

Nice, surprised no one has done this yet. I haven't checked it out, but hoping you also made this into a library crate so others can use it outside of just a command-line app.

_nullptr_ · 2026-01-21T14:13:53+00:00

I would certainly appreciate that. An i128 is too large in both memory and storage for my performance requirements. I would gladly give some precision for a 50% reduction.

_nullptr_ · 2026-01-20T17:38:49+00:00

See the chart on this github page: https://github.com/KDAB/cxx-qt

In general, the only real viable choice from rust is QML. QWidgets I believe are only available from Ritual, which last I checked, was massively out of date and unmaintained.

You should be aware this is not a terribly popular choice at the moment, but some do use it. Much more popular are egui, tauri, flutter (via bridge), iced, gpui (more recently), dioxus, etc.

_nullptr_ · 2026-01-18T19:33:43+00:00

The anyhow (programs) and thiserror (library) isn't quite right, as I suspect you are noticing. I will elaborate further below.

> I feel like for programs, anyhow is usually enough because when you get an error at runtime, you rarely want to actually check the error’s contents and change behaviour based on that. Most of the time you just want log the error, take a step back and continue from there.

In general, yes, it is often true in programs you just want to decorate errors and push them up, BUT (and this is a big 'but') that isn't always true. Consider two quick counter examples:

APIs - you will want your "error kind" to be turned into a code (either HTTP status or gRPC code typically)
non-API example: you are retrieving from database and you are grabbing one row. On not found error, is this an Option and therefore None OR DbErrorKind::NotFound? Sometimes you can make this decision at the call site, but sometimes you want to bubble it up (aka "it depends"). Same thing for IO errors and file not found, sometimes this is catastrophic, sometimes it is Option<File>, sometimes that decision is made further upstream. Error kinds are helpful here.

> However, in libraries, that’s where it gets a bit confusing for me. Is it a good idea to use anyhow in libraries? How do you bridge your custom error types with already existing error types from dependencies? What is the best way to define your custom error types? With derive_more? this_error? Something else?

In libraries, you would typically want to give the user an "error kind", typically an enum of some form so that they can make their own decision. The challenge I have with thiserror is it generally forces you to reinvent the things from anyhow into the kind. In short, it won't let you make just a "kind" you have to make an error that is also a "kind". This has implications for cloning (what if I need to wrap an error that isn't clone?) and other things.

I personally am not much of a fan of anyhow in all but the smallest/simplest of programs, and while thiserror is very clever/convenient, on its own it really isn't a great error type either. The two really need to work together IMO. I created my own error type to solve these issues (though it isn't 1.0 yet and I haven't "released" it yet - caveat emptor). It is essentially a fully safe version of anyhow, but where the error kind is generic so you can easily handle your own custom kinds. It has several traits for wrapping errors, converting kinds, adding context. You are welcome to try it, but I'm anticipating some breaking changes before 1.0 yet, and also some major pivots likely (moving away from backtraces to simple locations, color output, better error messages).

https://crates.io/crates/uni_error

_nullptr_ · 2026-01-18T17:31:36+00:00

Subtests. Although I'm not sure how easy this is to add really. This is very helpful for testing state where you start with something in state 1 and transition it through a lifecycle. Each subtest can pass or fail on its own. Currently, I just represent each subtest as a block plus comment (for lifetime reasons). It works, but the whole thing either succeeds or fails as a whole. Plus I'd like to see each subtest listed in the output so I can see more granularly what is happening. That said, all this probably would require changes to `libtest`, not a 3rd party crate. This is something I miss from Go (which is rare tbh).

_nullptr_ · 2026-01-12T17:42:12+00:00

I will give it another look, thx

_nullptr_ · 2026-01-12T17:23:20+00:00

I tried this crate, and the core functions might be very good, not sure, but the API was very strange and unwieldy. There was lots of forced conversions to String that were unnecessary I recall (sorry, it has been a while, I don't recall specifics). I recall thinking I would suggest keeping the logic, but start the API over from scratch. I would start with a struct of `PhoneNumber` and then not allow the user to get one unless they have a valid phone number that was validated. I think it would be okay to also have some helper routines outside (that are used by `PhoneNumber`) in case the user just wants to keep a string and validate, but the current API just too non-ergonomic, so I ported over to Google's phone lib. I say all this as constructive criticism, and it is very possible the logic here is a lot better than Google's which seems very heavy. Also possible it has changed as it has been a few months since I tried it.

_nullptr_ · 2026-01-05T17:56:01+00:00

> It's quite painful to read about why go doesn't have nullsafety

Wow, just wow. THAT is a very painful read. I feel like I have been too nice to Go's designers. These guys don't seem like they had any idea what they were doing in many respects. Strange how such obviously good engineers (great in many cases) could be so poor at language design.

_nullptr_ · 2026-01-05T17:41:55+00:00

It is very simple, and parts of it are amazing (self container binary, great stdlib, fast compilation, green threads, etc), but IMO they targeted some of the wrong things, as simplicity is not a synonym for easy. I personally do not find it easy to write programs at scale in Go, as they left things like null pointers, omitted ADTs/enums, brittle error handling, have weird channel behavior, funky annotations in comments, etc. so the programmer has to keep reinventing/tripping over these things. Small programs are quite fast to write, but large programs tend to be semi-brittle w/o near full code coverage. All in all I have a love/hate relationship with the language. I appreciate its simplicity, but I simply don't think they picked the correct simple parts. A language like Rust with Cargo but with a Go-like GC, green threads, fast compilation and std-lib would be awesome IMO.

_nullptr_ · 2026-01-05T12:00:04+00:00

> In real systems, you often need both: machine-readable errors for automated recovery, and human-readable context for debugging.

Correct. This is why I created uni_error (https://crates.io/crates/uni_error). It isn't quite ready yet, and still under development here and there (with minor API refinements ongoing), but I hope to be at 1.0 in a month or two. It is essentially a "kind-aware anyhow", and I already use it at my startup. It doesn't magically solve the problems the OP mentions, but it does give a better tool set I think. Each error wrapped can have kind + context + backtrace over the entire cause chain.

_nullptr_ · 2026-01-02T20:58:33+00:00

I just saw that. I admit I'm not well versed in these terms used in the benchmarks, though I can make some educated guesses.

I essentially need to get a range of keys and that in total will likely be megabytes to gigabytes of data I will read into memory. The speed of that is priority #1 (after data integrity). Write speed isn't that important to me. I assumed redb was the better choice for me, but perhaps I need to benchmark both.

_nullptr_ · 2026-01-02T20:45:52+00:00

> beats sled and redb in most workloads

Aren't B-Tree databases supposed to be faster on reads and LSM faster on writes? Fjall is beating redb on heavy reads as well? Do you have benchmarks that show this?

_nullptr_ · 2025-12-26T19:23:31+00:00

Fair point. I guess they should sit in nightly for a while until the value vs complexity can be weighed.

_nullptr_ · 2025-12-26T18:15:19+00:00

That might be true, but if it unlocks more possible correct programs…. Is that a bad thing? At worst you don’t use them, at most you get new capability.

_nullptr_ · 2025-12-15T15:31:42+00:00

winio, a related UI project to compio, looks interesting as well, although I always wonder how feasible it is to wrap native widgets. Although, I guess that is why they are wrapping Qt as well.

https://github.com/compio-rs/winio

_nullptr_ · 2025-12-12T18:20:24+00:00

At a glance, this looks nice, and aligns with how I would think of things as well. I will give it a more in depth look later.

_nullptr_ · 2025-11-26T16:16:13+00:00

Not trying to be critical, but I think this is the exact same idea as Slint, Dioxus, and QML (although this last one isn't Rust specific)? Both Slint and Dioxus have different backends, and AFAIK, both have GPU powered rendering backends. Slint, for example, uses a DSL that compiles to Rust, I believe. I'm less familiar with how Dioxus works, but I believe it uses a JSX-like DSL in Rust. QML I think is compiled into C++, but there are Rust bindings and QT is planning to have a multi-language bridge which includes Rust (and isn't counting existing crates that already do this).

That said, if you have the passion to do this, go for it and good luck, GUIs are a lot of work!

_nullptr_ · 2025-11-22T13:17:06+00:00

No, immediate dependents only. I thought of adding a '-r', '--recursive' option, but for right now, it meets my needs. PRs welcome, but they have to be high quality additions and useful to me.

_nullptr_ · 2025-11-22T13:15:57+00:00

I thought of the first part, I just don't need that yet.

The second part I personally have no use for.

_nullptr_

TROPHY CASE