symbolicator
nilaway
symbolicator | nilaway | |
---|---|---|
6 | 3 | |
341 | 2,787 | |
1.5% | 4.9% | |
9.3 | 8.7 | |
4 days ago | 3 days ago | |
Rust | Go | |
MIT License | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
symbolicator
-
Practical nil panic detection for Go
- it entirely removes a class of discussion of "opinion" on style. Tabs or spaces? Import ordering? Alignment? Doesn't matter, use go fmt. It's built into the toolchain, everyone has it. Might it be slightly more optimal to do X? Sure, but there's no discussion here.
- it hits that sweet spot between python and C - compilation is wicked fast, little to no app startup time, and runtime is closer to C than it is to python.
- interfaces are great and allow for extensions of library types.
- it's readable, not overly terse. Compared to rust, e.g. [0], anyone who has any programming experience can probably figure out most of the syntax.
We've got a few internal services and things in Go,vanr we use them for onboarding. Most of my team have had PR's merged with bugfixes on their first day of work, even with no previous go experience. It lets us care about business logic from the get go.
[0] https://github.com/getsentry/symbolicator/blob/master/crates...
-
This isn’t the way to speed up Rust compile times
> Aren't they slower or about as slow as C++, which is notorious for being frustratingly slow, especially for local, non-distributed builds?
Yes. Significantly slower. The last rust crate I pulled [0] took as long to build as the unreal engine project I work on.
[0] https://github.com/getsentry/symbolicator/
-
Launch HN: Highlight.io (YC W23) – Open-source, full stack web app monitoring
2022: https://blog.sentry.io/we-just-gave-260-028-dollars-to-open-...
In addition to that, there are contributions to open source done in the form of code that is, open source, such as the symbolication service: https://github.com/getsentry/symbolicator and many others: https://github.com/getsentry/
- Introduction to Sentry Symbolicator
-
Seed – A Rust front-end framework for creating fast and reliable web apps
Digging up the topic, I also found that new framework https://github.com/tokio-rs/axum, which already seems to be popular.
Sentry is rewriting some of their libs from Actix to Axum: https://github.com/getsentry/symbolicator/commit/b6ef7cb00b7...
-
What’s up with these new not-open source licenses?
Disclosure: I work at Sentry.
> My personal term for this sort of "We're OK with little people using the software but we don't want any competition"
Large companies are free to use Sentry. There are Fortune 50 companies running Sentry at scale internally without paying us a cent. That's totally cool.
You're also free to compete with Sentry. You're not free to repackage Sentry for the purposes of competing us. There are lots of competing error and performance monitoring products out there that do perfectly fine without it.
I should also note that many components of Sentry are distributed with OSI-approved licenses that you are free to use to compete with us. For example, our Symbolication service (https://github.com/getsentry/symbolicator) ships with an MIT license, and it's an important part of our business.
nilaway
-
Go: What We Got Right, What We Got Wrong
I would have more respect if they at least admitted to the flawed type system but instead say it is not a problem. It is disappointing to see past mistakes repeated in a new programming language. Even the Java language creator was humble enough to admit fault for the null pointer problem. The Go devs do not have such humility.
https://github.com/uber-go/nilaway
-
Practical nil panic detection for Go
We'd be interested in the general characteristics of the most common ones you are seeing. If you have a chance to file a couple issues (and haven't done so yet): https://github.com/uber-go/nilaway/issues
We definitely have gotten some useful reports there already since the blog post!
We are aware of a number of sources of false positives and actively trying to drive them down (prioritizing the patterns that are common in our codebase, but very much interested in making the tool useful to others too!).
Some sources of false positives are fundamental (any non-trivial type system will forbid some programs which are otherwise safe in ways that can't be proven statically), others need complex in-development features for the tool to understand (e.g. contacts, such as "foo(...) returns nil iff its third argument is nil"), and some are just a matter of adding a library model or similar small change and we just haven't run into it ourselves.
What are some alternatives?
pgbouncer-fast-switchover - Adds query routing and rewriting extensions to pgbouncer
reviewdog - 🐶 Automated code review tool integrated with any code analysis tools regardless of programming language
rust-rdom - 🍂 A Rust-based simulated DOM (browser-independent replacement for web_sys)
syft - CLI tool and library for generating a Software Bill of Materials from container images and filesystems
sycamore - A library for creating reactive web apps in Rust and WebAssembly
go - The Go programming language
pinwheel - Pinwheel is a library for writing web user interfaces with Rust.
grype - A vulnerability scanner for container images and filesystems
dropshot - expose REST APIs from a Rust program
tfsec - Security scanner for your Terraform code
sauron - A versatile web framework and library for building client-side and server-side web applications
clair - Vulnerability Static Analysis for Containers