5 ms·

One choice people sometimes have is the language to implement parsers in. Among other languages, I think Go is fantastic language for parsers. Great basic type

One choice people sometimes have is the language to implement parsers in. Among other languages, I think Go is fantastic language for parsers. Great basic types to work with, no need to typedef uint64 long long, easy to parallelize parsing logic and use up multiple cores. Race detector and other static analysis will help verify there's no easy to spot issues, and good code review for the rest. Built in testing facilities make it trivial to create tests anyone can run and reproduce. Finally, if you're still worried about a programmer error leading to a panic, can use recover at the top level to ensure that it would get caught. The HTTP server does that for user handlers, so that a panic in a user-written handler fails that single HTTP request, rather than taking down entire server. But need to do this in all goroutines that are at risk, not just the main one. I would feel so much more comfortable and confident implementing or reviewing code for parsers in Go than C/C++. Because Go is so short on features and highly explicit, it's just so much easier to read the code and be fully confident it does the right thing, and nothing else.

matthewaveryusa 10y ago
It's unfair to compare a 2017 re-write in Go vs. C++ that's festered for 20 years. If you want to do apples-to-apples Go vs. C++, first you'll need to compare it to well written C++11 (no need to crop C in this.) C++ without raw pointers and references is pretty safe, just like Go with the unsafe package can be, well, unsafe.
- shurcooL 10y ago
  I wasn't comparing with a 20-year-old existing C++. I was comparing how I felt about doing an implementation or code review of a parser in 2017 in both languages.
dom0 10y ago
> Among other languages, I think Go is fantastic language for parsers. While that may be true in a self-contained environment, a library simply can't drag an invasive runtime around: no one will use a format whose only implementation has that requirement (e.g. imagine libjpeg was written in Go - no one would bother with it). So for general purpose libraries, like these mentioned by GP, there are much fewer options. One can try to write safe C (ideally using analyzers and only a subset of C), but we know how that usually turns out. One can try to write safe C++, which can be easier, but usually kinda isn't [because a lot of code is older than five years; I'd wager most C++ code is much older than both Go and Rust]. At this point in this HN comment we pretty much narrowed it down to Rust or perhaps D.

matthewaveryusa 10y ago

It's unfair to compare a 2017 re-write in Go vs. C++ that's festered for 20 years. If you want to do apples-to-apples Go vs. C++, first you'll need to compare it to well written C++11 (no need to crop C in this.) C++ without raw pointers and references is pretty safe, just like Go with the unsafe package can be, well, unsafe.

shurcooL 10y ago
I wasn't comparing with a 20-year-old existing C++. I was comparing how I felt about doing an implementation or code review of a parser in 2017 in both languages.

dom0 10y ago

> Among other languages, I think Go is fantastic language for parsers. While that may be true in a self-contained environment, a library simply can't drag an invasive runtime around: no one will use a format whose only implementation has that requirement (e.g. imagine libjpeg was written in Go - no one would bother with it). So for general purpose libraries, like these mentioned by GP, there are much fewer options. One can try to write safe C (ideally using analyzers and only a subset of C), but we know how that usually turns out. One can try to write safe C++, which can be easier, but usually kinda isn't [because a lot of code is older than five years; I'd wager most C++ code is much older than both Go and Rust]. At this point in this HN comment we pretty much narrowed it down to Rust or perhaps D.