symbolicator VS rust-dominator

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

> 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/

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/

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

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.

They are both async and made for GUI -- in case of rust-signals WebGUI, provided by dominator and MoonZoon.

You shouldn’t ever need to deal with OsString itself on wasm32-unknown-unknown, since that target basically just doesn’t cover functionality that needs it, but the actual situation is genuinely worse than OsString: Rust insists on valid Unicode (as is right and proper), but the web suffers from the affliction of ill-formed UTF-16. If you blindly convert from JavaScript strings to Rust strings, you will encounter data and functionality loss in a few situations, in practice always involving IME (or similar) text entry on Windows. The first bug I filed about this: https://github.com/Pauan/rust-dominator/issues/10, and you can follow further links if you’re interested. IE and Edge used to be largely immune to this, but IE is dead and I suppose Edge will have regressed in this way with the Chromium migration, since the bug filed in Chromium a few years ago <https://bugs.chromium.org/p/chromium/issues/detail?id=949056> has languished. (Firefox too, with <https://bugzilla.mozilla.org/show_bug.cgi?id=1541349>.) In the worst-case scenario, careless use like was the case in rust-dominator will mean that some users typing with particular software in a language that’s outside the Basic Multilingual Plane will not be able to type anything.

One comparison I'm missing , which I think provides quite a nice solution in Rust, is the signals based approach popularized by Solid JS and implemented in Rust by sycamore and earlier by dominator.

Missing support for characters beyond U+FFFF is the main problem caused by surrogates (their existence, even if indirect)—it normally comes of some kind of UCS-2/UTF-16 confusion. It’s not fair to disqualify them. The only (class of) case that I’m aware of for a long time where it’s not linked to that is with MySQL’s idiotic utf8 → utf8mb3 type.

You may not have encountered such bugs, but I’m very familiar with surrogate-related bugs, because I use a Compose key extensively. I haven’t been using Windows for the last year, but from time to time I would definitely encounter bugs that are certainly due to surrogates. On the web, I found bugs a few times, all but once in Rust WebAssembly things, such as https://github.com/Pauan/rust-dominator/issues/10. And even now I’m back on Linux, I know of one almost certainly surrogate-related bug: I can’t type astral plane characters in Zoom at all; pretty sure I had this problem back on Windows, too. Copy and paste, sure, but type, no, they become REPLACEMENT CHARACTER.

The history is unfortunate but I strongly refute that they had not much choice. UCS-2 should have been abandoned as a failed experiment. Certainly there had been significant investment into it in the last few years, but with the benefit of hindsight, switching to UTF-8 (which was invented before they decided on surrogates) would have made everyone’s life much easier, especially given its ASCII-compatibility.

Ah, BOM characters. Haven’t seen one in years. Good riddance.

I really don't understand why everyone jumps to Yew when it comes to front-end development. Dominator is a far cleaner and more Rust-orientated approach to building front-end apps. I have worked with both and I feel that Yew adds a lot complexity/forces a lot of design philosophies but gives very little back in terms of advantages.

Hi, I've just released a major new version of Silkenweb. It's a signals based web framework like Dominator or Sycamore, but with the emphasis on plain rust syntax rather than a macro DSL.

Check out the alternatives without vdom, especially Dominator https://github.com/Pauan/rust-dominator. It’s faster than nearly all JS frameworks. The underlying rust-signals it’s based on is a fantastic crate. Unfortunately it’s not very well documented (check the prs for some wip docs). I got a frontend up and going with reactivity and nice styles using trunk and tailwindcss with daisyUI very quickly.

- https://github.com/Pauan/rust-dominator

How does this compare to dominator?