epage (u/epage) - Readit News

epage commented on Prek: A better, faster, drop-in pre-commit replacement, engineered in Rust github.com/j178/prek... · Posted by u/fortuitous-frog

fishgoesblub · 11 days ago

Am I alone in that I never have had an issue with performance with pre-commit? granted I don't work on projects the size of the Linux kernel, but I haven't had any complaints.

epage · 11 days ago

For me the issue isn't performance but bad hook updating logic. They expect hooks to be managed in isolated repos with exclusive use of tags. I have my gh action and hook in the repo of my program and it has been a source of pain to users but I'd rather drop pre-commit support than have to deal with update across repos. prek fixed this.

epage commented on Workspaces and Monorepos in Package Managers nesbitt.io/2026/01/18/wor... · Posted by u/Couto

epage · 22 days ago

In Rust, we use workspaces for

- splitting up a package into smaller compilation units to speed up builds as llvm doesn't like large compilation units, e.g. I'm assuming this is why uv is split up

- splitting semver concerns (easiest if different parts of the api are versioned independently), e.g. one hope for splitting out `serde_core` is to allow breaking changes of `serde_derive`

- splitting out optional parts to improve build time (`features` can also be used but usability isn't as great), e.g. `clap` (cli parser) and `clap_complete` (completion support)

- local development tools, e.g. https://github.com/matklad/cargo-xtask

- less commonly run tests or benches that have expensive dependencies, e.g. `toml` splits out a benchmark package for comparing performance of `toml`, `toml_edit`, an old version of `toml`, and `serde_json`

- proc-macros generally have a regular library they generate code against

- lower development overhead to develop them together, e.g. anstyle has a lot of related packages and I wouldn't be wanting to maintain a repo per package

Packages also let you mix a library with bins and examples. We talked about multi-purpose packages vs libraries at https://blog.rust-lang.org/inside-rust/2024/02/13/this-devel... (this was before workspace publishing was supported).

Something this doesn't mention is that Cargo workspaces allow for sharing parts of the manifest through "workspace inheritance", including package metadata like the repo, dependency version requirements, lint configuration, or compilation profiles.

epage commented on Nested code fences in Markdown susam.net/nested-code-fen... · Posted by u/todsacerdoti

epage · 24 days ago

> In fact, a code fence need not consist of exactly three backticks or tildes. Any number of backticks or tildes is allowed, as long as that number is at least three

Unfortunately, some markdown implementations don't handle this well. We were looking at using code-fence like syntax in Rust and we were worried about people knowing how to embed it in markdown code fences but bad implementations was the ultimate deal breaker. We switched to `---` instead, making basic cases look like yaml stream separators which are used for frontmatter.

epage commented on Improving the performance of WAT parser blog.gplane.win/posts/imp... · Posted by u/gplane

epage · 25 days ago

> Use hand-written parser > > The old parser was written with winnow which is a parser combinator library. While it’s easy to create a parser with parser combinators, it’s generally slower than a hand-written parser, so the first step is to write the parser by hands. Hand-written parser is not only faster but also allows to do more optimizations in the future.

Maintainer of Winnow here. I wish there were more details on this. I switched `toml` / `toml_edit` to being hand written and got some performance boost but I feel like the other things listed would have dwarfed the gains that I got. I wonder if there were sub optimal patterns they employeed that we could find ways to help better guide people.

For anyone going on about "hand written is always better", I disagree. Parser combinators offer a great way to map things back to grammar definitions which makes them much easier to maintainer. Only in extreme circumstances of features and/or performance does it seem worth going hand-written to me.

epage commented on CLI's completion should know what options you've typed hackers.pub/@hongminhee/2... · Posted by u/dahlia

tiltowait · a month ago

fish is a bit insonsistent on it. For instance, `git add <tab>` will only autocomplete for modified files. It will also fill in wildcards, e.g. `cat *.txt <tab>` will expand to show all .txt files. On the failure side, `rm foo <tab>` will still show `foo` as an option.

IME, zsh has better autocompletion (which, at the time at least, was a separate install).

epage · a month ago

There are a couple differen things going on

- completions being aware of the subcommand

- dynamic look ups for specific values

- completions being aware of previous options, flags, and values

A lot of completions have the first. Some have the second. The last is rare. The completer needs knowledge of when flags, options, and value can be repeated and change which future options and values are suggested.

epage commented on NPM to implement staged publishing after turbulent shift off classic tokens socket.dev/blog/npm-to-im... · Posted by u/feross

woodruffw · a month ago

> In its current form, however, trusted publishing applies to a limited set of use cases. Support is restricted to a small number of CI providers, it cannot be used for the first publish of a new package, and it does not yet offer enforcement mechanisms such as mandatory 2FA at publish time. Those constraints have led maintainer groups to caution against treating trusted publishing as a universal upgrade, particularly for high-impact or critical packages.

This isn't strictly accurate: when we designed Trusted Publishing for PyPI, we designed it to be generic across OIDC IdPs (typically CI providers), and explicitly included an accommodation for creating new projects via Trusted Publishing (we called it "pending" publishers[1]). The latter is something that not all subsequent adopters of the Trusted Publishing technique have adopted, which is IMO both unfortunate and understandable (since it's a complication over the data model/assumptions around package existence).

I think a lot of the pains here are self-inflicted on GitHub's part here: deciding to remove normal API credentials entirely strikes me as extremely aggressive, and is completely unrelated to implementing Trusted Publishing. Combining the two together in the same campaign has made things unnecessarily confusing for users and integrators, it seems.

[1]: https://docs.pypi.org/trusted-publishers/creating-a-project-...

epage · a month ago

As I'm not familiar with the npm ecosystem so maybe I'm misunderstanding this but it sounds like they removed support for local publishes (via a token) in favor of CI publishing using Trusted Publishing.

If that is correct, I thought this was discussed when Trusted Publishing was proposed for Rust that it was not meant to replace local publishing, only harden CI publishing.

epage commented on The C3 Programming Language c3-lang.org... · Posted by u/y1n0

gkbrk · a month ago

This feels very natural though, in a "principle of least surprise" kinda way. This is what you'd expect a properly designed switch statement to do.

epage · a month ago

It reads naturally but I can see people getting tripped up writing this. Worse for changing existing code. Refactor in a way that removes a body? Likely forget to add a breake

epage commented on The C3 Programming Language c3-lang.org... · Posted by u/y1n0

epage · a month ago

I think the switch statement design is a foot gun: defaults to fall-through when empty and break when there is a body.

https://c3-lang.org/language-overview/examples/#enum-and-swi...

epage commented on Rust errors without dependencies vincents.dev/blog/rust-er... · Posted by u/vsgherzi

IshKebab · 2 months ago

> Struct variant fields are public, limiting how you evolve the fields and types

But the whole point of thiserror style errors is to make the errors part of your public API. This is no different to having a normal struct (not error related) as part of your public API is it?

> Struct variants need non_exhaustive

Can't you just add that tag? I dunno, I've never actually used thiserror.

Your third point makes sense though.

epage · a month ago

> > Struct variant fields are public, limiting how you evolve the fields and types

> But the whole point of thiserror style errors is to make the errors part of your public API. This is no different to having a normal struct (not error related) as part of your public API is it?

Likely you should use private fields with public accessors so you can evolve it.

epage commented on Rust errors without dependencies vincents.dev/blog/rust-er... · Posted by u/vsgherzi

IshKebab · 2 months ago

Why is it an extensibility hazard (assuming you mark the `pub enum Error` as non-exhaustive)?

I mean I don't see the difference between having the non-exhaustive enum at the top level vs in a subordinate 'kind'.

epage · 2 months ago

Take the example at https://docs.rs/thiserror/latest/thiserror/

- Struct variant fields are public, limiting how you evolve the fields and types

- Struct variants need non_exhaustive

- It shows using `from` on an error. What happens if you want to include more context? Or change your impl which can change the source error type

None of this is syntactically unique to errors. This becomes people's first thought of what to do and libraries like thiserror make it easy and showcase it in their docs.