4 ms·
This only works for simple algorithms that don't touch the system. As soon as you try to bind something that handles a file on disk, a socket, a thread, it's wi
by giovannibajo1 10y ago
This only works for simple algorithms that don't touch the system. As soon as you try to bind something that handles a file on disk, a socket, a thread, it's wishful thinking anyway, as any language have different ways and paradigms to approach threading, asynchronous I/O, signals and other runtime-level issues, and getting code from a different language / library / paradigm is probably not going to fly, or even introduce subtle bugs.
For instance, if I bind a Rust library that opens a file on disk and use it from Go, I lose all the benefits of the Go runtime like the fact that the FD is not inherited by sub processes (as Go always uses O_CLOEXEC, while glibc doesn't), or the fact that blocking calls never return EINTR to application code in case of signals (the Go runtime handles this for the application).
So you might think that the library works, while its subtly violating your language's runtime conventions in a way that might cause hard to debug bugs in production.
One of the benefit of writing code in single "modern" language/runtime is that you don't have to worry about these hairy issues.
- pcwalton 10y agoNote that the Rust standard library also sets O_CLOEXEC. https://github.com/rust-lang/rust/pull/24034 https://github.com/rust-lang/rust/pull/24034
- burntsushi 10y agoIt feels like you're throwing the baby out with the bath water, and I don't think a good regex library could be classified as "simple." I specifically wrote Go bindings to Rust's regex lib in tandem with the C API to make sure I wasn't baking any assumptions into the C API that would make it difficult for another language to bind to them. This process was lucrative. My first draft of the C API defined an iterator that held on to a pointer to the text being searched for the lifetime of the iterator. It turns out that this is inconvenient to use from a language like Go (or perhaps, any language with a moving GC) because C holding on to pointers to memory allocated in the host language can be bad juju. Because I did this process in tandem, I was able to correct the issue at the C API level. As a result, if you need fast regexes in Go, you now have an option, and that option is built on a reasonably mature regex library with thousands of tests and a benchmark harness that sports PCRE1, PCRE2, Tcl, RE2 and Oniguruma, of which, Rust's regex engine compares quite favorably.
- giovannibajo1 10y agoMy comment wasn't meant to disrespect your work, or make it look like a simple task to achieve. The GP comment said that Rust is nice because you can write libraries that can be bound to other languages with more runtime. I was highlighting that this property sounds nice in theory, but has a small scope of applicability in practice. A regex library fits the small scope.
- burntsushi 10y ago> but has a small scope of applicability in practice I disagree. It's a critical tool for adopting Rust libraries in projects that are otherwise C or C++ or Python or Go or Java or ..., for example. The scope is pretty vast.