ntp-parser VS rust

Well nom does list out examples on the readme page, though many are probably for older versions of nom. I clicked through a couple and it looks like ntp is up to date with nom 6.0. The last full parser I wrote using nom was in v4.0 days, which was more macro-oriented than current nom. Since what you pass nom is slices of data, you will basically be reading from a file into a buffer, and calling your parsing functions on that. If it returns an error indicating it is incomplete, just read in another chunk of data into your buffer and try again.

Visitors additionally allow you to decouple graph traversal from the processing. It is still needed even in the languages with pattern matching.

There's also the question of exhaustiveness checking. With visitors, you can typically opt-in to either checking that you handle everything. Or use the default no-ops for anything that you're not interested in.

So if you look at compilers for languages with pattern matching (e.g. Rust), you still see... visitors! E.g.: https://github.com/rust-lang/rust/blob/64a99db105f45ea330473...

“Once Rust clicks, it’s like wearing a seatbelt that makes you faster.” Rust user on GitHub

This year also marked my first contribution to the Rust programming language. While the PR is still awaiting merging due to holiday delays, it was a milestone in my journey with Rust. The experience taught me about the rigor and community involvement required in contributing to such a widely used language.

IIRC C++ and Rust don't technically prohibit throwing exceptions out of destructors; it's triggering unwinding during unwinding that's the main problem.

Does make me wonder about the specifics behind that. I had assumed that there are some kind of soundness issues that force that particular approach (e.g., https://github.com/rust-lang/rust/pull/110975, "Any panics while the panic hook is executing will force an immediate abort. This is necessary to avoid potential deadlocks like rustc hangs after ICEing due to memory limit #110771 where a panic happens while holding the backtrace lock."; alternatively, some other kind of soundness issue?), but I don't have the knowledge to say whether this is a fundamental limitation or "just" an implementation quirk that basically got standardized. Rust' first public release was after Java 7, so in principle the precedent was there, for what it's worth.

To drive the point home: https://github.com/rust-lang/rust/pulls?q=is%3Apr+author%3Aj...

SurrealDB is admittedly a pretty shiny database. It's built in Rust, a programming language that has just barely hit the 10-year mark since it hit version 1.0. A good deal of attention is paid to the website and brand design, and the official Surrealist app is not only slick but even capable of visualizing data as an interconnected net of records.

Agreed, I really like Zig's explicit allocation (and to be fair, lots of people from Rust like it too[0], it's just such an insane lift that who knows when it will stabilize)

The new "managed" async strategy (I was previously mistaken thinking it was the same as sans-io) is also really intriguing IMO, and feels like a fantastic balance (people in Rust are doing this too, but for the unrelated reason of trying to support various async runtimes).

[0]: https://github.com/rust-lang/rust/issues/32838

Certainly compiler developers are only human, and many of them write C++ so they're humans working with a terrible programming language, I wouldn't sign up for that either (I have written small contributions to compilers, but not in C++). I still don't see "any excuses". I see more usual human laziness and incompetence, LLVM for example IMNSHO doesn't work hard enough to ensure their IR has coherent semantics and to deliver on those semantics.

The compiler bug I'm most closely following, and which I suspect you have your eye on too is: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119472 aka https://github.com/rust-lang/rust/issues/107975 https://github.com/llvm/llvm-project/issues/45725

But it seems like it's just that everybody fucked this up in similar ways, that's two different major compiler backends! I wouldn't be surprised if Microsoft (whose code we can't see) find that they don't get this quite right either.

> Is Go in mostly safer than C++? Maybe

Maybe? You forgot /s there? Asking if Go is mostly safer than C++ is like asking if child proof caps are mostly safer than mason jars for medicine.

> https://www.ralfj.de/blog/2025/07/24/memory-safety.html

Can you show RCE using this? Because, to this day, no one has been able to show me a reasonable program that someone would write and that would result in RCE from "Go memory unsafety" presented in this article. Meanwhile, I can show you thousands of examples and CVEs of how you can easily get RCE using C++.

> Can you prove Rust code is safe? Well there is the simple way - no unsafe. But what about unsafe blocks? Yes, you can prove it for them as well. If the unsafe code block is it will note safety invariants and why are they preserved by unsafe block. Can this be practically done? Depends on the crate, but with enough effort, yes.

You can’t prove Rust code "safe" in the absolute. Safety guarantees apply to safe Rust under the language’s (still evolving) rules, and even then the compiler/backend must uphold them. We still hit unsoundness[1] and miscompiles in safe code (equal pointers comparing unequal... [2]), and the official unsafe code guidelines are not a finalized spec. So documenting invariants in unsafe helps a lot, but it’s not a formal proof, especially across crates and compiler versions.

1. https://github.com/rust-lang/rust/issues/107975

2. https://github.com/rust-lang/rust/labels/I-unsound

On the safety spectrum: C/C++ -> Zig -> Go -> Rust