configs VS relay

I was a long time pre-commit fan, just converted to https://trunk.io/ though

Trunk | https://trunk.io | Sr Full Stack / Sr C++ | Full-Time | Remote / Hybrid, SF

Trunk is an a16z funded dev tools startup, redefining software development at scale. We've built three products so far and have plans for more:

* Trunk Check: a universal linter/formatter, available as a CLI, VSCode extension, and CI check;

Trunk is also a command line tool, so you can run all these checks on CI, with the same versions of tools you use locally

Tests are a good way to assert an invariant that you expect of your codebase, but as with all things, resolving the error can get a bit tricky/frustrating.

The canonical example in my mind is any kind of autofix-able linter, where there's some kind of patch (or more nuanced autofix) that the linter can generate on-the-spot for you. With a sh_test construct (or any other unit test), you generally find yourself printing out some command that the user can run to fix things, which in a sufficiently large codebase can get really frustrating.

(My company - https://trunk.io - is actually building a universal linter as part of our product offering, and we already have a system to write custom linters with varying levels of sophistication that can plug into both your IDE and CI system.)

It's probable the core will always remain closed. That's both a business and practical decision. However, much like how Sentry have some of their services open-source, we may follow that route.

There's rust stuff too: https://github.com/getsentry/relay

Sentry uses Rust in their backend, check out relay.

Sentry (sentry.io) | senior software engineer, Rust | Vienna, Austria OR Remote (EU) | https://sentry.io/careers/4635809/

As a Senior Software Engineer on our client infrastructure team, you'll join a cross-functional group of Software Engineers that is responsible for the client-facing operation of Sentry. This includes building and maintaining our event ingestion and processing pipeline, most notably Relay (https://github.com/getsentry/relay). This means you will be involved in the design and evolution of both external and internal services, as well as create new mission-critical software at Sentry.

If you like system programming, know Rust (or another systems programming language) and want to work on mission-critical high-volume services, this is the role for you. And your contributions are open source!

Apply here: https://sentry.io/careers/4635809/

Try https://docs.sentry.io/product/relay/

We have no Nim usage in the company. One of our engineers nominated it as something they find personally interesting, and we wanted to give at least a little bit to every project that our employees nominated.

By contrast, we use Rust quite heavily, including our core ingest component: https://github.com/getsentry/relay.

That's why there's such a discrepancy in this case.